RTSP协议分析-2

jonry

3 协议参数
3.1 RTSP版本
同[H3.1]定义，仅用RTSP代替HTTP即可。
如下：
     RTSP采用主从（.）数字形式来表示版本。协议的版本政策倾向于让发
送方表明其消息的格式及功能，而不仅仅为了获得通讯的特性，这样做的目的是为了与更高
版本的RTSP实现通讯。只增加扩展域的值或增加了不影响通讯行为的消息组件都不会导致
版本数据的变化。当协议消息的主要解析算法没变，而消息语法及发送方的隐含功能增加了，
将会导致从版本号（）增加；当协议中消息的格式变化了，主版本号（）也
将发生改变。
     RTSP消息的版本由消息第一行中的RTSP版本域来表示。
RTSP-Version            = "RTSP" "/" 1*DIGIT "." 1*DIGIT
注意，主从版本应当被看作单独的整数，因为它们都有可能增加，从而超过一位整
数。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。
版本号前面的0将被接收方忽略，而在发送方处也不应产生。
           
本文档定义了RTSP协议的1.0版本。发送本规范定义的请求（Request）或回应（Response）消息的应用必须指明RTSP的版本为“RTSP/1.0”。使用该版本号意味着发送消息的应用至少有条件的遵循本规范。
应用的RTSP版本即为应用至少能有条件遵循的RTSP版本中的最高版本。
     当代理及网关收到与其自身版本不同的RTSP请求时，必须小心处理请求的推送，因为
协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。如果收到高版本的
请求，代理或网关必须降低该请求的版本，并回应一个错误。而低版本的请求也应在被推送
前升级。代理或网关回应请求时必须和请求的版本相同。
3.2 RTSP URL
“rtsp”和“rtspu”表示要通过RTSP协议来定位网络资源。本节详细定义了RTSP URL的语法和语义。
rtsp_URL =  ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host   =  
port   =  *DIGIT
abs_path 在 [H3.2.1]中定义如下：
    abs_path     = "/" rel_path
    rel_path     = [ path ] [ ";" params ] [ "?" query ]
    path       = fsegment *( "/" segment )
    fsegment     = 1*pchar
    segment     = *pchar
          params       = param *( ";" param )
         param       = *( pchar | "/" )
          scheme       = 1*( ALPHA | DIGIT | "+" | "-" | "." )
          net_loc     = *( pchar | ";" | "?" )
          query       = *( uchar | reserved )
          fragment     = *( uchar | reserved )
        pchar       = uchar | ":" | "@" | "&" | "=" | "+"
          uchar       = unreserved | escape
          unreserved   = ALPHA | DIGIT | safe | extra | national
        escape       = "%" HEX HEX
          reserved     = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
        extra       = "!" | "*" | "'" | "(" | ")" | ","
          safe       = "$" | "-" | "_" | "."
        unsafe       = CTL | SP |  | "#" | "%" | ""
        national     =
           权威的URL语法及语义信息请参见RFC1738[4]和RFC1808[9]。
[注意]：段(fragment)和询问(query)标识符在这时没有明确的定义，需要到RTSP服务器上解释。
rtsp要求使用可靠协议（Internet的TCP协议）发出命令，而rtspu则使用不可靠协议（Internet的UDP协议）。
如是端口为空或没指定，则缺省为80端口。对于rtsp_URI来说，拥有被请求的
资源的服务器主机通过侦听该端口的TCP连接(rtsp)或UDP包(rtspu)来接收该URI请求。
只要可能，应尽量避免的在URL中直接使用IP地址。（请参考RFC1924）
文
本媒体标识符使用URL中的字符集及转义规则（参考RFC1738）来标识一个表示(presentation)与单个流(stream)。URL可以用
于单个流或者多个流的集合，比如表示(presentation)。因此，在第十章所描述的请求(request)可以用于整个表示
(presentation)或表示中的单个流。注意，有些请求方法仅能用于流而不能用于表示，反之亦然。
例如：RTSP URL:
[color="#0000ff"]rtsp://media.example.com:554/twister/audiotrack
标识了twister表示(presentation)中，可以通过media.example.com554端口的TCP连接发送RTSP请求来控制的音频流。
也可以是这样RTSP URL：
[color="#0000ff"]rtsp://media.example.com:554/twister
标识了由音频和视频流组成的twister表示(presentation)。
这并没有给出URL中相关流的标准方法。表示描述定义了表示中的层次关系以及单独流的URL。如一个表示描述可能将一个流命名为a.mov，而将整个表示命名为b.mov。
RTSP URL的路径组成对客户端来说不可见并且也并没有给出服务器的具体文件系统结构。
只需进行简单替换后，表示描述同样可以用于非RTSP媒体控制协议。
3.3 会议标识
会议标识采用URI标准编码方法编码，并对RTSP来说是不可见的。它们能包含任一八位位组值。必须保证会议标识在全局中的唯一性。在H.323中，将用到会议的标识值。
conference-id =  1*xchar
会议标识允许RTSP会话从媒体服务器参与的多媒体会议中获取参数。比如，可以要求媒体服务器用会议描述中的标识值来代替RTSP客户端以提供详细的传输信息。多媒体会议的建立不属于本协议内容，具体请参见H.323或SIP协议。
3.4 会话标识
会话标识符是不可见的任意长度的字符串。线性空格必须是URL-escaped。会话标识符必须随机产生并且至少应有8个八位位组长以保证其难以被猜出。（详见16章）
session-id  =  1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相对时间戳
SMPTE
相对时间戳表示相对于开始剪辑的时间。相对时间戳以SMPTE时间编码形式表示而可以达到帧级量级的精度。时间编码的格式为：时：分：秒；帧.子帧，并以
剪辑开始为起点。缺省的SMPTE格式为“SMPTE 30 drop”格式，其帧速是29.97帧每秒。可通过选择使用不同“SMPTE
time”来选择其他SMPTE编码格式（如“SMPTE
25”格式）。帧域的时间值在0到29之间。30帧每秒和29.97帧每秒的不同之处在于后者除每第十分钟外的每分钟都要丢掉头两个帧（00和01）。忽
略帧值为0的帧，子帧以百分之一帧为单位。
smpte-range =  smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type  =  "smpte" | "smpte-30-drop" | "smpte-25"
                  ; 还可以加入其他时间编码
