牽著老婆滿街逛

目錄:

概述

RTSP簡介

RTSP(Real Time Streaming Protocol), 實時流傳輸協(xié)議, 是TCP/IP協(xié)議體系中的一個應(yīng)用層協(xié)議, 由哥倫比亞大學, 網(wǎng)景和RealNetworks公司提交的IETF RFC標準. 該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù). RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上, 它使用TCP或RTP完成數(shù)據(jù)傳輸.

流媒體服務(wù)協(xié)議棧

RTSP提供了一個可擴展框架, 使實時數(shù)據(jù), 如音頻與視頻的受控點播成為可能. 數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù). 該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接, 為選擇發(fā)送通道, 如UDP, 組播UDP與TCP, 提供途徑, 并為選擇基于RTP上發(fā)送機制提供方法.

它的語法和運作跟HTTP 1.1類似, 但并不特別強調(diào)時間同步, 所以比較能容忍網(wǎng)絡(luò)延遲.

HTTP與RTSP相比, * HTTP傳送HTML. HTTP請求由客戶機發(fā)出, 服務(wù)器作出響應(yīng) * RTSP傳送的是多媒體數(shù)據(jù). 使用RTSP時, 客戶機和服務(wù)器都可以發(fā)出請求, 即RTSP可以是雙向的.

RTSP是用來控制聲音或影像的多媒體串流協(xié)議, 并允許同時多個串流需求控制, 傳輸時所用的網(wǎng)絡(luò)通訊協(xié)議并不在其定義的范圍內(nèi), 服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容.

而前面提到的允許同時多個串流需求控制(Multicast), 除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量, 更進而支持多方視訊會議(Video Conference). 因為與HTTP1.1的運作方式相似, 所以代理服務(wù)器〈Proxy〉的快取功能〈Cache〉也同樣適用于RTSP, 并因RTSP具有重新導(dǎo)向功能, 可視實際負載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器, 以避免過大的負載集中于同一服務(wù)器而造成延遲.

該協(xié)議用于C/S模型, 是一個基于文本的協(xié)議, 用于在客戶端和服務(wù)器端建立和協(xié)商實時流會話.

實時流協(xié)議(RTSP)建立并控制一個或幾個時間同步的連續(xù)流媒體. 盡管連續(xù)媒體流與控制流交換是可能的, 通常它本身并不發(fā)送連續(xù)流. 換言之, RTSP充當多媒體服務(wù)器的網(wǎng)絡(luò)遠程控制. RTSP連接沒有綁定到傳輸層連接, 如TCP. 在RTSP連接期間, RTSP用戶可打開或關(guān)閉多個對服務(wù)器的可傳輸連接以發(fā)出RTSP請求. 此外, 可使用無連接傳輸協(xié)議, 如UDP. RTSP流控制的流可能用到RTP, 但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制.

協(xié)議支持的操作如下: (1)從媒體服務(wù)器上檢索媒體: 用戶可通過HTTP或其它方法提交一個演示描述. 如演示是組播, 演示式就包含用于連續(xù)媒體的的組播地址和端口. 如演示僅通過單播發(fā)送給用戶, 用戶為了安全應(yīng)提供目的地址. (2)媒體服務(wù)器邀請進入會議: 媒體服務(wù)器可被邀請參加正進行的會議, 或回放媒體, 或記錄其中一部分, 或全部. 這種模式在分布式教育應(yīng)用上很有用, 會議中幾方可輪流按遠程控制按鈕. (3)將媒體加到現(xiàn)成講座中: 如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容, 對現(xiàn)場講座顯得尤其有用. 如HTTP/1.1中類似, RTSP請求可由代理, 通道與緩存處理.

協(xié)議特點

