　　Session Description Protocol(簡稱是SDP)全稱是會話描述協(xié)議，此協(xié)議用來創(chuàng)建一種協(xié)商機制，這種協(xié)商機制是由呼叫控制協(xié)議創(chuàng)建的介于兩個呼叫用戶之間的會話進行，協(xié)商機制支持的四大協(xié)商方式是：

功能協(xié)商
性能協(xié)商
語音和視頻的安全設置協(xié)商
在多媒體會議中的數(shù)據(jù)協(xié)商

　　為了說明SDP的具體內容討論，我們首先需要明確呼叫控制協(xié)議的概念。目前，絕大部分的呼叫控制協(xié)議中，市場上主要使用SIP和WebRTC來實現(xiàn)呼叫控制。因為篇幅所限和當前實用性的考慮，我們僅介紹SIP協(xié)議和WebRTC協(xié)議。SIP協(xié)議已經(jīng)部署了很多年，已經(jīng)普遍使用在VoIP的絕大部分場景中。WebRTC是最近幾年比較熱門的實時通信協(xié)議，也逐漸進入了應用場景中。本章節(jié)，我們將先從呼叫控制協(xié)議介紹開始，介紹SIP協(xié)議基本內容和WebRTC協(xié)議的基礎知識。

　　圖片來自于互聯(lián)網(wǎng)資源

　　注意：如果一些讀者已經(jīng)具備了基本的SIP協(xié)議和WebRTC協(xié)議的基礎，可以跳過本章節(jié)的基礎介紹。如果讀者想了解更多完整的SIP協(xié)議和WebRTC介紹文檔，可以查閱本公眾號歷史文檔來進一步學習。這里，僅為了為SDP協(xié)議的介紹做一個簡單的SIP和WebRTC的回顧介紹。

　　1、呼叫控制協(xié)議

　　我們知道，一個簡單的電話呼叫涉及了很多其他輔助功能，其目的是保證此呼叫功能正常，并且保證運營層面的業(yè)務監(jiān)控也正常工作。呼叫控制協(xié)議是電話網(wǎng)絡環(huán)境中一個必不可少的環(huán)節(jié)，其主要功能大致包括呼叫數(shù)據(jù)流量路由控制，增值服務計費支撐，終端之間的連接性，可靠性傳輸機制，信令控制和媒體通信等功能。在傳統(tǒng)的或者現(xiàn)在的基礎網(wǎng)絡中，很多控制協(xié)議仍然是核心的協(xié)議，例如，Q.931和H323等具體協(xié)議。此概念將會涉及太多的底層細節(jié)的協(xié)議和歷史介紹，例如，PRI和SS7等相關協(xié)議。它們通過電路時隙或者通道實現(xiàn)信令控制和語音傳輸。因為篇幅和文章主題的關系，我們不再討論那些配置。有興趣的讀者可以查閱一些常用的文章來補充這方面的知識。通過以上簡單介紹，我們知道，如果實現(xiàn)一個簡單的，哪怕最簡單的呼叫都需要呼叫控制協(xié)議參與，否則沒有辦法發(fā)起呼叫，也沒有辦法對呼叫拆線執(zhí)行掛機。在目前大家非常熟悉的VoIP環(huán)境中，SIP是一種非常常見的呼叫控制協(xié)議，基本上是目前主流的呼叫控制協(xié)議。另外，WebRTC也是我們正在逐步使用的呼叫控制協(xié)議。我們在本文章后續(xù)部分就重點回顧這兩種協(xié)議，為將來進一步深入討論SDP做一個準備工作。

　　2、SIP協(xié)議概要

　　SIP全稱是Session Initiation Protocol。它是我們重點介紹的一種呼叫信令控制協(xié)議，用來創(chuàng)建，修改和拆線基于網(wǎng)絡通信的會話，會話由語音視頻和多方視頻數(shù)據(jù)等構成，通過RFC3261的規(guī)定的請求實現(xiàn)。SDP作為消息體的在SIP交互中負責雙方媒體協(xié)商，支持能力的協(xié)商。另外，SIP使用RTP/RTCP的傳輸參數(shù)支持語，視頻和數(shù)據(jù)的參數(shù)。因此，SDP和RTP/RTCP是創(chuàng)建SIP媒體會話的最基本的要求。

