WebRTC實(shí)時(shí)音視頻通話(huà)之語(yǔ)音通話(huà)設計與實(shí)踐

　　在移動(dòng)互聯(lián)網(wǎng)流量時(shí)代，很多業(yè)務(wù)場(chǎng)景都有音視頻通信的需求，比如IM場(chǎng)景，除了文字交流還需要音視頻通話(huà)進(jìn)行實(shí)時(shí)交互。為了幫助58、趕集、安居客等業(yè)務(wù)線(xiàn)更好的為用戶(hù)提供服務(wù)，節約溝通成本，提升效率，TEG基于WebRTC提供了一套完整的實(shí)時(shí)音視頻通話(huà)解決方案——WRTC。

　　另外還有一種場(chǎng)景，比如在進(jìn)行語(yǔ)音通話(huà)時(shí)，APP中的兩個(gè)用戶(hù)可能不是同時(shí)在線(xiàn)，導致一端無(wú)法向另一端發(fā)起實(shí)時(shí)通話(huà)。為了解決這個(gè)問(wèn)題，WRTC還具備語(yǔ)音轉IP電話(huà)的能力。業(yè)務(wù)方可以通過(guò)后端配置選擇是否使用。本文主要以語(yǔ)音通話(huà)為切入點(diǎn)，詳細介紹語(yǔ)音及語(yǔ)音轉IP電話(huà)在WRTC中的設計與實(shí)踐。

　　作為音視頻開(kāi)源核心項目之一，WebRTC整個(gè)框架的設計非常龐大，很多大型公司都在基于WebRTC進(jìn)行音視頻能力開(kāi)發(fā)，包括阿里云、網(wǎng)易云、七牛云等。TEG也在2016年就開(kāi)始提供基于WebRTC的實(shí)時(shí)音視頻通話(huà)能力。同時(shí)WebRTC的架構設計靈活，功能強大，覆蓋了大部分移動(dòng)端多媒體技術(shù)。

　　比如APM（聲音處理模塊），被很多公司借鑒用于音頻的AEC、NS、AGC。JitterBuffer用于視頻抗抖動(dòng)。Android端Camera和Camera2結合使用，用于視頻采集，可擴展的軟編碼框架以及軟硬編結合方式處理視頻流等。可以說(shuō)WebRTC的每個(gè)模塊都值得我們深入研究，學(xué)習其中的設計思想和音視頻處理技術(shù)。

　　目前網(wǎng)上關(guān)于WebRTC資料有很多，限于篇幅，本文也只做個(gè)簡(jiǎn)單介紹，具體細節，感興趣的同學(xué)可以深入研究模塊代碼，就像Linux鼻祖Linus曾說(shuō)的至理名言"Read the f*** source code"。

　　WRTC功能模塊主要分為視頻通話(huà)、語(yǔ)音通話(huà)、語(yǔ)音轉IP電話(huà)。本文主要介紹語(yǔ)音和語(yǔ)音轉IP電話(huà)部分。

　　音視頻通話(huà)包括音頻通話(huà)和視頻通話(huà)。同時(shí)，為了豐富音視頻電話(huà)在當前網(wǎng)絡(luò )環(huán)境下的應用場(chǎng)景和通話(huà)能力，WRTC還需要提供IP電話(huà)的解決方案。業(yè)界比較流行的IP電話(huà)方案是用FreeSwitch作為電話(huà)網(wǎng)關(guān)后臺，該方案支撐的架構如下圖：

　　在上圖這種架構下，客戶(hù)端除了實(shí)現WRTC需要的信令協(xié)議通信之外，還需要額外增加同FreeSwitch服務(wù)之間的SIP協(xié)議通信。從SDK的角度來(lái)考慮，這對客戶(hù)端SDK的包體積、接入復雜度、容錯率以及版本靈活性等都帶來(lái)了額外的挑戰。所以我們最終決定將這部分實(shí)現放在服務(wù)端，架構如下圖：

　　架構優(yōu)化后，在沒(méi)有增加客戶(hù)端和服務(wù)端交互復雜度的前提下，由服務(wù)端對音頻流進(jìn)行轉接，通過(guò)SIP協(xié)議對接到電話(huà)網(wǎng)關(guān)，實(shí)現與對端手機的通信。另外，服務(wù)端還可以進(jìn)行語(yǔ)音錄制，為后期業(yè)務(wù)方的語(yǔ)音監控、通話(huà)記錄分析等需求增加了便利。