• 可擴展性: 新方法和參數(shù)很容易加入RTSP.
• 易解析: RTSP可由標準HTTP或MIME解析器解析.
• 安全: RTSP使用網(wǎng)頁安全機制.
• 獨立于傳輸: RTSP可使用不可靠數(shù)據(jù)報協(xié)議(EDP), 可靠數(shù)據(jù)報協(xié)議(RDP); 如要實現(xiàn)應(yīng)用級可靠, 可使用可靠流協(xié)議.
• 多服務(wù)器支持: 每個流可放在不同服務(wù)器上, 用戶端自動與不同服務(wù)器建立幾個并發(fā)控制連接, 媒體同步在傳輸層執(zhí)行.
• 記錄設(shè)備控制: 協(xié)議可控制記錄和回放設(shè)備.
• 流控與會議開始分離: 僅要求會議初始化協(xié)議提供, 或可用來創(chuàng)建惟一會議標識號. 特殊情況下, 可用SIP或H.323來邀請服務(wù)器入會.
• 適合專業(yè)應(yīng)用: 通過SMPTE時標, RTSP支持幀級精度, 允許遠程數(shù)字編輯.
• 演示描述中立: 協(xié)議沒強加特殊演示或元文件, 可傳送所用格式類型; 然而, 演示描述至少必須包括一個RTSP URL.
• 代理與防火墻友好: 協(xié)議可由應(yīng)用和傳輸層防火墻處理. 防火墻需要理解SETUP方法, 為UDP媒體流打開一個“缺口”.
• HTTP友好: 此處, RTSP明智地采用HTTP觀念, 使現(xiàn)在結(jié)構(gòu)都可重用. 結(jié)構(gòu)包括Internet內(nèi)容選擇平臺(PICS). 由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài), RTSP不僅僅向HTFP添加方法.
• 適當?shù)姆?wù)器控制: 如用戶啟動一個流, 必須也可以停止一個流.
• 傳輸協(xié)調(diào): 實際處理連續(xù)媒體流前, 用戶可協(xié)調(diào)傳輸方法.
• 性能協(xié)調(diào): 如基本特征無效, 必須有一些清理機制讓用戶決定哪種方法沒生效. 這允許用戶提出適合的用戶界面.

協(xié)議細節(jié)

典型的rtsp交互過程

1. C->S:OPTION request //詢問S有哪些方法可用
1. S->C:OPTION response //S回應(yīng)信息中包括提供的所有可用方法
2. C->S:DESCRIBE request //要求得到S提供的媒體初始化描述信息
2. S->C:DESCRIBE response //S回應(yīng)媒體初始化描述信息, 主要是sdp
3. C->S:SETUP request //設(shè)置會話的屬性, 以及傳輸模式, 提醒S建立會話
3. S->C:SETUP response //S建立會話, 返回會話標識符, 以及會話相關(guān)信息
4. C->S:PLAY request //C請求播放
4. S->C:PLAY response //S回應(yīng)該請求的信息
S->C:發(fā)送流媒體數(shù)據(jù)
5. C->S:TEARDOWN request //C請求關(guān)閉會話
5. S->C:TEARDOWN response //S回應(yīng)該請求

上述的過程是標準的, 友好的rtsp流程, 但實際的需求中并不一定按部就班來. 其中第3和4步是必需的！

第一步, 只要服務(wù)器客戶端約定好, 有哪些方法可用, 則option請求可以不要.

第二步, 如果我們有其他途徑得到媒體初始化描述信息(比如http請求等等), 則我們也不需要通過rtsp中的describe請求來完成.

第五步, 可以根據(jù)系統(tǒng)需求的設(shè)計來決定是否需要.

RTSP消息格式

RTSP的消息有兩大類: 請求消息(request), 回應(yīng)消息(response).

方法 URI RTSP版本 CR LF
消息頭 CR LF
CR LF
消息體 CR LF

其中方法包括OPTION回應(yīng)中所有的命令,URI是接受方的地址,例如:rtsp://192.168.20.136. RTSP版本一般都是 RTSP/1.0. 每行后面的CR LF表示回車換行, 需要接受端有相應(yīng)的解析, 最后一個消息頭需要有兩個CR LF(即空行)

RTSP版本 狀態(tài)碼 解釋 CR LF
消息頭 CR LF
CR LF
消息體 CR LF

其中RTSP版本一般都是RTSP/1.0, 狀態(tài)碼是一個數(shù)值, 200表示成功, 解釋是與狀態(tài)碼對應(yīng)的文本解釋.

方法定義

