[asterisk-bugs] [JIRA] (ASTERISK-27646) ICE fails with no candidate nominated

[Thomas Guebels (JIRA)]

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

Thomas Guebels commented on ASTERISK-27646:
-------------------------------------------

I tested the patch, it doesn't improve the situation. ice_start is now indeed called in add_sdp (actually we saw the SIP_RESPONSE condition earlier when trying to debug it and were confused by it) but this just stores it in rtp->role.

Later on, when we receive the SDP from the browser, process_sdp calls change_ice_components and start_ice and this triggers 2 ICE reset:

[2018-02-08 10:11:42.459202] DEBUG[25391][C-00000025] res_rtp_asterisk.c: Resetting ICE for RTP instance '0x7f1e5c030bd0'
[2018-02-08 10:11:42.459215] DEBUG[25391][C-00000025] res_rtp_asterisk.c: Nevermind. ICE isn't ready for a reset
[2018-02-08 10:11:42.459224] DEBUG[25391][C-00000025] res_rtp_asterisk.c: Set role to CONTROLLING (0x7f1e5c030bd0)
[2018-02-08 10:11:42.459240] DEBUG[25391][C-00000025] res_rtp_asterisk.c: Resetting ICE for RTP instance '0x7f1e5c030bd0'
[2018-02-08 10:11:42.459247] DEBUG[25391][C-00000025] res_rtp_asterisk.c: Nevermind. ICE isn't ready for a reset

However the role still isn't applied to the ICE session since now the state check doesn't pass. We are already nominating (note that this is apparently cause by the ICE aggressive nomination activated in pjnath).


> ICE fails with no candidate nominated
> -------------------------------------
>
>                 Key: ASTERISK-27646
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27646
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.18.0
>            Reporter: Thomas Guebels
>            Assignee: Thomas Guebels
>              Labels: patch
>         Attachments: ASTERISK-27646.diff, C-0000003b.log, udp_C-0000003b.pcap, udp_C-0000031C_20180207.pcap
>
>
> Since the change made in ASTERISK-27088, we have intermittent ICE issues.
> The ICE negotiation fails on the asterisk side with all checks succeeded but none nominated.
> [2018-01-31 16:22:00.159361] DEBUG[4908][C-00000023] pjproject: 	icess0x7efe980 .ICE process complete, status=All ICE checklists failed (PJNATH_EICEFAILED)
> [2018-01-31 16:22:00.159377] DEBUG[4908][C-00000023] pjproject: 	icess0x7efe980 .Valid list
> [2018-01-31 16:22:00.159394] DEBUG[4908][C-00000023] pjproject: 	icess0x7efe980 . 0: [1] 100.64.72.5:26424-->172.16.39.121:51919 (not nominated, state=Succeeded)
> [2018-01-31 16:22:00.159414] DEBUG[4908][C-00000023] pjproject: 	icess0x7efe980 . 1: [1] 100.64.72.5:26424-->172.16.39.121:51919 (not nominated, state=Succeeded)
> On the browser (Chrome 64) side, it thinks that ICE succeeded but there is one-way voice and the call soon stops because asterisk doesn't reply to STUN pings anymore.
> It seems to be timing dependent as it can only be reproduced with at least 2 network paths with similar latency. When one is noticeably slower, it doesn't happen.



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