在上一章節 SDP基礎-使用和要求的章節中，筆者討論了關於SDP的使用場景和一些SDP語法構建。這裡，我們根據SDP的規範說明，重點介紹SDP的具體參數。
5
SDP規範標準
一般來說，SDP會話描述的語法由五個核心部分構成，它們分別是：會話元數據，流媒體，服務保障，網絡和安全。
Session metadata(會話元數據)描述了會話本身所需要的數據標識，包括SDP協議版本，會話發起方描述，會話身份確認描述和會話活動時間。
Stream description包含了媒體功能的描述細節和參數。
QoS描述包含了所有媒體流性能參數，它可能通過其他信息的調用對多媒體流打包支持帶寬和其他資源的優化。
Network description可能包括各種傳輸協議（TCP，UDP等）和網絡協議以便支持多媒體會議參與方之間的媒體收發。
Security 描述包括了密鑰，籤權，認證，不可否認性，完整性內容。
一個SDP會話描述通過媒體類型標識為："application/sdp"。SDP會話描述完全是一種文本格式，其格式遵從UTF-8解碼規範。其基本的語法規範是：
<code><type>=<value>/<type>/<code>
這裡，type必須是一個大小寫敏感的字符，value是一種具有一定結構的文本，value的格式完全取決於type的取值。通常情況下，value可以是多個值域或者一個自由文本格式。如果value包含多個值域的話，通過單空格隔離。注意，“=”兩邊決定不能使用空格。
SDP會話描述由會話級描述緊接著零或多個媒體級的描述構成。其中，會話級描述以"v="行開始，一直繼續到第一個媒體級的"m="行之前結束。媒體級會話描述以"m="行開始，然後繼續到下一個媒體級或整個會話描述結束。通常來說，除非媒體級的值覆蓋默認設置，一般來說，對所有媒體來說，會話級的設置是默認的。會話描述行分為必要設置和可選設置兩個部分，其會話描述文本格式必須按照固定順序呈現，這樣可以方便處理，避免語法錯誤。其中，可選會話描述設置帶有一個"*"字符作為標識。
<code>v=(protocol version) // "v" 開始o=(originator 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， 這裡可能無媒體會話/<code> 媒體描述示例：
<code>m=(media name and transport address) // "m" 開始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)/<code>
接下來，筆者重點介紹幾個常用的會話描述設置，主要包括會話級參數，時間和媒體級參數設置。其他的會話描述在後續具體章節中再做闡述。
Protocol Version ("v=")，其語法格式為：
<code>v=0/<code>
"v"定義了SDP版本。此規範定義的是0，沒有子版本。
Origin ("o=")，其語法格式為：
<code>o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>/<addrtype>/<nettype>/<sess-version>/<sess-id>/<username>/<code>
"o=" 定義了會話發起方名稱，sess-id 是一個數值字符串，通過用戶名稱，sess-id，nettype，addrtype，和unicast-address構成了一個全局唯一認證ID，<sess-version>是此會話描述的版本號，<nettype>是一個文本字符串，表示網絡類型，初始設置是”IN"表示Internet。<addrtype>是一個文本字符串地址，表示是IP4或IP6，也可能使用其他的值。<unicast-address>，此地址是一個創建此會話的機器地址。/<unicast-address>/<addrtype>/<nettype>/<sess-version>
Session Name ("s=")， 其語法格式為：
<code>s=<session>/<code>
"s="定義了文本會話名稱，這裡必須是僅一個會話名稱，此名稱不能為空，其字符串應該包含ISO 10646字符。
Session Information ("i=")， 其語法格式為：
<code>i=<session>/<code>
"i=" 提供了關於此會話的文本信息，每個會話描述必須有一個"i="，一個媒體至少一個"i="。如果出現了"a=charset"屬性的話，它會設定"i="的字符設置。如果沒有出現"a=charset"的話，"i="必須包含用UTF-8解碼的ISO 1646字符。單個"i="也可以使用在每個媒體定義中。在媒體定義中，"i="的主要目的是為了標註媒體流。因此，這種標註方式對單會話環境中有同一媒體類型，它需要支持完全不同的媒體流時非常有用。例如，兩個不同的白板功能，一個白板是支持自己的幻燈片播放，另外一個白板支持問題答疑和回覆處理。
URI ("u=")，其語法格式為：
<code>u=/<code>
URL是www用戶使用的處理方式，URL應該指向一個針對此會話的其他另外資源地址。此描述是可選描述。但是，如果它出現的話，它必須出現在第一個媒體前面。在每個會話描述中不允許第二個URL出現。
Email Address 和 Phone Number ("e=" 和 "p=")，其語法格式為：
<code>e=<email-address>p=<phone-number>/<email-address>/<code>
"e=" 和 "p="定義了負責會議的聯繫人信息。是否包含"e=" 和 "p="是可選的。這兩個會話描述使用不是非常廣泛。但是，如果出現了郵箱和電話號碼的話，它們必須出現在第一個媒體域前面。一個會話可以支持一個或者多個郵箱或者電話號碼。電話號碼的格式必須按照ITU-T推薦格式來定義，號碼前加一個”+“前綴，並且使用”-“分離電話號碼，方便用戶閱讀。例如：
<code>p=+1 617 555-6011/<code>
如果是電子郵件的話，兩種格式都可以支持：
<code>[email protected] (Jane Doe)或者e=Jane Doe <j.doe>/<code>
Connection Data ("c="), 其語法格式為：
<code>c=<nettype> <addrtype> <connection-address>/<addrtype>/<nettype>/<code>
它包含一些連接數據。在會話描述中，媒體描述必須至少包含一個"c="行，或者在會話級包含一個單個"c="行。在某些應用場景中，預設的媒體設置可以覆蓋默認的設置會話級的參數。因此，在每個媒體會話中，"c="可以包含一個單個的會話級的"c="和其他另外的子"c="行。這裡的<nettype>和<addrtype>值和前面介紹的一樣，讀者參考前面的介紹。<connection-address>是一個連接地址，在連接地址後可以增加另外的子項，這些子項取決於<addrtype>類型（是IP4還是IP6地址）。如果會話在多播方式做工作，連接地址必須是一個多播地址組，如果會話在單播方式工作，則廣播地址是單播地址。如果會話使用的是一個多播IP4類型的話，多播連接地址必須支持存活時間（TTL），TTL取值範圍在0-255之間（例如：c=IN IP4 224.2.36.42/127，TTL是127）。注意，IP6沒有使用TTL，因此也沒有TTL設置，TTL肯定不會出現在IP4中。IP6使用的是一種繼承或層級方式來實現連接地址的處理（例如：c=IN IP6 FF15::101， 無TTL）。/<addrtype>/<connection-address>/<addrtype>/<nettype>
Bandwidth ("b=")，其語法格式為：
<code>b=<bwtype>:<bandwidth> // kilobits per second/<bandwidth>/<bwtype>/<code>
它是一個可選會話描述，表示對會話或者媒體建議使用的帶寬。帶寬類型子項是
以字母方式表示（我們這裡討論的是支持兩種類型：CT和AS，還有可能出現TIAS），針對後面的帶寬數值描述。CT和AS在創建使用上有明顯的不同。CT（Conference Total）表示多會話廣播中會話或者媒體使用的最大帶寬建議值，CT值相當於所有會話帶寬值。AS(Application-Specific)是指具體某個應用程序所佔用的總帶寬建議值，相當於最大應用程序帶寬值，它僅值單媒體在單點所佔用的帶寬。如果讀者對AS有興趣的話，可以閱讀RFC3550-6，RFC3556-2中的RS/PR收發帶寬修改機制和RFC3890關於Bandwidth Modifier的規範說明。
Timing ("t=")，其語法格式為：
<code>t=<start-time> <stop-time>/<start-time>/<code>
它設置了啟動和停止會話的時間。如果在非正常週期時間段啟動會話，此會話需要增加多"t="行。每個"t="支持另外一個時間段表示會話在此時間段是活動狀態。如果會話使用在正常時間週期，"t="後面加了一個"r="行表示重複次數。這兩個時間標識使用的是NTP的十進制的方式表示，以秒為單位。此時間規範在RFC1305中有非常明確的發明，此時間不是UNIX定義的時間，用戶可以參考轉換方式來進一步瞭解如何轉換。 如果<stop-time>設置為0，則表示會話不受限，除非<start-time>後，此會話才會被啟動。如果<start-time>設置為0，則表示此會話是一個永久會話。通常情況下，規範不建議在用戶接口或者其他應用控制界面設置這兩個時間取值，這樣會導致會話時間錯亂，會話控制失效。/<start-time>/<start-time>/<stop-time>
Repeat Times ("r=")，其語法規則為：
<code>r=<repeat> <active> <offsets>/<active>/<repeat>/<code>
它定義了對此會話的時間重複次數。"r="行的取值是根據前面的"t="決定的。
Time Zones ("z="), 其語法格式為：
<code>z=<adjustment> <offset> <adjustment> <offset> ..../<offset>/<adjustment>/<offset>/<adjustment>/<code>
會話時差處理。為了對重複的會話（此會話貫穿一個白天晚上到標準時間的修改流程，或者相反處理）進行定時處理，有必要對標準時間設定一個偏移時間數值。這樣就要求針對不同的時間對應不同的時間標準。每個國家可能都有自己的時差日期基準。因此，為了保證對同一會話在不同時期進行定時處理，必須對數據雙方雙方明確設定一個時間基準和偏移值。
Encryption Keys ("k=")，其語法結構如下：
<code>k=<method>k=<method>:<encryption>/<method>/<method>/<code>
如果傳輸消息需要通過一個安全的傳輸方式進行的話，SDP可以用來傳輸密鑰。"k=" 行提供了一個簡單的密鑰交換機制。為什麼說是簡單的交換機制，因為當初設計"k="行的主要目的是考慮和舊部署規範的兼容性支持，也不是規範所推薦的使用方式。"k="本身不具有拓展性，支持不了更多傳輸參數和密鑰管理功能，一些比較新的密鑰交換機制也逐步使用在了SDP會話描述中。因為"k="使用仍然在更新中，一些語法和內容相對比較舊（例如缺少安全協議中要求的兩個密鑰的支持：confidentiality 和integrity），因此，筆者不打算在這裡再展開討論。關於"k="具體的使用方式，用戶可以通過RFC 4567規範和RFC4568做更加詳細的理解，這兩個規範中增加了更多對SDP的拓展支持。這些交換機制和密鑰管理也會使用在一些新的應用場景中。
Attributes ("a=")，其語法格式為：
<code>a=<attribute>a=<attribute>:<value>/<attribute>/<attribute>/<code>
Attributes 表示拓展的SDP的基本含義。特徵屬性參數可以定義在會話級和媒體級。媒體描述中可以定義多個"a="行來定義具體的媒體特性。"a="可以出現在第一個媒體描述前，這是會話級的屬性參數，這樣的屬性是針對整個會議會議定義的，不是針對單獨媒體定義的屬性。特徵Attributes屬性可以支持兩種屬性格式：
<code>"a=<flag>." // 例如："a=recvonly." "a=<attribute>:<value>. // 例如 "a=orient: landscape."/<value>/<attribute>/<flag>/<code>
特徵屬性的取值取決於使用的媒體工具。特徵屬性的值除了0x00 (Null)，0x0A (LF)，和 0x0D (CR)以外，可以是任何octet字符串。默認取值解析為ISO-10646字符形式，通過UTF-8解碼取值。如果接收方不理解已接收的特徵屬性值，接收方必須忽略此特徵屬性值。
Media Descriptions ("m="): 其語法格式為：
<code>m=<media> <port> <proto>... /<proto>/<port>/<media>/<code>
一個會話描述中可以包含多個媒體描述。每個媒體描述以"m="開始，媒體描述結束以下一個媒體描述開始或者以會話描述結束來結尾。一個媒體描述包含幾個媒體描述子項：
<media>，/<media>它表示媒體類型，目前定義的媒體類型包括語音，視頻，應用程序，和消息。未來可能還有其他類型，用戶需要密切關注。
<port>，它是一個傳輸端口，媒體發送到此端口。此端口依賴於"c="行定義的網絡傳輸協議。其他被媒體應用程序使用的端口，例如RTCP端口需要根據其基準端口來設定相應的端口，或者分開特徵屬性設置。如果使用了非連續端口或者沒有遵從偶數-RTP端口，奇數-RTCP端口的規則處理的話，必須增加一個"a=rtcp:"行。應用程序被髮送到一個端口，此端口是一個奇數端口，並且出現"a=rtcp:"行時，此媒體一定不能從RTP端口減一，應用程序必須發送RTP數據到<port>指定的端口，並且發送RTCP到"a=rtcp"屬性設定的端口。對於某些應用程序，它們的媒體流通過層級解碼發送到單播地址時，它們有必要設定多個傳輸端口。使用語法和多播地址的方式類似： m=<media> <port>/<number> <proto>
<code>m=video 49170/2 RTP/AVP 31/<code>
這裡，媒體會話將設定一個視頻媒體類型，端口從49170開始計算，包括兩對RTP媒體會話，其中第一對媒體會話是49170端 口（RTP）和 49171 端口（RTCP）。第二對是從49172（RTP）和49173端 口（RTCP）端口。RTP/AVP是傳輸協議，31是媒體格式（fmt，H261）。以上介紹的是默認環境中使 用的連續端口，如果端口使用的是非連續的端口，需要增加屬 性"a=rtcp:" 分開獨立 的端口屬性。
<proto>，它是/<proto>傳輸協議。這裡的傳輸協議依賴於"c="行定義的地址類型。目前支持的主要的幾個類型包括：UDP，RTP/AVP，RTP/SAVP。這裡專門針對媒體格式設定不同的傳輸協議是因為同一網絡協議時，標準的媒體格式可以通過不同的傳輸協議來進行傳輸。這樣的設定可以支持不同的網絡傳輸和滿足不同檢測工具部署。
<code>Unsupported payload type received/<code>
關於動態payload的規範定義，用戶可以查閱RFC3551-6。
6
SDP屬性說明/IANA/ABNF
除了我們前面介紹的會話描述和媒體描述說明以外，SDP以支持了特徵屬性的拓展，通過拓展的屬性可以支持更多的屬性參數。SDP屬性支持了會話級和媒體級屬性兩種。會話級屬性顧名思義，它是針對會話層級的屬性。媒體級屬性針對媒體屬性設置所設置的屬性。大家經常遇到的也是一些在應用場景中常見的屬性設置，我們這裡也不可能做一個非常完整的歸納。因此，因為篇幅所限，筆者只能介紹一下其基本的語法構成:
<code>a=tool:<name>/<code>
具體在一般場景中看到的例如：
<code>a=ptime:<packet>/<code>
此特徵屬性表示一個數據包中的媒體打包時長的特徵屬性。如果使用RTP映射的話，使用的語法為：
<code>a=rtpmap:<payload> <encoding>/<clock> [/<encodingparameters>]/<encodingparameters>/<clock>/<encoding>/<payload>/<code>
另外，為了規範SDP會話描述中的語法格式，讀者也需要了解幾個相關的規範，這些規範定義了SDP的語法規則。IANA和ABNF是在SDP規範中需要了解的基本語法，其中，ABNF規定了一些基本的規則，包括空格，大小寫，分割行和各種會話描述，媒體描述以及特徵屬性的完整說明。
7
總結
在本章節中，筆者重點介紹了關於SDP規範細節的會話描述部分以及相關的拓展屬性介紹。筆者通過三個子章節的篇幅，基本介紹了SDP的使用方式和要求，增加針對SDP會話描述和媒體描述的規範細節做了充分說明和拓展介紹，並且對SDP的特徵屬性已經IANA和ABFN做了一些簡單介紹。以上內容都相對比較抽象，讀者需要在實際生產環境中不斷練習，不斷解決排查問題，才能對這些內容有進一步的瞭解。
到此為止，筆者已經完整介紹了SDP的基礎和核心語法。這些基礎的內容為我們後續章節的介紹打下了一個比較好的基礎。在接下來的章節中，我們將首先完整介紹SDP的協商模式。
再次說明，因為很多約定用語需要翻譯成中文的含義，本文中的翻譯風格或者理解不同可能有一些出入，希望讀者諒解。
參考鏈接：
https://www.rfc-editor.org/rfc/rfc3556
https://www.rfc-editor.org/rfc/rfc3890
https://www.rfc-editor.org/rfc/rfc4567
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業分享
Asterisk freepbx FreeSBC技術文檔: www.freepbx.org.cn
融合通信/IPPBX商業解決方案：www.hiastar.com
如何使用FreeSBC，qq技術分享群：334023047, www.freesbc.cn
閱讀更多 Asterisk 的文章