方法記號表示資源上執(zhí)行的方法, 它區(qū)分大小寫. 新方法可在將來定義, 但不能以$開頭. 已定義方法如下表所示:

(注: P----演示, S----流, C----用戶端, S----服務(wù)器端)

| 方法 | 方向 | 對象 | 要求 | 含義 |
|---------------|-----------|------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| DESCRIBE | C->S | P,S | 推薦 | 檢查演示或媒體對象的描述, 也允許使用接收頭指定用戶理解的描述格式. DESCRIBE的答復(fù)-響應(yīng)組成媒體RTSP初始階段 |
| ANNOUNCE | C->S S->C | P,S | 可選 | 當從用戶發(fā)往服務(wù)器時, ANNOUNCE將請求URL識別的演示或媒體對象描述發(fā)送給服務(wù)器; 反之, ANNOUNCE實時更新連接描述. 如新媒體流加入演示, 整個演示描述再次發(fā)送, 而不僅僅是附加組件, 使組件能被刪除 |
| `GET_PARAMETER` | C->S S->C | P,S | 可選 | `GET_PARAMETER`請求檢查RUL指定的演示與媒體的參數(shù)值. 沒有實體體時, `GET_PARAMETER`也許能用來測試用戶與服務(wù)器的連通情況 |
| OPTIONS | C->S S->C | P,S | 要求 | 可在任意時刻發(fā)出OPTIONS請求, 如用戶打算嘗試非標準請求, 并不影響服務(wù)器狀態(tài) |
| PAUSE | C->S | P,S | 推薦 | PAUSE請求引起流發(fā)送臨時中斷. 如請求URL命名一個流, 僅回放和記錄被停止; 如請求URL命名一個演示或流組, 演示或組中所有當前活動的流發(fā)送都停止. 恢復(fù)回放或記錄后, 必須維持同步. 在SETUP消息中連接頭超時參數(shù)所指定時段期間被暫停后, 盡管服務(wù)器可能關(guān)閉連接并釋放資源, 但服務(wù)器資源會被預(yù)訂 |
| PLAY | C->S | P,S | 要求 | PLAY告訴服務(wù)器以SETUP指定的機制開始發(fā)送數(shù)據(jù); 直到一些SETUP請求被成功響應(yīng), 客戶端才可發(fā)布PLAY請求. PLAY請求將正常播放時間設(shè)置在所指定范圍的起始處, 發(fā)送流數(shù)據(jù)直到范圍的結(jié)束處. PLAY請求可排成隊列, 服務(wù)器將PLAY請求排成隊列, 順序執(zhí)行 |
| RECORD | C->S | P,S | 可選 | 該方法根據(jù)演示描述初始化媒體數(shù)據(jù)記錄范圍, 時標反映開始和結(jié)束時間; 如沒有給出時間范圍, 使用演示描述提供的開始和結(jié)束時間. 如連接已經(jīng)啟動, 立即開始記錄, 服務(wù)器數(shù)據(jù)請求URL或其他URL決定是否存儲記錄的數(shù)據(jù); 如服務(wù)器沒有使用URL請求, 響應(yīng)應(yīng)為201(創(chuàng)建), 并包含描述請求狀態(tài)和參考新資源的實體與位置頭. 支持現(xiàn)場演示記錄的媒體服務(wù)器必須支持時鐘范圍格式, smpte格式?jīng)]有意義 |
| REDIRECT | S->C | P,S | 可選 | 重定向請求通知客戶端連接到另一服務(wù)器地址. 它包含強制頭地址, 指示客戶端發(fā)布URL請求; 也可能包括參數(shù)范圍, 以指明重定向何時生效. 若客戶端要繼續(xù)發(fā)送或接收URL媒體, 客戶端必須對當前連接發(fā)送TEARDOWN請求, 而對指定主執(zhí)新連接發(fā)送SETUP請求 |
| SETUP | C->S | S | 要求 | 對URL的SETUP請求指定用于流媒體的傳輸機制. 客戶端對正播放的流發(fā)布一個SETUP請求, 以改變服務(wù)器允許的傳輸參數(shù). 如不允許這樣做, 響應(yīng)錯誤為"455 Method Not Valid In This State”. 為了透過防火墻, 客戶端必須指明傳輸參數(shù), 即使對這些參數(shù)沒有影響 |
| `SET_PARAMETER` | C->S S->C | P,S | 可選 | 這個方法請求設(shè)置演示或URL指定流的參數(shù)值. 請求僅應(yīng)包含單個參數(shù), 允許客戶端決定某個特殊請求為何失敗. 如請求包含多個參數(shù), 所有參數(shù)可成功設(shè)置, 服務(wù)器必須只對該請求起作用. 服務(wù)器必須允許參數(shù)可重復(fù)設(shè)置成同一值, 但不讓改變參數(shù)值. 注意: 媒體流傳輸參數(shù)必須用SETUP命令設(shè)置. 將設(shè)置傳輸參數(shù)限制為SETUP有利于防火墻. 將參數(shù)劃分成規(guī)則排列形式, 結(jié)果有更多有意義的錯誤指示 |
| TEARDOWN | C->S | P,S | 要求 | TEARDOWN請求停止給定URL流發(fā)送, 釋放相關(guān)資源. 如URL是此演示URL, 任何RTSP連接標識不再有效. 除非全部傳輸參數(shù)是連接描述定義的, SETUP請求必須在連接可再次播放前發(fā)布 |