　　首先介紹下WRTC的音視頻通話(huà)流程，如下圖所示，主叫通過(guò)Room/Signaling服務(wù)和被叫進(jìn)行信息交互，IM服務(wù)器對于音視頻通話(huà)來(lái)說(shuō)并不是必須的，把它放在WRTC的流程當中是為了讓被叫順利接收主叫的通話(huà)請求。在一個(gè)完整的通話(huà)流程中，主叫首先嘗試和被叫建立音視頻通話(huà)的連接，假如連接超時(shí)或者主叫主動(dòng)發(fā)起IP電話(huà)時(shí)，WRTC服務(wù)端會(huì )通過(guò)運營(yíng)商撥打被叫電話(huà)，從而完成IP電話(huà)的流程。

　　1、房間管理。房間是一個(gè)抽象概念，目的是在主被叫之間建立一個(gè)隨時(shí)可查詢(xún)可追溯的信息通道，比如說(shuō)當主叫發(fā)起音視頻通話(huà)請求時(shí)，被叫需要一個(gè)標識來(lái)確定需要和哪一方進(jìn)行通話(huà)，這個(gè)標識就是用房間信息來(lái)儲存的。音視頻通話(huà)需要雙方先加入房間，然后再使用PeerConnection建立連接進(jìn)行通話(huà)。下面舉幾個(gè)房間管理的例子：

　　/**

　　@brief 請求RoomInfo（后臺需要進(jìn)行身份驗證，并分配roomId等）

　　@param completeHandler 回調block

　　@since v1.0.0

　　*/

　　+ （void）requestRoomInfo:（CompleteHandler）completeHandler;

　　/**

　　@brief 加入房間

　　@param roomid 房間的id

　　@param params 參數字典

　　@param completeHandler 回調返回

　　@since v1.1.1

　　*/

　　+ （void）joinToRoom:（NSString *）roomId

　　Parameters:（NSDictionary *）params

　　Complete:（CompleteHandler）completeHandler;

　　/**

　　@brief 通知此時(shí)處于忙狀態(tài)

　　@param roomId 第三方呼叫發(fā)來(lái)的roomId

　　@since v1.0.0

　　*/

　　+ （void）notifyBusy:（NSString *）roomId;

　　2、信令管理。WRTC采用的是Websocket作為信令服務(wù)器，進(jìn)行媒體協(xié)商，發(fā)送SDP會(huì )話(huà)描述協(xié)議和Candidate候選信息等。這里主要涉及SDP會(huì )話(huà)描述協(xié)議（offer/answer）和Candidate信息交換。為了提升編碼性能，WRTC視頻編解碼采用H264，音頻編解碼綜合考慮性能和帶寬，采用的是OPUS。Candidate交換的是打洞候選IP地址和端口號，用于p2p連接和中繼。

　　下面是一對一音頻通話(huà)，主叫方發(fā)送的SDP（offer）。

　　offer

　　…

　　a=mid:audio

　　a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

　　a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

　　a=sendrecv

　　a=rtcp-mux

　　a=rtpmap:111 opus/48000/2

　　a=rtcp-fb:111 transport-cc

　　a=fmtp:111 minptime=10;useinbandfec=1

　　a=rtpmap:103 ISAC/16000

　　a=rtpmap:104 ISAC/32000

　　a=rtpmap:9 G722/8000

　　a=rtpmap:102 ILBC/8000

　　a=rtpmap:0 PCMU/8000

　　a=rtpmap:8 PCMA/8000

　　a=rtpmap:106 CN/32000

　　a=rtpmap:105 CN/16000

　　a=rtpmap:13 CN/8000

　　a=rtpmap:126 telephone-event/8000

　　…

　　主叫發(fā)送的sdp信息通過(guò)信令服務(wù)器發(fā)送到被叫，被叫收到該offer后，會(huì )根據該offer回一個(gè)answer信息。至此，主叫和被叫完成了媒體信息的協(xié)議協(xié)商。

　　3、狀態(tài)管理。通過(guò)信令服務(wù)器進(jìn)行雙方通話(huà)狀態(tài)的管理，狀態(tài)包括busy、refuse、cancel等。狀態(tài)管理一方面可以防止雙通話(huà)，另一方面也能根據通話(huà)狀態(tài)進(jìn)行用戶(hù)行為統計分析，然后進(jìn)行迭代優(yōu)化，為各個(gè)業(yè)務(wù)線(xiàn)提供更好、更穩定的音視頻通話(huà)服務(wù)。

