[asterisk-bugs] [JIRA] (ASTERISK-25467) A11 ICE/DTLS , SDP Signalling change x-post chrome

[Dade Brandon (JIRA)]

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

Dade Brandon edited comment on ASTERISK-25467 at 10/15/15 2:37 PM:
-------------------------------------------------------------------

Hi, I just wanted to add some information here

The issue is a consistent 0.9s delay being added; 0.9s is (<1 second> - <our latency to the server, 90ms>), which I imagine is significant as it appears that a timeout is being hit in either Chrome or Asterisk + that a second attempt of <whatever isn't working the first time> is allowing the call setup to complete.

If I can summarize what the Chromium project team has said, hopefully effectively, they say that the updated version of Chrome (which is their 'Canary' aka 'bleeding edge' build - due to stable promotion in ~ 6 weeks) has speed improvements to their ICE+DTLS processes, which is likely now causing Chrome to win a race to a condition that causes this to break -- where Asterisk is not receiving an initial DTLS packet because it's no longer listening at the necessary time.   We're hoping that between Asterisk and Chromium, that there can be an agreement that one side or the other is at breach of protocol/rfc and that whichever side that is can correct the issue on their end.

On the table below, if "Delay problem exists" is yes, then there was exactly 0.9s more delay than if "Delay problem exists" is no, using the same test client/server hardware/network.  Three tests per row were done.  Network jitter between client/server locations was sub 1ms at the time.

||Answering WebRTC peer||Offering WebRTC peer||Commit 1ad827?||Delay problem exists||
|Chrome 47.0.2519.0|Asterisk 11.19|Yes|Yes|
|Chrome 47.0.2521.0|Asterisk 11.19|Yes|Yes|
|Chrome 47.0.2521.0|Asterisk 11.19|Reverted|No|
|Chrome 47.0.2519.0|Asterisk 11.16|No|No|
|Chrome 47.0.2521.0|Asterisk 11.16|No|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.19|Yes|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.19|Reverted|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.16|No|No|

(Restricted to JIRA Users group)

was (Author: dade):
Hi, I just wanted to add some information here

The issue is a consistent 0.9s delay being added; 0.9s is (<1 second> - <our latency to the server, 90ms>), which I imagine is significant as it appears that a timeout is being hit in either Chrome or Asterisk + that a second attempt of <whatever isn't working the first time> is allowing the call setup to complete.

If I can summarize what the Chromium project team has said, hopefully effectively, they say that the updated version of Chrome (which is their 'Canary' aka 'bleeding edge' build - due to stable promotion in ~ 6 weeks) has speed improvements to their ICE+DTLS processes, which is likely now causing Chrome to win a race to a condition that causes this to break -- where Asterisk is not receiving an initial DTLS packet because it's no longer listening at the necessary time.   We're hoping that between Asterisk and Chromium, that there can be an agreement that one side or the other is at breach of protocol/rfc and that whichever side that is can correct the issue on their end.

On the table below, if "Delay problem exists" is yes, then there was exactly 0.9s more delay than if "Delay problem exists" is no, using the same test client/server hardware/network.  Three tests per row were done.  Network jitter between client/server locations was sub 1ms at the time.

||Answering WebRTC peer||Offering WebRTC peer||Commit 1ad827?||Delay problem exists||
|Chrome 47.0.2519.0|Asterisk 11.19|Yes|Yes|
|Chrome 47.0.2521.0|Asterisk 11.19|Yes|Yes|
|Chrome 47.0.2521.0|Asterisk 11.19|Reverted|No|
|Chrome 47.0.2519.0|Asterisk 11.16|No|No|
|Chrome 47.0.2521.0|Asterisk 11.16|No|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.19|Yes|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.19|Reverted|No|
|Chrome 46.0.2490.42 beta-m 64 bit|Asterisk 11.16|No|No|


> A11 ICE/DTLS , SDP Signalling change x-post chrome
> --------------------------------------------------
>
>                 Key: ASTERISK-25467
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25467
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.19.0
>         Environment: Ubuntu 14.04.2 LTS , asterisk version 11.19 updated to trunk, last commit: b4535b0
>            Reporter: Nicole McIntosh
>
> There was a change introduced in Commit #  1ad827327a,
> (ChangeId:Ib75ea2546f29d6efc3d2d37c58df6986c7bd9b91)
> This affected ICE/DTLS SSL behavior. 
> The problem appears when comparing ICE negotiation delay, and differences in delay depending on version of chrome, as well as Asterisk version.
> Testing with Asterisk 11.19 and latest chrome (Canary M47) there is a significantly longer ICE negotiation delay. 
> But, with same chrome on asterisk Before Commit 1ad827327a , no longer delay is present.
> (See external chromium issue linked in external issue ID)
> One possible solution may be to have Asterisk handle incoming DTLS packets as soon as ICE is connected, even if the signalling is delayed.  
> This issue is for the behavior of asterisk when handling the ICE/DTLS handshake and signalling.
> reproducable everytime.
> To reproduce, compare webrtc asterisk ICE signalling delay between versions of asterisk after the commit(latest version) and Chrome Canary, and previous versions of Asterisk before aforementioned commit and Chrome Canary.



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