　　圖片來自于互聯(lián)網(wǎng)資源

　　任何協(xié)議都有其規(guī)范的語法結構,SIP協(xié)議也是一樣的。它的基本語法結構和HTTP的HTML語法類似。其信令消息包括兩個部分：消息頭和消息體。通過各種語法參數(shù)設置來支持SIP協(xié)議中的支持能力，協(xié)商和應用層級的通信。SIP頭消息主要目的是對從呼叫方到被呼叫方的SIP消息進行路由管理，信令消息中包含一個Request-line，它由請求類型，目的地的SIP URL，或下一跳(next hop)，還有SIP版本構成等。取決于消息體類型，SIP消息體是一個可選項。SIP消息中的消息頭和消息體通過空白行來加以區(qū)分。消息體構建有太多話題可以討論，如果讀者有興趣的話，可以參考RFC 3261-13.2.1章節(jié)。

　　如果SIP請求中創(chuàng)建的會話中包含了會話描述的具體消息內容，會話描述中包含了雙方的媒體類型和編碼等，那么，消息體中將會作為SDP包含這些會話描述的消息內容。

　　因為SDP消息包含了很多參數(shù)設置，涉及了太多SIP消息的頭和消息體設置，因此，關于SIP消息的內容，我們這里需要再花費一點時間做進一步的介紹，以便幫助讀者了解后續(xù)章節(jié)中的SDP內容討論。RFC3261規(guī)定了SIP協(xié)議的消息格式，根據(jù)官方的描述說明，雖然其語法和HTTP/1.1類似(客戶-服務器端協(xié)議架構)，但是SIP協(xié)議是一種請求-響應機制的處理方式，通過雙方請求消息和對方響應消息來實現(xiàn)信令的協(xié)商。因此，其消息構成包括起始行，一個或者多個頭消息，空行(表示頭消息結束)，最后，還有一個可選消息體構成。

　　generic-message = start-line*message-headerCRLF[ message-body ]start-line = Request-Line / Status-Line

