An upcoming change in Chrome 57 (currently Chrome Dev) will see your WebRTC application fail if it relies on Asterisk to be a webRTC gateway.
TL;DR
Your WebRTC app will break soon if you use Asterisk - add a new flag to the RTCPeerConnection instantiation to keep your app working.
The issue
In a recent change to the WebRTC stack inside Chrome 57, the rtcp-mux setting has gone from "negotiate" to "require". This doesn't cause an issue for any peer to peer calls as the browsers are able to deal with the changes; but does cause an issue for some WebRTC gateways. I've seen the change cause problems in RTPEngine and Asterisk. Fortunately, RTPEngine has a flag you can enable to get past the issue. You can see the Public Service Announcement on the discuss-webrtc mailing list.
For now, Asterisk does not support RTCP multiplexing and so can't offer this option within the SDP that Chrome 57 requires. So where does this leave us? An issue has been raised on the Asterisk Issue tracker and its been mentioned on the asterisk-dev mailing list. But in short; right now, the only thing you can do to save your application from failing catastrophically when Chrome 57 gets released as Stable, is to pass in an extra option into your RTCPeerConnection instantiation to enable the old behaviour within Chrome.
pc = new RTCPeerConnection({rtcpMuxPolicy: "negotiate"})
You can just pass this in without any browser conditionals around it; its safe to do so. If you don't do this, your application will likely start giving out errors when setting the remote description; you'll likely see an error similar to this in chrome://webrtc-internals
setRemoteDescriptionOnFailure
Failed to set remote answer sdp: Session error code:
ERROR_CONTENT. Session error description: Failed to setup RTCP mux filter...
As with any extra flag to enable old behaviour, I expect the flag to disappear sometime in the future - I'm still trying to find out how long the new flag will hang around for which allows us to carry on utilising Asterisk as a WebRTC gateway.
Chrome 55 is around mid cycle right now, which means Chrome 57 is around 6 weeks away; maybe a little bit more - An Asterisk update is unlikely to happen in that time.
Libraries
If you use jsSIP, its an easy change for you as jsSIP allows you to specify the object that gets passed in to creation of the RTCPeerConnection.
If you use sip.js; Sean Bright has issued a Pull Request enabling you to pass in an option to enable this additional setting.
