2017-03-09 80 views
1

根据此announcement: “截至最新的Chrome Canary版本,默认的RTCP复用策略是”require“,而不是”协商“,这将影响Chrome的下一个版本M57。sipML5 - Negotiate rtcpMuxPolicy

我使用sipml5 API进行webrtc调用(后端是Asterisk)。当我尝试通过webrtc扩展进行调用时,我在Chrome控制台中出现了此错误,并且没有音频。

onSetRemoteDescriptionError 

DOMException: Failed to set remote answer sdp: Session error code: ERROR_CONTENT. 
Session error description: rtcpMuxPolicy is 'require', but media description does not contain 'a=rtcp-mux'.. 

那么如何设置rtcpMuxPolicy在sipml5中“协商”?

  • 我的Chrome版本:58.0.3026.3 DEV(64位)
  • SIPML5 API版本:2.0.3
  • Asterisk的版本:13.11.0

回答

0

挖在很长一段时间后,从星号论坛网上我发现了以下几点,

报价:https://issues.asterisk.org/jira/browse/ASTERISK-26732

Chrome 57 has a breaking change when it comes to interop with WebRTC gateways. They've changed their previous "negotiate", to "require" when it comes to rtcp-mux. Asterisk, as I understand it does not have rtcp multiplexing and so will break when it comes to compatibility with WebRTC across all versions of Asterisk that supports WebRTC.

参考rtcpMuxPolicy铬:https://www.chromestatus.com/feature/5654810086866944

The rtcpMuxPolicy is used by the application to specify its preferred policy regarding use of RTP/RTCP multiplexing. When the policy is "negotiate", the ICE candidates for both RTP and RTCP will be gathered. If the remote-endpoint is capable of multiplexing RTCP, multiplex RTCP on the RTP candidates. If it is not, use both the RTP and RTCP candidates separately.

根据谷歌的小组论坛 - https://groups.google.com/forum/#!topic/discuss-webrtc/eM57DEy89MY

As of the most recent Chrome Canary build, the default RTCP multiplexing policy is "require", instead of "negotiate". This will affect the next Chrome release, M57. This means that offer/answer negotiation with an endpoint that doesn't support RTCP multiplexing will fail, resulting in the error: "ERROR_CONTENT. Session error description: Failed to setup RTCP mux filter." We can probably make this error more descriptive, but the bottom line is that setRemoteDescription will fail if the SDP does not contain "a=rtcp-mux". For any application that doesn't yet support RTCP multiplexing, you can get the old behavior by explicitly setting the RTCRtpMuxPolicy to "negotiate" in the RTCConfiguration. For example: pc = new RTCPeerConnection({rtcpMuxPolicy: "negotiate"})

总之,

  • 在Chrome RTCP的早期版本multiplxing设为'协商'
  • S从版本57铬开始改变rtcp multiplxing为'require'
  • Asterisk,据我了解,它不支持rtcp多路复用。
  • webrtc允许RTCRtpMuxPolicy标志选项“协商”和“要求”
  • 在Sipml5 API 2.0.3中,据我所知,没有设置RTCRtpMuxPolicy的选项。

解决方案: 我将sipml5 API从2.0.3更新到2.1.3。现在错误改为警告。

[Deprecation] The rtcpMuxPolicy option is being considered for removal and may be removed no earlier than M60, around August 2017. If you depend on it, please see https://www.chromestatus.com/features/5654810086866944 for more details. 

现在一切工作正常。

相关问题