目錄:
- 1 概述
- 1.1 RTSP簡介
- 1.2 協定特點
- 2 協定細節
- 2.1 典型的rtsp互動過程
- 2.2 RTSP消息格式
- 2.3 方法定義
- 2.4 消息頭定義
- 2.5 狀态碼
- 3 rtsp中常用方法舉例
- 4 SDP協定概述
- 4.1 簡介
- 4.2 SDP協定格式
- 4.3 SDP協定舉例說明
RTSP(Real Time Streaming Protocol), 實時流傳輸協定, 是TCP/IP協定體系中的一個
應用層
協定, 由哥倫比亞大學, 網景和RealNetworks公司送出的IETF RFC标準. 該協定定義了一對多應用程式如何有效地通過IP網絡傳送多媒體資料. RTSP在體系結構上位于RTP和RTCP之上, 它使用TCP或RTP完成資料傳輸.
流媒體服務協定棧
RTSP提供了一個可擴充架構, 使實時資料, 如音頻與視訊的受控點播成為可能. 資料源包括現場資料與存儲在剪輯中資料. 該協定目的在于控制多個資料發送連接配接, 為選擇發送通道, 如UDP, 多點傳播UDP與TCP, 提供途徑, 并為選擇基于RTP上發送機制提供方法.
它的文法和運作跟HTTP 1.1類似, 但并不特别強調時間同步, 是以比較能容忍網絡延遲.
HTTP與RTSP相比, * HTTP傳送HTML. HTTP請求由客戶機發出, 伺服器作出響應 * RTSP傳送的是多媒體資料. 使用RTSP時, 客戶機和伺服器都可以送出請求, 即RTSP可以是
雙向
的.
RTSP是用來控制聲音或影像的多媒體串流協定, 并允許同時多個串流需求控制, 傳輸時所用的網絡通訊協定并不在其定義的範圍内, 伺服器端可以自行選擇使用TCP或UDP來傳送串流内容.
而前面提到的允許同時多個串流需求控制(Multicast), 除了可以降低伺服器端的網絡用量, 更進而支援多方視訊會議(Video Conference). 因為與HTTP1.1的運作方式相似, 是以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣适用于RTSP, 并因RTSP具有重新導向功能, 可視實際負載情況來轉換提供服務的伺服器, 以避免過大的負載集中于同一伺服器而造成延遲.
該協定用于C/S模型, 是一個基于文本的協定, 用于在用戶端和伺服器端建立和協商實時流會話.
實時流協定(RTSP)建立并控制一個或幾個時間同步的連續流媒體. 盡管連續媒體流與控制流交換是可能的, 通常它本身并不發送連續流. 換言之, RTSP充當多媒體伺服器的網絡遠端控制. RTSP連接配接沒有綁定到傳輸層連接配接, 如TCP. 在RTSP連接配接期間, RTSP使用者可打開或關閉多個對伺服器的可傳輸連接配接以發出RTSP請求. 此外, 可使用無連接配接傳輸協定, 如UDP. RTSP流控制的流可能用到RTP, 但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制.
協定支援的操作如下: (1)從媒體伺服器上檢索媒體: 使用者可通過HTTP或其它方法送出一個示範描述. 如示範是多點傳播, 示範式就包含用于連續媒體的的多點傳播位址和端口. 如示範僅通過單點傳播發送給使用者, 使用者為了安全應提供目的位址. (2)媒體伺服器邀請進入會議: 媒體伺服器可被邀請參加正進行的會議, 或回放媒體, 或記錄其中一部分, 或全部. 這種模式在分布式教育應用上很有用, 會議中幾方可輪流按遠端控制按鈕. (3)将媒體加到現成講座中: 如伺服器告訴使用者可獲得附加媒體内容, 對現場講座顯得尤其有用. 如HTTP/1.1中類似, RTSP請求可由代理, 通道與緩存處理.
- 可擴充性: 新方法和參數很容易加入RTSP.
- 易解析: RTSP可由标準HTTP或MIME解析器解析.
- 安全: RTSP使用網頁安全機制.
- 獨立于傳輸: RTSP可使用不可靠資料報協定(EDP), 可靠資料報協定(RDP); 如要實作應用級可靠, 可使用可靠流協定.
- 多伺服器支援: 每個流可放在不同伺服器上, 使用者端自動與不同伺服器建立幾個并發控制連接配接, 媒體同步在傳輸層執行.
- 記錄裝置控制: 協定可控制記錄和回放裝置.
- 流控與會議開始分離: 僅要求會議初始化協定提供, 或可用來建立惟一會議辨別号. 特殊情況下, 可用SIP或H.323來邀請伺服器入會.
- 适合專業應用: 通過SMPTE時标, RTSP支援幀級精度, 允許遠端數字編輯.
- 示範描述中立: 協定沒強加特殊示範或元檔案, 可傳送所用格式類型; 然而, 示範描述至少必須包括一個RTSP URL.
- 代理與防火牆友好: 協定可由應用和傳輸層防火牆處理. 防火牆需要了解SETUP方法, 為UDP媒體流打開一個“缺口”.
- HTTP友好: 此處, RTSP明智地采用HTTP觀念, 使現在結構都可重用. 結構包括Internet内容選擇平台(PICS). 由于在大多數情況下控制連續媒體需要伺服器狀态, RTSP不僅僅向HTFP添加方法.
- 适當的伺服器控制: 如使用者啟動一個流, 必須也可以停止一個流.
- 傳輸協調: 實際處理連續媒體流前, 使用者可協調傳輸方法.
- 性能協調: 如基本特征無效, 必須有一些清理機制讓使用者決定哪種方法沒生效. 這允許使用者提出适合的使用者界面.
C表示rtsp用戶端, S表示rtsp服務端
1. C->S:OPTION request //詢問S有哪些方法可用
1. S->C:OPTION response //S回應資訊中包括提供的所有可用方法
2. C->S:DESCRIBE request //要求得到S提供的媒體初始化描述資訊
2. S->C:DESCRIBE response //S回應媒體初始化描述資訊, 主要是sdp
3. C->S:SETUP request //設定會話的屬性, 以及傳輸模式, 提醒S建立會話
3. S->C:SETUP response //S建立會話, 傳回會話辨別符, 以及會話相關資訊
4. C->S:PLAY request //C請求播放
4. S->C:PLAY response //S回應該請求的資訊
S->C:發送流媒體資料
5. C->S:TEARDOWN request //C請求關閉會話
5. S->C:TEARDOWN response //S回應該請求
上述的過程是标準的, 友好的rtsp流程, 但實際的需求中并不一定按部就班來. 其中第3和4步是必需的！
第一步, 隻要伺服器用戶端約定好, 有哪些方法可用, 則option請求可以不要.
第二步, 如果我們有其他途徑得到媒體初始化描述資訊(比如http請求等等), 則我們也不需要通過rtsp中的describe請求來完成.
第五步, 可以根據系統需求的設計來決定是否需要.
RTSP的消息有兩大類:
請求消息(request)
,
回應消息(response)
.
請求消息
方法 URI RTSP版本 CR LF
消息頭 CR LF
CR LF
消息體 CR LF
其中
方法
包括OPTION回應中所有的指令,URI是接受方的位址,例如:rtsp://192.168.20.136. RTSP版本一般都是 RTSP/1.0. 每行後面的CR LF表示回車換行, 需要接受端有相應的解析, 最後一個
消息頭
需要有兩個CR LF(即空行)
回應消息
RTSP版本 狀态碼 解釋 CR LF
消息頭 CR LF
CR LF
消息體 CR LF
其中RTSP版本一般都是RTSP/1.0, 狀态碼是一個數值, 200表示成功, 解釋是與狀态碼對應的文本解釋.
方法記号表示資源上執行的方法, 它區分大小寫. 新方法可在将來定義, 但不能以$開頭. 已定義方法如下表所示:
(注: P----示範, S----流, C----使用者端, S----伺服器端)
| 方法 | 方向 | 對象 | 要求 | 含義 |
|---------------|-----------|------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 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`請求檢查RUL指定的示範與媒體的參數值. 沒有實體體時, `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方法和流資料. 由于插入将使用戶端和伺服器操作複雜, 并增加附加開銷, 除非有必要, 應避免這樣做. 插入二進制資料僅在RTSP通過TCP傳輸時才可使用. 流資料(如RTP包)用一個ASCII字元'ʹ封裝, 後跟一個一位元組通道辨別, 其後是封裝二進制資料的長度, 兩位元組整數. 流資料緊跟其後, 沒有CRLF, 但包括高層協定頭. 每個塊包含一個高層協定資料單元.
當傳輸選擇為RTP, RTCP資訊也被伺服器通過TCP連接配接插入. 預設情況下, RTCP包在比RTP通道高的第一個可用通道上發送. 用戶端可能在另一通道顯式請求RTCP包, 這可通過指定傳輸頭插入參數中的兩個通道來做到. 當兩個或更多流交叉時, 為取得同步, 需要RTCP. 而且, 這為當網絡設定需要通過TCP控制連接配接透過RTP/RTCP提供了一條友善的途徑, 可能時, 在UDP上進行傳輸.
消息頭的定義如下表. 表格說明:
- Type:
- 類型 "g" 表示請求和響應中的通用請求頭;
- 類型 "R" 表示請求頭;
- 類型 "r" 表示響應頭;
- 類型 "e" 表示實體頭字段.
- Support:
- "req." 表示必須由接收者以特殊的方法實作; 注意, 不是所有 "req." 字段在該類型的每個請求中都會被發送. "req." 隻表示客戶機(支援響應頭)和伺服器(支援請求頭)必須執行該字段.
- "opt." 表示是可選的.
- 最後一欄列出了關于頭字段産生作用的方法; 其中 "entity" 針對于傳回一個資訊主體的所有方法. )
| Header | Type | Support | Methods |
|--------------------|------|---------|---------------------------|
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | R | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | All but OPTIONS, TEARDOWN |
| Cache-Control | G | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | G | req. | all |
| Content-Base | E | opt. | entity |
| Content-Encoding | E | req. | SET_PARAMETER |
| Content-Encoding | E | req. | DESCRIBE, ANNOUNCE |
| Content-Language | E | req. | DESCRIBE, ANNOUNCE |
| Content-Length | E | req. | SET_PARAMETER, ANNOUNCE |
| Content-Length | E | req. | entity |
| Content-Location | E | opt. | entity |
| Content-Type | E | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | R | req. | entity |
| CSeq | G | req. | all |
| Date | G | opt. | all |
| Expires | E | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | E | opt. | entity |
| Proxy-Authenticate | | | |
| Proxy-Require | R | req. | all |
| Public | R | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | R | opt. | all |
| RTP-Info | R | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | All but SETUP, OPTIONS |
| Server | R | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | R | req. | all |
| User-Agent | R | opt. | all |
| Via | G | opt. | all |
| WWW-Authenticate | R | opt. | all |
常用頭解析:
| Header | Description |
|-------------------------|---------------------------------------------------------------------------------------|
| 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指令後，伺服器會在應答消息頭裡面發送一個session值給用戶端。這算建立的一個會話. |
| X-Accept-Authentication | 允許的authentication 方法. NTLM, Digest 和 Basic 是标準的 |
| X-Broadcast-Id | 是否是實況或者是先期錄制的流。0 表示先期錄制，其他的值表示是實況。 |
| Range | 暫無中文釋義 |
| Speed | 用來調整傳輸到用戶端的流得速度。假如你的帶寬可以接受更高速的資料傳送，這個域的值可以設定大于1來加速下載下傳資料. i.e. x1 rate |
| Server | 伺服器類型和軟體版本 |
| EOF | 檔案結束标記，也是流的結束标記 |
| Date | 日期時間，下面舉個例子：Tue, 18 Nov 2003 15:57:07 GMT |
| Bandwidth | 流需要的最大帶寬，bits/秒 |
| Transport | 使用什麼協定來傳輸資料，比如TCP或者UDP等 |
| Etag | 實體标記Entity tag，是一個配置設定給會話的值，就像”23180160″ |
| Supported | 支援的COM modules , 有的是可選的. |
| 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 它被用來确定連接配接的可用帶寬。 |
标準RTSP 消息的狀态碼(在應答消息的第一行表示)
| value | meaning |
|-------|-------------------------------------|
| ”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 |
本節針對上面所述的典型互動過程進行說明
OPTION
目的是得到伺服器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每個消息都有序号來标記, 第一個包通常是option請求消息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
伺服器的回應資訊包括提供的一些方法,例如:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 1 //每個回應消息的cseq數值和請求消息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,GET_PARAMETER //伺服器提供的可用的方法
DESCRIBE
C向S發起DESCRIBE請求,為了得到會話描述資訊(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 2
token:
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
伺服器回應一些對此會話的描述資訊(sdp):
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp
v=0 //以下都是sdp資訊
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1
a=range:npt=0-
m=video 0 RTP/AVP 96 //m表示媒體描述, 下面是對會話中視訊通道的媒體描述
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0 //trackID＝0表示視訊流用的是通道0
SETUP
用戶端提醒伺服器建立會話,并确定傳輸模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri中 帶有trackID＝0, 表示對該通道進行設定. Transport參數設定了傳輸模式, 包的結構. 接下來的資料標頭部第二個位元組位置就是 interleaved, 它的值是每個通道都不同的, trackID＝0的interleaved值有兩個0或1, 0表示rtp包, 1表示rtcp包, 接 受端根據interleaved的值來差別是哪種資料包.
伺服器回應資訊:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894 //伺服器回應的會話辨別符
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
PLAY
用戶端發送播放請求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000- //設定播放時間的範圍
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309
//seq和rtptime都是rtp包中的資訊
TEARDOWN
用戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
伺服器回應:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close
以上方法都是互動過程中最為常用的, 其它還有一些重要的方法如
get/set_parameter,pause,redirect
等等
SDP 完全是一種會話描述格式, 它不屬于傳輸協定.
它使用不同的适當的傳輸協定，包括會話通知協定（SAP）、會話初始協定（SIP）、 實時流協定（RTSP）、MIME 擴充協定的電子郵件以及超文本傳輸協定（HTTP）。
SDP協定是也是基于文本的協定，這樣就能保證協定的可擴充性比較強, 這樣就使其具有廣泛的應用範圍。SDP 不支援會話内容或媒體編碼的協商, 是以在流媒體中隻用來描述媒體資訊。媒體協商這一塊要用RTSP來實作．
SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。
＜type＞=<value>[CRLF]
sdp的格式:
v=<version>
o=<username> <session id> <version> <network type> <address type> <address>
s=<session name>
i=<session description>
u=<URI>
e=<email address>
p=<phone number>
c=<network type> <address type> <connection address>
b=<modifier>:<bandwidth-value>
t=<start time> <stop time>
r=<repeat interval> <active duration> <list of offsets from start-time>
z=<adjustment time> <offset> <adjustment time> <offset> ....
k=<method>
k=<method>:<encryption key>
a=<attribute>
a=<attribute>:<value>
m=<media> <port> <transport> <fmt list>
v = (協定版本)
o = (所有者/建立者和會話辨別符)
s = (會話名稱)
i = * (會話資訊)
u = * (URI 描述)
e = * (Email 位址)
p = * (電話号碼)
c = * (連接配接資訊)
b = * (帶寬資訊)
z = * (時間區域調整)
k = * (加密密鑰)
a = * (0 個或多個會話屬性行)
時間描述:
t = (會話活動時間)
r = * (0或多次重複次數)
媒體描述:
m = (媒體名稱和傳輸位址)
i = * (媒體标題)
c = * (連接配接資訊 — 如果包含在會話層則該字段可選)
b = * (帶寬資訊)
k = * (加密密鑰)
a = * (0 個或多個媒體屬性行) SDP（Session Description Protocol）是一個用來描述多媒體會話的應用層控制協定，它是一個基于文本的協定，用于會話建立過程中的媒體類型和編碼方案的協商等。
消息正文格式：
v=0 //該行訓示協定的版本
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 //o行中包含與會話所有者有關的參數
- 第一個參數表明會話發起者的名稱，該參數可不填寫，如填寫和SIP消息中，from消息頭的内容一緻。
- 第二個參數為主叫方的會話辨別符。
- 第三個參數為主叫方會話的版本，會話資料有改變時，版本号遞增。
- 第四個參數定義了網絡類型，IN表示Internet網絡類型，目前僅定義該網絡類型。
- 第五個參數為位址類型，目前支援IPV4和IPV6兩種位址類型。
- 第六個參數為位址：表明會話發起者的IP位址，該位址為信令面的IP位址，信令PDP激活時為手機配置設定。
s=SDP Seminar //表明本次會話的标題，或會話的名稱
i=A Seminar on the session description protocol //會話的描述
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps //會話的URI，通過該位址可以查閱到會話的更多内容
[email protected] (Mark Handley) //會話責任人的EMIAL位址
c=IN IP4 224.2.17.12/127 //C行包含為多媒體會話而建立的連接配接的資訊，其中指出了真正的媒體流使用的IP位址
- 第一個參數為網絡類型，目前僅定義INTERNET網絡類型。用“IN”表示。
- 第二個參數為位址類型，目前支援兩種位址類型：IPV4和IPV6。
- 第三個參數為位址，該位址為多媒體流使用的IP位址。
t=2873397496 2873404696 //表示會話的開始時間和結束時間
- 第一個參數表明會話的開始時間，數字表明從1900年1月1日00：00以來所經過的秒數。
- 第二個參數表明會話的結束時間，數字表明從1900年1月1日00：00以來所經過的秒數。
m=audio 3458 RTP/AVP 0 96 97 // m行又稱媒體行，描述了發送方所支援的媒體類型等資訊
- 第一個參數為媒體名稱：表明支援音頻類型。
- 第二個參數為端口号，表明UE在本地端口為3458上發送音頻流。
- 第三個參數為傳輸協定，一般為RTP/AVP協定。
- 第四~七參數為所支援的四種淨荷類型編号
a=rtpmap:0 PCMU //a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
格式為：a=rtpmap:<淨荷類型><編碼名稱> * 淨荷類型0固定配置設定給了PCMU， * 淨荷類型96對應的編碼方案為G.726,為動态配置設定的。 * 淨荷類型97對應的編碼方式為自适應多速率寬帶編碼（AMR-WB），為動态配置設定的。
- 第一個參數為媒體名稱：表明支援視訊類型。
- 第二個參數為端口号，表明UE在本地端口為3400上發送視訊流。
- 四、五參數給出了兩種淨荷類型編号
![【網絡篇】第五篇——網絡套接字程式設計(一)(socket詳解)socket程式設計LINUX下socket程式的示範[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)