轉(zhuǎn)載自:http://hp.dewen.org/?p=82
關(guān)于 RTSP.
RTSP協(xié)議是一個(gè)非常類似HTTP協(xié)議的流控制協(xié)議。它們都使用純文本來(lái)發(fā)送信息，而且rtsp協(xié)議的語(yǔ)法也和HTTP類似。Rtsp一開(kāi)始這樣設(shè)計(jì)，也是為了能夠兼容使用以前寫(xiě)的HTTP協(xié)議分析代碼 。這是個(gè)好消息。
它們主要的區(qū)別是HTTP協(xié)議是沒(méi)有狀態(tài)的， http協(xié)議在發(fā)送一個(gè)命令后，連接會(huì)斷開(kāi)，而且命令之間沒(méi)有依賴性。不同的是RTSP的命令需要知道現(xiàn)在正處于一個(gè)什么狀態(tài)，也就是說(shuō)rtsp的命令總是按照順序來(lái)發(fā)送，某個(gè)命令總在另外一個(gè)命令之前要發(fā)送。Rtsp不管處于什么狀態(tài)都不會(huì)去斷掉連接。
HTTP 協(xié)議默認(rèn)使用80端口，而RTSP 默認(rèn)使用554端口。如果一些服務(wù)器因?yàn)槟承┌踩脑蚨獾袅诉@個(gè)端口，那代理和防火墻可能不讓RTSP消息通過(guò)，需要管理員去放開(kāi)554端口，而使得rtsp協(xié)議能通過(guò)。
RTSP 并非只是微軟在用！
這是一個(gè)公開(kāi)的規(guī)范，在這個(gè)規(guī)范上開(kāi)發(fā)了很多的流服務(wù)器。甚至Linux服務(wù)提供者和蘋(píng)果的程序員也使用rtsp協(xié)議以及Real Networks流媒體。似乎整個(gè)世界的網(wǎng)絡(luò)流傳輸都用這個(gè)協(xié)議。然而，微軟并不只在rtsp上有所作為。
微軟和RTSP.
在寫(xiě)這個(gè)文檔的時(shí)候，微軟正處于從首選MMS協(xié)議轉(zhuǎn)換到首選采用RTSP協(xié)議的過(guò)程中。這個(gè)說(shuō)明在Media Player9.0版本和流媒體服務(wù)器2003版本之后，我們會(huì)看到微軟將rtsp協(xié)議作為流媒體傳輸?shù)闹饕獏f(xié)議 。
隨著時(shí)間慢慢的流逝，我們會(huì)發(fā)現(xiàn)mms協(xié)議正逐步走出人們的視野。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 disregarding the need to publicise their own MMS protocol once its gone from media player. 然而，mms還沒(méi)有真的死亡，至少在接下來(lái)的幾年中我們依然可以看到它在流媒體傳輸中的身影。
是否微軟的RTSP協(xié)議和標(biāo)準(zhǔn)的開(kāi)放式RTSP不同？
是的。跟在RFC2326（1998年四月）中定義的原始RTSP協(xié)議相比，微軟的rtsp協(xié)議有一些輕微的改動(dòng)。我們網(wǎng)站上有本文檔（還有后續(xù)版本）和一個(gè)簡(jiǎn)單的研究，它們可以幫助你了解這些信息。
區(qū)別在哪兒？
微軟的rstp規(guī)范與標(biāo)準(zhǔn)rtsp協(xié)議相比最主要的改動(dòng)是發(fā)送包payloads到客戶端的方式，另外還有一些請(qǐng)求命令有一些改動(dòng)。傳輸單個(gè)媒體包的機(jī)制并沒(méi)有文檔（就 我目前所知），這可能是微軟要保留的信息。
就像MMS和HTTP 1.0 流協(xié)議使用一個(gè)媒體數(shù)據(jù)包頭一樣，RTSP也有。但是微軟的數(shù)據(jù)包頭格式?jīng)]有在任何的rtsp文檔中注明。在企圖連接微軟的rtsp服務(wù)器時(shí)，這是主要的問(wèn)題。
微軟RTSP協(xié)議的命令采用的語(yǔ)法和標(biāo)準(zhǔn)rtsp協(xié)議的命令語(yǔ)法一樣，只有一些小的修改和添加，可以通過(guò)閱讀網(wǎng)上的一些文檔，就可以知道怎么去組成這些命令。微軟rtsp命令部分已經(jīng)有文檔了。
一次典型的RTSP協(xié)議傳輸過(guò)程
這個(gè)例子為了簡(jiǎn)略，沒(méi)有把發(fā)送接收的包放上來(lái)
TO SERVER => NETWORK <= TO CLIENT
客戶端連服務(wù)器的554端口
客戶端發(fā)送“DESCRIBE”命令
服務(wù)器返回標(biāo)準(zhǔn)rtsp頭
這個(gè)rtsp頭和數(shù)據(jù)實(shí)體包含ASF文件頭信息
以及所有的和媒體文件相關(guān)的流bit rate data
客戶端發(fā)送“SETUP” 音頻流媒體建立命令(stream 1)
服務(wù)器返回標(biāo)準(zhǔn)rtsp頭
客戶端發(fā)送“SETUP” 視頻流媒體建立命令(stream 2)
服務(wù)器返回標(biāo)準(zhǔn)rtsp頭
客戶端發(fā)送“PLAY” 命令
服務(wù)器返回標(biāo)準(zhǔn)rtsp頭
客戶端發(fā)送 “SET_PARAMETER” 命令
這個(gè)命令還包含了一些客戶端發(fā)送給服務(wù)器的信息，比如客戶端的操作系統(tǒng)，CPU類型，播放器版本，日期時(shí)間等信息。消息格式是tagged XML.
服務(wù)器返回標(biāo)準(zhǔn)rtsp頭
#### 服務(wù)器即將開(kāi)始一個(gè)流，發(fā)送媒體數(shù)據(jù)包（包含媒體數(shù)據(jù)包頭），請(qǐng)看接下來(lái)的 ####
當(dāng)要斷開(kāi)這個(gè)流的時(shí)候，服務(wù)器會(huì)向客戶端發(fā)送一個(gè)EOF指示
服務(wù)器斷開(kāi)socket連接
一個(gè)典型的發(fā)給服務(wù)器的RTSP命令
DESCRIBE rtsp://wm.microsoft.com/ms/video/0001-hi.wmv RTSP/1.0
User-Agent: WMPlayer/9.0.0.2980 guid/3300AD50-2C39-46C0-AE0A-81D88F547805
Accept: application/sdp
Accept-Charset: UTF-8, *;q=0.1
X-Accept-Authentication: NTLM, Digest, Basic
Accept-Language: en-GB, *;q=0.1
CSeq: 1
Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.predstrm
注意：
DESCRIBE rtsp://wm.microsoft.com/ms/video/0001-hi.wmv RTSP/1.0
這是要連接的url（服務(wù)器域名和流路徑），后面跟著RTSP的版本。
User-Agent: WMPlayer/9.0.0.2980 guid/3300AD50-2C39-46C0-AE0A-81D88F547805
這條表示了客戶端使用的是什么播放器，以及播放器的版本，再跟著一個(gè)獨(dú)特的GUID。
X-Accept-Authentication: NTLM, Digest, Basic
客戶端可以接受的authentication 類型
注意CSeq 要從1開(kāi)始。服務(wù)器針對(duì)請(qǐng)求命令的應(yīng)答也應(yīng)該有Cseq: 加上數(shù)字 ，這樣可以知道是針對(duì)哪條請(qǐng)求發(fā)的應(yīng)答。
在客戶端發(fā)送一個(gè)請(qǐng)求命令，得到成功的應(yīng)答后，再發(fā)送下一條命令，CSeq的值要加1。
一個(gè)典型的RTSP應(yīng)答消息，它們跟HTTP的消息非常的相似
一個(gè)針對(duì)客戶端發(fā)的DESCRIBE命令，服務(wù)器的應(yīng)答例子如下所示：
<<<HEADER START>>>
RTSP/1.0 200 OK
Content-Type: application/sdp
Vary: Accept
X-Playlist-Gen-Id: 27006
X-Broadcast-Id: 0
Content-Length: 3324
Date: Tue, 18 Nov 2003 15:57:05 GMT
CSeq: 1
Server: WMServer/9.0.0.3372
Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, com.microsoft.wm.packetpairssrc
Last-Modified: Tue, 18 Jun 2002 21:05:39 GMT
Cache-Control: x-wms-content-size=23180160, max-age=86399, must-revalidate, proxy-revalidate
Etag: “23180160″
<<<BODY START>>> ( 兩個(gè)“/r/n”指示本SDP數(shù)據(jù)的開(kāi)始 ).
<<< 這是Session Description Protocol 協(xié)議>>>
v=0
o=- 200311171721060249 200311171721060249 IN IP4 127.0.0.1
s=<No Title>
c=IN IP4 0.0.0.0
b=AS:1091
a=maxps:13632
t=0 0
a=control:rtsp://wm.microsoft.com/ms/video/0001-hi.wmv/
a=etag:{9D7121C3-1A1B-8ED6-6675-CB15D19D1FB7}
a=range:npt=3.100-173.903
a=recvonly
a=pgmpu:data:application/x-wms-contentdesc,8,language,31,0,,5,title,31,0,,6,author,31,0,,9,copyright,31,0,,35,WMS_CONTENT_DESCRIPTION_DESCRIPTION,31,0,,30,WMS_CONTENT_DESCRIPTION_RATING,31,0,,44,WMS_CONTENT_DESCRIPTION_SERVER_BRANDING_INFO,31,12,WMServer/9.0,51,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_START_OFFSET,3,4,3100,47,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_DURATION,3,6,170803,58,WMS_CONTENT_DESCRIPTION_COPIED_METADATA_FROM_PLAYLIST_FILE,3,1,1,42,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_URL,31,17,0001-hi.wmv%0D%0A
a=pgmpu:data:application/vnd.ms.wms-hdr.asfv1;base64,Mcay…dY5mm2QCAQ==
m=audio 0 RTP/AVP 96
b=AS:35
b=RS:0
b=RR:0
a=rtpmap:96 x-asf-pf/1000
a=control:audio
a=stream:1
m=application 0 RTP/AVP 96
b=RS:0
b=RR:0
a=rtpmap:96 x-wms-rtx/1000
a=control:rtx
a=stream:65536
m=video 0 RTP/AVP 96
b=AS:471
b=RS:0
b=RR:0
a=rtpmap:96 x-asf-pf/1000
a=control:stream=2
a=stream:2
以/r/n/r/n結(jié)束
看下面這行：
a=pgmpu:data:application/vnd.ms.wms-hdr.asfv1;base64, Mcay..…==
這是真實(shí)的ASF文件頭數(shù)據(jù)（被Base64編碼過(guò)）。在將這部分頭數(shù)據(jù)寫(xiě)到文件之前需要Base64解碼成標(biāo)準(zhǔn)的ascii碼。
SDP實(shí)體數(shù)據(jù)也告訴我們?cè)诿襟w數(shù)據(jù)中都有些什么流
這個(gè)文件有2個(gè)媒體流：
ID = 1 有一個(gè)“audio”標(biāo)志的音頻流
ID = 2 有一個(gè)“stream=2”標(biāo)志的視頻流
還有第三個(gè)以“rtx”標(biāo)志的流，這是一個(gè)控制流，并不攜帶任何的媒體內(nèi)容。這個(gè)控制流使用stream ID = 65536.
看下面這行：
a=pgmpu:data:application/x-wms-contentdesc, …..
這表示了緊跟的數(shù)據(jù)是一個(gè)內(nèi)容描述對(duì)象。
標(biāo)準(zhǔn)RTSP 消息的錯(cuò)誤代碼– 在應(yīng)答消息的第一行表示
”100” ; Continue (all 100 range)
“200” ; OK
”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 Failed
”413” ; Request Entity Too Large
”414” ; Request-URI Too Large
”415” ; Unsupported Media Type
”451” ; Parameter Not Understood
”452” ; reserved
”453” ; Not Enough Bandwidth
”454” ; Session Not Found
”455” ; Method Not Valid in This State
”456” ; Header Field Not Valid for Resource
”457” ; Invalid Range
”458” ; Parameter Is Read-Only
”459” ; Aggregate operation not allowed
”460” ; Only aggregate operation allowed
”461” ; Unsupported transport
”462” ; Destination unreachable
”500” ; Internal Server Error
”501” ; Not Implemented
”502” ; Bad Gateway
”503” ; Service Unavailable
”504” ; Gateway Time-out
”505” ; RTSP Version not supported
”551” ; Option not supported
RTSP數(shù)據(jù)包頭(每一個(gè)媒體數(shù)據(jù)包的開(kāi)頭)
二進(jìn)制包頭數(shù)據(jù)后面緊跟著媒體數(shù)據(jù)包（asf/wmv 等等）。
Values are in Big Endian order. (not little endian as in mms and http protocols).
——–這些數(shù)據(jù)位在公開(kāi)的RTSP 文檔中也指示了——-
BYTE “$” or 0×24
BYTE Channel id ，一般= 0×00, 你可以看到“P” 或者 0×50 for packet pairs data, 看下面的描述.
WORD 數(shù)據(jù)包的長(zhǎng)度（從接下來(lái)的區(qū)域算起）
——– 接下來(lái)的數(shù)據(jù)位表示的含義還沒(méi)有確定，微軟也許會(huì)指出———–
WORD ??? 填充0x80E0
WORD 序列號(hào)。這個(gè)值被初始化成一個(gè)隨即的值，然后在每一個(gè)數(shù)據(jù)包發(fā)送時(shí)加1。 在這個(gè)值達(dá)到0xffff時(shí)，它將設(shè)置成0。跟其他協(xié)議相比，這個(gè)值得范圍比較小（16位），使得它不能在寫(xiě)媒體數(shù)據(jù)到文件中時(shí)做為有指導(dǎo)性的序列號(hào)使用。大的流媒體文件有很多的數(shù)據(jù)包，包的數(shù)量超過(guò)了他的范圍，所以可能會(huì)發(fā)生相同序列號(hào)的包。只使用這個(gè)序列號(hào)來(lái)作錯(cuò)誤檢驗(yàn)——缺少了某一個(gè)序列號(hào)的包意味著發(fā)生了丟包錯(cuò)誤。
DWORD 發(fā)送時(shí)間。This is stated in milliseconds and shows the time that this media packet should be presented. 預(yù)先錄制的文件設(shè)置T = 0 ，實(shí)況流設(shè)置一個(gè)不同于0的值。
DWORD ??? 固定的一個(gè)值. 它是一個(gè)隨即值，但是一旦一個(gè)rtsp會(huì)話建立，這個(gè)值就一直保持不變，所有的數(shù)據(jù)包都是這個(gè)值。可以使用這個(gè)值作為每次會(huì)話的一個(gè)ID，新的rtsp會(huì)話會(huì)有新的值。
BYTE 標(biāo)志位， 看下面：
Bit 0 (lsb) ? = 0
Bit 1 ? = 0
Bit 2 ? = 0
Bit 3 ? = 0
Bit 4 Duration field present in pre header if set (see below)
Bit 5 ? = 0
Bit 6 ? = 1 (總是1)
Bit 7 (msb) 被設(shè)置成1，表示數(shù)據(jù)包含有一個(gè)關(guān)鍵楨
BYTE ??? 總是設(shè)置成0
WORD 包長(zhǎng)度。此16位表示從上面標(biāo)志位域開(kāi)始的包長(zhǎng)度。
DWORD [可選的] 持續(xù)時(shí)間。只有上面的標(biāo)志位的Bit4 被設(shè)置了才會(huì)有這個(gè)域，否則就沒(méi)有這個(gè)域。表示為多少毫秒，指出了傳輸?shù)拿襟w包的總持續(xù)時(shí)間。
<<< 下面跟著媒體數(shù)據(jù), like 82 00 00 ….. >>>
在RTSP請(qǐng)求和應(yīng)答中使用的有用的標(biāo)簽值：
CSeq: 命令的序列號(hào)，逐1增加。
所有的請(qǐng)求和應(yīng)答都用得到。
Content-Length: 這個(gè)標(biāo)記的存在說(shuō)明后面有實(shí)體數(shù)據(jù)，而且給出了這個(gè)數(shù)據(jù)塊的大小，單位是byte
X-Playlist-Gen-Id: 用來(lái)檢查播放列表是否有效。這個(gè)標(biāo)記最初在客戶端發(fā)送DESCRIBE命令后使用。
客戶端在發(fā)送“SETUP”命令給服務(wù)器時(shí)必須回應(yīng)一樣的值
X-Playlist-Seek-Id: 值必須和X-Playlist-Gen-Id 域的值相同，在PLAY請(qǐng)求命令中使用.
Blocksize: 媒體包的總長(zhǎng)度，單位是byte
Session: Session ID是用作客戶端和服務(wù)器之間是否是正確的連接。在客戶端發(fā)送SETUP命令，服務(wù)器會(huì)在應(yīng)答消息頭里面發(fā)送這個(gè)值給客戶端。 We only see the Session value on the first stream selected (usually this is the audio stream)。 Session值相當(dāng)?shù)拈L(zhǎng)，一共有20個(gè)阿拉伯?dāng)?shù)字。
緊跟著Session值， 你可以看到一個(gè)值： “timeout= xxxx”。. 這是服務(wù)器需要得到回應(yīng)或者ACK回應(yīng)（為了保持連接）的時(shí)間。客戶端必須在這個(gè)時(shí)段內(nèi)發(fā)送一個(gè)ACK ，要不然連接就要被強(qiáng)制中斷。一個(gè)ACK就是發(fā)送一條GET_PARAMETER命令到服務(wù)器。
X-Accept-Authentication: 允許的authentication 方法
NTLM, Digest 和 Basic 是標(biāo)準(zhǔn)的
X-Broadcast-Id: 是否是實(shí)況或者是先期錄制的流。
0 表示先期錄制，其他的值表示是實(shí)況。
Range: Range is the offset and end time positions to stream the media. For a zero start and full file stream, this value is set to: npt=0.000-
where 0.000 is the offset and –0.000 (optional) is the ending time. Values are stated in seconds.
Speed: 用來(lái)調(diào)整傳輸?shù)娇蛻舳说牧鞯盟俣取＜偃缒愕膸捒梢越邮芨咚俚臄?shù)據(jù)傳送，這個(gè)域的值可以設(shè)置大于1來(lái)加速下載數(shù)據(jù)
普通情況 Speed: 1.0 i.e. x1 rate
Media player 使用 : Speed: 1.294
這個(gè)主要取決于你的網(wǎng)絡(luò)連接速度。
Server: 服務(wù)器類型和軟件版本
EOF: 文件結(jié)束標(biāo)記，也是流的結(jié)束標(biāo)記
Date: 日期時(shí)間，下面舉個(gè)例子：
Tue, 18 Nov 2003 15:57:07 GMT
Bandwidth: 流需要的最大帶寬，bits/秒
Transport: 使用什么協(xié)議來(lái)傳輸數(shù)據(jù)，比如TCP或者UDP等
Etag: 實(shí)體標(biāo)記Entity tag，是一個(gè)分配給會(huì)話的值，就像”23180160″
Supported: 支持的COM modules , 有的是可選的.
com.microsoft.wm.srvppair - packet pairs at server
com.microsoft.wm.sswitch - stream ID selection com.microsoft.wm.eosmsg - end of stream message com.microsoft.wm.fastcache - fast cache for buffering com.microsoft.wm.packetpairssrc. - packet pairs
Content-Type: 此域用來(lái)表示命令或者應(yīng)答的用意
下面是常用的幾種類型：
application/x-wms-Logconnectstats
這個(gè)在SET_PARAMETER命令中用到，表示將客戶端的信息登記到服務(wù)器上。
application/sdp
這個(gè)表示接下來(lái)數(shù)據(jù)包里面的是sdp數(shù)據(jù)，它是在服務(wù)器對(duì)DESCRIBE命令的應(yīng)答包中。
application/x-wms-contentdesc
表示緊跟的數(shù)據(jù)是一個(gè)內(nèi)容描述對(duì)象，它設(shè)置the layout of the dialog.
application/vnd.ms.wms-hdr.asfv1
表示跟著一個(gè)流媒體頭信息(ASF header)，
可以用BASIC 或者DIGEST來(lái)解碼。
application/x-rtsp-packetpair
Packet Pair data is random non-compressible data and is sent to the client and timed for response times. 它被用來(lái)確定連接的可用帶寬。Packet pair data 是可選的，你不必經(jīng)常去請(qǐng)求這個(gè)數(shù)據(jù)。 這個(gè)是在發(fā)送GET_PARAMATER命令到服務(wù)器時(shí)，用到的。