在RTP回話中，事實(shí)上已經(jīng)涉及了兩路不同的媒體數(shù)據(jù)：RTP和RTCP的數(shù)據(jù)。傳統(tǒng)的方式是，當(dāng)終端準(zhǔn)備接收RTP數(shù)據(jù)時(shí)，終端開(kāi)啟一個(gè)UDP端口來(lái)接收RTP數(shù)據(jù)，同時(shí)需要開(kāi)啟另外一個(gè)UDP端口來(lái)接收RTCP數(shù)據(jù)流。換句話說(shuō)，其實(shí)在傳輸層，已經(jīng)執(zhí)行了多路分解的服務(wù)。通過(guò)進(jìn)入到端口，用戶會(huì)知道進(jìn)入到數(shù)據(jù)是何種數(shù)據(jù)類型。RFC 5761 則定義了一個(gè)新的傳輸方式，不同于以前的方式，新的傳輸方式中，終端僅使用一個(gè)端口來(lái)接收數(shù)據(jù)，而不是傳統(tǒng)的方式-終端發(fā)送數(shù)據(jù)使用了兩個(gè)UDP端口來(lái)控制數(shù)據(jù)。新的方式具有以下優(yōu)點(diǎn)：
簡(jiǎn)化了NAT traversal，因?yàn)閮H使用一個(gè)端口實(shí)現(xiàn)媒體和消息控制。
理論上，系統(tǒng)中的媒體回話數(shù)量可以實(shí)現(xiàn)翻倍。
采集新的 ICE 和 SDP 支持ICE會(huì)變得相對(duì)簡(jiǎn)單。用戶僅需要一個(gè)candidates 集合，而不是其中的兩個(gè)。
當(dāng)配合 SDP ”BUNDLE“ 協(xié)商時(shí)，所有媒體回話使用同一端口，簡(jiǎn)化了傳輸 方式和NAT處理流程。
Google在WebRTC做出來(lái)非常大的貢獻(xiàn)，當(dāng)然也一直對(duì)此技術(shù)不斷進(jìn)行優(yōu)化和改進(jìn)。為了更加簡(jiǎn)化數(shù)據(jù)傳輸?shù)姆绞剑珿oogle工程師提出了新的方式來(lái)處理RTP數(shù)據(jù)，官方工程師采用了新的方式來(lái)管理RTP數(shù)據(jù)，這個(gè)功能就是rtcp-mux。為了配合Google瀏覽器的工作，Asterisk也必須增加對(duì)rtcp-mux的功能支持。目前，google 可以支持兩種：
- negotiate: 這種模式下，Chrome 會(huì)首先嘗試使用rtcp-mux，但是如果遠(yuǎn)端終端不支持rtcp-mux，則會(huì)回退到傳統(tǒng)模式。
- require: 在這種模式下，如果遠(yuǎn)端終端不支持rtcp-mux，那么則不會(huì)創(chuàng)建呼叫連接。
- rtcp-mux 是WebRTC 數(shù)據(jù)的主要超時(shí)方式。
- [size=1em]JSEP[size=1em]新標(biāo)準(zhǔn)使用了 “require” 的方式。根據(jù)協(xié)議規(guī)定： “the default multiplexing policy MUST be set to require”。
關(guān)注公眾號(hào)：asterisk-cn，論壇：www.freeuc.org 獲得有價(jià)值的技術(shù)分享資料。