　　具體關于SIP消息的語法結構，讀者可以參考RFC3261-7章節(jié)。提醒讀者，根據(jù)RFC3261的規(guī)定，無論是否有可選消息體存在，空行是必須保留的。在SIP消息底部的start-line部分，讀者可以看到，它可以支持Request-Line或者Status-Line。如果是從客戶端對服務器端發(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：結束會話
OPTIONS：查詢服務器端支持能力
MESSAGE：即時聊天
REFER：呼叫轉移
SUBSCRIBE和NOTIFY ：SIP會話相關的事件管理
PUBLISH：發(fā)布SIP指定事件狀態(tài)
UPDATE ：更新會話參數(shù)
INFO：支持mid-session 信息轉發(fā)
PRACK：類似請求確認

　　除了我們提到的請求和以上的Request-Line中的method以外，服務器端回復響應消息來表示對請求的處理狀態(tài)。響應中的Status code是一個重要的標識。具體的狀態(tài)碼如下：

　　在日常的排查活動中，系統(tǒng)技術人員需要以上狀態(tài)碼來判斷系統(tǒng)所處狀態(tài)。當然，在六大狀態(tài)分類中，還有其子分類，子分類中包含了更加詳細的說明。用戶可參考RFC 3261-13.2.2(處理INVITE響應)和21章節(jié)來學習，這里不再討論。

　　當然，除了請求methods和響應狀態(tài)碼以外，因為消息體可能需要通過SIP代理/轉發(fā)服務器和注冊服務器的處理節(jié)點，因此消息體具有很強的靈活性，它可以被讀取，被修改，被移除或者重新處理，為了滿足多種場景的響應，消息體也可能增加一些必要的拓展，包括SIP可選tags標簽，修改的SIP標簽，同時它也可能增加支持Content type的頭域，以下這些頭域都可能添加到消息體中：Allow, Allow-Events, Content-Disposition, Content-Encoding, Content-Language, Content-Length和Content-Type。以上這些頭域值得介紹在RFC3261-20，此章節(jié)介紹了具體的定義。

　　另外，在SIP消息中，讀者需要了解基本的消息格式，其中請求消息格式和響應消息告訴都有不同的語法結構。兩者的消息內容有明顯的區(qū)別：

請求消息格式包括三個主要部分：Request-Line，Header和Message-Body。
響應消息格式包括三個主要部分：Status-Line，Header和 Message-Body。

　　請求消息格式和響應消息格式對比如下：

　請求消息格式規(guī)范

　　響應消息格式規(guī)范

　　關于消息體更多的規(guī)定，讀者可以參考RFC3261-7章節(jié)。

　　接下來，我們討論一下關于SIP在網(wǎng)絡拓撲中和其他相關協(xié)議的關聯(lián)性。

　　SIP是一種應用層的協(xié)議規(guī)范，和其他的前面所提到的協(xié)議同屬應用層的協(xié)議。它的目的是用來實現(xiàn)網(wǎng)絡媒體的創(chuàng)建服務，電話呼叫，電話會議，視頻會議，媒體共享等應用。在這些應用服務中，終端需要支持不同的數(shù)據(jù)形式，語音編碼，數(shù)據(jù)文件，視頻編碼等。在這些數(shù)據(jù)交換的過程中，用戶之間的通信可能通過UDP傳輸/TCP傳輸方式來傳輸RTP，也需要RTCP來對媒體流傳輸控制進行處理。因此，SIP協(xié)議協(xié)議配合其他的協(xié)議完成整個通信服務的處理，其相關協(xié)議如下示例圖所示：

　　SIP和其他相關協(xié)議的關系

　　通過以上圖例讀者可以看到，事實上，在一個普通的應用環(huán)境中，一個環(huán)境可能涉及了很多終端和服務器端以及各種應用程序的協(xié)商支持，通過確保雙方功能協(xié)商和性能能力的協(xié)商，確保雙方具有一系列共同確認的參數(shù)才能進行通信(例如，傳輸方式是否相同，端口是否一致，編碼是否支持)。因此，雙方都認可的，標準的，共同支持的協(xié)商機制是必不可少的。SDP就是SIP協(xié)議中進行協(xié)商的標準機制。

　　通過以上對SIP以及基本語法的介紹，我們大概了解了SIP的消息和一些必要的請求響應消息體構成。接下來，筆者從宏觀的角度介紹一下SIP網(wǎng)絡技術環(huán)境中一些核心的實體構件，包括支持SIP場景的客戶端和服務器端的功能，以及SIP/SDP整體協(xié)商流程。

　　如果我們從最基本的SIP網(wǎng)絡構成中討論的話，基本的SIP網(wǎng)絡構成包括以下幾個核心的模塊：各種UA，注冊服務器，轉發(fā)服務器，定位服務器和代理服務器，還有應用服務器等。如果實現(xiàn)完整的SIP媒體通信的話，SIP需要支持至少五種功能：

定位服務：決定通信使用的最終終端系統(tǒng)。
用戶有效性：決定被呼叫方是否有意愿加入到通信環(huán)境中。
用戶媒體支持能力：決定雙方通信所需要的媒體和媒體參數(shù)
會話創(chuàng)建：創(chuàng)建會話，啟動ring振鈴等。
會話管理：轉接，修改會話參數(shù)，發(fā)起其他服務，結束會話等。

　　通過以上五種功能的支持，SIP網(wǎng)絡中的核心構件才能成功工作。這些核心模塊負責以上五種能力的支持。當然，隨著當前SIP網(wǎng)絡的應用場景不斷變化和用戶業(yè)務需求的變化，SIP網(wǎng)絡中有可能各種服務器的部署不是固定的，因此此圖例不一定完全表示所有的應用場景。關于SIP服務器端的討論，用戶可以參考筆者歷史文章做進一步的學習。

　　在以上圖例中，我們看到一些核心的模塊包括了SIP UA(User Agent)，UA又可分為UAS和UAC，另外，UA是以客戶端-服務器端模式的模式工作的用戶，這表示一個UA實體，為了滿足SIP的邏輯實體的要求，它既可能是UAC，又可能是UAS，也是我們通常所的背靠背代理方式。如下示例說明了一個應用場景中兩個SIP終端通過兩個代理的呼叫流程：

　　兩個UA通過不同代理進行呼叫整體協(xié)商流程

　　兩個UA首先注冊到各自的服務器端，然后通過服務器呼叫另外一個終端。讀者需要注意，這里假設，Alice在F5 INVITE(標識部分)可能已經(jīng)攜帶了本端SDP的媒體支持能力，而且，Bob收到服務器端通過F8 INVITE發(fā)送到請求，也回復了可接受的媒體支持能力。雙方都協(xié)商一致，然后開始語音媒體流發(fā)送(F19)。

　　UA又根據(jù)具體呼叫控制角色不同，可能劃分為不同的UA使用角色，電話會議就是一個例子。RFC4579中定義了電話會議中的在SIP 構件中UA定義：

　　Conference-unaware UA：最簡單的UA，參與電話會議，忽略了所有SIP相關消息。此UA可通過撥號加入會議或者被邀請加入會議。它僅支持RFC 3261規(guī)范。

　　Conference-aware UA-此UA可以支持呼叫控制，另外可以支持SIP轉發(fā)處理，也可以訂閱消息等。

　　Focus-控制發(fā)起會議，負責會議呼叫控制，包含一個Conference-aware UA。

　　我們前面已經(jīng)討論，SIP服務器類型支持了多種處理方式，并且都具有不同的處理流程。有時，這些服務器的功能定位可能互相交叉，因此一些讀者可能比較迷惑。如果讀者單純從定義上了理解的話，可能有引起很多誤解，讀者可以查閱筆者的歷史文檔來理解這些概念：IPPBX的工作模式SBC/B2BUA的處理方式

　　深入理解SIP服務器的注冊和定位服務流程

　　3、關于WebRTC基本介紹

　　前面，我們簡單概述了SIP協(xié)議作為呼叫控制協(xié)議的基本內容，利用消息體中的SDP參數(shù)進行呼叫媒體協(xié)商。WebRTC也是一種呼叫控制協(xié)議，只是WebRTC利用的是瀏覽器的方式。這里，筆者不打算花費時間再介紹一次WebRTC，筆者以前發(fā)布過一篇關于WebRTC的概要，讀者通過此文章基本上可以理解WebRTC的基本要點：

　　完整WebRTC技術及應用概要

　　4、總結

　　一個最基本的呼叫場景都至少需要兩個部分來完成。首先是呼叫控制協(xié)議的創(chuàng)建，然后才能實現(xiàn)SDP 媒體協(xié)商的流程。因此，在本章節(jié)中，我們介紹了呼叫控制協(xié)議的基本概念，接下來，筆者介紹了呼叫控制協(xié)議中的SIP協(xié)議和WebRTC協(xié)議。在SIP協(xié)議的概要介紹中，我們介紹了SIP消息的基本結構和核心模塊。通過這些基本的介紹，為我們后續(xù)關于SDP的深入討論打下一個基礎。在后續(xù)章節(jié)中，我們將逐步介紹SDP和其相關規(guī)范。

　　再次說明，在本章節(jié)中，筆者針對SIP和WebRTC的介紹僅是為了在后續(xù)章節(jié)中為SDP討論做一個鋪墊作用，可能有一些內容不是讀者所希望了解的，望見諒。

　　參考資料：

　　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