某些防火墻設(shè)計與其他環(huán)境可能要求服務(wù)器插入RTSP方法和流數(shù)據(jù). 由于插入將使客戶端和服務(wù)器操作復(fù)雜, 并增加附加開銷, 除非有必要, 應(yīng)避免這樣做. 插入二進制數(shù)據(jù)僅在RTSP通過TCP傳輸時才可使用. 流數(shù)據(jù)(如RTP包)用一個ASCII字符'?封裝, 后跟一個一字節(jié)通道標識, 其后是封裝二進制數(shù)據(jù)的長度, 兩字節(jié)整數(shù). 流數(shù)據(jù)緊跟其后, 沒有CRLF, 但包括高層協(xié)議頭. 每個塊包含一個高層協(xié)議數(shù)據(jù)單元.

當傳輸選擇為RTP, RTCP信息也被服務(wù)器通過TCP連接插入. 缺省情況下, RTCP包在比RTP通道高的第一個可用通道上發(fā)送. 客戶端可能在另一通道顯式請求RTCP包, 這可通過指定傳輸頭插入?yún)?shù)中的兩個通道來做到. 當兩個或更多流交叉時, 為取得同步, 需要RTCP. 而且, 這為當網(wǎng)絡(luò)設(shè)置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑, 可能時, 在UDP上進行傳輸.

消息頭定義

消息頭的定義如下表. 表格說明:

• Type:
  • 類型 "g" 表示請求和響應(yīng)中的通用請求頭;
  • 類型 "R" 表示請求頭;
  • 類型 "r" 表示響應(yīng)頭;
  • 類型 "e" 表示實體頭字段.
• Support:
  • "req." 表示必須由接收者以特殊的方法實現(xiàn); 注意, 不是所有 "req." 字段在該類型的每個請求中都會被發(fā)送. "req." 只表示客戶機(支持響應(yīng)頭)和服務(wù)器(支持請求頭)必須執(zhí)行該字段.
  • "opt." 表示是可選的.