smpte-time  =  1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
            [ "." 1*2DIGIT ]
比如：
  smpte=10:12:33:20-
  smpte=10:07:33-
  smpte=10:07:00-10:07:33:05.01
  smpte-25=10:07:00-10:07:33:05.01
3.6正常播放时间
正常播放时间(NPT)指出了流相对于表示(presentation)开始时的绝对位置。时间戳由一个十进制小数组成，以秒为单位，小数点左边可以直接以秒表示或者以小时：分：秒的形式表示。
表示开始时对应0.0秒。负值没有意义。特殊的常数now定义为现场事件当前瞬间。它只能用于现场事件。
在DSM
-CC中，正常播放时间（NPT）是这样定义的：“直观地讲，NPT是用户和程序联系的时钟。它经常作为数字显示在VCR上。当处于普通播放模式
(scale =
1)时，NPT正常前进。当处于快进扫描模式时(scale率为大于1的正数)，NPT快速前进。当处于反向扫描模式(scale率小于-1)时，NPT
快速后退。当处于暂停模式时，NPT停止。NPT（逻辑上）等同于SMPTE时间编码。
npt-range  =  ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time   =  "now" | npt-sec | npt-hhmmss
npt-sec   =  1*DIGIT [ "." *DIGIT ]
npt-hhmmss  =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh    =  1*DIGIT   ; any positive number
npt-mm    =  1*2DIGIT  ; 0-59
npt-ss    =  1*2DIGIT  ; 0-59
  比如：
  npt=123.45-125
  npt=12:05:35.3-
  npt=now-
  语法遵循ISO 8601规则。npt-sec标志法便于自动产生， ntp-hhmmss标志法便于人工使用。“now”常数允许客户端请求接收实时反馈而不是存储或者延时的版本。因为对于这种情况而言，既没有绝对时间，也没有0时间，所以需要该参数。
3.7 绝对时间
绝对时间表示为ISO 8601时间戳，使用UTC(GMT)小数法表示。
utc-range  =  "clock" "=" utc-time "-" [ utc-time ]
utc-time   =  utc-date "T" utc-time "Z"
utc-date   =  8DIGIT          ;
utc-time   =  6DIGIT [ "." fraction ]  ;
比如，1996年11月8日14点37分20.25秒UTC时间为：
19961108T143720.25Z
3.8 选择标签
选择标签是用来指定RTSP新选择的唯一标识符。这些标签用于要求(Require)(12.32节)和代理要求(Proxy Require)(12.27节)标题域中。
语法：
  option-tag  =  1*xchar
