博客 / 詳情

返回

webrtc sdp協議介紹

Session Description Protocol(會話描述協議)

RFC定義SDP的協議有兩個:

  • RFC3264: An Offer/Answer Model with the session Description Protocol(SDP),用來概述一個請求/響應模型
  • RFC2327: SDP:Session Description Protocol,描述數據格式.

1.RFC2327

1.1.概述

SDP 完全是一種會話描述格式 ― 它不屬於傳輸協議 ― 它只使用不同的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。SDP協議是也是基於文本的協議，這樣就能保證協議的可擴展性比較強，這樣就使其具有廣泛的應用範圍。SDP 不支持會話內容或媒體編碼的協商，所以在流媒體中只用來描述媒體信息。媒體協商這一塊要用RTSP來實現．
SDP包括以下一些方面：

  • 會話的名稱和目的
  • 會話存活時間

  • 包含在會話中的媒體信息，包括：

    • 媒體類型(video, audio, etc)
    • 傳輸協議(RTP/UDP/IP, H.320, etc)
    • 媒體格式(H.261 video, MPEG video, etc)
    • 多播或遠端（單播）地址和端口
  • 為接收媒體而需的信息(addresses, ports, formats and so on)
  • 使用的帶寬信息
  • 可信賴的接洽信息（Contact information）

1.2.SDP協議格式

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。
＜type＞=<value>[CRLF]

1.2.1.fields分類
  1. Seeesion Description
  2. v(Protocol Version),mnd,The current protocol version.Always "0" using RFC4566
  3. o(Origin),Mnd,The session originator's name and session identifiers.
  4. s(Session Name), Mnd,The textural session Name
  5. i(Session Information), opt,Textural information about the session
  6. u(Uri),opt, A pointer to supplemental session Information
  7. e(Email Address), opt, Email contract information for the person responsible.
  8. P(phone Address),opt,Phone contract information for the person responsible
  9. c(Connection Data),C,The connection type and Address
  10. b(Bandwidth),opt,Proposed bandwidth limits.
  11. z(Time Zones), opt, Accounts for daylight saving information
  12. k(Encryption Keys),opt,A simple mechanism for exchanging keys, Rarely used.
  13. Timing Description
  14. t(Timing),mnd, start and end times.
  15. r(Repeat Times),opt, Specified the duration and intervals for any session repeats.
  16. Media Description
  17. m(Media Description),mnd, Media definitions including media type(e.g."audio"),transport details and formats.
  18. i(Session Information),opt
  19. c(Connection Data),c
  20. b(Bandwidth):opt
  21. k( Encryption keys),opt
  22. a(Attributes),opt
1.2.2.典型格式
Session description
   v=  (protocol version)
   o=  (owner/creator and session identifier)
   s=  (session name)
   i=* (session information)
   u=* (URI of description)
   e=* (email address)
   p=* (phone number)
   c=* (connection information - not required if included in all media)
   b=* (zero or more bandwidth information lines)
   One or more time descriptions ("t=" and "r=" lines, see below)
   z=* (time zone adjustments)
   k=* (encryption key)
   a=* (zero or more session attribute lines)
   Zero or more media descriptions
Time description
   t=  (time the session is active)
   r=* (zero or more repeat times)
Media description, if present
   m=  (media name and transport address)
   i=* (media title)
   c=* (connection information - optional if included at
        session-level)
   b=* (zero or more bandwidth information lines)
   k=* (encryption key)
   a=* (zero or more media attribute lines)

帶"*"號的是可選的,其餘的是必須的。一般順序也按照上面的順序來排列。

