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

Thomas Guebels (JIRA) noreply at issues.asterisk.org
Wed Feb 7 05:23:13 CST 2018


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

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

>From what we saw, chan_sip is calling ice->set_role in add_sdp or process_sdp, but with the ASTERISK-27088 change this doesn't actually set the role of ICE session anymore, it is "delayed" until ice->reset is called. Do you mean chan_sip should now reset ICE at some point ? 

> 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: Joshua Colp
>         Attachments: 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)



More information about the asterisk-bugs mailing list