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

　　根据Asterisk官方消息，如果用户在使用WebRTC时升级了Google浏览器（Chrome 57）时，可能会导致WebRTC不能正常工作。Asterisk官方因为这个问题，增加了一个新功能来支持解决这个问题。大家都知道，VoIP中，RTP是用来发送和接收语音数据的主要协议。除了RTP协议以外，终端也使用了RTCP跟踪发送metadata来解析各自的回话。这些数据包括了发送接收的数据包数量， jitter 信息和其他统计数据。RTCP的拓展则可以对媒体进行控制，例如指示发送完整帧视频。
　　在RTP回话中，事实上已经涉及了两路不同的媒体数据：RTP和RTCP的数据。传统的方式是，当终端准备接收RTP数据时，终端开启一个UDP端口来接收RTP数据，同时需要开启另外一个UDP端口来接收RTCP数据流。换句话说，其实在传输层，已经执行了多路分解的服务。通过进入到端口，用户会知道进入到数据是何种数据类型。RFC 5761  则定义了一个新的传输方式，不同于以前的方式，新的传输方式中，终端仅使用一个端口来接收数据，而不是传统的方式-终端发送数据使用了两个UDP端口来控制数据。新的方式具有以下优点：
　　简化了NAT traversal，因为仅使用一个端口实现媒体和消息控制。
　　理论上，系统中的媒体回话数量可以实现翻倍。
　　采集新的 ICE 和 SDP 支持ICE会变得相对简单。用户仅需要一个candidates 集合，而不是其中的两个。
　　当配合 SDP ”BUNDLE“ 协商时，所有媒体回话使用同一端口，简化了传输 方式和NAT处理流程。
　　Google在WebRTC做出来非常大的贡献，当然也一直对此技术不断进行优化和改进。为了更加简化数据传输的方式，Google工程师提出了新的方式来处理RTP数据，官方工程师采用了新的方式来管理RTP数据，这个功能就是rtcp-mux。为了配合Google浏览器的工作，Asterisk也必须增加对rtcp-mux的功能支持。目前，google 可以支持两种：

• negotiate: 这种模式下，Chrome 会首先尝试使用rtcp-mux，但是如果远端终端不支持rtcp-mux，则会回退到传统模式。
• require: 在这种模式下，如果远端终端不支持rtcp-mux，那么则不会创建呼叫连接。

　　在Chrome 57以前的版本中， Chrome 是以negotiate的模式工作，这表示如果和Asterisk创建一个呼叫连接时，Asterisk不支持rtcp-mux时，则可以回退到传统的模式来创建一个呼叫。Chrome 57 以后的版本，则切换到了“Require”模式。当然，这样的处理方式具有双层作用：

• rtcp-mux 是WebRTC 数据的主要超时方式。
• [size=1em]JSEP[size=1em]新标准使用了 “require” 的方式。根据协议规定： “the default multiplexing policy MUST be set to require”。

　　为了确保Asterisk能够及时支持WebRTC，Asterisk在SIP协议中添加了对rtcp-mux的支持，两个新版本的Asterisk（13.15.0 和 Asterisk 14.4.0）都提供了对rtcp-mux的支持。用户仅需要在pjsip.conf文件中设置 rtcp_mux=yes。
　　关注公众号：asterisk-cn，论坛：www.freeuc.org 获得有价值的技术分享资料。