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