- 功能協(xié)商
- 性能協(xié)商
- 語音和視頻的安全設(shè)置協(xié)商
- 在多媒體會議中的數(shù)據(jù)協(xié)商
為了說明SDP的具體內(nèi)容討論，我們首先需要明確呼叫控制協(xié)議的概念。目前，絕大部分的呼叫控制協(xié)議中，市場上主要使用SIP和WebRTC來實(shí)現(xiàn)呼叫控制。因為篇幅所限和當(dāng)前實(shí)用性的考慮，我們僅介紹SIP協(xié)議和WebRTC協(xié)議。SIP協(xié)議已經(jīng)部署了很多年，已經(jīng)普遍使用在VoIP的絕大部分場景中。WebRTC是最近幾年比較熱門的實(shí)時通信協(xié)議，也逐漸進(jìn)入了應(yīng)用場景中。本章節(jié)，我們將先從呼叫控制協(xié)議介紹開始，介紹SIP協(xié)議基本內(nèi)容和WebRTC協(xié)議的基礎(chǔ)知識。
圖片來自于互聯(lián)網(wǎng)資源
注意：如果一些讀者已經(jīng)具備了基本的SIP協(xié)議和WebRTC協(xié)議的基礎(chǔ)，可以跳過本章節(jié)的基礎(chǔ)介紹。如果讀者想了解更多完整的SIP協(xié)議和WebRTC介紹文檔，可以查閱本公眾號歷史文檔來進(jìn)一步學(xué)習(xí)。這里，僅為了為SDP協(xié)議的介紹做一個簡單的SIP和WebRTC的回顧介紹。
1、呼叫控制協(xié)議
我們知道，一個簡單的電話呼叫涉及了很多其他輔助功能，其目的是保證此呼叫功能正常，并且保證運(yùn)營層面的業(yè)務(wù)監(jiān)控也正常工作。呼叫控制協(xié)議是電話網(wǎng)絡(luò)環(huán)境中一個必不可少的環(huán)節(jié)，其主要功能大致包括呼叫數(shù)據(jù)流量路由控制，增值服務(wù)計費(fèi)支撐，終端之間的連接性，可靠性傳輸機(jī)制，信令控制和媒體通信等功能。在傳統(tǒng)的或者現(xiàn)在的基礎(chǔ)網(wǎng)絡(luò)中，很多控制協(xié)議仍然是核心的協(xié)議，例如，Q.931和H323等具體協(xié)議。此概念將會涉及太多的底層細(xì)節(jié)的協(xié)議和歷史介紹，例如，PRI和SS7等相關(guān)協(xié)議。它們通過電路時隙或者通道實(shí)現(xiàn)信令控制和語音傳輸。因為篇幅和文章主題的關(guān)系，我們不再討論那些配置。有興趣的讀者可以查閱一些常用的文章來補(bǔ)充這方面的知識。通過以上簡單介紹，我們知道，如果實(shí)現(xiàn)一個簡單的，哪怕最簡單的呼叫都需要呼叫控制協(xié)議參與，否則沒有辦法發(fā)起呼叫，也沒有辦法對呼叫拆線執(zhí)行掛機(jī)。在目前大家非常熟悉的VoIP環(huán)境中，SIP是一種非常常見的呼叫控制協(xié)議，基本上是目前主流的呼叫控制協(xié)議。另外，WebRTC也是我們正在逐步使用的呼叫控制協(xié)議。我們在本文章后續(xù)部分就重點(diǎn)回顧這兩種協(xié)議，為將來進(jìn)一步深入討論SDP做一個準(zhǔn)備工作。
2、SIP協(xié)議概要
SIP全稱是Session Initiation Protocol。它是我們重點(diǎn)介紹的一種呼叫信令控制協(xié)議，用來創(chuàng)建，修改和拆線基于網(wǎng)絡(luò)通信的會話，會話由語音視頻和多方視頻數(shù)據(jù)等構(gòu)成，通過RFC3261的規(guī)定的請求實(shí)現(xiàn)。SDP作為消息體的在SIP交互中負(fù)責(zé)雙方媒體協(xié)商，支持能力的協(xié)商。另外，SIP使用RTP/RTCP的傳輸參數(shù)支持語，視頻和數(shù)據(jù)的參數(shù)。因此，SDP和RTP/RTCP是創(chuàng)建SIP媒體會話的最基本的要求。
圖片來自于互聯(lián)網(wǎng)資源
任何協(xié)議都有其規(guī)范的語法結(jié)構(gòu),SIP協(xié)議也是一樣的。它的基本語法結(jié)構(gòu)和HTTP的HTML語法類似。其信令消息包括兩個部分：消息頭和消息體。通過各種語法參數(shù)設(shè)置來支持SIP協(xié)議中的支持能力，協(xié)商和應(yīng)用層級的通信。SIP頭消息主要目的是對從呼叫方到被呼叫方的SIP消息進(jìn)行路由管理，信令消息中包含一個Request-line，它由請求類型，目的地的SIP URL，或下一跳(next hop)，還有SIP版本構(gòu)成等。取決于消息體類型，SIP消息體是一個可選項。SIP消息中的消息頭和消息體通過空白行來加以區(qū)分。消息體構(gòu)建有太多話題可以討論，如果讀者有興趣的話，可以參考RFC 3261-13.2.1章節(jié)。
如果SIP請求中創(chuàng)建的會話中包含了會話描述的具體消息內(nèi)容，會話描述中包含了雙方的媒體類型和編碼等，那么，消息體中將會作為SDP包含這些會話描述的消息內(nèi)容。
因為SDP消息包含了很多參數(shù)設(shè)置，涉及了太多SIP消息的頭和消息體設(shè)置，因此，關(guān)于SIP消息的內(nèi)容，我們這里需要再花費(fèi)一點(diǎn)時間做進(jìn)一步的介紹，以便幫助讀者了解后續(xù)章節(jié)中的SDP內(nèi)容討論。RFC3261規(guī)定了SIP協(xié)議的消息格式，根據(jù)官方的描述說明，雖然其語法和HTTP/1.1類似(客戶-服務(wù)器端協(xié)議架構(gòu))，但是SIP協(xié)議是一種請求-響應(yīng)機(jī)制的處理方式，通過雙方請求消息和對方響應(yīng)消息來實(shí)現(xiàn)信令的協(xié)商。因此，其消息構(gòu)成包括起始行，一個或者多個頭消息，空行(表示頭消息結(jié)束)，最后，還有一個可選消息體構(gòu)成。
generic-message = start-line*message-headerCRLF[ message-body ]start-line = Request-Line / Status-Line
具體關(guān)于SIP消息的語法結(jié)構(gòu)，讀者可以參考RFC3261-7章節(jié)。提醒讀者，根據(jù)RFC3261的規(guī)定，無論是否有可選消息體存在，空行是必須保留的。在SIP消息底部的start-line部分，讀者可以看到，它可以支持Request-Line或者Status-Line。如果是從客戶端對服務(wù)器端發(fā)送請求的話，start-line就是Request-Line，它包含請求method名稱，請求URL，協(xié)議版本和CRLF，它們通過一個單倍行距隔開(SP字符)。沒有其他額外的空格或者其他字符。SIP消息中Request-Line具體用法格式為：
Request-Line = Method SP Request-URI SP SIP-Version CRLF
在以上語法中，SIP支持了以下Methods：
- REGISTER：用戶注冊Method
- INVITE，ACK，和CANCEL：用來呼叫和創(chuàng)建會話
- BYE：結(jié)束會話
- OPTIONS：查詢服務(wù)器端支持能力
- MESSAGE：即時聊天
- REFER：呼叫轉(zhuǎn)移
- SUBSCRIBE和NOTIFY ：SIP會話相關(guān)的事件管理
- PUBLISH：發(fā)布SIP指定事件狀態(tài)
- UPDATE ：更新會話參數(shù)
- INFO：支持mid-session 信息轉(zhuǎn)發(fā)
- PRACK：類似請求確認(rèn)
除了我們提到的請求和以上的Request-Line中的method以外，服務(wù)器端回復(fù)響應(yīng)消息來表示對請求的處理狀態(tài)。響應(yīng)中的Status code是一個重要的標(biāo)識。具體的狀態(tài)碼如下：
在日常的排查活動中，系統(tǒng)技術(shù)人員需要以上狀態(tài)碼來判斷系統(tǒng)所處狀態(tài)。當(dāng)然，在六大狀態(tài)分類中，還有其子分類，子分類中包含了更加詳細(xì)的說明。用戶可參考RFC 3261-13.2.2(處理INVITE響應(yīng))和21章節(jié)來學(xué)習(xí)，這里不再討論。
當(dāng)然，除了請求methods和響應(yīng)狀態(tài)碼以外，因為消息體可能需要通過SIP代理/轉(zhuǎn)發(fā)服務(wù)器和注冊服務(wù)器的處理節(jié)點(diǎn)，因此消息體具有很強(qiáng)的靈活性，它可以被讀取，被修改，被移除或者重新處理，為了滿足多種場景的響應(yīng)，消息體也可能增加一些必要的拓展，包括SIP可選tags標(biāo)簽，修改的SIP標(biāo)簽，同時它也可能增加支持Content type的頭域，以下這些頭域都可能添加到消息體中：Allow, Allow-Events, Content-Disposition, Content-Encoding, Content-Language, Content-Length和Content-Type。以上這些頭域值得介紹在RFC3261-20，此章節(jié)介紹了具體的定義。
另外，在SIP消息中，讀者需要了解基本的消息格式，其中請求消息格式和響應(yīng)消息告訴都有不同的語法結(jié)構(gòu)。兩者的消息內(nèi)容有明顯的區(qū)別：
- 請求消息格式包括三個主要部分：Request-Line，Header和Message-Body。
- 響應(yīng)消息格式包括三個主要部分：Status-Line，Header和 Message-Body。
請求消息格式和響應(yīng)消息格式對比如下：
請求消息格式規(guī)范
關(guān)于消息體更多的規(guī)定，讀者可以參考RFC3261-7章節(jié)。
接下來，我們討論一下關(guān)于SIP在網(wǎng)絡(luò)拓?fù)渲泻推渌嚓P(guān)協(xié)議的關(guān)聯(lián)性。
SIP是一種應(yīng)用層的協(xié)議規(guī)范，和其他的前面所提到的協(xié)議同屬應(yīng)用層的協(xié)議。它的目的是用來實(shí)現(xiàn)網(wǎng)絡(luò)媒體的創(chuàng)建服務(wù)，電話呼叫，電話會議，視頻會議，媒體共享等應(yīng)用。在這些應(yīng)用服務(wù)中，終端需要支持不同的數(shù)據(jù)形式，語音編碼，數(shù)據(jù)文件，視頻編碼等。在這些數(shù)據(jù)交換的過程中，用戶之間的通信可能通過UDP傳輸/TCP傳輸方式來傳輸RTP，也需要RTCP來對媒體流傳輸控制進(jìn)行處理。因此，SIP協(xié)議協(xié)議配合其他的協(xié)議完成整個通信服務(wù)的處理，其相關(guān)協(xié)議如下示例圖所示：
SIP和其他相關(guān)協(xié)議的關(guān)系
通過以上圖例讀者可以看到，事實(shí)上，在一個普通的應(yīng)用環(huán)境中，一個環(huán)境可能涉及了很多終端和服務(wù)器端以及各種應(yīng)用程序的協(xié)商支持，通過確保雙方功能協(xié)商和性能能力的協(xié)商，確保雙方具有一系列共同確認(rèn)的參數(shù)才能進(jìn)行通信(例如，傳輸方式是否相同，端口是否一致，編碼是否支持)。因此，雙方都認(rèn)可的，標(biāo)準(zhǔn)的，共同支持的協(xié)商機(jī)制是必不可少的。SDP就是SIP協(xié)議中進(jìn)行協(xié)商的標(biāo)準(zhǔn)機(jī)制。
通過以上對SIP以及基本語法的介紹，我們大概了解了SIP的消息和一些必要的請求響應(yīng)消息體構(gòu)成。接下來，筆者從宏觀的角度介紹一下SIP網(wǎng)絡(luò)技術(shù)環(huán)境中一些核心的實(shí)體構(gòu)件，包括支持SIP場景的客戶端和服務(wù)器端的功能，以及SIP/SDP整體協(xié)商流程。
如果我們從最基本的SIP網(wǎng)絡(luò)構(gòu)成中討論的話，基本的SIP網(wǎng)絡(luò)構(gòu)成包括以下幾個核心的模塊：各種UA，注冊服務(wù)器，轉(zhuǎn)發(fā)服務(wù)器，定位服務(wù)器和代理服務(wù)器，還有應(yīng)用服務(wù)器等。如果實(shí)現(xiàn)完整的SIP媒體通信的話，SIP需要支持至少五種功能：
- 定位服務(wù)：決定通信使用的最終終端系統(tǒng)。
- 用戶有效性：決定被呼叫方是否有意愿加入到通信環(huán)境中。
- 用戶媒體支持能力：決定雙方通信所需要的媒體和媒體參數(shù)
- 會話創(chuàng)建：創(chuàng)建會話，啟動ring振鈴等。
- 會話管理：轉(zhuǎn)接，修改會話參數(shù)，發(fā)起其他服務(wù)，結(jié)束會話等。
通過以上五種功能的支持，SIP網(wǎng)絡(luò)中的核心構(gòu)件才能成功工作。這些核心模塊負(fù)責(zé)以上五種能力的支持。當(dāng)然，隨著當(dāng)前SIP網(wǎng)絡(luò)的應(yīng)用場景不斷變化和用戶業(yè)務(wù)需求的變化，SIP網(wǎng)絡(luò)中有可能各種服務(wù)器的部署不是固定的，因此此圖例不一定完全表示所有的應(yīng)用場景。關(guān)于SIP服務(wù)器端的討論，用戶可以參考筆者歷史文章做進(jìn)一步的學(xué)習(xí)。
在以上圖例中，我們看到一些核心的模塊包括了SIP UA(User Agent)，UA又可分為UAS和UAC，另外，UA是以客戶端-服務(wù)器端模式的模式工作的用戶，這表示一個UA實(shí)體，為了滿足SIP的邏輯實(shí)體的要求，它既可能是UAC，又可能是UAS，也是我們通常所的背靠背代理方式。如下示例說明了一個應(yīng)用場景中兩個SIP終端通過兩個代理的呼叫流程：
兩個UA通過不同代理進(jìn)行呼叫整體協(xié)商流程
兩個UA首先注冊到各自的服務(wù)器端，然后通過服務(wù)器呼叫另外一個終端。讀者需要注意，這里假設(shè)，Alice在F5 INVITE(標(biāo)識部分)可能已經(jīng)攜帶了本端SDP的媒體支持能力，而且，Bob收到服務(wù)器端通過F8 INVITE發(fā)送到請求，也回復(fù)了可接受的媒體支持能力。雙方都協(xié)商一致，然后開始語音媒體流發(fā)送(F19)。
UA又根據(jù)具體呼叫控制角色不同，可能劃分為不同的UA使用角色，電話會議就是一個例子。RFC4579中定義了電話會議中的在SIP 構(gòu)件中UA定義：
Conference-unaware UA：最簡單的UA，參與電話會議，忽略了所有SIP相關(guān)消息。此UA可通過撥號加入會議或者被邀請加入會議。它僅支持RFC 3261規(guī)范。
Conference-aware UA-此UA可以支持呼叫控制，另外可以支持SIP轉(zhuǎn)發(fā)處理，也可以訂閱消息等。
Focus-控制發(fā)起會議，負(fù)責(zé)會議呼叫控制，包含一個Conference-aware UA。
我們前面已經(jīng)討論，SIP服務(wù)器類型支持了多種處理方式，并且都具有不同的處理流程。有時，這些服務(wù)器的功能定位可能互相交叉，因此一些讀者可能比較迷惑。如果讀者單純從定義上了理解的話，可能有引起很多誤解，讀者可以查閱筆者的歷史文檔來理解這些概念：IPPBX的工作模式SBC/B2BUA的處理方式
深入理解SIP服務(wù)器的注冊和定位服務(wù)流程
3、關(guān)于WebRTC基本介紹
前面，我們簡單概述了SIP協(xié)議作為呼叫控制協(xié)議的基本內(nèi)容，利用消息體中的SDP參數(shù)進(jìn)行呼叫媒體協(xié)商。WebRTC也是一種呼叫控制協(xié)議，只是WebRTC利用的是瀏覽器的方式。這里，筆者不打算花費(fèi)時間再介紹一次WebRTC，筆者以前發(fā)布過一篇關(guān)于WebRTC的概要，讀者通過此文章基本上可以理解WebRTC的基本要點(diǎn)：
完整WebRTC技術(shù)及應(yīng)用概要
4、總結(jié)
一個最基本的呼叫場景都至少需要兩個部分來完成。首先是呼叫控制協(xié)議的創(chuàng)建，然后才能實(shí)現(xiàn)SDP 媒體協(xié)商的流程。因此，在本章節(jié)中，我們介紹了呼叫控制協(xié)議的基本概念，接下來，筆者介紹了呼叫控制協(xié)議中的SIP協(xié)議和WebRTC協(xié)議。在SIP協(xié)議的概要介紹中，我們介紹了SIP消息的基本結(jié)構(gòu)和核心模塊。通過這些基本的介紹，為我們后續(xù)關(guān)于SDP的深入討論打下一個基礎(chǔ)。在后續(xù)章節(jié)中，我們將逐步介紹SDP和其相關(guān)規(guī)范。
再次說明，在本章節(jié)中，筆者針對SIP和WebRTC的介紹僅是為了在后續(xù)章節(jié)中為SDP討論做一個鋪墊作用，可能有一些內(nèi)容不是讀者所希望了解的，望見諒。
參考資料：
https://www.ccexpert.us/network-design/call-control-and-transport-protocols.html
https://ribboncommunications.com/company/get-help/glossary/call-control
https://tools.ietf.org/html/rfc5589
https://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol
https://www.itu.int/rec/T-REC-Q.1912.5-200403-S/en
https://tools.ietf.org/html/rfc3261
關(guān)注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx FreeSBC技術(shù)文檔: www.freepbx.org.cn
融合通信/IPPBX商業(yè)解決方案：www.hiastar.com
如何使用FreeSBC，qq技術(shù)分享群：334023047
