RTSP
实时流传输协议（Real Time Streaming Protocol，RTSP），RFC2326（中文版），是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。 [1]
RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。行以CRLF中断，包括消息类型、消息头、消息体和消息长。但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。 [2]
RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。 [3]
协议支持的操作如下：
RTSP协议支持（2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
（3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
集合控制
实体（Entity）
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
容器文件（Containerfile）
可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。
RTSP会话
RTSP交互的全过程。对一个电影的观看过程,会话（session）包括由客户端建立媒体流传输机制（SETUP），使用播放（PLAY）或录制（RECORD）开始传送流，用停止（TEARDOWN）关闭流。 [4]
RTSP协议具有如下特点：
可扩展性：新方法和参数很容易加入RTSP。不同的媒体服务器可以根据各自的功能，支持不同的请求集，扩展自己的新参数、方法，甚至定义新版本协议;当然也正是由于这个特点，使得同一个客户端软件不一定能同时支持不同的媒体服务器。 [11]
易解析：RTSP可由标准HTTP或MIME解析器解析。
安全：RTSP使用网页安全机制。
独立于传输：RTSP可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；如要实现应用级可靠，可使用可靠流协议。
记录设备控制：协议可控制记录和回放设备。
演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。
代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
适当的服务器控制：如用户启动一个流，必须也可以停止一个流。
传输协调：实际处理连续媒体流前，用户可协调传输方法。
性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。
RTSP中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，RTSP是对称的协议，客户机和服务器都可以发送和回应请求。RTSP是一个基于文本的协议，它使用UTF -8编码（RFC2279）和ISO10646字符序列，采用RFC882定义的通用消息格式，每个语句行由CRLF结束。RTSP的消息包括请求和应答两类。
请求消息
请求消息由请求行、标题行中的各种标题域和主体实体组成。请求行和标题行由ASCⅡ字符组成。
图1 请求消息格式其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行后面的CRLF表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个CRLF。消息体是可选的，有的请求消息并不带消息体 [5]
应答消息
图2 应答消息格式RTSP版本
H.321采用，用RTSP代替HTTP。
RTSPURL
“rksp"和“rtspu"方案用于指RTSP协议使用的网络资源，为RTSP URL定义方案特定的语法和语义。
会议标识
会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何八位组数值。会议标识必须全局惟一。
连接标识
连接标识是长度不确定的字符串，必须随机选择，至少要8个八位组长，使其很难被猜出。
SMPTE相关时标
SMPTE相关时标表示相对剪辑开始的时间，相关时标表示成SMPTE时间代码，精确到帧级。时间代码格式为小时：分钟：秒：帧。缺省smpte格式是"SMPTE 30"，帧速率为每秒29.97帧。其他SMPTE代码可选择使用smpte时间获得支持（如"SMPIE 25"）。时间数值中帧段值可从0到29。每秒30与29.97帧的差别可将每分钟的头两帧丢掉来实现。如帧值为零，就可删除。
正常播放时间
正常播放时间（NPT）表示相对演示开始的流绝对位置。时标由十进制分数组成。左边部分用秒或小时、分钟、秒表示；小数点右边部分表示秒的部分。演示的开始对应0.0秒，负数没有定义。特殊常数定义成现场事件的当前时刻，这也许只用于现场事件。直观上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。
绝对时间
可选标签
可选标签是用于指定RTSP新可选项的惟一标记。这些标记用在请求和代理-请求头段。当登记新RTSP选项时，需提供下列信息：
（1）名称和描述选项。名称长度不限，但不应该多于20个字符。名称不能包括空格、控制字符。
（2）表明谁改变选项的控制。如IETF，ISO，ITU-T，或其他国际标准团体、联盟或公司。
（4）对专用选项，附上联系方式。
RTSP是基于文本的协议，采用ISO 10646字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。文本协议很容易以脚本语言（如：Tcl，Visual Basic与Perl）实现研究原型。
ISO 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定：
（1）不管实体头段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。
（2）如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
（3）服务器关闭连接。
注意，RTSP目前并不支持HTTP 1.1“块”传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，但没有定义任何HTTP代码。
RTSP请求可以几种不同方式传送：
· 持久传输连接，用于多个请求/响应传输；
· 每个请求/响应传输一个连接；
· 无连接模式。
传输连接类型由RTSP URL来定义。对“rtsp'’方案，需要持续连接；而"rtspu"方案，调用RTSP请求发送，而不用建立连接。
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。已定义方法如下表所示。
|
方法
|
方向
|
对象
|
要求
|
含义
|
|
DESCRIBE
|
C->S
|
P，S
|
推荐
|
检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE的答复-响应组成媒体RTSP初始阶段
|
|
ANNOUNCE
|
C->S
S->C
|
P，S
|
可选
|
当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除
|
|
GET_PARAMETER
|
C->S
S->C
|
P，S
|
可选
|
GET_PARAMETER请求检查URL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况
|
|
OPTIONS
|
C->S
S->C
|
P，S
|
要求
|
可在任意时刻发出OPTIONS请求，如用户打算尝试非标准请求，并不影响服务器状态
|
|
PAUSE
|
C->S
|
P，S
|
推荐
|
PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订
|
|
PLAY
|
C->S
|
P，S
|
要求
|
PLAY告诉服务器以SETUP指定的机制开始发送数据；直到一些SETUP请求被成功响应，客户端才可发布PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行
|
|
RECORD
|
C->S
|
P，S
|
可选
|
该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义
|
|
REDIRECT
|
S->C
|
P，S
|
可选
|
重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求
|
|
SETUP
|
C->S
|
S
|
要求
|
对URL的SETUP请求指定用于流媒体的传输机制。客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响
|
|
SET_PARAMETER
|
C->S
S->C
|
P，S
|
可选
|
这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示
|
|
TEARDOWN
|
C->S
|
P，S
|
要求
|
TEARDOWN请求停止给定URL流发送，释放相关资源。如URL是此演示URL，任何RTSP连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP请求必须在连接可再次播放前发布
|
注：P----演示，S----流，C----用户端，S----服务器端
某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并增加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII字符$封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。 [6]
当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP可以如下三种方式扩展： [2]
（1） 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
（3） 定义新版本协议，允许改变所有部分（协议版本号位置除外）。
在TCP中RTT估计的初始值为500ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不像HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。
每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其他途径用户可获得这个文件，它没有必要保存在媒体服务器上。为了说明这个问题，假设演示描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。RTSP作为流媒体传输中的控制协议，可以对流媒体提供播放，暂停、快进、慢退等操作。 [10]
下面区分几种操作模式。
RTSP状态机（1） SETUP：让服务器给流分配资源，启动RTSP连接。
（2） PLAY与RECORD：启动SETUP分配流的数据传输。
（3） PAUSE：临时停止流，而不释放服务器资源。
（4） TEARDOWN：释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。
RTSP引入了大量新方法并具有一个不同的协议标识符；
在大多数情况下，RTSP服务器需要保持缺省状态，与HTTP的无状态相对；
RTSP中客户端和服务器都可以发出请求；
在多数情况下，数据由不同的协议传输；
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP。
但是，RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近时，在缓存、代理和授权上采用HTTP功能是有价值的。
词条图册
更多图册
词条图片(5)
概述图册(2)
漫思
