此圖例以及以下圖例均來(lái)自于互聯(lián)網(wǎng)資源關(guān)于其它信令支持方式和WebRTC核心概念，ICE/SDP, Offer/answer模式和主要應(yīng)用場(chǎng)景等，筆者在下面的鏈接中已經(jīng)進(jìn)行了比較詳細(xì)地分享說(shuō)明。今天，我們重點(diǎn)對(duì)WebSocket 協(xié)議進(jìn)行討論。
完整SIP/SDP媒體協(xié)商概論-WebRTC/ICE概覽
完整WebRTC架構(gòu)ICE連接等技術(shù)詳解及應(yīng)用場(chǎng)景分析
很多用戶(hù)可能對(duì)WebRTC和WebSocket的概念比較模糊。除了web相同以外，從簡(jiǎn)單命名我們就可以看出其基本差異，一個(gè)是RTC-實(shí)現(xiàn)實(shí)時(shí)通信，一個(gè)是socket-實(shí)現(xiàn)連接。實(shí)際上，它們兩者之間存在很大不同，包括應(yīng)用場(chǎng)景，傳輸方式， 技術(shù)實(shí)現(xiàn)目標(biāo)都有著某些差別。網(wǎng)絡(luò)有很多這方面的資料，讀者可以進(jìn)一步學(xué)習(xí)其差別。我們這里主要討論的是基于WebRTC用戶(hù)場(chǎng)景中，使用WebSocket協(xié)議實(shí)現(xiàn)的SIP子信令的支持，特別重點(diǎn)強(qiáng)調(diào)的是RFC7188-The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)，包括其IP語(yǔ)音方案背景說(shuō)明和RFC7188規(guī)范詳解。
1-背景說(shuō)明
隨著WebRTC的部署應(yīng)用越來(lái)越多，無(wú)論是基于瀏覽器的終端方面還是IP語(yǔ)音通信的服務(wù)器端方面發(fā)布了很多的規(guī)范來(lái)支持WebRTC技術(shù)，并且重點(diǎn)強(qiáng)調(diào)了通過(guò)WebSocket實(shí)現(xiàn)對(duì)SIP協(xié)議的支持，例如，ETSI TS 124 371中規(guī)定的WIC (WebRTC IMS Client) 。很多業(yè)務(wù)場(chǎng)景中，比如WebRTC-SIP或者WebSocket gateway網(wǎng)關(guān)，SBC，服務(wù)器端（例如Asterisk，F(xiàn)reeSWITCH，Kamailio/OpenSIPS和其它商業(yè)解決方案）客戶(hù)端（例如，JsSIP）等已經(jīng)開(kāi)始支持了WebSocket SIP子協(xié)議。
另外，很多的基于WebSocket的瀏覽器終端除了支持SIP協(xié)議以外，也支持了WebSocket，實(shí)現(xiàn)了RFC7188中規(guī)定的SIP WebRTC客戶(hù)端（例如jsSIP）的功能定義。
SIP WebSocket Client: A SIP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket SIP subprotocol as defined by this document. SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket SIP subprotocol as defined by this document.
比較常見(jiàn)的應(yīng)用場(chǎng)景是SBC，呼叫中心或者IPPBX和WebRTC客戶(hù)端的對(duì)接。WebRTC客戶(hù)端（JsSIP）通過(guò)SIP通過(guò)WebSocket連接實(shí)現(xiàn)和SBC或者WebRTC網(wǎng)關(guān)設(shè)備進(jìn)行通信，然后SBC通過(guò)SIP通過(guò)UDP，TCP或者TLS連接方式和對(duì)端SIP終端進(jìn)行通信。
具體應(yīng)用示例如下-WebRTC 客戶(hù)端通過(guò)WebSocket實(shí)現(xiàn)SBC對(duì)接支持：
2-關(guān)于RFC7118 規(guī)范完整詳解
2.1-關(guān)于RFC7118 介紹
WebSocket已經(jīng)有具體的規(guī)范定義，RFC6455對(duì)其進(jìn)行了詳解說(shuō)明。根據(jù)RFC6455的規(guī)范說(shuō)明，WebSocket是基于TCP連接創(chuàng)建的連接協(xié)議，初始協(xié)議握手使用的是HTTP（RFC2616）協(xié)議，通過(guò)主要的方式可以實(shí)現(xiàn)WebSocket重用現(xiàn)存的HTTP架構(gòu)。
隨著互聯(lián)網(wǎng)發(fā)展，很多瀏覽器兼容了更多的功能，同時(shí)也支持了更多的協(xié)議棧，W3C也要求支持了WebSocket棧，通過(guò)WebSocket API接口實(shí)現(xiàn)支持。通過(guò)這樣的規(guī)范，個(gè)人PC端，智能手機(jī)也希望能夠支持這些WebSocket API客戶(hù)端應(yīng)用。RFC7118是針對(duì)以上需求發(fā)布的規(guī)范。我們今天重點(diǎn)介紹的RFC7118就是一個(gè)這樣的協(xié)議，RFC7118發(fā)布使得瀏覽器支持SIP網(wǎng)絡(luò)成為可能。
實(shí)際上，RFC7118是RFC6455的一個(gè)子規(guī)范，它定義了WebSocket 客戶(hù)端和服務(wù)器端傳輸SIP消息的機(jī)制，它是一個(gè)可靠性的，支持SIP消息體邊界預(yù)留，針對(duì)SIP的傳輸協(xié)議，支持了DNA NAPTR服務(wù)值。另外，RFC7118定義了兩個(gè)SIP實(shí)體(包括了SIP WebSocket 客戶(hù)端和SIP WebSocket 服務(wù)器端)在部署WebSocket時(shí)的流程�；赟IP的WebSocket 客戶(hù)端可以開(kāi)啟一個(gè)對(duì)服務(wù)器端的連接，基于SIP的WebSocket 服務(wù)器端可以監(jiān)聽(tīng)一個(gè)連接。注意，媒體傳輸不在RFC7118討論范圍之內(nèi)。
2.2-WebSocket Protocol
在介紹其它細(xì)節(jié)之前，我們首先介紹一下關(guān)于WebSocket協(xié)議（RFC6455）和其加密TLS支持協(xié)議。此協(xié)議定義了連接握手機(jī)制，WebSocket子協(xié)議，擴(kuò)展協(xié)商，用來(lái)發(fā)送應(yīng)用和控制數(shù)據(jù)的幀格式，掩碼機(jī)制和關(guān)閉連接狀態(tài)碼等內(nèi)容。
協(xié)議通信的連接首先需要處理連接握手。WebSocket協(xié)議握手連接是基于HTTP握手機(jī)制，使用Get method配合Upgrade請(qǐng)求來(lái)實(shí)現(xiàn)�？蛻�(hù)端發(fā)送請(qǐng)求，服務(wù)器端接收請(qǐng)求，協(xié)商成功后，通過(guò)HTTP 101狀態(tài)碼進(jìn)行回復(fù)響應(yīng)。一旦握手完成后，這個(gè)連接就會(huì)從HTTP更新為WebSocket協(xié)議。握手協(xié)議設(shè)計(jì)目的是為了重用HTTP架構(gòu)。在連接握手期間，客戶(hù)端和服務(wù)器端都同意在應(yīng)用層協(xié)議使用WebSocket協(xié)議來(lái)進(jìn)行傳輸，并且在雙方終端之間定義了消息交互的格式和語(yǔ)義。這樣的處理機(jī)制可以支持一個(gè)自定義的協(xié)議或者一個(gè)標(biāo)準(zhǔn)的協(xié)議，具備了一定的靈活性和可擴(kuò)展性。以下圖例是客戶(hù)端和服務(wù)器端更新切換協(xié)議的處理機(jī)制說(shuō)明。
這里要注意，一旦HTTP 101 響應(yīng)處理后，客戶(hù)端和服務(wù)器端將會(huì)重用潛在的TCP來(lái)發(fā)送WebSocket消息，控制雙方的幀格式。和HTTP不同的是，這里的HTTP連接是一個(gè)持久的連接，可以用來(lái)支持多個(gè)消息的交互。關(guān)于其握手處理方式，讀者可進(jìn)一步閱讀RFC6455-4章節(jié)的Opening Handshake 了解更多詳情，這里不再進(jìn)行進(jìn)一步討論。
除了握手以后進(jìn)行的數(shù)據(jù)交互機(jī)制以外，RFC6455中的WebSocket也定義了為了進(jìn)行數(shù)據(jù)交互，在應(yīng)用程序中使用的消息單元，因此它提供了一個(gè)所謂的message-boundary-preserving transport layer，我們稱(chēng)之為消息邊界預(yù)留傳輸協(xié)議層。這些消息單元可以包含UTF-8文本數(shù)據(jù)或二進(jìn)制數(shù)據(jù)和ping/pong幀數(shù)據(jù)，并且這些UTF-8文本數(shù)據(jù)或二進(jìn)制數(shù)據(jù)可以進(jìn)一步分解為多個(gè)WebSocket的UTF-8文本數(shù)據(jù)或二進(jìn)制數(shù)據(jù)傳輸幀數(shù)據(jù)支持WebSocket處理需要。
2.3-The WebSocket SIP Subprotocol
通常情況下，我們這里討論的WebSocket Subprotocol是基于WebSocket連接的應(yīng)用層的協(xié)議。在RFC7188中我們特別針對(duì)的是WebSocket SIP 子協(xié)議，此協(xié)議通過(guò)WebSocket連接傳輸SIP請(qǐng)求和響應(yīng)。在此子協(xié)議中，我們?nèi)匀恍枰獜倪B接握手為切入點(diǎn)來(lái)進(jìn)行討論。在SIP WebSocket 客戶(hù)端和服務(wù)器端協(xié)商中，雙方WebSocket握手協(xié)商流程是在RFC6455-1.3章節(jié)進(jìn)行定義的。在此規(guī)范中，我們使用的是SIP協(xié)議。因此，客戶(hù)端在握手請(qǐng)求的頭字段Sec-WebSocket-Protocol中必須包括“SIP”值，而且在服務(wù)器端的101回復(fù)響應(yīng)中，其相應(yīng)的Sec-WebSocket-Protocol要必須包含一個(gè)“SIP”值。在以下WebSocket 握手連接中，客戶(hù)端發(fā)送了一個(gè)WebSocket SIP subprotocol，同樣服務(wù)器端回復(fù)的響應(yīng)中支持了這個(gè)請(qǐng)求：
GET / HTTP/1.1 Host: sip-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol: sip // 包含的SIP 頭字段 Sec-WebSocket-Version: 13
從服務(wù)器端返回的握手響應(yīng)中支持了WebSocket SIP subprotocol，表示服務(wù)器端接受了此WebSocket的握手：
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip // 包含了SIP 頭字段值
一旦雙方在成功完成了此協(xié)商，WebSocket就創(chuàng)建好了。創(chuàng)建好了以WebSocket的連接以后，這個(gè)連接就可以用來(lái)發(fā)送SIP 請(qǐng)求和響應(yīng)。這里一定要注意，此連接僅傳輸SIP請(qǐng)求和響應(yīng)消息，此連接不支持非SIP請(qǐng)求響應(yīng)消息的傳輸。關(guān)于SIP消息編碼。傳輸完成后，當(dāng)然接下來(lái)還要涉及對(duì)SIP消息的解碼。前面我們已說(shuō)明，WebSocket消息可以通過(guò)UTF-8文本幀格式或者二進(jìn)制幀格式進(jìn)行傳輸。比較巧合的是，SIP協(xié)議中的請(qǐng)求和響應(yīng)中也支持文本和二進(jìn)制的消息體傳輸。因此，SIP WebSocket客戶(hù)端和SIP WebSocket服務(wù)器端雙方必須接受文本幀格式和二進(jìn)制幀格式數(shù)據(jù)。這里需要注意，如果在SIP消息中至少出現(xiàn)了一個(gè)非UTF-8格式標(biāo)識(shí)字符（包括SIP頭字段和消息體），那么整個(gè)消息一定要以一個(gè)WebSocket二進(jìn)制消息再次發(fā)送。這里，因?yàn)镴avaScript and the WebSocket API的屬性，RFC7188規(guī)范推薦使用UTF-8編碼對(duì)通過(guò)WebSocket連接傳輸?shù)腟IP消息進(jìn)行處理。
2.4-SIP WebSocket Transport
根據(jù)RFC6455規(guī)范定義，我們知道WebSocket是一種可靠性協(xié)議。因?yàn)槠淅^承關(guān)系，我們這里的SIP WebSocket 子協(xié)議也是一種可靠性協(xié)議，也是一種SIP可靠性傳輸協(xié)議。簡(jiǎn)言之，無(wú)論是SIP客戶(hù)端和服務(wù)器端之間的事務(wù)，使用了WebSocket連接來(lái)傳輸?shù)脑挘鼈冎g的可靠性傳輸必須按照RFC3261定義的流程和定時(shí)器來(lái)執(zhí)行。
這里特別說(shuō)明的是，每個(gè)SIP消息一定要通過(guò)單個(gè)WebSocket消息中傳輸，并且，一個(gè)WebSocket消息一定不能包含超過(guò)一個(gè)以上的SIP消息。因?yàn)閃ebSocket傳輸預(yù)留了消息體的邊界設(shè)置，因此，當(dāng)使用WebSocket傳輸SIP消息時(shí)，SIP消息中的Content-Length 頭字段不是一個(gè)必要的字段。通過(guò)這樣的方式可以簡(jiǎn)化在SIP客戶(hù)端和服務(wù)器端的SIP消息解析流程。解析SIP消息時(shí)，無(wú)論是客戶(hù)端還是服務(wù)器端無(wú)需通過(guò)Content-Length來(lái)創(chuàng)建消息邊界范圍。在解析SIP消息體時(shí)，有幾個(gè)比較重要的SIP頭字段需要說(shuō)明。
首先說(shuō)明的是Via傳輸參數(shù)。我們知道，Via頭字段在SIP消息中發(fā)送傳輸協(xié)議的身份標(biāo)識(shí)。在RFC7188中，這里定義使用的是“WS”值通過(guò)普通WbeSocket發(fā)送請(qǐng)求，通過(guò)加密的WebSocket連接“WSS”（secure WebSocket）發(fā)送加密的請(qǐng)求，按照RFC5246 TLS傳輸規(guī)范處理。具體消息語(yǔ)法格式如下：
transport =/ "WS" / "WSS"
另外一個(gè)比較重要的SIP頭字段是SIP URI 傳輸參數(shù)。此規(guī)范定義了針對(duì)SIP URL使用的傳輸參數(shù)是“WS” 。具體的語(yǔ)法格式如下：
transport-param =/ "transport=" "ws"
還有一個(gè)比較重要的SIP頭字段是 Via中的“received”。關(guān)于Via "received" 參數(shù)的處理需要加以特別的注意。在SIP協(xié)議第18章節(jié)中關(guān)于接收請(qǐng)求中，接收請(qǐng)求可以是域名或者IP地址。"received"參數(shù)中必須包含一個(gè)數(shù)據(jù)包接收的源地址。
當(dāng)服務(wù)器傳輸通過(guò)任何傳輸收到一個(gè)請(qǐng)求時(shí)，它必須檢查在頂部的 Via 頭值中的“sent-by”參數(shù)。如果“sent-by”參數(shù)中的 host 主機(jī)部分包含一個(gè) domain 名稱(chēng) 或者如果它包含一個(gè) IP 地址，這個(gè)地址不同于數(shù)據(jù)包源地址，此服務(wù)器必須在 Via 頭字段中添加一個(gè)“received”參數(shù)。這個(gè)參數(shù)必須包含一個(gè)從數(shù)據(jù)包收到的源地址。這樣做的目的是幫助服務(wù)器端傳輸發(fā)送響應(yīng)，因此，它必須源 IP 地址，這個(gè)地址是從請(qǐng)求方來(lái)的地址。
www.sip.org.cn
不幸的是，增加對(duì)"received"參數(shù)支持不能很好地兼容到WebSocket協(xié)議的設(shè)計(jì)框架中。前面我們已經(jīng)說(shuō)明，WebSocket連接握手重用了現(xiàn)存的HTTP架構(gòu)設(shè)計(jì)。在現(xiàn)存架構(gòu)中，SIP WebSocket 客戶(hù)端和服務(wù)器端之間可能會(huì)有大量的未知的HTTP代理和TCP均衡負(fù)載服務(wù)器。如果服務(wù)器端把源地址寫(xiě)入到Via中的“received”頭字段中，這些地址可能就是SIP實(shí)體的前端HTTP或者TCP中介的地址。這樣會(huì)引起內(nèi)部服務(wù)器地址或者敏感地址暴露給了客戶(hù)端的問(wèn)題�？赡苡脩�(hù)需要考慮一些折中的辦法來(lái)對(duì)Via中的“received”進(jìn)行處理。假設(shè)這樣的一個(gè)場(chǎng)景中，SIP響應(yīng)僅可以通過(guò)現(xiàn)存的WebSocket連接發(fā)送，這樣的話，就不會(huì)有太多的Via中的“received”參數(shù)使用。因此，為了避免SIP WebSocket內(nèi)部服務(wù)器的敏感地址暴露給客戶(hù)端，RFC7188更新了RFC3216中18.2.1章節(jié)的描述。具體描述更新為以下內(nèi)容：
當(dāng)一個(gè)SIP WebSocket服務(wù)器端收到了一個(gè)請(qǐng)求時(shí)，它可以決定不在TOP Via參數(shù)中添加一個(gè)“received”參數(shù)。因此，無(wú)論Via頭中的"sent-by"是否包含域名，SIP WebSocket客戶(hù)端必須接受在Top Via中無(wú)這樣的參數(shù)的響應(yīng)。
SIP實(shí)體的定位服務(wù)（Locating a SIP Server）是非常重要的。RFC3261有對(duì)SIP服務(wù)器定位的定義。在本規(guī)范中，針對(duì)SIP WebSocket服務(wù)器端定義了自己的方式，此規(guī)范支持NAPTR服務(wù)值"SIP+D2W"來(lái)實(shí)現(xiàn)普通的SIP WebSocket服務(wù)器端的定位服務(wù)，加密服務(wù)提供“SIPS+D2W”實(shí)現(xiàn)。這里要提醒用戶(hù)，在此規(guī)范發(fā)布時(shí)，DNS NAPTR/Service Record (SRV) queries仍然不能很好地支持WebSocket 客戶(hù)端（包括一些JavaScript 引擎和頁(yè)面瀏覽器）。在DNS NAPTR/Service Record缺省或者聲明端口場(chǎng)景中，對(duì)于SIP URL來(lái)說(shuō)仍然使用默認(rèn)端口，“WS”傳輸端口是默認(rèn)的80端口，默認(rèn)加密端口是443端口。
2.5-連接存活機(jī)制
我們知道，如果要保證一個(gè)socket一直處于連接狀態(tài)，雙方都要不斷通過(guò)發(fā)送存活消息來(lái)驗(yàn)證其狀態(tài)和心跳。SIP WebSocket 客戶(hù)端和服務(wù)器端也不例外。如果它們之間要一直保持一個(gè)開(kāi)放狀態(tài)的話，它們需要周期性地發(fā)送一個(gè)“Ping或者Pong” 幀數(shù)據(jù)（乒乓球來(lái)回處理）。這個(gè)處理機(jī)制在RFC6455-5.5.2章節(jié)中有說(shuō)明。
當(dāng)前可能存在的問(wèn)題是，對(duì)于某些運(yùn)行于瀏覽器的應(yīng)用，它們的WebSocket API不支持類(lèi)似的處理機(jī)制，對(duì)客戶(hù)端或者服務(wù)器端周期性地發(fā)送Ping消息或者回復(fù)Pong消息。這些應(yīng)用完全取決于瀏覽器支持本身或者瀏覽器設(shè)置。目前，比較主流的瀏覽器對(duì)存活支持還是比較友好的。關(guān)于SIP連接的存活機(jī)制的討論，用戶(hù)可以參考其它兩個(gè)規(guī)范RFC5626-3.5.1或者RFC6223規(guī)范來(lái)進(jìn)一步學(xué)習(xí)存活機(jī)制的狀態(tài)設(shè)置。
2.6-關(guān)于WebSocket客戶(hù)端和服務(wù)器端之間的認(rèn)證機(jī)制
認(rèn)證是現(xiàn)代網(wǎng)絡(luò)環(huán)境安全運(yùn)行的必要條件。因?yàn)閃ebSocket應(yīng)用應(yīng)用于瀏覽器端，客戶(hù)端需要和服務(wù)器端執(zhí)行雙向交互實(shí)現(xiàn)文本，語(yǔ)音和視頻的交互。而且很多時(shí)候，服務(wù)器端需要對(duì)特定客戶(hù)端執(zhí)行特別路由處理，因此，服務(wù)器端對(duì)客戶(hù)端的身份認(rèn)證是非常必要的。在本規(guī)范RFC7118中利用了其它規(guī)范進(jìn)行身份認(rèn)證，其相關(guān)協(xié)議包括RFC6455，RFC6265，RFC2617和RFC3261。需要注意的是，在WebSocket 協(xié)議（RFC6455）中沒(méi)有具體定義認(rèn)證機(jī)制，但是其協(xié)議公布了一個(gè)連接握手時(shí)的WebSocket Client Authentication說(shuō)明。具體來(lái)說(shuō)，RFC6455的關(guān)于WebSocket 客戶(hù)端認(rèn)證是這樣描述的，在握手連接期間，RFC6455不提供關(guān)于客戶(hù)端認(rèn)證的具體機(jī)制，WebSocket 可以使用對(duì)一般HTTP服務(wù)器支持的任何客戶(hù)端的認(rèn)證機(jī)制來(lái)進(jìn)行驗(yàn)證，例如，cookies, HTTP authentication或者TLS authentication。為了更好地實(shí)現(xiàn)客戶(hù)端和服務(wù)器端認(rèn)證兼容性支持，在WebSocket 認(rèn)證層面，RFC7188規(guī)范發(fā)布了強(qiáng)制支持和可選的關(guān)于SIP WebSocket 客戶(hù)端和服務(wù)器端的兼容性列表：
當(dāng)運(yùn)行在瀏覽器環(huán)境時(shí)，SIP WebSocket 客戶(hù)端必須準(zhǔn)備添加一個(gè)會(huì)話cookie, 并且前面已經(jīng)從頁(yè)面服務(wù)器獲取了一個(gè)會(huì)話cookie，此頁(yè)面服務(wù)器URL域名匹配WebSocket域名。具體規(guī)范參考RFC6265。
當(dāng)執(zhí)行WebSocket 握手時(shí)，SIP WebSocket 客戶(hù)端必須準(zhǔn)備挑戰(zhàn)由SIP WebSocket服務(wù)器返回的帶HTTP 401狀態(tài)碼響應(yīng)。具體規(guī)范參考RFC2617。
SIP WebSocket客戶(hù)端可以使用TLS客戶(hù)端認(rèn)證作為可選認(rèn)證機(jī)制。
當(dāng)cookies出現(xiàn)在WebSocket握手請(qǐng)求時(shí)，SIP WebSocket服務(wù)器端必須準(zhǔn)備讀取會(huì)話cookies，并且使用這些cookies值來(lái)決定是否WebSocket 連接已經(jīng)被HTTP 客戶(hù)端初始化，作為SIP WebSocket服務(wù)器端正在和同樣域名的網(wǎng)站進(jìn)行協(xié)商處理。
SIP WebSocket服務(wù)器應(yīng)該可以拒絕一個(gè)帶HTTP 401狀態(tài)碼的WebSocket握手請(qǐng)求。這個(gè)HTTP狀態(tài)碼是由一個(gè)HTTP協(xié)議定義的Basic/Digest challenge提供。
2.7-SIP-WSS場(chǎng)景示例
在SIP應(yīng)用中，絕大部分的使用場(chǎng)景涉及了SIP注冊(cè)和SIP呼叫主要流程。在RFC7118規(guī)范在列出了關(guān)于SIP-WSS注冊(cè)和SIP INVITE呼叫流程。首先，我們介紹如何通過(guò)SIP WSS對(duì)SIP WebSocket 服務(wù)器端進(jìn)行注冊(cè)的示例。以下圖例說(shuō)明了Alice客戶(hù)端通過(guò)SIP WSS對(duì)代理服務(wù)器進(jìn)行注冊(cè)，注冊(cè)大概需要4個(gè)流程來(lái)完成，它們分別包括：連接握手成功，返回101 狀態(tài)碼，切換為SIP注冊(cè)，執(zhí)行SIP注冊(cè)，返回成功注冊(cè)響應(yīng)碼。
根據(jù)以上圖例，我們具體說(shuō)明其步驟。首先，Alice使用瀏覽器加載頁(yè)面，獲取到帶JavaScript，其代碼應(yīng)用支持了本規(guī)范規(guī)定的WebSocket SIP子協(xié)議。腳本代碼作為一個(gè)SIP WebSocket客戶(hù)端嘗試和SIP WebSocket服務(wù)器端(proxy.example.com)創(chuàng)建連接握手。基于創(chuàng)建的連接，Alice發(fā)送一個(gè)SIP注冊(cè)請(qǐng)求，請(qǐng)求中包含了Outbound和GRUU支持。因?yàn)�，瀏覽器中的腳本代碼無(wú)法決定來(lái)自于WebSocket連接的本地地址，因此使用了一個(gè)任意的".invalid" 域名來(lái)支持Via頭字段中的"sent-by"參數(shù)和Contact頭字段中的URL的主機(jī)端口。 具體流程如下：第一步，發(fā)送GET，開(kāi)始WS握手：
F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) GET / HTTP/1.1 Host: proxy.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: https://www.example.com Sec-WebSocket-Protocol: sip Sec-WebSocket-Version: 13
第二步：服務(wù)器端發(fā)送101狀態(tài)碼，進(jìn)行協(xié)議切換
F2 101 Switching Protocols proxy.example.com -> Alice (TLS) HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip
第三步，通過(guò)WSS傳輸進(jìn)行SIP注冊(cè)：
F3 REGISTER Alice -> proxy.example.com (transport WSS) REGISTER sip:proxy.example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf From: sip:alice@example.com;tag=65bnmj.34asd To: sip:alice@example.com Call-ID: aiuy7k9njasd CSeq: 1 REGISTER Max-Forwards: 70 Supported: path, outbound, gruu Contact:;reg-id=1 ;+sip.instance=""
第四步，服務(wù)器返回完成SIP注冊(cè)消息：
F4 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf From: sip:alice@example.com;tag=65bnmj.34asd To: sip:alice@example.com;tag=12isjljn8 Call-ID: aiuy7k9njasd CSeq: 1 REGISTER Supported: outbound, gruu Contact:;reg-id=1 ;+sip.instance="" ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" ;expires=3600
除了SIP-WSS注冊(cè)流程以外，RFC7118規(guī)范列出了一個(gè)通過(guò)SIP INVITE進(jìn)行語(yǔ)音呼叫的示例列出。具體流程圖示例如下，呼叫流程大概經(jīng)過(guò)了11個(gè)步驟。
根據(jù)以上流程圖，首先Alice多Bob的AOR地址進(jìn)行了呼叫。SIP WebSocket服務(wù)器端proxy.example.com作為一個(gè)SIP代理服務(wù)器，路由此呼叫到相應(yīng)的Bob的contact地址。代理服務(wù)器和Bob之間的SIP呼叫通過(guò)UDP傳輸完成。Bob接聽(tīng)了呼叫，然后掛機(jī)。第一步，Alice通過(guò)WSS呼叫：
F1 INVITE Alice -> proxy.example.com (transport WSS) // WSS INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route:Contact:Content-Type: application/sdp
第二步，代理服務(wù)器返回100 trying。
F2 100 Trying proxy.example.com -> Alice (transport WSS) SIP/2.0 100 Trying Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE
第三步，代理服務(wù)器呼叫Bob，通過(guò)UDP傳輸。
F3 INVITE proxy.example.com -> Bob (transport UDP) INVITE sip:bob@203.0.113.22:5060 SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Supported: path, outbound, gruu Contact:Content-Type: application/sdp
第四步, Bob返回響應(yīng)，準(zhǔn)備接收呼叫。
F4 200 OK Bob -> proxy.example.com (transport UDP) SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c ;received=192.0.2.10 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact:Content-Type: application/sdp
第五步，代理服務(wù)器對(duì)Alice 返回 200 OK：
F5 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact:Content-Type: application/sdp
第六步，確認(rèn) 200 OK:
F6 ACK Alice -> proxy.example.com (transport WSS) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Route:,, From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 70
第七步，代理服務(wù)器確認(rèn) 200 OK:
F7 ACK proxy.example.com -> Bob (transport UDP) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 69
雙方開(kāi)始RTP語(yǔ)音流，正式通話。然后Bob首先掛機(jī)，發(fā)送BYE消息到代理服務(wù)器，代理服務(wù)器再發(fā)送BYE消息到Alice SIP WebSocket 客戶(hù)端。最后，Alice對(duì)代理服務(wù)器發(fā)送BYE消息的200 OK, 然后代理服務(wù)器對(duì)Bob發(fā)送BYE消息的200 OK。
F8 BYE Bob -> proxy.example.com (transport UDP) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Route:,From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 70
代理服務(wù)器對(duì)Alice發(fā)送BYE消息，后續(xù)流程忽略。
F9 BYE proxy.example.com -> Alice (transport WSS) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 69
在RFC7188規(guī)范中還規(guī)定了其它的一些安全考慮和語(yǔ)法規(guī)范，例如關(guān)于加密WebSocket連接使用，關(guān)于SIPS的使用，SIP注冊(cè)的進(jìn)一步說(shuō)明，部署指南，用戶(hù)認(rèn)證場(chǎng)景等章節(jié)。這些章節(jié)相對(duì)不是非常重要的內(nèi)容，筆者這里不再討論。
3-總結(jié)
很多程度上，WebRTC的技術(shù)發(fā)展依賴(lài)于瀏覽器的技術(shù)發(fā)展。通過(guò)瀏覽器實(shí)現(xiàn)和電腦設(shè)備的通信是互聯(lián)網(wǎng)應(yīng)用的一個(gè)大的飛躍，它能夠融合更多的語(yǔ)音，視頻和其它數(shù)據(jù)交互。在企業(yè)通信方面，WebRTC利用WebSocket傳輸實(shí)現(xiàn)SIP語(yǔ)音通信讓企業(yè)通信能力上了一個(gè)新的臺(tái)階。RFC7188規(guī)范對(duì)SIP通信結(jié)合WebSocket傳輸進(jìn)行了完整的規(guī)定，用戶(hù)通過(guò)SIP websocket 客戶(hù)端和服務(wù)器端實(shí)現(xiàn)瀏覽器和其它應(yīng)用的對(duì)接。筆者首先介紹了WebRTC以及WebSocket的應(yīng)用場(chǎng)景，包括IMS的規(guī)范要求，另外，詳細(xì)介紹了關(guān)于RFC7188的核心內(nèi)容，包括連接握手，存活處理，用戶(hù)認(rèn)證和SIP傳輸以及語(yǔ)法定義和注冊(cè)呼叫示例。筆者希望用戶(hù)在部署SIP WebSocket客戶(hù)端和服務(wù)器端的過(guò)程中能夠充分考慮到其業(yè)務(wù)的局限性，另外可以充分利用SIP WebSocket 客戶(hù)端和服務(wù)器端的靈活部署能力來(lái)服務(wù)更強(qiáng)大的業(yè)務(wù)場(chǎng)景。
參考資料：
https://libwebsockets.org/
https://www.rfc-editor.org/rfc/rfc7118.html
https://www.rfc-editor.org/rfc/rfc6455.html
www.asterisk.org.cn
www.asterisk.org
www.dinstar.cn
https://jssip.net/
www.sip.org.cn
https://github.com/resiprocate/resiprocate/wiki/WebRTC-and-SIP-Over-WebSockets
https://github.com/SIPp/sipp/issues/124https://www.etsi.org/deliver/etsi_ts/124300_124399/124371/15.02.00_60/ts_124371v150200p.pdf
https://arxiv.org/abs/1601.00184
