[asterisk-bugs] [JIRA] (ASTERISK-26732) res_rtp_asterisk: Implement RTCP Multiplexing - breaking WebRTC in Chrome

[James Van Vleet (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235618#comment-235618 ] 

James Van Vleet commented on ASTERISK-26732:
--------------------------------------------

Well since you asked this watcher moved to pjsip specifically because we were moving to webRTC.  I can understand the plight of people that might struggle getting off of chan_sip but if you are going to be running something as leading edge as webRTC you really need to run pjsip on Asterisk.  Things are still quite fluid and what is known as webRTC is really a large (and loose) set of features and standards - many of which have been ignored by the voip community for years.   This won't be the last new feature (this really is not a bug) that causes webRTC to not work.  

> res_rtp_asterisk: Implement RTCP Multiplexing - breaking WebRTC in Chrome
> -------------------------------------------------------------------------
>
>                 Key: ASTERISK-26732
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26732
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.13.1, 14.2.1
>         Environment: Chrome 57 onwards 
>            Reporter: Dan Jenkins
>            Assignee: Mark Michelson
>         Attachments: asterisk-ugly-rtcpmux.diff
>
>
> 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 (as far as I understand, thats back to 11 I think)
> We have a flag we can enable client side for the time being; and I'm trying to find out how long that flag will be available for - but thats no lomng term solution.
> I wrote on the mailing list about the issue - http://lists.digium.com/pipermail/asterisk-dev/2017-January/076091.html
> For comparison - I've got other systems using WebRTC which use RTPEngine (with Kamailio) and Freeswitch - both of these have enabled me to enable flags etc to get past this issue.
> I don't know what the right move is going forward. I'm just reporting the issue - every single application out there that utilises Asterisk for WebRTC will have to either move platform or enable a flag client side in the hope that Asterisk will enable the feature set required for compatibility with Chrome
> This affects Chrome 57 onwards - We're currently on Chrome 55 mid cycle - which means roughly 6 weeks until this becomes mainstream.
> If you want help reproducing this, please let me know and we can have a conversation about URLs in somewhere less public. 
> The error you'll get will be something along the lines of "setRemoteDescriptionOnFailure
> Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to setup RTCP mux filter.."



--
This message was sent by Atlassian JIRA
(v6.2#6252)