建立新的RTSP选择可以通过在选择前加入相反域名的前缀（如：对于能访问到foo.com则com.foo.mynewfeature" 是个合适的名字）或者在英特网权威数字分派委员会注册（IANA）新的选择。
3.8.1 用IANA注册新的选择标签
当注册新RTSP选择标签的时候，应该提供以下信息：
?      选择的名字和描述。名字长度不限，但是应该不少于20字符。名字不得包含任何空格，控制符或句点。
?      指出谁拥有选择的改变控制权（例如，IETF，国际标准化组织，国际电信联盟-T，其他的国际标准化体，一个团体，一个公司，或者一组公司）。
?      描述更为详细的参考文档（如果有），比如，RFC，发表论文，专利文档，技术报告，源代码，或者计算机手册。
?      选择的所有权，以及联系地址（邮编及电子信件地址）。
4 RTSP消息
　 RTSP是基于文本的协议，采用ISO 10646
字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于
参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual
Basic与Perl）实现研究原型。
　 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
　 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
　 不管实体标题域是否出现在信息中，不包括信息体的的回应信息总以标题域后第一和空行结束。
　 如出现内容长度标题域，其值以字节计，表示信息体长度。如未出现标题域，其值为零。
　 服务器关闭连接。
　 注意：RTSP目前并不支持HTTP/1.1\"块\"传输编码，需要有内容长度头。假如返回适度表示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
　 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
4.1 消息类型
见[H4.1]。如下：
RTSP消息由客户端到服务器的请求和由服务器到客户端的回应组成。
RTSP -message = Request | Response            ; RTSP /1.0 messages
请求（Request）和回应（Response）消息都使用RFC822中实体传输部分规定（作为消息中的有效载荷）的消息格式。两者的消息都可能包括
一起始行，一个或多个标题域（headers）、一行表示标题域结束的空行（即CRLF前没有内容的行），和一个消息主体（message-body,
可选）。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。换句话说，如果服务器正在读协议流，在一个消息开始时如果首先收到了CRLF，这个CRLF符应被忽略。
     
4.2 消息标题
见[H4.2]。
     RTSP标题域，包括主标题（General-Header,4.3节）、请求标题（Request-Header ,5.2节）、
回应标题（Response-Header ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1
节[7]给出的通用格式定义。每个标题域由后紧跟冒号的名字，单空格（SP），字符及域值组
成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一
个以上的SP或HT开头就行。
RTSP-header            = field-name ":" [ field-value ] CRLF
field-name            = token
field-value            = *( field-content | LWS )
field-content            =
标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应
标题，最后是实体标题。
     当且仅当标题域的全部域值都用逗号分隔的列表示时（即，#（值）），多个有相同域名
的RTSP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发
的域值加到第一个值后面，之间用逗号分隔，最终能将多个标题域结合成“域名：域值”对。
4.3 消息主体
见[H4.3]。
RTSP消息的消息主体（如果有）用来携带请求或回应的主体。仅在使用传输编码(Transfer-Encoding)时消息主体和实体主体才有所不同，这种情况在传输编码标题域中有详细说明。（见[H14.40]）
message-body = entity-body
|
传输编码必须能解释所有保证传输安全和正确的应用程序的传输编码。传输编码是消息而不是实体的一个属性，因此可以由任一应用程序随着请求/回应链添加或者删除。
什么时候允许消息带消息体的规则在请求和回应两种情况下有所不同。
在请求中有无消息主体的标志是是否包含内容长度或请求消息标题域中的传输编码标题域。只有当请求方法允许有实体主体的时候才能在请求中包含消息主体。
而
对于回应消息来说，无论消息中是否存在消息主体都与请求方法和回应状态编码无关。所有回应标题请求方法的消息都不能包含消息主体，尽管有时会因为存在实体
标题域而使人产生误解。所有1××（信息），204（无内容），304（未修改）回应都不包含消息主体。而其他回应则都包含主体，尽管其长度有可能长度为
零。
4.4 消息长度
当消息包含消息主体时，消息主体的长度由以下规则来决定（按优先级高低顺序排列）：
1.      任何回应消息都不包含消息主体（如1××，204和304回应），并且不管消息中是否存在实体标题域都以消息标题域后的第一行空行表示结束。
2.      如果内容长度标题域存在，它在字节中的值就是消息主体的长度。如果内容标题域不存在，则假设值为零。
3.      服务器关闭连接时。（关闭连接没有用来表明请求主体结束，否则可能导致服务器不能回应。
注意，RTSP不支持（至少现在）HTTP/1.1的块传输编码（详见[H3.6]）并且要求有内容长度标题域。
     尽管表示描述长度动态产生，但由于可获得了表示描述返回长度，使得服务器总是能决定表示描述长度而不需使用块传输编码方式。只要有实体主体就必须有内容长度项，这些规则保证了即使没有给出明确长度也能做出合理的操作。
5 普通标题域
     有几种标题域是请求与回应都要使用的，但并不用于被传输的实体。这些标题只用于被
传输的消息。
General-Header = Date                  ; Section 10.6
        | Pragma            ; Section 10.12
     普通标题域名称只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，
