RTSP报文交互过程

1、RTSP报文交互方式详解 王启东 fw0027RTSP是Real Time Streaming Protocol,实时流传输协议的简写，用来描述实时流传输的协议控制。它是一个基于文本的协议，依然基于C/S架构，有典型的request和reply的交互过程。第一部分：RTSP报文标准交互流程一个完整的RTSP交互过程如下，请求一段录像文件或者实时流，需要交互如下报文过程：第一个过程：options字段，用于确认后续的操作动作，包括实时流的的播放暂停等动作。响应报文中包含：DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECO

2、RD。标准的交互过程：1. OPTIONSclient->server=OPTIONS rtsp:/115.182.51.79/zuoyou001.mp4 RTSP/1.0CSeq: 2User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)server->client=RTSP/1.0 200 OKServer: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )Cseq:

3、 2Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD第二个过程，describe交互过程。顾名思义，describe字段用来描述所请求的码流的详细描述，比如请求的码流的传输模式是RTP格式，封装格式是MP4。这个报文的回复消息也通过SDP来描述会话信息，与SIP的交互过程很相似，标准的报文流程：2. DESCRIBEclient->server=DESCRIBE rtsp:/115.182.51.79/zuoyou001.mp4 RTSP/1.0CSeq: 3User-Agent: LibV

4、LC/1.1.11 (LIVE555 Streaming Media v2011.05.25)Accept: application/sdpserver->client=RTSP/1.0 200 OKServer: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )Cseq: 3Last-Modified: Thu, 17 Jan 2002 11:20:30 GMTCache-Control: must-revalidateContent-lengt

5、h: 876Date: Wed, 04 Jan 2012 06:14:53 GMTExpires: Wed, 04 Jan 2012 06:14:53 GMTContent-Type: application/sdpx-Accept-Retransmit: our-retransmitx-Accept-Dynamic-Rate: 1Content-Base: rtsp:/115.182.51.79/zuoyou001.mp4/v=0o=StreamingServer 3534646499 1011266430000 IN IP4 115.182.51.79s=/zuoyou001.mp4u=h

6、ttp:/e=adminc=IN IP4 0.0.0.0b=AS:632t=0 0a=control:*a=x-copyright: MP4/3GP File hinted with GPAC 0.4.6-DEV (build 1 - May 19 2009) - compiled by Kurtnoise (C)2000-2005 - a=range:npt=0-6640.12667m=video 0 RTP/AVP 96b=AS:600a=3GPP-Adaptation-Support:1a=rtpmap:96 H264/90000a=control:trackID=65536a=fmtp

7、:96 profile-level-id=4D401E; packetization-mode=1; sprop-parameter-sets=Z01AHpp0BaGdgIgAAAMACAAAAwGUeLF1,aO48gA=a=framesize:96 720-400m=audio 0 RTP/AVP 97b=AS:32a=3GPP-Adaptation-Support:1a=rtpmap:97 mpeg4-generic/24000/2a=control:trackID=65537a=fmtp:97 profile-level-id=40; config=131056e59d4800; st

8、reamType=5; mode=AAC-hbr; objectType=64; constantDuration=2048; sizeLength=13; indexLength=3; indexDeltaLength=3第三、四个过程，setup操作，用来建立媒体流传输通道，两个封装格式是一样的。其中第一条setup操作用来建立音频流传输通道，第二条setup用来建立视频流传输通道。这两个报文，会携带收发端的通道号，单组播类型，ssrc id（用来标志媒体流的类型）。标准的交互流程：3. SETUPclient->server=SETUP rtsp:/115.182.51.79/zu

9、oyou001.mp4/trackID=65536 RTSP/1.0CSeq: 4User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)Transport: RTP/AVP/TCP;unicast;interleaved=0-1server->client=RTSP/1.0 200 OKServer: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )Cseq: 4Last-Mo

