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

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

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

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

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