[Home]

Summary:ASTERISK-26982: chan_sip: rtcp_mux setting may cause ice completion failure/delay if client offers rtcp-mux as negotiable
Reporter:Stefan Engström (StefanEng86)Labels:
Date Opened:2017-05-04 09:02:56Date Closed:2017-05-23 08:51:10
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General Resources/res_rtp_asterisk
Versions:13.15.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:built with pjprojects bundled.Attachments:
Description: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.
Comments:By: Asterisk Team (asteriskteam) 2017-05-04 09:02:57.207-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Stefan Engström (StefanEng86) 2017-05-04 10:23:25.650-0500

For those who have the same issue as me, one can work-around this issue by forcing both sides to require rtcp_mux... In firefox I had to modify the SDP before sending it to asterisk, doing something like:
sdp=sdp.replace(/a=candidate:[0-9]* 2 .*\r\n/g,'')
which removes the rtcp ice candidates from the SDP offer, which solved the issue for now...

By: Sebastian Gutierrez (sum) 2017-05-04 14:22:05.518-0500

I can confirm the issue. Calls started in firefox are with delay.

By: Rusty Newton (rnewton) 2017-05-05 13:33:26.937-0500

[~sum] can you verify the work-around mentioned by Stefan?

By: Stefan Engström (StefanEng86) 2017-05-05 13:56:45.717-0500

I talked to scgm11 before; he uses chan_sip too but his users use chrome which do not experience the issue by default, unless you set the rtcpmuxpolicy to negotiate, which the SIPml library does, but he doesn't use a SIPml-based webrtc client... In SIPml the work-around is applied by inserting one extra line in onIceGatheringCompleted in the SIPml src/tinyMEDIA/src/tmedia_session_jsep.js see below, but that's just a ugly hotfix, since that unconditionally prevents any rtcp ice candidates from being transmitted via SDP
{noformat}
tmedia_session_jsep01.onIceGatheringCompleted = function (_This) {
...
This.o_sdp_jsep_lo = localDescription;
This.o_sdp_jsep_lo.sdp=This.o_sdp_jsep_lo.sdp.replace(/a=candidate:[0-9]* 2 .*\r\n/g,'');
...
}
{noformat}


By: Stefan Engström (StefanEng86) 2017-05-06 10:39:02.263-0500

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;
               }


By: Stefan Engström (StefanEng86) 2017-05-10 07:20:00.422-0500

From what the developers at #asterisk-dev said, it seems to me that the easiest fix would be to patch chan_sip.c to strip the rtcp ice candidates from the SDP at the sdp-parsing-function. This could be done by mimicing the rtcp ice candidates stripping logic that chan_pjsip already does. I invite anyone that understood ASTERISK-26846 to push such a patch to gerrit for review; I may do it myself but not in the nearest future


By: Sean Bright (seanbright) 2017-05-19 10:13:44.235-0500

Proposed patch is [here|https://gerrit.asterisk.org/#/c/5650].

By: Friendly Automation (friendly-automation) 2017-05-23 08:51:10.803-0500

Change 5651 merged by Jenkins2:
chan_sip: Better ICE handling for RTCP-MUX

[https://gerrit.asterisk.org/5651|https://gerrit.asterisk.org/5651]

By: Friendly Automation (friendly-automation) 2017-05-24 10:37:51.149-0500

Change 5711 merged by Jenkins2:
chan_sip: Better ICE handling for RTCP-MUX

[https://gerrit.asterisk.org/5711|https://gerrit.asterisk.org/5711]

By: Friendly Automation (friendly-automation) 2017-05-24 10:44:56.185-0500

Change 5712 merged by Jenkins2:
chan_sip: Better ICE handling for RTCP-MUX

[https://gerrit.asterisk.org/5712|https://gerrit.asterisk.org/5712]

By: Friendly Automation (friendly-automation) 2017-05-24 11:42:31.956-0500

Change 5652 merged by Jenkins2:
chan_sip: Better ICE handling for RTCP-MUX

[https://gerrit.asterisk.org/5652|https://gerrit.asterisk.org/5652]

By: Friendly Automation (friendly-automation) 2017-05-24 11:43:00.012-0500

Change 5650 merged by Joshua Colp:
chan_sip: Better ICE handling for RTCP-MUX

[https://gerrit.asterisk.org/5650|https://gerrit.asterisk.org/5650]