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