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

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

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

• rtcp-mux 是WebRTC 數(shù)據(jù)的主要超時方式。
• [size=1em]JSEP[size=1em]新標(biāo)準(zhǔn)使用了 “require” 的方式。根據(jù)協(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文件中設(shè)置 rtcp_mux=yes。
　　關(guān)注公眾號：asterisk-cn，論壇：www.freeuc.org 獲得有價(jià)值的技術(shù)分享資料。