• 最后一欄列出了關(guān)于頭字段產(chǎn)生作用的方法; 其中 "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 | 這個標記的存在說明后面有實體數(shù)據(jù), 而且給出了這個數(shù)據(jù)塊的大小, 單位是byte |
| X-Playlist-Gen-Id | 用來檢查播放列表是否有效. 這個標記最初在客戶端發(fā)送DESCRIBE命令后使用. 客戶端在發(fā)送“SETUP”命令給服務(wù)器時必須回應(yīng)一樣的值 |
| X-Playlist-Seek-Id | 值必須和X-Playlist-Gen-Id 域的值相同, 在PLAY請求命令中使用. |
| Blocksize | 媒體包的總長度，單位是byte |
| Session | Session ID是用作客戶端和服務(wù)器之間是否是正確的連接。在客戶端發(fā)送SETUP命令后，服務(wù)器會在應(yīng)答消息頭里面發(fā)送一個session值給客戶端。這算建立的一個會話. |
| X-Accept-Authentication | 允許的authentication 方法. NTLM, Digest 和 Basic 是標準的 |
| X-Broadcast-Id | 是否是實況或者是先期錄制的流。0 表示先期錄制，其他的值表示是實況。 |
| Range | 暫無中文釋義 |
| Speed | 用來調(diào)整傳輸?shù)娇蛻舳说牧鞯盟俣取＜偃缒愕膸捒梢越邮芨咚俚臄?shù)據(jù)傳送，這個域的值可以設(shè)置大于1來加速下載數(shù)據(jù). i.e. x1 rate |
| Server | 服務(wù)器類型和軟件版本 |
| EOF | 文件結(jié)束標記，也是流的結(jié)束標記 |
| Date | 日期時間，下面舉個例子：Tue, 18 Nov 2003 15:57:07 GMT |
| Bandwidth | 流需要的最大帶寬，bits/秒 |
| Transport | 使用什么協(xié)議來傳輸數(shù)據(jù)，比如TCP或者UDP等 |
| Etag | 實體標記Entity tag，是一個分配給會話的值，就像”23180160″ |
| Supported | 支持的COM modules , 有的是可選的. |
| Content-Type | 此域用來表示命令或者應(yīng)答的用意. 下面是常用的幾種類型 |
| \/ | application/x-wms-Logconnectstats 這個在SET_PARAMETER命令中用到，表示將客戶端的信息登記到服務(wù)器上。 |
| \/ | application/sdp 這個表示接下來數(shù)據(jù)包里面的是sdp數(shù)據(jù)，它是在服務(wù)器對DESCRIBE命令的應(yīng)答包中。 |
| \/ | application/x-wms-contentdesc 表示緊跟的數(shù)據(jù)是一個內(nèi)容描述對象，它設(shè)置the layout of the dialog. |
| \/ | application/vnd.ms.wms-hdr.asfv1 表示跟著一個流媒體頭信息(ASF header)，可以用BASIC 或者DIGEST來解碼。 |
| \/ | application/x-rtsp-packetpair 它被用來確定連接的可用帶寬。 |

狀態(tài)碼

標準RTSP 消息的狀態(tài)碼(在應(yīng)答消息的第一行表示)

| 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 |

rtsp中常用方法舉例

本節(jié)針對上面所述的典型交互過程進行說明

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 //每個回應(yīng)消息的cseq數(shù)值和請求消息的cseq相對應(yīng)
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,GET_PARAMETER //服務(wù)器提供的可用的方法

DESCRIBE

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)

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, 表示對該通道進行設(shè)置. Transport參數(shù)設(shè)置了傳輸模式, 包的結(jié)構(gòu). 接下來的數(shù)據(jù)包頭部第二個字節(jié)位置就是 interleaved, 它的值是每個通道都不同的, trackID＝0的interleaved值有兩個0或1, 0表示rtp包, 1表示rtcp包, 接 受端根據(jù)interleaved的值來區(qū)別是哪種數(shù)據(jù)包.

RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894 //服務(wù)器回應(yīng)的會話標識符
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- //設(shè)置播放時間的范圍
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協(xié)議概述

簡介

SDP 完全是一種會話描述格式, 它不屬于傳輸協(xié)議.

它使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議（SAP）、會話初始協(xié)議（SIP）、 實時流協(xié)議（RTSP）、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）。

SDP協(xié)議是也是基于文本的協(xié)議，這樣就能保證協(xié)議的可擴展性比較強, 這樣就使其具有廣泛的應(yīng)用范圍。SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商, 所以在流媒體中只用來描述媒體信息。媒體協(xié)商這一塊要用RTSP來實現(xiàn)．

SDP協(xié)議格式

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結(jié)構(gòu)化的文本串，其格式依<類型>而定。