10、dified: Thu, 17 Jan 2002 11:20:30 GMTCache-Control: must-revalidateSession: 1837199341906602386Date: Wed, 04 Jan 2012 06:14:53 GMTExpires: Wed, 04 Jan 2012 06:14:53 GMTTransport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=0E4646D1第五个操作，点播play过程。Play过程主要用于前面协商的视频参数，根据获取到的URL地址进行点播，这个URL包括ip地址和路径，其中还会携带

11、rtp时间戳和NTP时间格式。从交互过程上看非常简洁，一目了然。4. PLAYclient->server=PLAY rtsp:/115.182.51.79/zuoyou001.mp4/ RTSP/1.0CSeq: 6User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)Session: 1837199341906602386Range: npt=0.000-server->client=RTSP/1.0 200 OKServer: DSS/6.0.3 (Build/526.3; Platform/FreeBS

12、D; Release/Darwin Streaming Server; State/Development; )Cseq: 6Session: 1837199341906602386Range: npt=0.00000-6640.12667RTP-Info: url=rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=550154668.第六个过程，拆线报文t

13、eardown。Teardown过程由客户端向服务器发起，交互完成即完成会话释放。标准交互流程：5. TEARDOWN client->server=TEARDOWN rtsp:/115.182.51.79/zuoyou001.mp4/ RTSP/1.0CSeq: 7User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)Session: 1837199341906602386server->client。以上报文交互是标准的一个RTSP会话建立传输以及释放的过程必选报文。除此之外还有一些可选报文，举例如下：AN

14、NOUNCEC->SS->C可选当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。比如新插入一个媒体流时，加入混合器后的会话通告。GET_PARAMETERC->SS->C可选GET_PARAMETER请求检查RUL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况。所以通常用这个报文来做客户端和服务器的探针报文（设备保活）PAUSEC->S推荐PAUSE 请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL

15、命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订RECORDC->S可选该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201(创建)，并包含描述请求状态和参考新资源的实体与位置头。REDIRECTS->C可选重定向请求通知客户端连接到另一服

16、务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求SET_PARAMETERC->SS->C可选这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。第二部分：详

17、解我司不同产品组件对RTSP报文的交互鉴于开发时的不同产品组件形态，我司DA、ECR以及ISC产品对RTSP不同的流程所用的消息字段也不一致。下面介绍几个典型产品的字段应用：DA侧：DA如果使用RTSP配合ONVIF接入第三方IPC时，第一条option字段不会发送，必须支持setup、play和teardown。而DA和onvif ipc保活时使用的是协议推荐的SET_PARAMETER消息，而DA用于录像回放时采用options字段，字段中会携带时间戳标记。NVR侧：a.第一条option消息实际不会发，因为默认setup、play和teardown都必须支持，b.setup可能发一条，可

18、能发两条，根据是describe响应消息中会告诉是否支持音频，如果支持音频，会发两条setup，如果不支持音频，则只会发一条setup，c.如果发两条setup，则第一个setup是视频，第二个setup是音频，文档中第一个是音频肯定也是可以的，但我们的实现是第一个发视频的，d.发送play后需要有保活，可以用get_parameter或者option，我们用的是option保活。e.如果是回放，还需要通过RTSP OPTIONS字段支持快进快退后退暂停等功能，实况流不需要。最后附上：RTSP的报文响应状态：“100” ; Continue (all 100 range)“200” ; OK“

19、201” ; Created“250” ; Low on Storage Space“300” ; Multiple Choices“301” ; Moved Permanently“302” ; Moved Temporarily“303” ; See Other“304” ; Not Modified“305” ; Use Proxy“350” ; Going Away“351” ; Load Balancing“400” ; Bad Request“401” ; Unauthorized“402” ; Payment Required“403” ; Forbidden“404” ; Not Found“405” ; Method Not Allowed“406” ; Not Acceptable“407” ; Proxy Authentication Required“408” ; Request Time-out“410” ; Gone“411” ; Length Required“412” ; Precondition F