0

WebRTC中的rtcp-mux

已有 718 阅读此文人 - - WebRTC -

作者:Mark Michelson(原文链接

翻译:刘通

21095600_0E3u

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版本中强制使用“强制”模式。

期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.