　　4、音頻模塊、視頻模塊、ICE打洞服務(wù)、媒體流傳輸等在上文做了簡(jiǎn)單介紹。其實(shí)這里的每一個(gè)模塊，都值得我們去深入研究學(xué)習，比如我們也在嘗試借鑒其中的音頻處理模塊用于直播服務(wù)。篇幅所限，本文不做過(guò)多描述。

　　ICE打洞服務(wù)，WRTC音視頻通話(huà)方式分為p2p和中繼兩種方式。ICE包括STUN和TURN服務(wù)，用于打洞，STUN可以進(jìn)行NAT類(lèi)型檢測，并獲取NAT背后的外網(wǎng)IP地址和端口號。其中NAT類(lèi)型主要分為Full Cone NAT、RestrictedCone NAT、Port Restricted Cone NAT、Symmetric NAT四種。對于前三種都可以建立p2p直連，對于Symmetric NAT（對稱(chēng)性NAT），因為每次連接端口都是變化的，所以通過(guò)STUN獲取的端口號是無(wú)效的。此時(shí)WRTC會(huì )改走中繼模式，來(lái)保證雙端的正常通話(huà)。

　　考慮到一旦建立p2p連接，后續服務(wù)端不能控制干預媒體流，后端服務(wù)后續也計劃進(jìn)行系統升級，統一采用中繼的方式進(jìn)行音視頻通話(huà)，來(lái)保證音視頻通話(huà)的可靠性和可控性。

　　后端服務(wù)經(jīng)過(guò)判斷需要向被叫撥打IP電話(huà)時(shí)，協(xié)議轉換服務(wù)會(huì )將接到的offer轉換為SIP的帶有協(xié)商信息的invite協(xié)議，發(fā)送給運營(yíng)商，然后運營(yíng)商會(huì )回復給100trying，表明正在處理SIP信令。

　　當被叫手機振鈴時(shí)，運營(yíng)商回復180或183協(xié)議給協(xié)議轉換服務(wù)，并帶有第一次協(xié)商的結果，協(xié)議轉換服務(wù)將其轉化為answer回復給客戶(hù)端，完成第一次媒體通信即客戶(hù)端聽(tīng)到彩鈴。

　　當被叫手機接聽(tīng)時(shí)，運營(yíng)商會(huì )發(fā)送200給協(xié)議轉換服務(wù)，并帶有第二次協(xié)商的結果，協(xié)議轉換服務(wù)將其轉化為answer回復給客戶(hù)端，完成第二次媒體通信即被叫和主叫開(kāi)始通話(huà)。

　　對于IP電話(huà)，WRTC也具備對分機二次撥號的能力。比如被叫方是座機，可以通過(guò)二次撥號和指定用戶(hù)進(jìn)行語(yǔ)音通話(huà)。

　　電話(huà)撥號，就必須要提到雙音多頻信號DTMF。DTMF是電話(huà)系統中電話(huà)機與交換機之間的一種用戶(hù)信令，用于電話(huà)撥號。通過(guò)研究WebRTC底層代碼，其實(shí)它是支持DTMF撥號能力的，只是沒(méi)有對外部暴露。

　　我們需要修改PeerConnection，增加insertDtmf功能。撥打分機號時(shí)需要傳入本地AudioTrack ID，默認值為ARDAMSa0。分機號碼ext_number取值范圍0~15，對應event為0-9,*, #, A-D。撥號音duration SDK設置的為1000ms。

　　bool PeerConnection::insertDtmf（const std::string& audio_track_id,const int ext_number,const int duration）{

　　//判斷是否支持發(fā)送DTMF信號

　　bool canInsertDtmf = session_->CanInsertDtmf（audio_track_id）;

　　if （canInsertDtmf） {

　　//WebRTCSession對象發(fā)送DTMF

　　isInsert = session_->InsertDtmf（audio_track_id,ext_number,duration）;

　　}

　　return isInsert;

　　}

　　本文主要介紹了WRTC的實(shí)現方案、流程以及IP電話(huà)的原理。其中涉及到的細節還有很多，這里就不再贅述。目前WRTC已經(jīng)能提供了穩定的音視頻通話(huà)輸出能力，后續我們將繼續在WRTC方案的基礎之上，結合TEG的短視頻SDK，從采集端、通話(huà)端進(jìn)行持續優(yōu)化，采集端豐富音視頻處理細節，通話(huà)端增加多人通話(huà)，最終形成一對一以及多對多的音頻、視頻、IP電話(huà)混合對話(huà)的能力。