新的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将
被视为实体域。
6 请求
从客户端到服务器端的请求消息包括，消息首行中，对资源的请求方法、资源的标识符
及使用的协议。
Request = Request-Line ; 6.1节
*( general-header ; 5章
| request-header ; 6.2节
| entity-header ) ; 8.1节
CRLF
[ message-body ] ; 4.3节
6.1 请求队列
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
6.2 请求标题域
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
注意：相对于HTTP/1.1而言，RTSP请求要求绝对路径（并包括rtsp或rtspu方案，主机，端口号）。
HTTP/1.1 要求服务器理解绝对URL, 但是客户端需要假设为主机请求标题域。这样做完全是为了HTTP/1.0服务器端向后兼容性，因此RTSP并不需要这样做。
在请求URI中星号“*”表示此请求不用于其他资源，只用于服务器本身，并且它只能在使用的方法不要求应用于资源时才能使用。
比如：OPTIONS * RTSP/1.0。
7 回应
7.1 状态行
完整回应消息的第一行就是状态行，它依次由协议版本、数字形式的状态代码、及相应
的词语文本组成，各元素间以空格（SP）分隔，除了结尾的CRLF外，不允许出现单独的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
7.1.1 状态代码和原因分析
状态代码（Status-Code）由3位数字组成，表示请求是否被理解或被满足。原因分析是
用简短的文字来描述状态代码产生的原因。状态代码用来支持自动操作，原因分析是为人类
用户准备的。客户端不需要检查或显示原因分析。
状态代码的第一位数字定义了回应的类别，后面两位数字没有具体分类。首位数字有5
种取值可能：
o 1xx:：保留，将来使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成请求必须进行进一步操作。
o 4xx：客户端出错 － 请求有语法错误或无法实现。
o 5xx：服务器端出错 － 服务器无法实现合法的请求。
HTTP/1.0的状态代码、原因解释在下面给出。下面的原因解释只是建议采用，可任意
更改，而不会对协议造成影响。完整的代码定义在第9节。
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "250" ; Low on Storage Space
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood
| "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth
| "454" ; Session Not Found
| "455" ; Method Not Valid in This State
| "456" ; Header Field Not Valid for Resource
| "457" ; Invalid Range
| "458" ; Parameter Is Read-Only
| "459" ; Aggregate operation not allowed
| "460" ; Only aggregate operation allowed
| "461" ; Unsupported transport
| "462" ; Destination unreachable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; RTSP Version not supported
| "551" ; Option not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *
     HTTP状态代码是可扩展的，而只有上述代码才可以被当前全部的应用所识别。HTTP
应用不要求了解全部注册的状态代码，当然，如果了解了更好。实际上，应用程序必须理解
任何一种状态代码，如果碰到不识别的情况，可根据其首位数字来判断其类型并处理。另外，
不要缓存无法识别的回应。
     例如，如果客户端收到一个无法识别的状态码431，可以安全地假定是请求出了问题，
可认为回应的状态码就是400。在这种情况下，用户代理应当在回应消息的实体中通知用户，
因为实体中可以包括一些人类可以识别的非正常状态的描述信息。
Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
Table 1: Status codes and their usage with RTSP methods
7.1.2 回应标题域
回应标题域中包括不能放在状态行中的附加回应信息。该域还可以存放与服务器相关的
信息，以及在对请求URI所指定资源进行访问的下一步信息。
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
     回应标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。
8 实体
如不受请求方法或回应状态编码限制，请求和回应消息可传输实体，实体由实体标题域和实体主体组成，有些回应仅包括实体头。
在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
8.1 实体标题域
实体标题定义实体主体可选元信息，如没有实体主体，指请求标识的资源。
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
扩展头机制允许定义附加实体标题域，而不用改变协议，但这些段不能假定接收者能识别。不可识别标题域应被接收者忽略，而让代理转发。
8.2 实体主体
见[H7.2]
　      与RTSP请求或回应一起发送的实体主体的格式和编码信息都在实体标题域
（Entity-Header）中定义。
Entity-Body   = *OCTET
     实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度
标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体
主体的RTSP/1.0请求必须包含合法的内容长度标题域。
     
     对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD
请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包
括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0。
9 连接
　 RTSP请求可以几种不同方式传送：
　 1、持久传输连接，用于多个请求/回应传输。
　 2、每个请求/回应传输一个连接。
　 3、无连接模式。
　 传输连接类型由RTSP URI来定义。对 \"rtsp\" 方案，需要持续连接；而\"rtspu\"方案，调用RTSP 请求发送，而不用建立连接。
　 不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
9.1 流水线操作
　 支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。
9.2 可靠性及确认
如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。
如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。
如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。
时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。
每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
　 实现RTSP的系统必须支持通过TCP传输RTSP
，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与
RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/59592/showart_1192957.html