轉載自:http://hp.dewen.org/?p=82
關于 RTSP.
RTSP協議是一個非常類似HTTP協議的流控制協議。它們都使用純文本來發送信息，而且rtsp協議的語法也和HTTP類似。Rtsp一開始這樣設計，也是為了能夠兼容使用以前寫的HTTP協議分析代碼 。這是個好消息。
它們主要的區別是HTTP協議是沒有狀態的， http協議在發送一個命令后，連接會斷開，而且命令之間沒有依賴性。不同的是RTSP的命令需要知道現在正處于一個什么狀態，也就是說rtsp的命令總是按照順序來發送，某個命令總在另外一個命令之前要發送。Rtsp不管處于什么狀態都不會去斷掉連接。
HTTP 協議默認使用80端口，而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 disregarding the need to publicise their own MMS protocol once its gone from media player. 然而，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://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（服務器域名和流路徑），后面跟著RTSP的版本。
User-Agent: WMPlayer/9.0.0.2980 guid/3300AD50-2C39-46C0-AE0A-81D88F547805
這條表示了客戶端使用的是什么播放器，以及播放器的版本，再跟著一個獨特的GUID。
X-Accept-Authentication: NTLM, Digest, Basic
客戶端可以接受的authentication 類型
注意CSeq 要從1開始。服務器針對請求命令的應答也應該有Cseq: 加上數字 ，這樣可以知道是針對哪條請求發的應答。
在客戶端發送一個請求命令，得到成功的應答后，再發送下一條命令，CSeq的值要加1。
一個典型的RTSP應答消息，它們跟HTTP的消息非常的相似
一個針對客戶端發的DESCRIBE命令，服務器的應答例子如下所示：
<<<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>>> ( 兩個“/r/n”指示本SDP數據的開始 ).
<<< 這是Session Description Protocol 協議>>>
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結束
看下面這行：
a=pgmpu:data:application/vnd.ms.wms-hdr.asfv1;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, …..
這表示了緊跟的數據是一個內容描述對象。
標準RTSP 消息的錯誤代碼– 在應答消息的第一行表示
”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數據包頭(每一個媒體數據包的開頭)
二進制包頭數據后面緊跟著媒體數據包（asf/wmv 等等）。
Values are in Big Endian order. (not little endian as in mms and http protocols).
——–這些數據位在公開的RTSP 文檔中也指示了——-
BYTE “$” or 0×24
BYTE Channel id ，一般= 0×00, 你可以看到“P” 或者 0×50 for packet pairs data, 看下面的描述.
WORD 數據包的長度（從接下來的區域算起）
——– 接下來的數據位表示的含義還沒有確定，微軟也許會指出———–
WORD ??? 填充0x80E0
WORD 序列號。這個值被初始化成一個隨即的值，然后在每一個數據包發送時加1。 在這個值達到0xffff時，它將設置成0。跟其他協議相比，這個值得范圍比較小（16位），使得它不能在寫媒體數據到文件中時做為有指導性的序列號使用。大的流媒體文件有很多的數據包，包的數量超過了他的范圍，所以可能會發生相同序列號的包。只使用這個序列號來作錯誤檢驗——缺少了某一個序列號的包意味著發生了丟包錯誤。
DWORD 發送時間。This is stated in milliseconds and shows the time that this media packet should be presented. 預先錄制的文件設置T = 0 ，實況流設置一個不同于0的值。
DWORD ??? 固定的一個值. 它是一個隨即值，但是一旦一個rtsp會話建立，這個值就一直保持不變，所有的數據包都是這個值。可以使用這個值作為每次會話的一個ID，新的rtsp會話會有新的值。
BYTE 標志位， 看下面：
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) 被設置成1，表示數據包含有一個關鍵楨
BYTE ??? 總是設置成0
WORD 包長度。此16位表示從上面標志位域開始的包長度。
DWORD [可選的] 持續時間。只有上面的標志位的Bit4 被設置了才會有這個域，否則就沒有這個域。表示為多少毫秒，指出了傳輸的媒體包的總持續時間。
<<< 下面跟著媒體數據, like 82 00 00 ….. >>>
在RTSP請求和應答中使用的有用的標簽值：
CSeq: 命令的序列號，逐1增加。
所有的請求和應答都用得到。
Content-Length: 這個標記的存在說明后面有實體數據，而且給出了這個數據塊的大小，單位是byte
X-Playlist-Gen-Id: 用來檢查播放列表是否有效。這個標記最初在客戶端發送DESCRIBE命令后使用。
客戶端在發送“SETUP”命令給服務器時必須回應一樣的值
X-Playlist-Seek-Id: 值必須和X-Playlist-Gen-Id 域的值相同，在PLAY請求命令中使用.
Blocksize: 媒體包的總長度，單位是byte
Session: Session ID是用作客戶端和服務器之間是否是正確的連接。在客戶端發送SETUP命令，服務器會在應答消息頭里面發送這個值給客戶端。 We only see the Session value on the first stream selected (usually this is the audio stream)。 Session值相當的長，一共有20個阿拉伯數字。
緊跟著Session值， 你可以看到一個值： “timeout= xxxx”。. 這是服務器需要得到回應或者ACK回應（為了保持連接）的時間。客戶端必須在這個時段內發送一個ACK ，要不然連接就要被強制中斷。一個ACK就是發送一條GET_PARAMETER命令到服務器。
X-Accept-Authentication: 允許的authentication 方法
NTLM, Digest 和 Basic 是標準的
X-Broadcast-Id: 是否是實況或者是先期錄制的流。
0 表示先期錄制，其他的值表示是實況。
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: 用來調整傳輸到客戶端的流得速度。假如你的帶寬可以接受更高速的數據傳送，這個域的值可以設置大于1來加速下載數據
普通情況 Speed: 1.0 i.e. x1 rate
Media player 使用 : Speed: 1.294
這個主要取決于你的網絡連接速度。
Server: 服務器類型和軟件版本
EOF: 文件結束標記，也是流的結束標記
Date: 日期時間，下面舉個例子：
Tue, 18 Nov 2003 15:57:07 GMT
Bandwidth: 流需要的最大帶寬，bits/秒
Transport: 使用什么協議來傳輸數據，比如TCP或者UDP等
Etag: 實體標記Entity tag，是一個分配給會話的值，就像”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: 此域用來表示命令或者應答的用意
下面是常用的幾種類型：
application/x-wms-Logconnectstats
這個在SET_PARAMETER命令中用到，表示將客戶端的信息登記到服務器上。
application/sdp
這個表示接下來數據包里面的是sdp數據，它是在服務器對DESCRIBE命令的應答包中。
application/x-wms-contentdesc
表示緊跟的數據是一個內容描述對象，它設置the layout of the dialog.
application/vnd.ms.wms-hdr.asfv1
表示跟著一個流媒體頭信息(ASF header)，
可以用BASIC 或者DIGEST來解碼。
application/x-rtsp-packetpair
Packet Pair data is random non-compressible data and is sent to the client and timed for response times. 它被用來確定連接的可用帶寬。Packet pair data 是可選的，你不必經常去請求這個數據。 這個是在發送GET_PARAMATER命令到服務器時，用到的。