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

[Dan Jenkins (JIRA)]

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

Dan Jenkins edited comment on ASTERISK-26732 at 3/7/17 8:42 PM:
----------------------------------------------------------------

Yup- totally get that - and if you remember from AstriDevCon; I'm usually the advocate for not putting development time into adding new features into chan_sip - but this isn't a new feature. This is fixing a bug (even though its not truly a "bug" in asterisk - its been caused by Asterisk not following whats required in WebRTC) - and if I remember rightly - it was said that the core team would still work on fixing bugs. If you did a poll of people utilising WebRTC using Asterisk today; I'd bet a large proportion are using chan_sip - by not fixing this you'll be alienating all of those users (who will potentially leave using the project if they are forced to migrate to PJSIP - because lets face it, other projects are ahead of Asterisk when it comes to WebRTC). Right now I don't have hard numbers on users using Asterisk for WebRTC on chan_sip so I'm kinda waiting for people to proclaim "this won't fix my issue" enough....

(EDIT - sorry, got sidetracked - I worry that a lot of these chan_sip community users don't have the resources to fix this - and hence my belief that this being a bug, should have been fixed by core)

I'll stop worrying about this until people make a big enough noise about it.

As always - thank you for the work you all do on Asterisk - I may sound complainy but you know I do it from a place of love for the project :)


was (Author: danjenkins):
Yup- totally get that - and if you remember from AstriDevCon; I'm usually the advocate for not putting development time into adding new features into chan_sip - but this isn't a new feature. This is fixing a bug (even though its not truly a "bug" in asterisk - its been caused by Asterisk not following whats required in WebRTC) - and if I remember rightly - it was said that the core team would still work on fixing bugs. If you did a poll of people utilising WebRTC using Asterisk today; I'd bet a large proportion are using chan_sip - by not fixing this you'll be alienating all of those users (who will potentially leave using the project if they are forced to migrate to PJSIP - because lets face it, other projects are ahead of Asterisk when it comes to WebRTC). Right now I don't have hard numbers on users using Asterisk for WebRTC on chan_sip so I'm kinda waiting for people to proclaim "this won't fix my issue" enough....

I'll stop worrying about this until people make a big enough noise about it.

As always - thank you for the work you all do on Asterisk - I may sound complainy but you know I do it from a place of love for the project :)

> 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)