RFC2326(中文版)-实时流协议(RTSP)

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

实时流协议(RTSP)(RealTimeStreamingProtocol(RTSP))备忘录的状态:本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。版权声明:版权为TheInternetSociety所有。所有权利保留。摘要:实时流协议(RTSP)是应用层协议,控制实时数据的传送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP(RFC1889)上传送机制提供方法。目录:1绪论51.1目的51.2要求61.3术语61.4协议特点71.5RTSP扩展81.6操作模式91.7RTSP状态91.8与其他协议关系102符号协定103协议参数103.1RTSP版本103.2RTSPURL113.3会议标识133.4会话标识133.5SMPTE相对时间戳133.6正常播放时间143.7绝对时间153.8选择标签153.8.1用IANA注册新的选择标签154RTSP消息154.1消息类型164.2消息标题174.3消息主体174.4消息长度185普通标题域186请求196.1请求队列196.2请求标题域197回应207.1状态行207.1.1状态代码和原因分析207.1.2回应标题域238实体238.1实体标题域248.2实体主体249连接259.1流水线操作259.2可靠性及确认2510方法定义2510.1选择2610.2描述2610.3通告2610.4建立2610.5播放2710.6暂停2710.7断开2710.8获取参数2810.9设置参数2810.10重定向2810.11录制2910.12嵌入二进制数据2911状态代码定义(StatusCodeDefinitions)2911.1成功2xx(Success2xx)3011.1.1存储空间低2503011.2重定向(Redirection3xx)3111.3客户端错误(ClientError)4xx3111.3.1方法不允许3211.3.2参数不能理解3211.3.3会议未找到3311.3.4带宽不足3311.3.5会话未找到3411.3.6本状态下该方法无效3411.3.7标题域对资源无效3411.3.8无效范围3511.3.9参数只读3511.3.10不允许合操作3611.3.11只允许合操作3611.3.12不支持的传输3611.3.13目标不可达3711.3.14选择不支持3712标题域定义(HeaderFieldDefinitions)3812.1接受3812.2接受编码3812.3接受语言3912.4允许(Allow)3912.5授权(Authorization)4012.6带宽4012.7块大小4012.8缓存控制4112.9会议4112.10连接4112.11基本内容4212.12内容编码(Content-Encoding)4212.13内容语言4312.14内容长度(Content-Length)4312.15内容位置4312.16内容类型(Content-Type)4412.17序列号4412.18日期(Date)4412.19过期(Expires)4512.20来自(From)4512.21主机4512.22如果匹配4512.23从何时更改(If-Modified-Since)4612.24最近更改(Last-Modified)4612.25位置(Location)4612.26代理授权4712.27代理要求4712.28公用性4712.29范围4912.30提交方(Referer)4912.31稍后再试4912.32要求4912.33RTP信息4912.34比例4912.35速度4912.36服务器(Server)4912.37会话4912.38时间戳4912.39传输4912.40不支持4912.41用户代理(User-Agent)4912.42变化4912.43通过4912.44授权()5013缓存5014实例5014.1要求媒体(单播)5014.2容器文件的流5114.3单个流容器文件5114.4组播现场媒体表示5114.5在存在的会话中播放媒体5114.6录制5215语法5215.1基本语法5216安全考虑(SecurityConsiderations)52附录ARTSP协议状态机53A.1客户端状态机53A.2服务器端状态机53附录B同RTP协议的交互53附录C使用SDP进行RTSP会话描述54C.1定义54C.1.1控制URL55C.1.2媒体流55C.1.3有效载荷类型55C.1.4详细格式参数55C.1.5表示的范围56C.1.6有效时间56C.1.7连接信息56C.1.8实体标签57C.2合控制不可用57C.3合控制可用57附录D最简单的RTSP实现58D.1客户端58D.1.1回放58D.1.2授权58D.2服务器59D.2.1回放59D.2.2授权59附录E作者地址60附录F致谢60参考书目60版权申明611绪论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)中的每个流可放在不同服务器上,用户端自动同不同服务器建立几个并发控制连接,媒体同步在传输层执行。记录设备控制:协议可控制记录和回放设备,也可控制可在记录和回放切换的设备。流控与会议开始分离:流控与邀请媒体服务器入会分离;仅要求会议初始化协议提供,或可用来创建唯一会

1 / 39
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功