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

[Andrew Nagy (JIRA)]

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

Andrew Nagy edited comment on ASTERISK-26732 at 3/13/17 9:04 PM:
-----------------------------------------------------------------

I think it should also be mentioned that if one is using both chan_sip & pjsip at the same time the result is unknown upon with "driver" Asterisk will use for the websocket communication. Thus one should refer to ASTERISK-24106 which is a (resolved/fixed) ticket that disables chan_sip websockets. Which will be necessary to use pjsip only if [~seanbright]'s patch is not approved.

As to the question in this thread. I side with [~danjenkins]. As much as I like/love PJSIP this is a breaking change because Asterisk is (was?) not following the WebRTC spec. As such without Dan's blog a month ago I would have never figured out the error in Asterisk ([2017-03-13 18:33:09] WARNING[32113][C-0000004d]: res_rtp_asterisk.c:777 ast_rtp_ice_start: No RTCP candidates; skipping ICE checklist (0x7f4de4acb3d0))

So thank's Dan and all others who've contributed to this ticket.


was (Author: tm1000):
I think it should also be mentioned that if one is using both chan_sip & pjsip at the same time the result is unknown upon with "driver" Asterisk will use for the websocket communication. Thus one should refer to ASTERISK-24106 which is a (resolved/fixed) ticket that disables chan_sip websockets. Which will be necessary to use pjsip only if [~seanbright]'s patch is not approved.

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