1.2.3.各type對應值的結構化文本串
  1. v=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
    其中：nettype是IN,代表internet,addrtype是IP4或IP6。unicast-address任務創建計算機的地址。
    整個這個屬性，是唯一表示一個任務。
  2. e=123@126.com 或 p=+1 616 555-6011
    對於一個任務只能兩者之中的一個，表示會議控制者的聯繫方式。郵件地址可以是[email]j.doe@example.com[/email] (Jane Doe)形式，括號裏面的是描述聯繫人的名稱，或者Jane Doe <[email]j.doe@example.com[/email]>，前面的是聯繫人的名稱。
  3. c=<nettype> <addrtype> <connection-address>
    這個連接數據，可以是傳話級別的連接數據，或者是單獨一個媒體數據的連接數據。在是多播時，connection-address就該是一個多播組地址，當是單播時，connection-address就該是一個單播地址。對於addrtype是IP4的情況下，connection-address不僅包含IP地址，並且還要包含a time to live value(TTL 0-255)，如：c=IN IP4 224.2.36.42/128，IP6沒有這個TTL值。還允許象這樣的<base multicast address>[/<ttl>]/<number of addresses>格式的connection-address。如：c=IN IP4 224.2.1.1/127/3等同於包含c=IN IP4 224.2.1.1/127, c=IN IP4 224.2.1.2/127, c=IN IP4 224.2.1.3/127三行內容。
  4. b=<bwtype>:<bandwidth> bwtype可以是CT或AS，CT方式是設置整個會議的帶寬，AS是設置單個會話的帶寬。缺省帶寬是千比特每秒。
    t=<start-time> <stop-time>，這個可以有行，指定多個不規則時間段，如果是規則的時間段，則r=屬性可以使用。start-time和stop- time都遵從NTP(Network Time Protocol),是以秒為單位，自從1900以來的時間。要轉換為UNIX時間，減去2208988800。如果stop-time設置為0,則會話沒有時間限制。如果start-time也設置為0，則會話被認為是永久的。
  5. b=<bwtype>:<bandwidth> bwtype可以是CT或AS，CT方式是設置整個會議的帶寬，AS是設置單個會話的帶寬。缺省帶寬是千比特每秒。
    t=<start-time> <stop-time>，這個可以有行，指定多個不規則時間段，如果是規則的時間段，則r=屬性可以使用。start-time和stop- time都遵從NTP(Network Time Protocol),是以秒為單位，自從1900以來的時間。要轉換為UNIX時間，減去2208988800。如果stop-time設置為0,則會話沒有時間限制。如果start-time也設置為0，則會話被認為是永久的。
  6. r=<repeat-interval> <active duration> <offsets from start-time>重複次數在時間表示裏面可以如下表示：
    d - days (86400 seconds)
    h - hours (3600 seconds)
    m - minutes (60 seconds)
    s - seconds (allowed for completeness)
  7. z=<adjustment time> <offset> <adjustment time> <offset> ....
  8. k=<method>
  9. k=<method>:<encryption key>
  10. a=<attribute>
  11. a=<attribute>:<value>
  12. m=<media> <port> <proto> <fmt> ...
  13. m=<media> <port>/<number of ports> <proto> <fmt> ...
  14. a=cat:<category>分類，根據分類接收者隔離相應的會話
  15. a=keywds:<keywords>關鍵字，根據關鍵字隔離相應的會話
  16. a=tool:<name and version of tool>創建任務描述的工具的名稱及版本號
  17. a=ptime:<packet time>在一個包裏面的以毫秒為單位的媒體長度
  18. a=maxptime:<maximum packet time>以毫秒為單位，能夠壓縮進一個包的媒體量。
  19. a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]
  20. a=recvonly
  21. a=sendrecv
  22. a=sendonly
  23. a=inactive，
  24. a=orient:<orientation>其可能的值，"portrait", "landscape" and "seascape" 。
  25. a=type:<conference type>,建議值是，"broadcast", "meeting", "moderated", "test" and "H332"。
  26. a=charset:<character set>
  27. a=sdplang:<language tag>指定會話或者是媒體級別使用的語言
  28. a=framerate:<frame rate>設置最大視頻幀速率
  29. a=quality:<quality>值是0-10

  30. a=fmtp:<format> <format specific parameters>
    在SIP協議的包含的內容是SDP時，應該把Content-Type設置成application/sdp。

    1.3.SDP協議例子

    1.3.1.helix流媒體服務器的RTSP協議中的SDP協議:
    v=0 //SDP version
