RTSP协议详解
定义
RTSP(Real Time Streaming Protocol),RFC2326,实时流传输协议,是TCP/IP协议体系中的一个应用层协议。
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。
RTSP在网络模型(ISO)中的位置
协议支持
实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。
实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外,可使用无连接传输协议,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。
协议支持的操作如下:
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请求必须在连接可再次播放前发布
|
RTSP交互流程
C表示RTSP客户端,S表示RTSP服务端
① C->S: OPTION request //询问S有哪些方法可用
S->C: OPTION response //S回应信息中包括提供的所有可用方法
② C->S: DESCRIBE request //要求得到S提供的媒体初始化描述信息
S->C: DESCRIBE response //S回应媒体初始化描述信息,主要是sdp
③ C->S: SETUP request //设置会话属性,以及传输模式,提醒S建立会话
S->C: SETUP response //S建立会话,返回会话标识符及会话相关信息
④ C->S: PLAY request //C请求播放
S->C: PLAY response //S回应请求信息
S->C: 发送流媒体数据
⑤ C->S: TEARDOWN request //C请求关闭会话
S->C: TEARDOWN response //S回应请求
上述的过程是标准的RTSP流程,其中第3步和第4步是必需的。
OpenCore在执行完PLAYER_SET_DATASOURCE,prepare之后,执行PLAYER_INIT时,如果发现datasource是rtsp流,则进入rtsp模块。
OpenCore的RTSP模块实现在Pvrtsp_client_engine_node.cpp中,PVRTSPEngineNode::SendRtspDescribe()描述了连接建立过程中的状态变化过程。
需要注意的时,opencore在发出OPTION request后,并不会等着收response,而是直接发DESCRIBE request,然后才开始收OPTION response和DESCRIBE response。
Live555在RTSPServer.cpp中用RTSPServer::RTSPClientSession::incomingRequestHandler()来处理来自client端的request。
1. RTSP连接的建立过程
RTSPServer类用于构建一个RTSP服务器,该类同时在其内部定义了一个RTSPClientSession类,用于处理单独的客户会话。
首先创建RTSP服务器(具体实现类是DynamicRTSPServer),在创建过程中,先建立Socket(ourSocket)在TCP的554端口进行监听,然后把连接处理函数句柄(RTSPServer::incomingConnectionHandler)和socket句柄传给任务调度器(taskScheduler)。
任务调度器把socket句柄放入后面select调用中用到的socket句柄集(fReadSet)中,同时将socket句柄和incomingConnectionHandler句柄关联起来。接着,主程序开始进入任务调度器的主循环(doEventLoop),在主循环中调用系统函数select阻塞,等待网络连接。
当RTSP客户端输入(rtsp://192.168.0.1/1.mpg)连接服务器时,select返回对应的socket,进而根据前面保存的对应关系,可找到对应处理函数句柄,这里就是前面提到的incomingConnectionHandler了。在incomingConnectionHandler中创建了RTSPClientSession,开始对这个客户端的会话进行处理。
2. DESCRIBE请求消息处理过程
RTSP服务器收到客户端的DESCRIBE请求后,根据请求URL(rtsp://192.168.0.1/1.mpg),找到对应的流媒体资源,返回响应消息。live555中的ServerMediaSession类用来处理会话中描述,它包含多个(音频或视频)的子会话描述(ServerMediaSubsession)。
RTSP服务器收到客户端的连接请求,建立了RTSPClientSession类,处理单独的客户会话。在建立RTSPClientSession的过程中,将新建立的socket句柄(clientSocket)和RTSP请求处理函数句柄RTSPClientSession::incomingRequestHandler传给任务调度器,由任务调度器对两者进行一对一关联。
当客户端发出RTSP请求后,服务器主循环中的select调用返回,根据socket句柄找到对应的incomingRequestHandler,开始消息处理。先进行消息的解析,如果发现请求是DESCRIBE则进入handleCmd_DESCRIBE函数。根据客户端请求URL的后缀(如1.mpg),调用成员函数DynamicRTSPServer::lookupServerMediaSession查找对应的流媒体信息ServerMediaSession。如果ServerMediaSession不存在,但是本地存在1.mpg文件,则创建一个新的ServerMediaSession。在创建ServerMediaSession过程中,根据文件后缀.mpg,创建媒体MPEG-1or2的解复用器(MPEG1or2FileServerDemux)。再由MPEG1or2FileServerDemux创建一个子会话描述MPEG1or2DemuxedServerMediaSubsession。最后由ServerMediaSession完成组装响应消息中的SDP信息(SDP组装过程见下面的描述),然后将响应消息发给客户端,完成一次消息交互。
SDP消息组装过程:
ServerMediaSession负责产生会话公共描述信息,子会话描述由MPEG1or2DemuxedServerMediaSubsession产生。 MPEG1or2DemuxedServerMediaSubsession在其父类成员函数OnDemandServerMediaSubsession::sdpLines()中生成会话描述信息。在sdpLines()实现里面,创建一个虚构(dummy)的FramedSource(具体实现类为MPEG1or2AudioStreamFramer和MPEG1or2VideoStreamFramer)和RTPSink(具体实现类为MPEG1or2AudioRTPSink和MPEG1or2VideoRTPSink),最后调用setSDPLinesFromRTPSink(...)成员函数生成子会话描述。
Live555库是一个使用开放标准协议如RTP/RTCP、RTSP、SIP等实现多媒体流式传输的开源C 库集。这些函数库可以在Unix、Windows、QNX等操作系统下编译使用,基于此建立RTSP/SIP服务器和客户端来实现多媒体流的传输。下面给出具体实现过程[4]:
(1)客户端发起RTSP OPTION请求,目的是得到服务器提供什么方法。RTSP提供的方法一般包括OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、SCALE、GET_PARAMETER。
(2)服务器对RTSP OPTION回应,服务器实现什么方法就回应哪些方法。在此系统中,我们只对DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE方法做了实现。
(3)客户端发起RTSP DESCRIBE请求,服务器收到的信息主要有媒体的名字,解码类型,视频分辨率等描述,目的是为了从服务器那里得到会话描述信息(SDP)。
(4)服务器对RTSP DESCRIBE响应,发送必要的媒体参数,在传输H.264文件时,主要包括SPS/PPS、媒体名、传输协议等信息。
(5)客户端发起RTSP SETUP请求,目的是请求会话建立并准备传输。请求信息主要包括传输协议和客户端端口号。
(6)服务器对RTSP SETUP响应,发出相应服务器端的端口号和会话标识符。
(7)客户端发出了RTSP PLAY的请求,目的是请求播放视频流。
(8)服务器对RTSP PLAY响应,响应的消息包括会话标识符,RTP包的***,时间戳。此时服务器对H264视频流封装打包进行传输。
(9)客户端发出RTSP TEARDOWN请求,目的是关闭连接,终止传输。
(10)服务器关闭连接,停止传输。
相比, * HTTP传送HTML. HTTP请求由客户机发出, 服务器作出响应 * RTSP传送的是多媒体数据. 使用RTSP时, 客户机和服务器都可以发出
参考文献:(必看)