RFC2326中文版实时流协议RTSP.docx
《RFC2326中文版实时流协议RTSP.docx》由会员分享，可在线阅读，更多相关《RFC2326中文版实时流协议RTSP.docx（42页珍藏版）》请在冰豆网上搜索。
RFC2326中文版实时流协议RTSP
RFC2326（中文版）-实时流协议（RTSP）.txt我的人生有A面也有B面，你的人生有S面也有B面。
失败不可怕，关键看是不是成功他妈。
现在的大学生太没素质了！
过来拷毛片，居然用剪切！
有空学风水去，死后占个好墓也算弥补了生前买不起好房的遗憾。
实时流协议（RTSP）
（RealTimeStreamingProtocol（RTSP））
备忘录的状态：
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”（STD1）来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明：
版权为TheInternetSociety所有。
所有权利保留。
摘要：
实时流协议（RTSP）是应用层协议，控制实时数据的传送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP（RFC1889）上传送机制提供方法。
目录：
1绪论5
1.1目的5
1.2要求6
1.3术语6
1.4协议特点7
1.5RTSP扩展8
1.6操作模式9
1.7RTSP状态9
1.8与其他协议关系10
2符号协定10
3协议参数10
3.1RTSP版本10
3.2RTSPURL11
3.3会议标识13
3.4会话标识13
3.5SMPTE相对时间戳13
3.6正常播放时间14
3.7绝对时间15
3.8选择标签15
3.8.1用IANA注册新的选择标签15
4RTSP消息15
4.1消息类型16
4.2消息标题17
4.3消息主体17
4.4消息长度18
5普通标题域18
6请求19
6.1请求队列19
6.2请求标题域19
7回应20
7.1状态行20
7.1.1状态代码和原因分析20
7.1.2回应标题域23
8实体23
8.1实体标题域24
8.2实体主体24
9连接25
9.1流水线操作25
9.2可靠性及确认25
10方法定义25
10.1选择26
10.2描述26
10.3通告26
10.4建立26
10.5播放27
10.6暂停27
10.7断开27
10.8获取参数28
10.9设置参数28
10.10重定向28
10.11录制29
10.12嵌入二进制数据29
11状态代码定义（StatusCodeDefinitions）29
11.1成功2xx（Success2xx）30
11.1.1存储空间低25030
11.2重定向（Redirection3xx）31
11.3客户端错误（ClientError）4xx31
11.3.1方法不允许32
11.3.2参数不能理解32
11.3.3会议未找到33
11.3.4带宽不足33
11.3.5会话未找到34
11.3.6本状态下该方法无效34
11.3.7标题域对资源无效34
11.3.8无效范围35
11.3.9参数只读35
11.3.10不允许合操作36
11.3.11只允许合操作36
11.3.12不支持的传输36
11.3.13目标不可达37
11.3.14选择不支持37
12标题域定义（HeaderFieldDefinitions）38
12.1接受38
12.2接受编码38
12.3接受语言39
12.4允许（Allow）39
12.5授权（Authorization）40
12.6带宽40
12.7块大小40
12.8缓存控制41
12.9会议41
12.10连接41
12.11基本内容42
12.12内容编码（Content-Encoding）42
12.13内容语言43
12.14内容长度（Content-Length）43
12.15内容位置43
12.16内容类型（Content-Type）44
12.17序列号44
12.18日期（Date）44
12.19过期（Expires）45
12.20来自（From）45
12.21主机45
12.22如果匹配45
12.23从何时更改（If-Modified-Since）46
12.24最近更改（Last-Modified）46
12.25位置（Location）46
12.26代理授权47
12.27代理要求47
12.28公用性47
12.29范围49
12.30提交方（Referer）49
12.31稍后再试49
12.32要求49
12.33RTP信息49
12.34比例49
12.35速度49
12.36服务器（Server）49
12.37会话49
12.38时间戳49
12.39传输49
12.40不支持49
12.41用户代理（User-Agent）49
12.42变化49
12.43通过49
12.44WWW-授权（WWW-Authenticate）50
13缓存50
14实例50
14.1要求媒体（单播）50
14.2容器文件的流51
14.3单个流容器文件51
14.4组播现场媒体表示51
14.5在存在的会话中播放媒体51
14.6录制52
15语法52
15.1基本语法52
16安全考虑（SecurityConsiderations）52
附录ARTSP协议状态机53
A.1客户端状态机53
A.2服务器端状态机53
附录B同RTP协议的交互53
附录C使用SDP进行RTSP会话描述54
C.1定义54
C.1.1控制URL55
C.1.2媒体流55
C.1.3有效载荷类型55
C.1.4详细格式参数55
C.1.5表示的范围56
C.1.6有效时间56
C.1.7连接信息56
C.1.8实体标签57
C.2合控制不可用57
C.3合控制可用57
附录D最简单的RTSP实现58
D.1客户端58
D.1.1回放58
D.1.2授权58
D.2服务器59
D.2.1回放59
D.2.2授权59
附录E作者地址60
附录F致谢60
参考书目60
版权申明61
1绪论
1.1目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
尽管连续媒体流与控制流有可能交叉，但RTSP本身通常并不发送连续媒体流。
换言之，RTSP充当多媒体服务器的网络远程控制。
表示描述（presentationdescription）定义了被控流，但本文并没有定义表示描述的格式。
这里没有使用RTSP连接的概念，而由RTSP会话（session）代替（每次服务由服务器端保持一个带标签的会话）。
RTSP会话没有绑定到传输层连接（如TCP连接）。
因为虽然在RTSP会话期间，RTSP客户端可打开或关闭多个对服务器端的可靠传输连接以发出RTSP请求。
但此外，也可能使用无连接传输协议，比如用UDP发送RTSP请求。
RTSP控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。
尽管如此，RTSP在很多方面还是和HTTP有很大的不同：
2RTSP引入了很多新方法并且有不同的协议标识符。
2RTSP服务器在大多数默认情况下需要维持一个状态，但HTTP是无状态协议。
2RTSP客户机和服务器都可以发出请求。
2数据由另一个协议传送（有一特例除外）。
2RTSP使用ISO10646（UTF-8）而不是ISO8859-1，以配合当前HTML的国际化。
2RTSP使用URI请求时包含绝对URI。
而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中。
这使得“虚拟主机”实现更为简便，一个单独IP地址的主机可虚拟为几个文件树主机。
协议支持的操作如下：
从媒体服务器上检索媒体：
用户可通过HTTP或其它方法请求一个表示描述。
如表示是组播，表示描述就包含用于连续媒体的的组播地址和端口。
如表示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。
这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。
如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
1.2要求
在本文档中的关键字“必须”，“一定不能”，“要求”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，和“可选择的”都在RFC2119中解释。
1.3术语
一些术语原由HTTP/1.1采用。
在HTTP/1.1中定义的术语这里不再列举。
合控制：
服务器使用单条时间线对多个流的控制。
对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回馈。
会议：
多方参与的多媒体表示，这里的多方意味着大于或者等于一方。
客户端：
指请求媒体服务器上连续流媒体数据的客户端。
连接：
两个应用程序以通讯为目的在传输层建立虚拟电路。
容器文件：
可以容纳多个共同播放时包含表示（presentation）的媒体流的文件。
RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不是本协议内容。
连续媒体：
接受器和数据源之间存在时序关系的数据。
也就是说，接受器需要重新产生存在于源数据中的时序关系。
最普通的连续媒体的例子是音频和动画视频。
连续媒体可以是实时的（但是不交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。
实体：
作为请求或者回应的有效负荷传输的信息。
由以实体标题域（entity-headerfield）形式存在的元信息和以实体主体（entitybody）形式存在的内容组成，如第八章所述。
媒体的初始化：
数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。
用户请求媒体回放的任何独立传输信息，是在创建流时初始化媒体流相位时产生的。
媒体参数:
针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。
媒体服务器：
可对一个或多个媒体流提供回放和录制服务的服务器。
同一个表示（presentation）中不同的媒体流可能来自于不同的媒体服务器。
媒体服务器可以建立在作为传送请求表示（presentation）的Web服务器的主机上，也可以建立在不同的主机上。
媒体服务器重定向：
重新定向媒体客户端到另外一个媒体服务器。
（媒体）流：
单个媒体实例，比如，在应用中共用音频流或视频流。
当使用RTP时，流包括由RTP会话（session）中源所创建的所有RTP和RTCP包。
这和定义DSM-CC流时相同。
消息：
RTSP通讯的基本单元。
由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。
参与者：
一个会议成员。
参与者可以是机器，比如是媒体记录或回放服务器。
表示（presentation）：
对用户请求所回馈的一组流，其使用下面的表示描述（presentationdescription）形式。
在本文中的多数情况下，其意味着对流进行总体控制，但这并不是必须的。
表示描述（presentationdescription）：
表示描述包含在表示（presentation）中一个或者多个媒体流的信息。
比如，编码，网络地址和内容的信息。
另外，其他IETF协议，如SDP协议使用会话（session）代替现场presentation。
表示描述可以采用包括会话描述（sessiondescription）SDP在内的多种格式。
回应：
RTSP回应。
如果能理解HTTP回应，就能清楚的理解RTSP回应。
请求；
RTSP请求。
如果能理解HTTP请求，就能清楚的理解RTSP请求。
RTSP会话（session）：
RTSP交互的全过程。
比如，一个电影的观看过程。
会话（session）包括由客户端建立连续媒体流传输机制（SETUP），使用播放（PLAY）或录制（RECORD）开始传送流，用停止（TEARDOWN）关闭流。
传输初始化：
客户端和服务器端之间传输信息（端口号，传输协议等）的交互。
1.4协议特点
RTSP特性如下：
可扩展性：
RTSP中很容易加入新方法和参数。
易解析：
RTSP可由标准HTTP或MIME解析器解析。
安全：
RTSP使用网页安全机制。
所有HTTP授权机制如basic和digest授权都可直接使用。
也可以传输层或网络层安全机制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
表示（presentation）中的每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：
协议可控制记录和回放设备，也可控制可在记录和回放切换的设备。
流控与会议开始分离：
流控与邀请媒体服务器入会分离；仅要求会议初始化协议提供，或可用来创建唯一会议标识号。
特殊情况下，SIP或H.323可用来邀请服务器入会。
适合专业应用：
通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
表示描述中立：
协议没强加特殊表示或元文件，可传达所用格式类型；然而，表示描述至少必须包含一个RTSPURI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。
防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。
结构包括Internet内容选择平台（PICS）。
由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTTP添加方法。
适当的服务器控制：
如用户能启动一个流，它必须也能停止一个流。
服务器不能启动一个用户不能停止的流。
传输协调：
实际处理连续媒体流前，用户可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。
这允许用户提出适合的用户界面。
例如，如果不允许寻找，用户界面必定能禁止位置条滑动。
以前要求RTSP必须能支持多用户，但现在得出一个更好的方法就是保证RTSP能很容易扩展成支持多用户即可。
因为流的标志可以被多个控制流使用，因此”远程通过”成为可能。
协议不涉及到多个客户端如何协调入口，其由下层“社会协议”或其他下层控制机制提供。
1.5RTSP扩展
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。
例如：
?
服务器可能只须支持回放，因此不必不支持录制功能。
?
对于支持现场播放的服务器可能不支持寻找功能。
?
一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER。
但服务器应该实现所有12章中要求的标题域。
表示描述（presentationdescription）应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1中[H19.6]描述方法不支持acrossserver的情形一致。
RTSP可以如下三种方式扩展，这里以改变大小排序：
?
以新参数扩展。
如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
?
加入新方法。
如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。
用户可使用OPTIONS方法查询服务器支持的方法。
服务器使用公共回应标题列出支持的方法。
?
定义新版本协议，允许改变所有部分。
（除了协议版本号位置）
1.6操作模式
每个表示和媒体流可用RTSPURL识别。
表示组成的整个表示与媒体属性由表示描述（presentationdescription）文件定义，表示描述格式不在本协议中定义。
使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
为了说明，假设表示描述（presentationdescription）描述了多个表示（presentation），其中每个表示（presentation）维持了一个公共时间轴。
为简化说明，且不失一般性，假定表示描述（presentationdescription）的确包含这样一个表示（presentation）。
表示（presentation）可包含多个媒体流。
表示描述（presentationdescription）即组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。
在表示描述中，被RTSP分别控制的媒体流由RTSPURL表示。
RTSPURL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。
多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而负载共享。
描述（description）还列出了服务器传输可使用的方法。
除媒体参数外，网络目标地址和端口也需要决定。
下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
1.7RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。
例如，RTSP控制可通过TCP连接，而数据流通过UDP。
因此，即使媒体服务器没有收到请求，数据也会继续发送。
在会话生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。
所以，服务器需要维持能联系流与RTSP请求的会话状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
补充反馈方式（augmentedBNF）包括下面的结构：
要解释的名词＝名词解释（name=definition）
规则的名字（name）就是它本身（不带任何尖括号，“<”，“>”），后面跟个等号＝，
然后就是该规则的定义。
如果规则需要用多个行来描述，利用空格进行缩进格式排
版。
某些基本的规则使用大写，如SP,LWS,HT,CRLF,DIGIT,ALPHA,等等。
定义
中还可以使用尖括号来帮助理解规则名的使用。
字面意思（"literal"）
文字的字面意思放在引号中间，除非特别指定，该段文字是大小写敏感的。
规则1｜规则2（rule1|rule2）
“｜”表示其分隔的元素是可选的，比如，“是｜否”要选择‘是’或‘否’。
（规则1 规则2）（（rule1rule2））
在圆括号中的元素表明必选其一。
如（元素1（元素2｜元素3）元素4）可表明两
种意思，即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*规则（*rule）
在元素前加星号“*”表示循环，其完整形式是“*元素”，表明元素最少产
生次，最多次。
缺省值是0到无限，例如，“1*元素”意思是至少有一个，
而“1*2元素”表明允许有1个或2个。
［规则］（[rule]）
方括号内是可选元素。
如“［元素1 元素2］”与“*1（元素1 元素2）”是一回
事。
N 规则（Nrule）
表明循环的次数：
“（元素）”就是“*（元素）”，也就是精确指出
取值。
因而，2DIGIT就是2位数字,3ALPHA就是由三个字母组成字符串。
＃规则（#rule）
“#”与“*”类似，用于定义元素列表。
完整形式是“#元素”表示至少有个至多有个元素，中间用“,”或
任意数量的空格（LWS-linearwhitespace）来分隔，这将使列表非常方便，如“（*LWS
元素*（*LWS","*LWS元素））”就等同于“1#元素”。
空元素在结构中可被任意使用，但不参与元素个数的计数。
也就是说，“（元素1），，
（元素2）”仅表示2个元素。
但在结构中，应至少有一个非空的元素存在。
缺省
值是0到无限，即“#（元素）”表示可取任何数值，包括0；而“1#元素”表示至
少有1个；而“1#2元素”表示有1个或2个。
；注释（;comment）
分号后面是注释，仅在单行使用。
隐含*LWS（implied*LWS）
本文的语法描述是基于单词的。
除非另有指定，线性空格（LWS）可以两个邻近符
号或分隔符（tspecials）之间任意使用，而不会对整句的意思造成影响。
在两个符号之
间必须有至少一个分隔符，因为它们也要做为单独的符号来解释。
实际上，应用程序在
产生HTTP结构时，应当试图遵照“通常方式”，因为现在的确有些实现方式在通常方
式下无法正常工作。
在本备忘录中，我们用缩进的小型段落来提供动机和背景资料。
这将使没有参与制定RTSP规范的读者更容易理解RTSP中各部分为什么要以该方式来实现。
3协议参数
3.1RTSP版本
同[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）
升级会员 