// o field定義的源的一些信息。其格式為：o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
o=- 1271659412 1271659412 IN IP4 10.56.136.37 s=<No title>
i=<No author> <No copyright>  //session的信息
c=IN IP4 0.0.0.0 //connect 的信息，分別描述了：網絡協議，地址的類型，連接地址。
c=IN IP4 0.0.0.0
t=0 0 //時間信息，分別表示開始的時間和結束的時間，一般在流媒體的直播的時移中見的比較多。
a=SdpplinVersion:1610641560 //描述性的信息
a=StreamCount:integer;2 //用來描述媒體流的信息，表示有兩個媒體流。integer表示信息的格式為整數。
a=control:*
a=DefaultLicenseValue:integer;0 //License信息
a=FileType:string;"MPEG4" ////用來描述媒體流的信息説明當前協商的文件是mpeg4格式的文件
a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"
a=range:npt=0-72.080000  //用來表示媒體流的長度
m=audio 0 RTP/AVP 96 //做為媒體描述信息的重要組成部分描述了媒體信息的詳細內容：表示session的audio是通過RTP來格式傳送的，其payload值為96傳送的端口還沒有定。
b=as:24 //audio 的bitrate
b=RR:1800
b=RS:600
a=control:streamid=1  //通過媒體流1來發送音頻
a=range:npt=0-72.080000 //説明媒體流的長度。
a=length:npt=72.080000
a=rtpmap:96 MPEG4-GENERIC/32000/2 //rtpmap的信息，表示音頻為AAC的其sample為32000
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 //config為AAC的詳細格式信息
a=mimetype:string;"audio/MPEG4-GENERIC"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;48000
a=HasOutOfOrderTS:integer;1
a=MaxBitRate:integer;48000
a=Preroll:integer;1000
a=OpaqueData:buffer;"A4CAgCIAAAAEgICAFEAVABgAAAC7gAAAu4AFgICAAhKIBoCAgAEC"
a=StreamName:string;"Audio Track"
下面是video的信息基本和audio的信息相對稱，這裏就不再説了。
m=video 0 RTP/AVP 97
b=as:150
b=RR:11250
b=RS:3750
a=control:streamid=2
a=range:npt=0-72.080000
a=length:npt=72.080000
a=rtpmap:97 MP4V-ES/2500
a=fmtp:97 profile-level-id=1;
a=mimetype:string;"video/MP4V-ES"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;300000
a=HasOutOfOrderTS:integer;1
a=Height:integer;240 //影片的長度
a=MaxBitRate:integer;300000
a=MaxPacketSize:integer;1400
a=Preroll:integer;1000
a=Width:integer;320  //影片的寬度
a=OpaqueData:buffer;"AzcAAB8ELyARAbd0AAST4AAEk+AFIAAAAbDzAAABtQ7gQMDPAAABAAAAASAAhED6KFAg8KIfBgEC"
a=StreamName:string;"Video Track"
    1.3.2.Webrtc SDP示例
    v=0
