Asterisk rtcp-mux新功能更新支持WebRTC

　　根據Asterisk官方消息，如果用戶(hù)在使用WebRTC時(shí)升級了Google瀏覽器（Chrome 57）時(shí)，可能會(huì )導致WebRTC不能正常工作。Asterisk官方因為這個(gè)問(wèn)題，增加了一個(gè)新功能來(lái)支持解決這個(gè)問(wèn)題。大家都知道，VoIP中，RTP是用來(lái)發(fā)送和接收語(yǔ)音數據的主要協(xié)議。除了RTP協(xié)議以外，終端也使用了RTCP跟蹤發(fā)送metadata來(lái)解析各自的回話(huà)。這些數據包括了發(fā)送接收的數據包數量， jitter 信息和其他統計數據。RTCP的拓展則可以對媒體進(jìn)行控制，例如指示發(fā)送完整幀視頻。
　　在RTP回話(huà)中，事實(shí)上已經(jīng)涉及了兩路不同的媒體數據：RTP和RTCP的數據。傳統的方式是，當終端準備接收RTP數據時(shí)，終端開(kāi)啟一個(gè)UDP端口來(lái)接收RTP數據，同時(shí)需要開(kāi)啟另外一個(gè)UDP端口來(lái)接收RTCP數據流。換句話(huà)說(shuō)，其實(shí)在傳輸層，已經(jīng)執行了多路分解的服務(wù)。通過(guò)進(jìn)入到端口，用戶(hù)會(huì )知道進(jìn)入到數據是何種數據類(lèi)型。RFC 5761  則定義了一個(gè)新的傳輸方式，不同于以前的方式，新的傳輸方式中，終端僅使用一個(gè)端口來(lái)接收數據，而不是傳統的方式-終端發(fā)送數據使用了兩個(gè)UDP端口來(lái)控制數據。新的方式具有以下優(yōu)點(diǎn)：
　　簡(jiǎn)化了NAT traversal，因為僅使用一個(gè)端口實(shí)現媒體和消息控制。
　　理論上，系統中的媒體回話(huà)數量可以實(shí)現翻倍。
　　采集新的 ICE 和 SDP 支持ICE會(huì )變得相對簡(jiǎn)單。用戶(hù)僅需要一個(gè)candidates 集合，而不是其中的兩個(gè)。
　　當配合 SDP ”BUNDLE“ 協(xié)商時(shí)，所有媒體回話(huà)使用同一端口，簡(jiǎn)化了傳輸 方式和NAT處理流程。
　　Google在WebRTC做出來(lái)非常大的貢獻，當然也一直對此技術(shù)不斷進(jìn)行優(yōu)化和改進(jìn)。為了更加簡(jiǎn)化數據傳輸的方式，Google工程師提出了新的方式來(lái)處理RTP數據，官方工程師采用了新的方式來(lái)管理RTP數據，這個(gè)功能就是rtcp-mux。為了配合Google瀏覽器的工作，Asterisk也必須增加對rtcp-mux的功能支持。目前，google 可以支持兩種：

• negotiate: 這種模式下，Chrome 會(huì )首先嘗試使用rtcp-mux，但是如果遠端終端不支持rtcp-mux，則會(huì )回退到傳統模式。
• require: 在這種模式下，如果遠端終端不支持rtcp-mux，那么則不會(huì )創(chuàng )建呼叫連接。

　　在Chrome 57以前的版本中， Chrome 是以negotiate的模式工作，這表示如果和Asterisk創(chuàng )建一個(gè)呼叫連接時(shí)，Asterisk不支持rtcp-mux時(shí)，則可以回退到傳統的模式來(lái)創(chuàng )建一個(gè)呼叫。Chrome 57 以后的版本，則切換到了“Require”模式。當然，這樣的處理方式具有雙層作用：

• rtcp-mux 是WebRTC 數據的主要超時(shí)方式。
• [size=1em]JSEP[size=1em]新標準使用了 “require” 的方式。根據協(xié)議規定： “the default multiplexing policy MUST be set to require”。

　　為了確保Asterisk能夠及時(shí)支持WebRTC，Asterisk在SIP協(xié)議中添加了對rtcp-mux的支持，兩個(gè)新版本的Asterisk（13.15.0 和 Asterisk 14.4.0）都提供了對rtcp-mux的支持。用戶(hù)僅需要在pjsip.conf文件中設置 rtcp_mux=yes。
　　關(guān)注公眾號：asterisk-cn，論壇：www.freeuc.org 獲得有價(jià)值的技術(shù)分享資料。