＜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 = (協(xié)議版本)
o = (所有者/創(chuàng)建者和會話標識符)
s = (會話名稱)
i = * (會話信息)
u = * (URI 描述)
e = * (Email 地址)
p = * (電話號碼)
c = * (連接信息)
b = * (帶寬信息)
z = * (時間區(qū)域調(diào)整)
k = * (加密密鑰)
a = * (0 個或多個會話屬性行)
時間描述:
t = (會話活動時間)
r = * (0或多次重復(fù)次數(shù))
媒體描述:
m = (媒體名稱和傳輸?shù)刂?
i = * (媒體標題)
c = * (連接信息 — 如果包含在會話層則該字段可選)
b = * (帶寬信息)
k = * (加密密鑰)
a = * (0 個或多個媒體屬性行)

SDP協(xié)議舉例說明

SDP（Session Description Protocol）是一個用來描述多媒體會話的應(yīng)用層控制協(xié)議，它是一個基于文本的協(xié)議，用于會話建立過程中的媒體類型和編碼方案的協(xié)商等。

消息正文格式：

v=0 //該行指示協(xié)議的版本

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 //o行中包含與會話所有者有關(guān)的參數(shù)

• 第一個參數(shù)表明會話發(fā)起者的名稱，該參數(shù)可不填寫，如填寫和SIP消息中，from消息頭的內(nèi)容一致。
• 第二個參數(shù)為主叫方的會話標識符。
• 第三個參數(shù)為主叫方會話的版本，會話數(shù)據(jù)有改變時，版本號遞增。
• 第四個參數(shù)定義了網(wǎng)絡(luò)類型，IN表示Internet網(wǎng)絡(luò)類型，目前僅定義該網(wǎng)絡(luò)類型。
• 第五個參數(shù)為地址類型，目前支持IPV4和IPV6兩種地址類型。
• 第六個參數(shù)為地址：表明會話發(fā)起者的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，通過該地址可以查閱到會話的更多內(nèi)容

e=mjh@isi.edu (Mark Handley) //會話責任人的EMIAL地址

c=IN IP4 224.2.17.12/127 //C行包含為多媒體會話而建立的連接的信息，其中指出了真正的媒體流使用的IP地址

• 第一個參數(shù)為網(wǎng)絡(luò)類型，目前僅定義INTERNET網(wǎng)絡(luò)類型。用“IN”表示。
• 第二個參數(shù)為地址類型，目前支持兩種地址類型：IPV4和IPV6。
• 第三個參數(shù)為地址，該地址為多媒體流使用的IP地址。

t=2873397496 2873404696 //表示會話的開始時間和結(jié)束時間

• 第一個參數(shù)表明會話的開始時間，數(shù)字表明從1900年1月1日00：00以來所經(jīng)過的秒數(shù)。
• 第二個參數(shù)表明會話的結(jié)束時間，數(shù)字表明從1900年1月1日00：00以來所經(jīng)過的秒數(shù)。

m=audio 3458 RTP/AVP 0 96 97 // m行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息

• 第一個參數(shù)為媒體名稱：表明支持音頻類型。
• 第二個參數(shù)為端口號，表明UE在本地端口為3458上發(fā)送音頻流。
• 第三個參數(shù)為傳輸協(xié)議，一般為RTP/AVP協(xié)議。
• 第四~七參數(shù)為所支持的四種凈荷類型編號

a=rtpmap:0 PCMU //a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB

格式為：a=rtpmap:<凈荷類型><編碼名稱> * 凈荷類型0固定分配給了PCMU， * 凈荷類型96對應(yīng)的編碼方案為G.726,為動態(tài)分配的。 * 凈荷類型97對應(yīng)的編碼方式為自適應(yīng)多速率寬帶編碼（AMR-WB），為動態(tài)分配的。

m=video 3400 RTP/AVP 98 99 //m行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息

• 第一個參數(shù)為媒體名稱：表明支持視頻類型。
• 第二個參數(shù)為端口號，表明UE在本地端口為3400上發(fā)送視頻流。
• 第三個參數(shù)為傳輸協(xié)議，一般為RTP/AVP協(xié)議。
• 四、五參數(shù)給出了兩種凈荷類型編號

a=rtpmap:98 MPV
a=rtpmap:99 H.261

格式為：a=rtpmap:<凈荷類型><編碼名稱> * 凈荷類型98對應(yīng)的編碼方案為MPV,為動態(tài)分配的。 * 凈荷類型97對應(yīng)的編碼方式為H.261，為動態(tài)分配的。