RTSP协议详解.doc

关于RTSP.RTSP协议是一个非常类似HTTP协议的流控制协议它们都使用纯文本來发送信息，而且rtsp协议的语 法也和HTTP类似Rtsp 一开始这样设计，也是为了能够兼容使用以前写的HTTP协议分析代码这是 个好消息它们主要的区别是HTTP协议是没有状态的,http协议在发送一个命令后，连接会断开，而且命令之间 没有依赖性不同的是RTSP的命令需要愆道现在正处于一个什么状态，也就是说rtsp的命令总是按照顺 序來发送,某个命令总在另外一个命令之前要发送Rtsp不管处于什么状态都不会去断掉连接HTTP协议默认使用80端LI,而RTSP默认使用554端口如果一些服务器因为某些安全的原因而封掉 了这个端口,那代理和防火墙可能不让RTSP消息通过，需要管理员去放开554端口，而使得rtsp协议 能通过RTSP并非只是微软在用！这是一个公开的规范，在这个规范上开发了很多的流服务器甚至Linux服务提供者和苹果的程序员也使 用rtsp协议以及Real Networks流媒体似乎整个世界的网络流传输都用这个协议然而，微软并不只在 rtsp上有所作为微软和RTSP.在写这个文档的时候，微软正处于从首选MMS协议转换到首选采用RTSP协议的过程中。

这个说明在 Media Player9.0版本和流媒体服务器2003版本之后，我们会看到微软将rtsp协议作为流媒体传输的主 要协议随着时间慢慢的流逝,我们会发现mms协议正逐步走出人们的视野° It is only assumed that this is so MS can say they are being open with their protocols （rtsp is an open standard） while at the same time disregard!ng the need to publicise their own MMS protocol once its gone from media player 然［flj. mms 还没右，真的夕匕亡， 至少在接下來的几年中我们依然可以看到它在流媒体传输中的身影是否微软的RTSP协议和标准的开放式RTSP不同？是的跟在RFC2326 （ 1998年四月）中定义的瓯始RTSP协议相比，微软的rtsp协议有一些轻微的改 动我们网站上有本文档（还有后续版本）和一个简单的研究,它们可以帮助你了解这些信息区别在哪儿？微软的rstp规范与标准rtsp协议相比最主要的改动是发送包payloads到客户端的方式，另外还有一些 请求命令有一些改动。

传输单个媒体包的机制并没有文档（就我日前所知），这可能是微软要保阳的信息就像MMS和HTTP 1.0流协议使用一个媒体数据包头一样，RTSP也有但毘微软的数据包头格式没有 在任何的rtsp文档中注明在企图连接微软的rtsp服务器时，这是主要的问题微软RTSP协议的命令采用的语法和标准rtsp协议的命令语法一样，只有一些小的修改和添加，可以通过 阅读网上的一些文档，就可以知道怎么去组成这些命令微软rtsp命令部分已经有文档了—次典型的RTSP协议传输过程这个例子为了简略，没有把发送接收的包放上來To Server =>NETWORK<=To Client客户端连服务器的554端口客户端发送“DESCRIBE”命令服务器返冋标准rtsp头这个rtsp头和数据实体包含ASF文件头信息以及所有的和媒体文件相关的流bit rate data客户端发送“SETUP''音频流媒体建立命令(stream 1)服务器返回标准rtsp头客户端发送“SETUP”视频流媒体建立命令(stream 2)服务器返冋标准rtsp头客户端发送“PLAY”命令服务器返冋标准rtsp头客户端发送“SET_PARAMETER”命令这个命令还包含了一些客户端发送给服务器的信息，比如客户端的操作系统，CPU类型，播放器 版木，日期时间等信息。

消息格式是tagged XML.服务器返冋标准rtsp头####服务器即将开始一个流，发送媒体数据包 (包含媒体数据包头)，请看接下來的####当要 断开这个流的时候，服务器会向客户端发送一个 EOF指示服务器断开socket连接一个典型的发给服务器的RTSP命令DESCRIBE rtsp:// RTSP/1.0User-Agent: WMPIayer/9.0.0.2980 guid/3300AD50-2C39-46C0-AE0A-81D88F547805Accept: application/sdpAccept-Charset: UTF-8, *;q=0.1X-Accept-Authentication: NTLM, Digest, BasicAccept-Language: en-GB, *;q=0.1CSeq: 1Supported: com ・microsoft・wm・srvppair; com. microsoft.wm.sswitch, com .microsoft.wm.eosrnsg,com. microsoft.wm.predstrm注意：DESCRIBE rtsp:// RTSP/1.0这是要连接的url （服务器域名和流路径），后面跟着RTSP的版木。

