rfc2326(中文版)－实时流协议(rtsp) - p2p - confluence.htm

rtsp的一些说明文档,包含中文rfc格式以及其他的一些格式说明

            URL：<BR>rtsp://media.example.com:554/twister<BR>标识了由音频和视频流组成的twister表示(presentation)。</P>
            <P>这并没有给出URL中相关流的标准方法。表示描述定义了表示中的层次关系以及单独流的URL。如一个表示描述可能将一个流命名为a.mov，而将整个表示命名为b.mov。<BR>RTSP 
            URL的路径组成对客户端来说不可见并且也并没有给出服务器的具体文件系统结构。</P>
            <P>只需进行简单替换后，表示描述同样可以用于非RTSP媒体控制协议。<BR>3.3 
            会议标识<BR>会议标识采用URI标准编码方法编码，并对RTSP来说是不可见的。它们能包含任一八位位组值。必须保证会议标识在全局中的唯一性。在H.323中，将用到会议的标识值。</P>
            <P>conference-id = 1*xchar</P>
            <P>会议标识允许RTSP会话从媒体服务器参与的多媒体会议中获取参数。比如，可以要求媒体服务器用会议描述中的标识值来代替RTSP客户端以提供详细的传输信息。多媒体会议的建立不属于本协议内容，具体请参见H.323或SIP协议。<BR>3.4 
            会话标识<BR>会话标识符是不可见的任意长度的字符串。线性空格必须是URL-escaped。会话标识符必须随机产生并且至少应有8个八位位组长以保证其难以被猜出。（详见16章）<BR>session-id 
            = 1*( ALPHA | DIGIT | safe )<BR>3.5 SMPTE 相对时间戳<BR>SMPTE 
            相对时间戳表示相对于开始剪辑的时间。相对时间戳以SMPTE时间编码形式表示而可以达到帧级量级的精度。时间编码的格式为：时：分：秒；帧.子帧，并以剪辑开始为起点。缺省的SMPTE格式为"SMPTE 
            30 drop"格式，其帧速是29.97帧每秒。可通过选择使用不同"SMPTE time"来选择其他SMPTE编码格式（如"SMPTE 
            25"格式）。帧域的时间值在0到29之间。30帧每秒和29.97帧每秒的不同之处在于后者除每第十分钟外的每分钟都要丢掉头两个帧（00和01）。忽略帧值为0的帧，子帧以百分之一帧为单位。</P>
            <P>smpte-range= smpte-type "=" smpte-time "-" [ smpte-time 
            ]<BR>smpte-type = "smpte" | "smpte-30-drop" | 
            "smpte-25"<BR> ; 还可以加入其他时间编码<BR>smpte-time = 
            1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]<BR> [ 
            "." 1*2DIGIT ]</P>
            <P>比如：<BR> smpte=10:12:33:20-<BR> smpte=10:07:33-<BR> 
            smpte=10:07:00-10:07:33:05.01<BR> 
            smpte-25=10:07:00-10:07:33:05.01<BR>3.6正常播放时间<BR>正常播放时间(NPT)指出了流相对于表示(presentation)开始时的绝对位置。时间戳由一个十进制小数组成，以秒为单位，小数点左边可以直接以秒表示或者以小时：分：秒的形式表示。</P>
            <P>表示开始时对应0.0秒。负值没有意义。特殊的常数now定义为现场事件当前瞬间。它只能用于现场事件。</P>
            <P>在DSM 
            -CC中，正常播放时间（NPT）是这样定义的："直观地讲，NPT是用户和程序联系的时钟。它经常作为数字显示在VCR上。当处于普通播放模式 
            (scale = 
            1)时，NPT正常前进。当处于快进扫描模式时(scale率为大于1的正数)，NPT快速前进。当处于反向扫描模式(scale率小于-1)时，NPT 
            快速后退。当处于暂停模式时，NPT停止。NPT（逻辑上）等同于SMPTE时间编码。</P>
            <P>npt-range= ( npt-time "<DEL>" [ npt-time ] ) | ( "</DEL>" 
            npt-time )<BR>npt-time = "now" | npt-sec | 
            npt-hhmmss<BR>npt-sec= 1*DIGIT [ "." *DIGIT ]<BR>npt-hhmmss = 
            npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]<BR>npt-hh = 
            1*DIGIT ; any positive number<BR>npt-mm = 1*2DIGIT; 
            0-59<BR>npt-ss = 1*2DIGIT; 0-59</P>
            <P> 比如：<BR> npt=123.45-125<BR> npt=12:05:35.3-<BR> npt=now-</P>
            <P> 语法遵循ISO 8601规则。npt-sec标志法便于自动产生， 
            ntp-hhmmss标志法便于人工使用。"now"常数允许客户端请求接收实时反馈而不是存储或者延时的版本。因为对于这种情况而言，既没有绝对时间，也没有0时间，所以需要该参数。<BR>3.7 
            绝对时间<BR>绝对时间表示为ISO 8601时间戳，使用UTC(GMT)小数法表示。</P>
            <P>utc-range= "clock" "=" utc-time "-" [ utc-time ]<BR>utc-time 
            = utc-date "T" utc-time "Z"<BR>utc-date = 8DIGIT; &lt; 
            YYYYMMDD &gt;<BR>utc-time = 6DIGIT [ "." fraction ] ; &lt; 
            HHMMSS.fraction &gt;</P>
            <P>比如，1996年11月8日14点37分20.25秒UTC时间为：<BR>19961108T143720.25Z<BR>3.8 
            选择标签<BR>选择标签是用来指定RTSP新选择的唯一标识符。这些标签用于要求(Require)(12.32节)和代理要求(Proxy 
            Require)(12.27节)标题域中。</P>
            <P>语法：<BR>option-tag = 1*xchar</P>
            <P>建立新的RTSP选择可以通过在选择前加入相反域名的前缀（如：对于能访问到foo.com则com.foo.mynewfeature" 
            是个合适的名字）或者在英特网权威数字分派委员会注册（IANA）新的选择。<BR>3.8.1 
            用IANA注册新的选择标签<BR>当注册新RTSP选择标签的时候，应该提供以下信息：<BR>Ø 
            选择的名字和描述。名字长度不限，但是应该不少于20字符。名字不得包含任何空格，控制符或句点。<BR>Ø 
            指出谁拥有选择的改变控制权（例如，IETF，国际标准化组织，国际电信联盟-T，其他的国际标准化体，一个团体，一个公司，或者一组公司）。<BR>Ø 
            描述更为详细的参考文档（如果有），比如，RFC，发表论文，专利文档，技术报告，源代码，或者计算机手册。<BR>Ø 
            选择的所有权，以及联系地址（邮编及电子信件地址）。<BR>4 RTSP消息<BR>　 RTSP是基于文本的协议，采用ISO 10646 
            字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual 
            Basic与Perl）实现研究原型。<BR>　 
            10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 
            8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。<BR>　 
            请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：<BR>　 
            不管实体标题域是否出现在信息中，不包括信息体的的回应信息总以标题域后第一和空行结束。<BR>　 
            如出现内容长度标题域，其值以字节计，表示信息体长度。如未出现标题域，其值为零。<BR>　 服务器关闭连接。<BR>　 
            注意：RTSP目前并不支持HTTP/1.1\"块\"传输编码，需要有内容长度头。假如返回适度表示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。<BR>　 
            从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。</P>
            <P>4.1 消息类型<BR>见<SPAN class=error>[H4.1]</SPAN>。如下：</P>
            <P>RTSP消息由客户端到服务器的请求和由服务器到客户端的回应组成。</P>
            <P>RTSP -message = Request | Response ; RTSP /1.0 messages</P>
            <P>请求（Request）和回应（Response）消息都使用RFC822中实体传输部分规定（作为消息中的有效载荷）的消息格式。两者的消息都可能包括一起始行，一个或多个标题域（headers）、一行表示标题域结束的空行（即CRLF前没有内容的行），和一个消息主体（message-body, 
            可选）。</P>
            <P>generic-message = start-line<BR>*message-header<BR>CRLF<BR>[ 
            message-body ]</P>
            <P>start-line = Request-Line | Status-Line</P>
            <P>为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。换句话说，如果服务器正在读协议流，在一个消息开始时如果首先收到了CRLF，这个CRLF符应被忽略。</P>
            <P>4.2 消息标题<BR>见<SPAN 
            class=error>[H4.2]</SPAN>。<BR>RTSP标题域，包括主标题（General-Header,4.3节）、请求标题（Request-Header 
            ,5.2节）、<BR>回应标题（Response-Header 
            ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1<BR>节<SPAN 
            class=error>[7]</SPAN>给出的通用格式定义。每个标题域由后紧跟冒号的名字，单空格（SP），字符及域值组<BR>成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一<BR>个以上的SP或HT开头就行。</P>
            <P>RTSP-header = field-name ":" [ field-value ] CRLF</P>
            <P>field-name = token<BR>field-value = *( field-content | LWS )</P>
            <P>field-content = &lt;the OCTETs make up the field-value<BR>and 
            consisting of either *TEXT or combinations<BR>of token, tspecials, 
            and 
            quoted-string&gt;<BR>标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应<BR>标题，最后是实体标题。<BR>当且仅当标题域的全部域值都用逗号分隔的列表示时（即，#（值）），多个有相同域名<BR>的RTSP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发<BR>的域值加到第一个值后面，之间用逗号分隔，最终能将多个标题域结合成"域名：域值"对。</P>
            <P>4.3 消息主体<BR>见<SPAN 
            class=error>[H4.3]</SPAN>。<BR>RTSP消息的消息主体（如果有）用来携带请求或回应的主体。仅在使用传输编码(Transfer-Encoding)时消息主体和实体主体才有所不同，这种情况在传输编码标题域中有详细说明。（见<SPAN 
            class=error>[H14.40]</SPAN>）</P>
            <P>message-body = entity-body</P>
            <TABLE class=confluenceTable>
              <TBODY>
              <TR>
                <TD class=confluenceTd>&lt;entity-body encoded as per 
                  Transfer-Encoding&gt;</TD></TR></TBODY></TABLE>
            <P>传输编码必须能解释所有保证传输安全和正确的应用程序的传输编码。传输编码是消息而不是实体的一个属性，因此可以由任一应用程序随着请求/回应链添加或者删除。</P>
            <P>什么时候允许消息带消息体的规则在请求和回应两种情况下有所不同。</P>
            <P>在请求中有无消息主体的标志是是否包含内容长度或请求消息标题域中的传输编码标题域。只有当请求方法允许有实体主体的时候才能在请求中包含消息主体。</P>
            <P>而对于回应消息来说，无论消息中是否存在消息主体都与请求方法和回应状态编码无关。所有回应标题请求方法的消息都不能包含消息主体，尽管有时会因为存在实体标题域而使人产生误解。所有1××（信息），204（无内容），304（未修改）回应都不包含消息主体。而其他回应则都包含主体，尽管其长度有可能长度为零。<BR>4.4 
            消息长度<BR>当消息包含消息主体时，消息主体的长度由以下规则来决定（按优先级高低顺序排列）：<BR>1. 
            任何回应消息都不包含消息主体（如1××，204和304回应），并且不管消息中是否存在实体标题域都以消息标题域后的第一行空行表示结束。<BR>2. 
            如果内容长度标题域存在，它在字节中的值就是消息主体的长度。如果内容标题域不存在，则假设值为零。<BR>3. 
            服务器关闭连接时。（关闭连接没有用来表明请求主体结束，否则可能导致服务器不能回应。<BR>注意，RTSP不支持（至少现在）HTTP/1.1的块传输编码（详见<SPAN 
            class=error>[H3.6]</SPAN>）并且要求有内容长度标题域。<BR>尽管表示描述长度动态产生，但由于可获得了表示描述返回长度，使得服务器总是能决定表示描述长度而不需使用块传输编码方式。只要有实体主体就必须有内容长度项，这些规则保证了即使没有给出明确长度也能做出合理的操作。</P>
            <P>5 普通标题域<BR>有几种标题域是请求与回应都要使用的，但并不用于被传输的实体。这些标题只用于被<BR>传输的消息。</P>
            <P>General-Header = Date ; Section 10.6</P>
            <TABLE class=confluenceTable>
              <TBODY>
              <TR>
                <TD class=confluenceTd>Pragma ; Section 
                  10.12<BR>普通标题域名称只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，<BR>新的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将<BR>被视为实体域。<BR>6 
                  请求<BR>从客户端到服务器端的请求消息包括，消息首行中，对资源的请求方法、资源的标识符<BR>及使用的协议。</TD></TR></TBODY></TABLE>
            <P>Request = Request-Line ; 6.1节<BR>*( general-header ; 5章</P>
            <TABLE class=confluenceTable>
              <TBODY>
              <TR>
                <TD class=confluenceTd>request-header ; 6.2节</TD></TR>
              <TR>
                <TD class=confluenceTd>entity-header ) ; 8.1节<BR>CRLF<BR>[ 
                  message-body ] ; 4.3节</TD></TR></TBODY></TABLE>
            <P>6.1 请求队列<BR>Request-Line = Method SP Request-URI SP RTSP-Version 
            CRLF<BR>Method = "DESCRIBE" ; Section 10.2</P>
            <TABLE class=confluenceTable>
              <TBODY>
              <TR>
                <TD class=confluenceTd>"ANNOUNCE" ; Section 10.3</TD></TR>
              <TR>
                <TD class=confluenceTd>"GET_PARAMETER" ; Section 10.8</TD></TR>
              <TR>
                <TD class=confluenceTd>"OPTIONS" ; Section 10.1</TD></TR>
              <TR>
                <TD class=confluenceTd>"PAUSE" ; Section 10.6</TD></TR>
              <TR>
                <TD class=confluenceTd>"PLAY" ; Section 10.5</TD></TR>
              <TR>
                <TD class=confluenceTd>"RECORD" ; Section 10.11</TD></TR>
              <TR>
                <TD class=confluenceTd>"REDIRECT" ; Section 10.10</TD></TR>
              <TR>
                <TD class=confluenceTd>"SETUP" ; Section 10.4</TD></TR>
              <TR>