o=- 0 0 IN IP4 127.0.0.1
s=WX-RTC-SERVER
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS ryODEhTpFz
m=audio 1 UDP/TLS/RTP/SAVPF 0 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1 1 udp 2013266431 192.168.0.68 42739 typ host generation 0
a=ice-ufrag:T+0c
a=ice-pwd:FzV1T/5PiBI78s630cwSb6
a=fingerprint:sha-256 2D:38:ED:09:73:36:F9:18:A6:CB:BC:ED:FB:C5:60:B3:F1:6C:FC:BD:97:57:AD:A6:38:11:9D:D4:8F:77:D6:C3
a=setup:active
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
m=video 1 UDP/TLS/RTP/SAVPF 124 125 96
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1 1 udp 2013266431 192.168.0.68 42739 typ host generation 0
a=ice-ufrag:T+0c
a=ice-pwd:FzV1T/5PiBI78s630cwSb6
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=fingerprint:sha-256 2D:38:ED:09:73:36:F9:18:A6:CB:BC:ED:FB:C5:60:B3:F1:6C:FC:BD:97:57:AD:A6:38:11:9D:D4:8F:77:D6:C3
a=setup:active
a=recvonly
a=mid:video
a=rtcp-mux
a=rtpmap:124 H264/90000
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:124 goog-remb
a=fmtp:124 x-google-max-bitrate=800;x-google-min-bitrate=150;x-google-start-bitrate=300
a=rtpmap:125 H264/90000
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:125 goog-remb
a=fmtp:125 x-google-max-bitrate=800;x-google-min-bitrate=150;x-google-start-bitrate=300
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb

    2.RFC3264

    An Offer/Answer Model with the Session Description Protocol (SDP)

    2.1情態動詞

    定義在RFC2119:

  31. "MUST"，必須、一定要；
  32. "MUST NOT"，禁止；
  33. "REQUIRED"，需要；
  34. "SHALL"、"SHOULD"，應該；
  35. "SHALL NOT"、"SHOULD NOT"，不應該；
  36. "RECOMMENDED"，推薦；

  37. "MAY"，可以

    2.2術語

  38. 媒體流（Media Stream），或稱為媒體類型（Media Type），即我們通常所説的音頻流、視頻流等，所有通信實體要進行媒體交互之前都必須進行媒體注的協商
  39. 媒體格式（Media Format），每種媒體流都有不同的編碼格式，像音頻有G711、G712編碼，視頻有H261、H264等，像現在所謂的高清視頻採用是720P、1070P等。
  40. 單一會話（Unitcast Session）
  41. 多會話（Multicast Sessions）
  42. 單一媒體流（Unitcast Streams）

  43. 多媒體流（Multicast Streams）

    2.3offer/answer

    rfc3264協議[1]主要概述一個請求/響應模型（offer/answer，以下敍述採用英文），包括請求/響應的實體和不同階段的操作行為，如初始協商過程和重協商過程，並簡單介紹消息中各種參數的含義。具體各個參數的詳細説明見rfc2327協議[2]
    ![[8.Attachments/image/a5176ce3d80586e017f4de08f5e03140_MD5.png]]

    2.3.1.實體,消息

    Offer/Answer模型包括兩個實體，一個是請求主體Offerer，另外一個是響應實體Answerer，兩個實體只是在邏輯上進行區分，在一定條件可以轉換。例如，手機A發起媒體協商請求，那麼A就是Offerer，反之如果A為接收請求則為Offerer。
    Offerer發給Answerer的請求消息稱為請求offer，內容包括媒體流類型、各個媒體流使用的編碼集，以及將要用於接收媒體流的IP和端口。
    Answerer收到offer之後，回覆給Offerer的消息稱為響應，內容包括要使用的媒體編碼，是否接收該媒體流以及告訴Offerer其用於接收媒體流的IP和端口。

    2.3.2.SDP各個參數簡單介紹

    下面示例摘自3264協議[1]

  44. v=0
  45. o=carol 28908764872 28908764872 IN IP4 100.3.6.6 //會話ID號和版本
  46. s=- //用於傳遞會話主題
  47. t=0 0 //會話時間，一般由其它信令消息控制，因此填0
  48. c=IN IP4 192.0.2.4 //描述本端將用於傳輸媒體流的IP
  49. m=audio 0 RTP/AVP 0 1 3 //媒體類型 端口號 本端媒體使用的編碼標識（Payload）集
  50. a=rtpmap:0 PCMU/8000 //rtpmap映射表，各種編碼詳細描述參數，包括使用帶寬（bandwidth）
  51. a=rtpmap:1 1016/8000
  52. a=rtpmap:3 GSM/8000
  53. a=sendonly //説明本端媒體流的方向，取值包括sendonly/recvonly/sendrecv/inactive
  54. a=ptime:20 //説明媒體流打包時長
  55. m=video 0 RTP/AVP 31 34
  56. a=rtpmap:31 H261/90000

  57. a=rtpmap:34 H263/90000

    2.3.3.實體行為、操作過程
    2.3.3.1.初始協商的Offer請求

    實體A <-> 實體B，實體首先發起Offer請求，內容如2節所示，對於作何一個媒體流/媒體通道，這時實體A必須：

  58. 如果媒體流方向標為recvonly/sendrecv，即a=recvonly或a=sendrecv，則A必須（MUST）準備好在這個IP和端口上接收實體B發來的媒體流；

  59. 如果媒體流方向標為sendonly/inactive，即a=recvonly或a=sendrecv，則A不需要進行準備。

    2.3.3.1.Answer響應

    實體B收到A的請求offer後，根據自身支持的媒體類型和編碼策略，回覆響應。

  60. 如果實體B回覆的響應中的媒體流數量和順序必須（MUST）和請求offer一致，以便實體A進行甄別和決策。即m行的數量和順序必須一致，B不能（MUST NOT）擅自增加或刪除媒體流。如果B不支持某個媒體流，可以在對應的端口置0，但不能不帶這個m行描述。
  61. 對於某種媒體，實體B必須（MUST）從請求offer中選出A支持且自己也支持的該媒體的編碼標識集，並且可以（MAY）附帶自己支持的其它類型編碼。

  62. 對於響應消息中各個媒體的方向：

    • 如果請求某媒體流的方向為sendonly，那麼響應中對應媒體的方向必須為recvonly；
    • 如果請求某媒體流的方向為recvonly，那麼響應中對應媒體的方向必須為sendonly；
    • 如果請求某媒體流的方向為sendrecv，那麼響應中對應媒體的方向可以為sendrecv/sendonly/recvonly/inactive中的一種；
    • 如果請求某媒體流的方向為inactive，那麼響應中對應媒體的方向必須為inactive；
  63. 響應answer裏提供IP和端口，指示Offerer本端期望用於接收媒體流的IP和端口，一旦響應發出之後，Offerer必須（MUST）準備好在這個IP和端口上接收實體A發來的媒體流。
  64. 如果請求offer中帶了ptime（媒體流打包間隔）的a行或帶寬的a行，則響應answer也應該（SHOULD）相應的攜帶。

  65. 實體B Offerer應該（SHOULD）使用實體A比較期望的編碼生成媒體流發送。一般來説對於m行，如m=video 0 RTP/AVP 31 34，排充越靠前的編碼表示該實體越希望以這個編碼作為載體，這裏示例31(H261)，34（H263）中H261為A更期望使用的編碼類型。同理，當實體A收到響應answer後也是這樣理解的。

    2.3.3.2.實體收到響應後的處理

    當實體A收到B回覆的響應後，可以（MAY）開始發送媒體流，如果媒體流方向為sendonly/sendrecv，

  66. 必須（MUST）使用answer列舉的媒體類型/編碼生成媒體發送；
  67. 應該（SHOULD）使用answer中的ptime和bandwidth來打包發送媒體流；
  68. 可以（MAY）立即停止監聽端口，該端口為offer支持answer不支持的媒體所使用的端口。
2.3.4.修改媒體流（會話）

修改媒體流的offer-answer操作必須基於之前協商的媒體形式（音頻、視頻等），不能（MUST NOT）對已有媒體流進行刪減。

2.3.4.1.刪除媒體流

如果實體認定新的會話不支持之前媒商的某個媒體，新的offer只須對這種媒體所在m行的端口置0，但不能不描述這種媒體，即不帶對應m行。當answerer收到響應之後，處理同初始協商一樣。

2.3.4.2.增加媒體流

如果實體打算新增媒體流，在offer裏只須加上描述即可或者佔用之前端口被置0的媒體流，即用新的媒體描述m行替換舊的。當answerer收到offer請求後，發現有新增媒體描述，或者過於端口被置0的媒體行被新的媒體描述替換，即知道當前為新增媒體流，處理同初始協商。

2.3.4.3.修改媒體流

修改媒體注主要是針對初始協商結果，如果有變更即進入修改流程處理，可能的變更包括IP地址、端口，媒體格式（編碼），媒體類型（音、視頻），媒體屬性（ptime，bandwidth，媒體流方向變更等）。

音視頻 , webrtc
user avatar garfileo 頭像 alps2006 頭像
2 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.