User-Age nt: WMPIayer/9.0.0.2980 guid/5300AD50-2C39-46C0-AE0A-81D88F547805这条表示了客户端使用的是什么播放器，以及播放器的版木•再跟着一个独特的GUIDX-Accept-Authentication: NTLM, Digest, Basic客户端可以接受的authentication类型注意CSeq要从1开始服务器针对请求命令的应答也应该有Cseq:加上数字，这样可以知道是针对哪 条请求发的应答在客户端发送一个请求命令.得到成功的应答后，再发送下-•条命令.CSeq的值要加1 o 一个典型的RTSP应答消息，它们跟HTTP的消息非常的相似 一个针对客户端发的DESCRIBE命令，服务器的应答例子如下所示:«RTSP/1.0 200 OKContent-Type: application/sdpVary: AcceptX-Playlist-Gen-ld: 27006X-Broadcast-ld: 0Content-Length: 3324Date: Tue, 18 Nov 2003 15:57:05 GMTCSeq: 1Server: WMServer/9.0.0.3372Supported: com .microsoft.wm.srvppaii; com .microsoft.wm.sswitch， com .microsoft.wm.eosmsg,com.microsoft.wm.fastcach巳 com.microsoft.wm.packetpairssrcLast-Modified: Tue, 18 Jun 2002 21:05:39 GMTCache-Control: x-wms-content-size=23180160, max-age=86399, must-revalidate, proxy-revalidateEtag: "23180160"« （两个“ \r\n ”指示本SDP数据的开始）.«< 这是 Session Description Protocol |办议 »>v=0o=- 200311171721060249 200311171721060249 IN IP4 127.0.0.1s= c=IN IP4 0.0.0.0b=AS:1091 a=maxps:13632t=0 0a=c on trol:rtsp://wm a=etag:{9D7121C3-lAlB-8ED6-6675-CB15D19DlFB7}a=range:npt=3.100-173.903a=recv onlya=pgmpu:data:application/x-wms-c onten tdesc,8」a nguag 巳 3bO〃5，titl 巳 3匕0〃6刁 uthor,3：U0〃9,copyright，3：L0〃35，W MS_CONTENT_DESCRIPTION_DESCRIPTION,31,0〃30,WMS_CONTENT_DESCRIPTION_RATING,31,0"44,WIVIS_CON TENT_DESCRIPTION_SERVER_BRANDING」NF0,31 J2M/MServer/9O5bWMS_C0NTENT_DESCRIPTI0N_PLAYLIST _ENTRY_START_0FFSET34,3100,47,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_DURATION,36170803,5 & WMS_CONTENT_DESCRIPTION_COPIED_METADATA_FROM_PLAYLIST_FILE31 丄 42,WMS_CONTENT_DESCRIPTIO N_PLAYLIST_ENTRY_URL,31」7,0001・hi・wmv%0D%0Aa=pgmpu:data:applicatio n/vn d.ms.wms-hdr.asfvl;base64/Mcay...dY5mm2QCAQ==m二audio 0 RTP/AVP 96b=AS:35b=RS:Ob=RR:Oa=rtpmap:96 x-asf-pf/1000a=c on trokaudioa=stream:lm=application 0 RTP/AVP 96b=RS:O b=RR:0a=rtpmap:96 x-wms-rtx/1000 a=c on trokrtxa=stream:65536m=video 0 RTP/AVP 96b=AS:471b=RS:0b=RR:0a=rtpmap:96 x-asf-pf/1000a=c on trol:stream=2a=stream:2以\r\n\r\n结束看下面这行：a=pgmpu:data:application/vnd・ms・wms・hdr・asfvl;base64〃 Mcay.....==这是真实的ASF文件头数据（被Base64编码过在将这部分头数据写到文件之前需要Base64解码成标准的ascii码。

SDP实体数据也告诉我们在媒体数据中都有些什么流这个文件有2个媒体流：ID = 1有一个“audio”标志的音频流ID = 2有一个“stream=2”标志的视频流还有第三个以“ rtx ”标志的流，这是一个控制流，并不携带任何的媒体内容这个控制流使用stream ID=65536.看下面这行:a=pgmpu:data:application/x-wms-contentdesc, ••…这表示了紧跟的数据是i个内容描述对象标准RTSP消息的错误代码-在应答消息的第一行表示TOO" ; Continue (all 100 range)"200〃; OK"2。