前言
項目中我們有個通過瀏覽器進行人工外呼的需求，這邊就涉及了一些voip相關的技術棧。使用freeswitch作為軟交換平台，sip（會話初始協議）來作為信令的載體，結合webrtc等相關技術實現瀏覽器端撥打電話的需求。sip.js是使用javascript對sip協議進行了封裝，它恰恰也是結合了webrtc來幫助我們快速構建瀏覽器端音視頻的實時傳輸。
關於sip協議
sip如同我們熟悉的http協議一樣，是一個基於文本的應用層信令控制協議，它也是采用了請求/響應的方式進行通信。常見的請求消息包括:
- INVITE：表示主叫用戶發起會話請求
- ACK：客戶端向服務器端證實它已經收到了對INVITE請求的最終響應
- BYE：表示終止一個已經建立的呼叫（呼叫結束）
- CANCEL：表示在收到對請求的最終響應之前取消該請求，對於已完成的請求則無影響。
除此之外，還有其他的一些請求類型，但是並不常用，常見的基本上就是這4種。當收到請求后，服務端需要作出響應，例如客戶端發起INVITE請求后，服務端開始建立會話，此時會依次發送以下響應消息，表示當前會話狀態：
- 100試呼叫（Trying）
- 180/183表示正在外呼，此時可以有振鈴或者早起媒體。180和183的區別，可參考這篇文章
- 200成功響應
這時候客戶端需要返回一個ACK表示已成功建立會話。這里的3種響應消息，只代表着一通電話正常建立的情況，還有一些標識錯誤的消息，例如401未授權、486線路忙等等，可以看到其和http非常像，有標識碼和描述信息。不過要注意，sip只是用於創建、修改和釋放一個或多個參與者的會話，具體的選擇何種會話類型、語音編解碼信息、負載信息等需要通過sdp（會話描述協議）來控制。上面提到的183或是200響應狀態，均會攜帶sdp信息，用於建立媒體通道，關於sdp報文格式，可以參考這篇文章。
深入sip.js
sip.js使用javascript對sip協議進行了封裝，我們上面提到過sip只是用來控制會話的建立和修改，它並不提供會話描述、會議控制等功能，這些是通過sdp來進行描述的。並且它也不能提供媒體通道的建立，在瀏覽器端建立媒體通道，我們最容易想到的就是webrtc，sip正是通過webrtc來進行媒體通道的建立。有關webrtc的相關學習，我們可以參考這個。學習過webrtc之后我們知道，webrtc的客戶端之間是通過建立RTCPeerConnection（簡稱pc）來實現音視頻數據流的傳輸。在建立pc之前，也需要去交換一些媒體信息，我們稱之為signaling過程。signaling用來交換三種信息：
- 連接控制信息：初始化或者關閉連接報告錯誤。
- 網絡配置：對於外網，我們電腦的 IP 地址和端口。
- 多媒體數據：使用什么編碼解碼器，瀏覽器可以處理什么信息。
而webrtc已經提供api讓我們快速生成這些媒體數據，即pc的createOffer方法和createAnswer方法，而他們生成的數據恰恰就是上面提到的sdp格式的文本。因此我們可以得出結論，webrtc也是通過sdp來進行媒體數據的交換，從而建立媒體通道的。至於為什么會分createOffer方法和createAnswer方法，是因為signaling采取了一種offer/answer的方式，類似於請求/問答，發起方發送offer，應答方發送answer，雙方交換媒體信息之后才會完成signaling，從而建立pc。媒體數據的交換可以采取多種傳輸方式，sip.js中默認使用的是websocket進行傳輸。舉個例子可以讓大家更加清晰得明白使用sip.js之后一通會話的建立過程：
- 客戶端發起invite請求，invite中攜帶了客戶端的媒體數據，通過createoffer方法封裝成sdp報文，一並傳輸給服務端
- 服務端收到請求（我們是用freeswitch），解析sdp，發起呼叫，同時向客戶端發送呼叫狀態的響應，如100、183、200，在183和200的時候均會攜帶服務端sdp，區別在於200是真正建立的通話，183可能會攜帶早期媒體等信息。
- 客戶端默認情況會解析200狀態所攜帶的sdp信息，至此完成signaling過程，媒體通道建立，開始對話。
總結
通過以上的介紹，我們可以看出sip和webrtc的關系，它們其實負責實現不同的功能，但又可以非常好的結合在一起構建更強大的應用。sip主要負責會話的創建和管理，而webrtc用於建立媒體通道，從而實現瀏覽器端音視頻流的傳輸，而sip.js正是將兩者結合，從而幫助大家快速開發出大型web端的會話應用。本文只對sip.js的原理進行部分解讀，並沒有介紹如何使用這些技術，具體還需要參考文檔或是可以閱讀源碼獲得更多的信息。