rtsp協議詳解
目錄:html
1 概述
1.1 RTSP簡介
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能夠是雙向的.session
RTSP是用來控制聲音或影像的多媒體串流協議, 並容許同時多個串流需求控制, 傳輸時所用的網絡通信協議並不在其定義的範圍內, 服務器端能夠自行選擇使用TCP或UDP來傳送串流內容.併發
而前面提到的容許同時多個串流需求控制(Multicast), 除了能夠下降服務器端的網絡用量, 更進而支持多方視訊會議(Video Conference). 由於與HTTP1.1的運做方式類似, 因此代理服務器〈Proxy〉的快取功能〈Cache〉也一樣適用於RTSP, 並因RTSP具備從新導向功能, 可視實際負載狀況來轉換提供服務的服務器, 以免過大的負載集中於同一服務器而形成延遲.app
該協議用於C/S模型, 是一個基於文本的協議, 用於在客戶端和服務器端創建和協商實時流會話.框架
實時流協議(RTSP)創建並控制一個或幾個時間同步的連續流媒體. 儘管連續媒體流與控制流交換是可能的, 一般它自己並不發送連續流. 換言之, RTSP充當多媒體服務器的網絡遠程控制. RTSP鏈接沒有綁定到傳輸層鏈接, 如TCP. 在RTSP鏈接期間, RTSP用戶可打開或關閉多個對服務器的可傳輸鏈接以發出RTSP請求. 此外, 可以使用無鏈接傳輸協議, 如UDP. RTSP流控制的流可能用到RTP, 但RTSP操做並不依賴用於攜帶連續媒體的傳輸機制.tcp
協議支持的操做以下: (1)從媒體服務器上檢索媒體: 用戶可經過HTTP或其它方法提交一個演示描述. 如演示是組播, 演示式就包含用於連續媒體的的組播地址和端口. 如演示僅經過單播發送給用戶, 用戶爲了安全應提供目的地址. (2)媒體服務器邀請進入會議: 媒體服務器可被邀請參加正進行的會議, 或回放媒體, 或記錄其中一部分, 或所有. 這種模式在分佈式教育應用上頗有用, 會議中幾方可輪流按遠程控制按鈕. (3)將媒體加到現成講座中: 如服務器告訴用戶可得到附加媒體內容, 對現場講座顯得尤爲有用. 如HTTP/1.1中相似, RTSP請求可由代理, 通道與緩存處理.
1.2 協議特色
- 可擴展性: 新方法和參數很容易加入RTSP.
- 易解析: RTSP可由標準HTTP或MIME解析器解析.
- 安全: RTSP使用網頁安全機制.
- 獨立於傳輸: RTSP可以使用不可靠數據報協議(EDP), 可靠數據報協議(RDP); 如要實現應用級可靠, 可以使用可靠流協議.
- 多服務器支持: 每一個流可放在不一樣服務器上, 用戶端自動與不一樣服務器創建幾個併發控制鏈接, 媒體同步在傳輸層執行.
- 記錄設備控制: 協議可控制記錄和回放設備.
- 流控與會議開始分離: 僅要求會議初始化協議提供, 或可用來建立唯一會議標識號. 特殊狀況下, 可用SIP或H.323來邀請服務器入會.
- 適合專業應用: 經過SMPTE時標, RTSP支持幀級精度, 容許遠程數字編輯.
- 演示描述中立: 協議沒強加特殊演示或元文件, 可傳送所用格式類型; 然而, 演示描述至少必須包括一個RTSP URL.
- 代理與防火牆友好: 協議可由應用和傳輸層防火牆處理. 防火牆須要理解SETUP方法, 爲UDP媒體流打開一個「缺口」.
- HTTP友好: 此處, RTSP明智地採用HTTP觀念, 使如今結構均可重用. 結構包括Internet內容選擇平臺(PICS). 因爲在大多數狀況下控制連續媒體須要服務器狀態, RTSP不只僅向HTFP添加方法.
- 適當的服務器控制: 如用戶啓動一個流, 必須也能夠中止一個流.
- 傳輸協調: 實際處理連續媒體流前, 用戶可協調傳輸方法.
- 性能協調: 如基本特徵無效, 必須有一些清理機制讓用戶決定哪一種方法沒生效. 這容許用戶提出適合的用戶界面.
2 協議細節
2.1 典型的rtsp交互過程
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請求來完成.
第五步, 能夠根據系統需求的設計來決定是否須要.
2.2 RTSP消息格式
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表示成功, 解釋是與狀態碼對應的文本解釋.
2.3 方法定義
方法記號表示資源上執行的方法, 它區分大小寫. 新方法可在未來定義, 但不能以$開頭. 已定義方法以下表所示:
(注: 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上進行傳輸.
2.4 消息頭定義
消息頭的定義以下表. 表格說明:
- 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 它被用來肯定鏈接的可用帶寬。 |
2.5 狀態碼
標準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 |
3 rtsp中經常使用方法舉例
本節針對上面所述的典型交互過程進行說明
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等等
4 SDP協議概述
4.1 簡介
SDP 徹底是一種會話描述格式, 它不屬於傳輸協議.
它使用不一樣的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、 實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。
SDP協議是也是基於文本的協議，這樣就能保證協議的可擴展性比較強, 這樣就使其具備普遍的應用範圍。SDP 不支持會話內容或媒體編碼的協商, 因此在流媒體中只用來描述媒體信息。媒體協商這一塊要用RTSP來實現．
4.2 SDP協議格式
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 個或多個媒體屬性行)
4.3 SDP協議舉例說明
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，經過該地址能夠查閱到會話的更多內容
e=mjh@isi.edu (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），爲動態分配的。
m=video 3400 RTP/AVP 98 99 //m行又稱媒體行，描述了發送方所支持的媒體類型等信息
- 第一個參數爲媒體名稱：代表支持視頻類型。
- 第二個參數爲端口號，代表UE在本地端口爲3400上發送視頻流。
- 第三個參數爲傳輸協議，通常爲RTP/AVP協議。
- 4、五參數給出了兩種淨荷類型編號
a=rtpmap:98 MPV
a=rtpmap:99 H.261
格式爲：a=rtpmap:<淨荷類型><編碼名稱> * 淨荷類型98對應的編碼方案爲MPV,爲動態分配的。 * 淨荷類型97對應的編碼方式爲H.261，爲動態分配的。
- 1. RTSP協議詳解
- 2. RTSP協議解析
- 3. rtsp協議理解
- 4. RTSP協議詳解【入門篇】
- 5. 流媒體協議之RTSP詳解20170922
- 6. RTSP、HTTP、HTTPS、SDP四種協議詳解
- 7. RTMP、RTSP、HTTP視頻協議詳解（轉）
- 8. RTSP協議和IGMP協議
- 9. RTSP協議與HTTP協議
- 10. RTSP---協議
- 更多相關文章...
- • ARP協議的工作機制詳解 - TCP/IP教程
- • Swift 協議 - Swift 教程
- • Flink 數據傳輸及反壓詳解
- • 適用於PHP初學者的學習線路和建議
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. RTSP協議詳解
- 2. RTSP協議解析
- 3. rtsp協議理解
- 4. RTSP協議詳解【入門篇】
- 5. 流媒體協議之RTSP詳解20170922
- 6. RTSP、HTTP、HTTPS、SDP四種協議詳解
- 7. RTMP、RTSP、HTTP視頻協議詳解（轉）
- 8. RTSP協議和IGMP協議
- 9. RTSP協議與HTTP協議
- 10. RTSP---協議