📄 rfc2326(中文版)－实时流协议(rtsp) - p2p - confluence.htm
字号:
数据由另一个协议传送（有一特例除外）。<BR>² RTSP使用ISO 10646(UTF-8) 而不是ISO
8859-1，以配合当前HTML的国际化。<BR>²
RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中。<BR>这使得"虚拟主机"实现更为简便，一个单独IP地址的主机可虚拟为几个文件树主机。</P>
<P>协议支持的操作如下：</P>
<P>从媒体服务器上检索媒体：<BR>用户可通过HTTP或其它方法请求一个表示描述。如表示是组播，表示描述就包含用于连续媒体的的组播地址和端口。如表示仅通过单播发送给用户，用户为了安全应提供目的地址。</P>
<P>媒体服务器邀请进入会议：<BR>媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。</P>
<P>将媒体加到现成讲座中：<BR> 如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。</P>
<P>如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。<BR>1.2
要求<BR>在本文档中的关键字"必须"，"一定不能"，"要求"，"会"，"不会"，"应该"，"不应该"，"被推荐的"，"可以"，和"可选择的"都在RFC2119中解释。<BR>1.3
术语<BR>一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。</P>
<P>合控制：<BR>服务器使用单条时间线对多个流的控制。对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回馈。<BR>会议：<BR>多方参与的多媒体表示，这里的多方意味着大于或者等于一方。<BR>客户端：<BR>指请求媒体服务器上连续流媒体数据的客户端。<BR>连接：<BR>
两个应用程序以通讯为目的在传输层建立虚拟电路。<BR>容器文件：<BR>
可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不是本协议内容。<BR>连续媒体：<BR>
接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重新产生存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（但是不交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。<BR>实体：<BR>作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header
field）形式存在的元信息和以实体主体（entity
body）形式存在的内容组成，如第八章所述。<BR>媒体的初始化：<BR>数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创建流时初始化媒体流相位时产生的。<BR>媒体参数:<BR>针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。<BR>媒体服务器：<BR>可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上，也可以建立在不同的主机上。<BR>媒体服务器重定向：<BR>
重新定向媒体客户端到另外一个媒体服务器。<BR>(媒体)流：<BR>
单个媒体实例，比如，在应用中共用音频流或视频流。当使用RTP时，流包括由RTP
会话(session)中源所创建的所有RTP和RTCP包。这和定义DSM-CC流时相同。<BR>消息：<BR>RTSP通讯的基本单元。由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。<BR>参与者：<BR>一个会议成员。参与者可以是机器，比如是媒体记录或回放服务器。<BR>表示(presentation)：<BR>对用户请求所回馈的一组流，其使用下面的表示描述(presentation
description)形式。在本文中的多数情况下，其意味着对流进行总体控制，但这并不是必须的。<BR>表示描述(presentation
description)：<BR>表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息。另外，其他IETF协议，如SDP协议使用会话(session)代替现场presentation。表示描述可以采用包括会话描述(session
description)SDP在内的多种格式。<BR>回应：<BR>RTSP回应。如果能理解HTTP回应，就能清楚的理解RTSP回应。<BR>请求；<BR>RTSP请求。如果能理解HTTP请求，就能清楚的理解RTSP请求。<BR>RTSP会话(session)：<BR>RTSP交互的全过程。比如，一个电影的观看过程。会话(session)包括由客户端建立连续媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。<BR>传输初始化：<BR>客户端和服务器端之间传输信息（端口号，传输协议等）的交互。<BR>1.4
协议特点<BR>RTSP 特性如下：<BR>可扩展性：<BR> RTSP中很容易加入新方法和参数。<BR>易解析：<BR>
RTSP可由标准
HTTP或MIME解析器解析。<BR>安全：<BR>RTSP使用网页安全机制。所有HTTP授权机制如basic和digest授权都可直接使用。也可以传输层或网络层安全机制。<BR>独立于传输：<BR>RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。<BR>多服务器支持：<BR>表示(presentation)中的每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。<BR>记录设备控制：<BR>
协议可控制记录和回放设备，也可控制可在记录和回放切换的设备。<BR>流控与会议开始分离：<BR>流控与邀请媒体服务器入会分离；仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下，
SIP或H.323 可用来邀请服务器入会。<BR>适合专业应用：<BR> 通过SMPTE
时标，RTSP支持帧级精度，允许远程数字编辑。<BR>表示描述中立：<BR>协议没强加特殊表示或元文件，可传达所用格式类型；然而，表示描述至少必须包含一个RTSP
URI。<BR>代理与防火墙友好：<BR>协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。<BR>HTTP友好：<BR>此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet
内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP
添加方法。<BR>适当的服务器控制：<BR> 如用户能启动一个流，它必须也能停止一个流。
服务器不能启动一个用户不能停止的流。<BR>传输协调：<BR>
实际处理连续媒体流前，用户可协调传输方法。<BR>性能协调：<BR>如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。
例如，如果不允许寻找，用户界面必定能禁止位置条滑动。<BR>以前要求RTSP必须能支持多用户，但现在得出一个更好的方法就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此"远程通过"成为可能。协议不涉及到多个客户端如何协调入口，其由下层"社会协议"或其他下层控制机制提供。<BR>1.5
RTSP扩展<BR>由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。例如：<BR>Ø
服务器可能只须支持回放，因此不必不支持录制功能。<BR>Ø 对于支持现场播放的服务器可能不支持寻找功能。<BR>Ø
一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER。<BR>但服务器应该实现所有12章中要求的标题域。<BR>表示描述(presentation
description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1中<SPAN
class=error>[H19.6]</SPAN>描述方法不支持across server的情形一致。<BR>RTSP
可以如下三种方式扩展，这里以改变大小排序：<BR>Ø
以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。<BR>Ø
加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共回应标题列出支持的方法。<BR>Ø
定义新版本协议，允许改变所有部分。（除了协议版本号位置）<BR>1.6 操作模式<BR> 每个表示和媒体流可用RTSP
URL识别。表示组成的整个表示与媒体属性由表示描述(presentation
description)文件定义，表示描述格式不在本协议中定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。<BR> 为了说明，假设表示描述(presentation
description)描述了多个表示(presentation)，其中每个表示(presentation)维持了一个公共时间轴。为简化说明，且不失一般性，假定表示描述(presentation
description)的确包含这样一个表示(presentation)。表示(presentation)可包含多个媒体流。<BR>表示描述(presentation
description)即组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，被RTSP分别控制的媒体流由RTSP
URL表示。RTSP
URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而负载共享。描述（description)还列出了服务器传输可使用的方法。<BR>除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：<BR>单播：<BR>
以用户选择的端口号将媒体发送到RTSP请求源。<BR>组播，服务器选择地址：<BR>
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。<BR>组播，用户选择地址：<BR>
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。<BR>1.7 RTSP状态<BR>
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的会话状态。<BR>RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：<BR>SETUP：<BR>
让服务器给流分配资源，启动RTSP会话。<BR>PLAY与RECORD：<BR> 启动SETUP
分配流的数据传输。<BR>PAUSE：<BR> 临时停止流，而不释放服务器资源。<BR>TEARDOWN：<BR>
释放流的资源，RTSP会话停止。<BR>
标识状态的RTSP方法使用会话(session)标题域识别RTSP会话，为回应SETUP请求，服务器生成会话标识。<BR>1.8
与其他协议关系<BR>
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，表示描述(presentation
description)可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP
服务器与用户不全依靠HTTP。<BR> 但是，RTSP与HTTP
的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出回应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。<BR>重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。<BR>
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。<BR>RTSP假设存在表示描述格式可表示包含几个媒体流的表示的静态与临时属性。<BR>2
符号协定<BR>既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[
HX.Y ]表示对应HTTP/1.1（RFC 2068）中的X.Y部分。（<SPAN
class=error>[译者注：]</SPAN>为更方便学习RTSP，本翻译文档将相关段落完全译出）</P>
<P>与<SPAN
class=error>[H2.1]</SPAN>类似，本文对所有机制的说明都是以散文和补充反馈的方式来描述的。除RTSP中以"1#"代替","为分隔符不同外，其余在RFC
2234中有详细的描述。简单说明补充反馈方式如下：</P>
<P>补充反馈方式（augmented BNF）包括下面的结构：</P>
<P>要解释的名词＝名词解释（name =
definition）<BR>规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，<BR>然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排<BR>版。某些基本的规则使用大写，如SP,
LWS, HT, CRLF, DIGIT, ALPHA,等等。定义<BR>中还可以使用尖括号来帮助理解规则名的使用。</P>
<P>字面意思（"literal"）<BR>文字的字面意思放在引号中间，除非特别指定，该段文字是大小写敏感的。</P>
<P>规则1｜规则2（rule1 | rule2）<BR>"｜"表示其分隔的元素是可选的，比如，"是｜否"要选择'是'或'否'。</P>
<P>（规则1 规则2）（(rule1
rule2)）<BR>在圆括号中的元素表明必选其一。如（元素1（元素2｜元素3）元素4）可表明两<BR>种意思，即"元素1 元素2 元素4"和"元素1 元素3 元素4"</P>
<P>*规则（*rule）<BR>在元素前加星号"<B>"表示循环，其完整形式是"<n></B><m>元素"，表明元素最少产<BR>生<n>次，最多<m>次。缺省值是0到无限，例如，"1*元素"意思是至少有一个，<BR>而"1*2元素"表明允许有1个或2个。</P>
<P>［规则］（<SPAN
class=error>[rule]</SPAN>）<BR>方括号内是可选元素。如"［元素1 元素2］"与"*1（元素1 元素2）"是一回<BR>事。</P>
<P>N 规则（N
rule）<BR>表明循环的次数："<n>（元素）"就是"<n>*<n>（元素）"，也就是精确指出<n><BR>取值。因而，2DIGIT
就是2位数字, 3ALPHA 就是由三个字母组成字符串。</P>
<P>＃规则（#rule）<BR>"#"与"*"类似，用于定义元素列表。</P>
<P>完整形式是"<n>#<m>元素"表示至少有<n>个至多有<m>个元素，中间用","或<BR>任意数量的空格（LWS-linear
whitespace）来分隔，这将使列表非常方便，如"（*LWS<BR>元素 *（ *LWS "," *LWS 元素
））"就等同于"1#元素"。</P>
<P>空元素在结构中可被任意使用，但不参与元素个数的计数。也就是说，"（元素1），，<BR>（元素2）"仅表示2个元素。但在结构中，应至少有一个非空的元素存在。缺省<BR>值是0到无限，即"#（元素）"表示可取任何数值，包括0；而"1#元素"表示至<BR>少有1个；而"1#2元素"表示有1个或2个。</P>
<P>；注释（; comment）<BR>分号后面是注释，仅在单行使用。</P>
<P>隐含*LWS（implied
*LWS）<BR>本文的语法描述是基于单词的。除非另有指定，线性空格（LWS）可以两个邻近符<BR>号或分隔符（tspecials）之间任意使用，而不会对整句的意思造成影响。在两个符号之<BR>间必须有至少一个分隔符，因为它们也要做为单独的符号来解释。实际上，应用程序在<BR>产生HTTP结构时，应当试图遵照"通常方式"，因为现在的确有些实现方式在通常方<BR>式下无法正常工作。</P>
<P>在本备忘录中，我们用缩进的小型段落来提供动机和背景资料。这将使没有参与制定RTSP规范的读者更容易理解RTSP中各部分为什么要以该方式来实现。<BR>3
协议参数<BR>3.1 RTSP版本<BR>同<SPAN
class=error>[H3.1]</SPAN>定义，仅用RTSP代替HTTP即可。</P>
<P>如下：<BR>RTSP采用主从（<major>.<minor>）数字形式来表示版本。协议的版本政策倾向于让发<BR>送方表明其消息的格式及功能，而不仅仅为了获得通讯的特性，这样做的目的是为了与更高<BR>版本的RTSP实现通讯。只增加扩展域的值或增加了不影响通讯行为的消息组件都不会导致<BR>版本数据的变化。当协议消息的主要解析算法没变，而消息语法及发送方的隐含功能增加了，<BR>将会导致从版本号（<minor>）增加；当协议中消息的格式变化了，主版本号（<major>）也<BR>将发生改变。<BR>RTSP消息的版本由消息第一行中的RTSP版本域来表示。</P>
<P>RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT</P>
<P>注意，主从版本应当被看作单独的整数，因为它们都有可能增加，从而超过一位整<BR>数。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。<BR>版本号前面的0将被接收方忽略，而在发送方处也不应产生。</P>
<P>本文档定义了RTSP协议的1.0版本。发送本规范定义的请求（Request）或回应（Response）消息的应用必须指明RTSP的版本为"RTSP/1.0"。使用该版本号意味着发送消息的应用至少有条件的遵循本规范。</P>
<P>应用的RTSP版本即为应用至少能有条件遵循的RTSP版本中的最高版本。</P>
<P>当代理及网关收到与其自身版本不同的RTSP请求时，必须小心处理请求的推送，因为<BR>协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。如果收到高版本的<BR>请求，代理或网关必须降低该请求的版本，并回应一个错误。而低版本的请求也应在被推送<BR>前升级。代理或网关回应请求时必须和请求的版本相同。</P>
<P>3.2 RTSP URL<BR>"rtsp"和"rtspu"表示要通过RTSP协议来定位网络资源。本节详细定义了RTSP
URL的语法和语义。<BR>rtsp_URL= ( "rtsp:" | "rtspu:" ) "//" host [ ":"
port ] [ abs_path ]<BR>host=
<合法的Internet主机域名或IP地址(用十进制数及点组成),
见RFC1123，2.1节定义><BR>port= *DIGIT<BR>abs_path 在 <SPAN
class=error>[H3.2.1]</SPAN>中定义如下：</P>
<P>abs_path = "/" rel_path<BR>rel_path = [ path ] [ ";" params ] [
"?" query ]</P>
<P>path = fsegment *( "/" segment )<BR>fsegment = 1*pchar<BR>segment
= *pchar</P>
<P>params = param *( ";" param )<BR>param = *( pchar | "/" )</P>
<P>scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )<BR>net_loc = *(
pchar | ";" | "?" )<BR>query = *( uchar | reserved )<BR>fragment =
*( uchar | reserved )</P>
<P>pchar = uchar | ":" | "@" | "&" | "=" | "+"<BR>uchar =
unreserved | escape<BR>unreserved = ALPHA | DIGIT | safe | extra |
national</P>
<P>escape = "%" HEX HEX<BR>reserved = ";" | "/" | "?" | ":" | "@" |
"&" | "=" | "+"<BR>extra = "!" | "*" | "'" | "(" | ")" |
","<BR>safe = "$" | "-" | "_" | "."<BR>unsafe = CTL | SP | <">
| "#" | "%" | "<" | ">"<BR>national = <any OCTET excluding
ALPHA, DIGIT,</P>
<P>reserved, extra, safe, and
unsafe><BR>权威的URL语法及语义信息请参见RFC1738<SPAN
class=error>[4]</SPAN>和RFC1808<SPAN class=error>[9]</SPAN>。<BR><SPAN
class=error>[注意]</SPAN>：段(fragment)和询问(query)标识符在这时没有明确的定义，需要到RTSP服务器上解释。</P>
<P>rtsp要求使用可靠协议（Internet的TCP协议）发出命令，而rtspu则使用不可靠协议（Internet的UDP协议）。</P>
<P>如是端口为空或没指定，则缺省为80端口。对于rtsp_URI来说，拥有被请求的<BR>资源的服务器主机通过侦听该端口的TCP连接(rtsp)或UDP包(rtspu)来接收该URI请求。</P>
<P>只要可能，应尽量避免的在URL中直接使用IP地址。（请参考RFC1924）</P>
<P>文本媒体标识符使用URL中的字符集及转义规则（参考RFC1738）来标识一个表示(presentation)与单个流(stream)。URL可以用于单个流或者多个流的集合，比如表示(presentation)。因此，在第十章所描述的请求(request)可以用于整个表示
(presentation)或表示中的单个流。注意，有些请求方法仅能用于流而不能用于表示，反之亦然。</P>
<P>例如：RTSP
URL:<BR>rtsp://media.example.com:554/twister/audiotrack<BR>标识了twister表示(presentation)中，可以通过media.example.com554端口的TCP连接发送RTSP请求来控制的音频流。</P>
<P>也可以是这样RTSP
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -