牽著老婆滿街逛

目錄:

概述

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可以是雙向的.

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添加方法.
• 適當的服務器控制: 如用戶啟動一個流, 必須也可以停止一個流.
• 傳輸協調: 實際處理連續媒體流前, 用戶可協調傳輸方法.
• 性能協調: 如基本特征無效, 必須有一些清理機制讓用戶決定哪種方法沒生效. 這允許用戶提出適合的用戶界面.

協議細節

典型的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消息格式

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 |

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

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, 表示對該通道進行設置. 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協議概述

簡介

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

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

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

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 個或多個媒體屬性行)

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協議。
• 四、五參數給出了兩種凈荷類型編號

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

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