[asterisk-bugs] [JIRA] (ASTERISK-26982) chan_sip: rtcp_mux setting may cause ice completion failure/delay if client offers rtcp-mux as negotiable

[Stefan Engström (JIRA)]

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

Stefan Engström commented on ASTERISK-26982:
--------------------------------------------

My initial guess was wrong, chan_sip *does* correctly sets the number of ice components to 1, but it seems res_rtp_asterisk does not act on this, so maybe this issue extends to pjsip?

Anyways, one could add logic in ast_rtp_ice_start to skip adding remote rtcp ice candidates if rtp->ice_num_components == 1 is detected. I tested this by patching the chunk below into the while loop of ast_rtp_ice_start, which did solve the issue, but an asterisk developer should consider the side effects. Merely adding the line below produces false warnings later by ast logging's "Lost %d ICE candidates. Consider increasing PJ_ICE_MAX_CAND in PJSIP"
                 
if (rtp->ice_num_components == 1 && candidate->id == AST_RTP_ICE_COMPONENT_RTCP) {
                        ast_log(AST_LOG_NOTICE, "stefandebug skipping adding rcand rtcp %p\n", instance);
                        continue;
                }


> chan_sip: rtcp_mux setting may cause ice completion failure/delay if client offers rtcp-mux as negotiable
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26982
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26982
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
>    Affects Versions: 13.15.0
>         Environment: built with pjprojects bundled.
>            Reporter: Stefan Engström
>
> When asterisk (chan_sip) receives a SDP offer with rtcp_mux capabilities announced as optional in the sense that the SDP offer contains ice candidates for both RTP and RTCP components (this is the default case for firefox), it seems the resulting check_list that asterisk creates fails. Both parties support RTCP mux and do end up using RTCP MUX, but asterisk builds its ice-check-list with the ice->rcand structure containing candidates for both components. 
> I hope you can reproduce this issue in a proper test environment. At this time I only have my test notes:
> *Test scenario:*
> A chan_sip webrtc client makes an outgoing call
> *Description of general setup:*
> 	Webrtc client uses SIPml and matches a registered chan_sip peer A.x in asterisk configured as in https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5
> *Test case 1.1*
> Webrtc client uses firefox (which by default has rtcpmuxpolicy negotiate). Peer A.x has rtcp_mux=yes. X sends a SDP offer like the following to asterisk:
> {noformat}
> 	INVITE 333
> 	...
> 	a=candidate:0 1 UDP 2122252543 192.168.1.114 62470 typ host
> 	a=candidate:0 2 UDP 2122252542 192.168.1.114 62471 typ host
> 	a=candidate:1 1 UDP 1686052863 111.111.111.111 62470 typ srflx raddr 192.168.1.114 rport 62470
> 	a=candidate:1 2 UDP 1686052862111.111.111.111 62471 typ srflx raddr 192.168.1.114 rport 62471
> 	a=ice-pwd:468f8e9af5e2a3cb57391f164fc245e2
> 	a=ice-ufrag:935fa149
> 	a=rtcp:62471 IN IP4 111.111.111.111
> 	a=rtcp-mux
> 	...
> {noformat}
> Result: Asterisk sends a 200 OK within a second, but ast_rtp_on_ice_complete fires after 8 seconds and consequently 2-way audio is delayed 8 seconds in the corresponding call.
> Internal notes: By using gdb and inserting a breakpoint in  ast_rtp_on_ice_complete I could inspect the ice session attributes and I could verify "(gdb) p ice->clist" that none of the tests in the ice_checklist had succeeded, moreover the ice->rcand was populated with candidates for both components RTP and RTCP.
> *Test case 1.2*
>  As 1.2 but using chrome with rtcpmuxpolicy require.
> X then sends a SDP offer like the following:
> {noformat}
> 	INVITE 333
> 	...
> 	a=rtcp:9 IN IP4 0.0.0.0
> 	a=candidate:2469292855 1 udp <some ipv6> 57513 typ host generation 0 network-id 2 network-cost 50
> 	a=candidate:27784895 1 udp 2122194687 192.168.1.114 57514 typ host generation 0 network-id 1
> 	a=candidate:2163208203 1 udp 1685987071 111.111.111.111 57514 typ srflx raddr 192.168.1.114 rport 57514 generation 0 network-id 1
> 	a=candidate:3719141319 1 tcp 1518275327 <some ipv6> 9 typ host tcptype active generation 0 network-id 2 network-cost 50
> 	a=candidate:1327761999 1 tcp 1518214911 192.168.1.114 9 typ host tcptype active generation 0 network-id 1
> 	a=ice-ufrag:H+L8
> 	...
> 	a=rtcp-mux
> {noformat}
> Result: success, ice completion within a second, and there is only one component in the ice->rcand.
> *Test case 1.3*
> As 1.1 but webrtc client uses chrome with rtcpMuxPolicy explicitly set to "negotiate"
> Result: same result as 1.1
> *Test case 1.4*
> As 1.1 but A.x has rtcp_mux=no,
> Result, success, rtcp_mux is not used, ice->rcand contains seperate RTP and RTCP candidates and the ice check_list succeseds.



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