RTSP协议详解

1、概述

1.1  RTSP简介

        RTSP（Real Time Streaming Protocol）,实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准，该协议定义了一对多应用程序如何有效地通过IP网络传输多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。

流媒体服务协议栈：

        RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议的目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

        它的语法和运行跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。

        HTTP与RTSP相比，HTTP传送HTML，HTTP请求由客户端发出，服务器做出响应；RTSP传送的是多媒体数据，使用RTSP时，客户端和服务器都可以发出请求，即RTSP可以是双向的。

        RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协议并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容。

        而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络配置，更进而支持多方视频会议（Video Conference）。因为与HTTP1.1的运作方式相似，所以代理服务器<Proxy>的快取功能<Cache>也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

        该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。

        实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

        协议支持的操作如下：（1）从媒体服务器上检索媒体：用户可通过HTTP或其他方法提交一个演示描述。如演示是组播，演示就包含用于连续媒体的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。（2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方轮流按远程控制按钮。（3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。和HTTP/1.1类似，RTSP请求可由代理、通道与缓存处理。

1.2 协议特点

• 可扩展性：新方法和参数很容易加入RTSP
• 易解析：RTSP可由标准HTTP或MIME解析器解析
• 安全：RTSP使用网页安全机制
• 独立于传输：RTSP可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；如要实现应用级可靠，可使用可靠流协议
• 多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
• 记录设备控制：协议可控制记录和回放设备
• 流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会
• 适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑
• 演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL
• 代理与防火墙友好：协议可由应用或传输层防火墙处理。防火墙需要连接SETUP方法，为UDP媒体流打开一个“缺口”
• HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTTP添加方法
• 适当的服务器控制：如用户启动一个流，必须也可以停止一个流
• 传输协调：实际处理连续媒体流前，用户可协调传输方法
• 性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效，这允许用户提出适合的用户界面

2、协议细节

2.1 典型的rtsp交互过程

      C表示rtsp客户端，S表示rtsp服务端

      1. C—>S：OPTION request                //询问S有哪些方法可用                                               

      1.S—>C：OPTION response             //S回应信息中包括提供的所有可用方法                    

                                                                                                                                                               

      2. C—>S：DESCRIBE request          //要求得到S提供的媒体初始化描述信息                   

      2. S—>C：DESCRIBE response       //S回应媒体初始化描述信息，主要是sdp                 

                                                                                                                                                               

      3. C—>S：SETUP request                 //设置会话的属性，以及传输模式，提醒S建立会话

      3. S—>C：SETUP response              //S建立会话，返回会话标识符，以及会话相关信息

                                                                                                                                                               

      4. C—>S：PLAY request                     //C请求播放                                                                   

      4. S—>C：PLAY response                 //S回应请求的信息                                                        

      S—>C：发送流媒体数据                                                                                                             

                                                                                                                                                               

      5. C—>S：TEARDOWN request        //C请求关闭会话                                                           

      5. S—>C：TEARDOWN response     //S回应该请求                                                               

      上述的过程是标准的、友好的RTSP流程，但实际的需求中并不一定按部就班来，其中第3和第4步是必需的！

      第一步，只要服务器和客户端约定好有哪些方法可用，则option请求可以不要

      第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

      第五步，可以根据系统需求的设计来决定是否需要

      

2.2  RTSP消息格式