a=rtcp-mux 与 a=group:BUNDLE

rtcp-mux是什么？

         大多数的VoIP协议都使用RTP用来发送和接收媒体。除了RTP以外，终端还会向对方发送RTCP数据包，指出了会话的元数据。其中包括很多发送/接收的数据包，抖动信息，以及大量其他数据。RTCP的拓展内容还允许可以被用作数据流的指定控制协议，比如指定一个发送端来发送视频的全帧。

         关键之处是，一个典型的RTP会话涉及到两个单独的数据流：RTP和RTCP。传统上，当一个终端使用RTP时，这个终端会打开一个UDP端口来接收RTP数据，打开另一个UDP端口来接收RTCP数据。换句话说，就是在传输层进行数据种类的解复用。只要知道数据流是由哪个端口传入的，你就可以知道你所接收的数据类型是什么。

         RFC 5761定义了完成这些任务的一个新方法。与之前分别使用单独的UDP端口不同，RFC 5761规定RTP和RTCP数据由同一接口接收。这与旧方法相比有几点好处：

# 由于只用一个端口进行媒体和控制消息的传输，所以它简化了NAT穿越的过程

# 理论上你可以将你系统上同一个UDP端口的媒体会话量翻倍

# 收集ICE候选以及 ICE的SDP 信令变得简单的多。你只需要用一套候选项，而不是两套。

# 当与BUNDLE一起使用时，所有媒体会话都使用同一个端口，进一步的简化了传输用量和NAT穿越。

        

Google Chrome的rtcp-mux

         Google Chrome好几年前就已经有rtcp-mux功能了。Juan de Bravo，一名Chrome的开发人员，最近发表了一篇博文，详细阐述了chrome团队对rtcp-mux的观点。此外，Chrome和Asterisk guru Dan Jenkins也写了一篇博文，详细的描述了Chrome的改变，这些改变是如何影响Asterisk的，以及如果有需要的话你要如何处理它们。rtcp-mux选择执行这两个模式之一：

# 协商：这种模式下，Chrome会尝试使用rtcp-mux，但是如果远端不支持rtcp-mux的话也可以退回到传统模式。

# 强制：在这种模式下，如果远端不支持rtcp-mux的话，Chrome会进行协调，然后宣布会话建立失败。

         在57版本之前，Chrome执行“协商”模式。这意味着当给Asterisk拨打通话时，因为Asterisk不支持rtcp-mux，所以Chrome会退回到传统模式使用传统的RTCP。从Chrome 57版本开始，变成了“强制”模式。他们给出了这样做的两个理由：

# 绝大多数人都使用rtcp-mux处理他们的WebRTC数据流

# 一个即将到来的标准规定使用“强制”模式

         因为发生了这个改变，导致从Chrome到Asterisk的通话会失败。

         你可以通过在Chrome 浏览器中将你RTCPeerConnection中的rtcpMuxPolicy flag设定成“negotiate”而不是“require”来避免这种问题出现。上文中给出链接的Dan的博文更详细地写了对于特定的WebRTC SIP用户你应该怎么做。有传言说Chrome团队最终会去掉这个flag，并且在未来发布的Chrome版本中强制使用“强制”模式。