在移動互聯(lián)網(wǎng)流量時代，很多業(yè)務場景都有音視頻通信的需求，比如IM場景，除了文字交流還需要音視頻通話進行實時交互。為了幫助58、趕集、安居客等業(yè)務線更好的為用戶提供服務，節(jié)約溝通成本，提升效率，TEG基于WebRTC提供了一套完整的實時音視頻通話解決方案——WRTC。
另外還有一種場景，比如在進行語音通話時，APP中的兩個用戶可能不是同時在線，導致一端無法向另一端發(fā)起實時通話。為了解決這個問題，WRTC還具備語音轉(zhuǎn)IP電話的能力。業(yè)務方可以通過后端配置選擇是否使用。本文主要以語音通話為切入點，詳細介紹語音及語音轉(zhuǎn)IP電話在WRTC中的設計與實踐。
二、WebRTC簡介
作為音視頻開源核心項目之一，WebRTC整個框架的設計非常龐大，很多大型公司都在基于WebRTC進行音視頻能力開發(fā)，包括阿里云、網(wǎng)易云、七牛云等。TEG也在2016年就開始提供基于WebRTC的實時音視頻通話能力。同時WebRTC的架構(gòu)設計靈活，功能強大，覆蓋了大部分移動端多媒體技術。
比如APM（聲音處理模塊），被很多公司借鑒用于音頻的AEC、NS、AGC。JitterBuffer用于視頻抗抖動。Android端Camera和Camera2結(jié)合使用，用于視頻采集，可擴展的軟編碼框架以及軟硬編結(jié)合方式處理視頻流等。可以說WebRTC的每個模塊都值得我們深入研究，學習其中的設計思想和音視頻處理技術。
目前網(wǎng)上關于WebRTC資料有很多，限于篇幅，本文也只做個簡單介紹，具體細節(jié)，感興趣的同學可以深入研究模塊代碼，就像Linux鼻祖Linus曾說的至理名言"Read the f*** source code"。
- 音頻，音頻采集、處理模塊
- 視頻，視頻采集、編解碼模塊
- ICE打洞中繼服務器，STUN/TURN
- 媒體流傳輸，RTP/RTCP
WRTC功能模塊主要分為視頻通話、語音通話、語音轉(zhuǎn)IP電話。本文主要介紹語音和語音轉(zhuǎn)IP電話部分。
三、音視頻通話架構(gòu)
音視頻通話包括音頻通話和視頻通話。同時，為了豐富音視頻電話在當前網(wǎng)絡環(huán)境下的應用場景和通話能力，WRTC還需要提供IP電話的解決方案。業(yè)界比較流行的IP電話方案是用FreeSwitch作為電話網(wǎng)關后臺，該方案支撐的架構(gòu)如下圖：
在上圖這種架構(gòu)下，客戶端除了實現(xiàn)WRTC需要的信令協(xié)議通信之外，還需要額外增加同F(xiàn)reeSwitch服務之間的SIP協(xié)議通信。從SDK的角度來考慮，這對客戶端SDK的包體積、接入復雜度、容錯率以及版本靈活性等都帶來了額外的挑戰(zhàn)。所以我們最終決定將這部分實現(xiàn)放在服務端，架構(gòu)如下圖：
架構(gòu)優(yōu)化后，在沒有增加客戶端和服務端交互復雜度的前提下，由服務端對音頻流進行轉(zhuǎn)接，通過SIP協(xié)議對接到電話網(wǎng)關，實現(xiàn)與對端手機的通信。另外，服務端還可以進行語音錄制，為后期業(yè)務方的語音監(jiān)控、通話記錄分析等需求增加了便利。
通話流程
首先介紹下WRTC的音視頻通話流程，如下圖所示，主叫通過Room/Signaling服務和被叫進行信息交互，IM服務器對于音視頻通話來說并不是必須的，把它放在WRTC的流程當中是為了讓被叫順利接收主叫的通話請求。在一個完整的通話流程中，主叫首先嘗試和被叫建立音視頻通話的連接，假如連接超時或者主叫主動發(fā)起IP電話時，WRTC服務端會通過運營商撥打被叫電話，從而完成IP電話的流程。
客戶端：
1、房間管理。房間是一個抽象概念，目的是在主被叫之間建立一個隨時可查詢可追溯的信息通道，比如說當主叫發(fā)起音視頻通話請求時，被叫需要一個標識來確定需要和哪一方進行通話，這個標識就是用房間信息來儲存的。音視頻通話需要雙方先加入房間，然后再使用PeerConnection建立連接進行通話。下面舉幾個房間管理的例子：
/**
@brief 請求RoomInfo（后臺需要進行身份驗證，并分配roomId等）
@param completeHandler 回調(diào)block
@since v1.0.0
*/
+ （void）requestRoomInfo:（CompleteHandler）completeHandler;
/**
@brief 加入房間
@param roomid 房間的id
@param params 參數(shù)字典
@param completeHandler 回調(diào)返回
@since v1.1.1
*/
+ （void）joinToRoom:（NSString *）roomId
Parameters:（NSDictionary *）params
Complete:（CompleteHandler）completeHandler;
/**
@brief 通知此時處于忙狀態(tài)
@param roomId 第三方呼叫發(fā)來的roomId
@since v1.0.0
*/
+ （void）notifyBusy:（NSString *）roomId;
2、信令管理。WRTC采用的是Websocket作為信令服務器，進行媒體協(xié)商，發(fā)送SDP會話描述協(xié)議和Candidate候選信息等。這里主要涉及SDP會話描述協(xié)議（offer/answer）和Candidate信息交換。為了提升編碼性能，WRTC視頻編解碼采用H264，音頻編解碼綜合考慮性能和帶寬，采用的是OPUS。Candidate交換的是打洞候選IP地址和端口號，用于p2p連接和中繼。
下面是一對一音頻通話，主叫方發(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信息通過信令服務器發(fā)送到被叫，被叫收到該offer后，會根據(jù)該offer回一個answer信息。至此，主叫和被叫完成了媒體信息的協(xié)議協(xié)商。
3、狀態(tài)管理。通過信令服務器進行雙方通話狀態(tài)的管理，狀態(tài)包括busy、refuse、cancel等。狀態(tài)管理一方面可以防止雙通話，另一方面也能根據(jù)通話狀態(tài)進行用戶行為統(tǒng)計分析，然后進行迭代優(yōu)化，為各個業(yè)務線提供更好、更穩(wěn)定的音視頻通話服務。
4、音頻模塊、視頻模塊、ICE打洞服務、媒體流傳輸?shù)仍谏衔淖隽撕唵谓榻B。其實這里的每一個模塊，都值得我們?nèi)ド钊胙芯繉W習，比如我們也在嘗試借鑒其中的音頻處理模塊用于直播服務。篇幅所限，本文不做過多描述。
服務端：
- 后臺服務管理整個WRTC音視頻通話的連接建立、信息交換、房間信息等。
- 房間服務，對加入房間的主叫Caller和被叫Callee的行為進行管理，比如加入房間、退出房間等等（上文已經(jīng)在客戶端部分做過介紹，此處不再重復）。
- 信令服務，控制雙端用戶的媒體協(xié)商、Candidate交換等。
ICE打洞服務，WRTC音視頻通話方式分為p2p和中繼兩種方式。ICE包括STUN和TURN服務，用于打洞，STUN可以進行NAT類型檢測，并獲取NAT背后的外網(wǎng)IP地址和端口號。其中NAT類型主要分為Full Cone NAT、RestrictedCone NAT、Port Restricted Cone NAT、Symmetric NAT四種。對于前三種都可以建立p2p直連，對于Symmetric NAT（對稱性NAT），因為每次連接端口都是變化的，所以通過STUN獲取的端口號是無效的。此時WRTC會改走中繼模式，來保證雙端的正常通話。
考慮到一旦建立p2p連接，后續(xù)服務端不能控制干預媒體流，后端服務后續(xù)也計劃進行系統(tǒng)升級，統(tǒng)一采用中繼的方式進行音視頻通話，來保證音視頻通話的可靠性和可控性。
運營商（網(wǎng)關代理）：
后端服務經(jīng)過判斷需要向被叫撥打IP電話時，協(xié)議轉(zhuǎn)換服務會將接到的offer轉(zhuǎn)換為SIP的帶有協(xié)商信息的invite協(xié)議，發(fā)送給運營商，然后運營商會回復給100trying，表明正在處理SIP信令。
當被叫手機振鈴時，運營商回復180或183協(xié)議給協(xié)議轉(zhuǎn)換服務，并帶有第一次協(xié)商的結(jié)果，協(xié)議轉(zhuǎn)換服務將其轉(zhuǎn)化為answer回復給客戶端，完成第一次媒體通信即客戶端聽到彩鈴。
當被叫手機接聽時，運營商會發(fā)送200給協(xié)議轉(zhuǎn)換服務，并帶有第二次協(xié)商的結(jié)果，協(xié)議轉(zhuǎn)換服務將其轉(zhuǎn)化為answer回復給客戶端，完成第二次媒體通信即被叫和主叫開始通話。
如下圖所示：
IP電話二次撥號：
對于IP電話，WRTC也具備對分機二次撥號的能力。比如被叫方是座機，可以通過二次撥號和指定用戶進行語音通話。
電話撥號，就必須要提到雙音多頻信號DTMF。DTMF是電話系統(tǒng)中電話機與交換機之間的一種用戶信令，用于電話撥號。通過研究WebRTC底層代碼，其實它是支持DTMF撥號能力的，只是沒有對外部暴露。
我們需要修改PeerConnection，增加insertDtmf功能。撥打分機號時需要傳入本地AudioTrack ID，默認值為ARDAMSa0。分機號碼ext_number取值范圍0~15，對應event為0-9,*, #, A-D。撥號音duration SDK設置的為1000ms。
下面是insertDtmf部分代碼：
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;
}
四、總結(jié)
本文主要介紹了WRTC的實現(xiàn)方案、流程以及IP電話的原理。其中涉及到的細節(jié)還有很多，這里就不再贅述。目前WRTC已經(jīng)能提供了穩(wěn)定的音視頻通話輸出能力，后續(xù)我們將繼續(xù)在WRTC方案的基礎之上，結(jié)合TEG的短視頻SDK，從采集端、通話端進行持續(xù)優(yōu)化，采集端豐富音視頻處理細節(jié)，通話端增加多人通話，最終形成一對一以及多對多的音頻、視頻、IP電話混合對話的能力。
