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