[asterisk-bugs] [JIRA] (ASTERISK-26544) res_rtp_asterisk: Delay in DTLS handshake causes audio setup delay

Mon Dec 19 20:01:10 CST 2016

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

Marcelo Gornstein edited comment on ASTERISK-26544 at 12/19/16 7:59 PM:
------------------------------------------------------------------------

Hello Richard,

So you were absolutely right. The location of the cert used for the DTLS setup wasn't well documented, so I completely missed that file in FS. 

I grabbed the original etc/freeswitch/tls/dtls-srtp.pem and split it into a .crt and .key file, setup  the asterisk sip.conf file with these files and it seems to work perfectly.

Also, when using FreeSWITCH and overwriting their original dtls-srtp.pem file with wss.pem I can reproduce this problem too.

I'd like my team to make the final tests with this FS certificate with some customers before closing this one, and also would like to know your thoughts on where's the bug here, because with the original Comodo cert this issue can be reproduced consistently in different networks, in different countries, different ISPs, etc.

Although it does seem that both Asterisk and FreeSWITCH will behave the same now.

Thank you very much for your help! 

was (Author: marcelog):
Hello Richard,

So you were absolutely right. I completely missed that file in FS, it wasn't well documented the location of the cert used for the DTLS setup, so I grabbed the original etc/freeswitch/tls/dtls-srtp.pem and split it into a .crt and .key file, setup  the asterisk sip.conf file and it seems to work perfectly.

I'd like my team to make the final tests with this FS certificate with some customers before closing this one, and also would like to know your thoughts on where's the bug here, because with original Comodo cert this can be reproduced consistently in different networks, in different countries, different ISPs, etc.

Thank you very much for your help! 

> res_rtp_asterisk: Delay in DTLS handshake causes audio setup delay
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-26544
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26544
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.6.0, 13.9.0, 13.12.0, 13.11.2, 13.12.1, 14.0.0, 14.1.1
>         Environment: Amazon Linux: 4.4.23-31.54.amzn1.x86_64 #1 SMP x86_64 GNU/Linux
> OpenSSL: 1.0.2j
> LibSRTP: 1.5.4
> SIPml5: e3152e1edf116b651de379b3cc971bf699787c26 (Fri Mar 4 09:47:48 2016 +0100)
> Chrome: 54.0.2840.71 (64-bit)
> FireFox: 49.0.2
> Opera: 41.0
> Online JSSip Demo at: https://tryit.jssip.net/
> Amazon EC2 instance
>            Reporter: Marcelo Gornstein
>            Assignee: Unassigned
>         Attachments: 54752_jira_asterisk_26544_v13_test.pcap, 54755_jira_asterisk_26544_v13_test_force_dtlsv1.pcap, cert.txt, dtls-handshake-audio-delay-asterisk-14.1.1-2.zip, dtls-handshake-audio-delay-asterisk-14.1.1-3.zip, dtls-handshake-audio-delay-asterisk-14.1.1.zip, freeswitch-bad.pcap, freeswitch-capture-call-without-delay.zip, freeswitch-ok.pcap, fs-dtls.crt, fs-dtls.key, jira_asterisk_26544_v14_force_dtlsv1.patch, jira_asterisk_26544_v14_test.patch, res_rtp_asterisk.c.rej, screencapture-sslanalyzer-comodoca-1482194006200.png, screencapture-ssllabs-ssltest-analyze-html-1480426789448.png, sip_trace.txt
>
>
> Hello,
> It seems that there is a delay in the audio setup when using WebRTC with latest Asterisk versions and latest browser versions (described in the Environment section).
> Sometimes there is no delay, but most of the time the delay goes between 1 second to a couple of minutes. 
> This seems to be related to a delay in the DTLS connection handshake between Asterisk and the browser (although this is just a guess after trying to isolate the issue).
> sip.conf
> {code}
> [100]
> nat=force_rport,comedia
> host=dynamic
> type=friend
> secret=secret
> disallow=all
> allow=g722
> icesupport=yes
> transport=wss
> dtlsenable=yes
> dtlsverify=no
> dtlscertfile=/cert.crt
> dtlsprivatekey=/cert.key
> dtlssetup=actpass
> videosupport=no
> encryption=yes
> avpf=yes
> force_avp=yes
> directmedia=no
> canreinvite=no
> context=wrtc
> {code}
> extensions.conf
> {code}
> [wrtc]
> exten => _X.,1,Answer
> same => n,Playback(tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys&tt-monkeys)
> same => n,Hangup
> {code}
> rtp.conf
> {code}
> [general]
> rtpstart=6000
> rtpend=65535
> icesupport=true
> [ice_host_candidates]
> x.x.x.x => y.y.y.y ; x.x.x.x is the internal IP, y.y.y.y is the external IP
> {code}
> [Edit by Rusty - removed excessive debug in description field as per issue tracker guidelines. Moving to attachment.]
> FireFox shows this in its logs:
> {code}
> 276467712[7f8929a4aec0]: [|WebrtcAudioSessionConduit] AudioConduit.cpp:612: GetAudioFrame 
> 276467712[7f8929a4aec0]: [|WebrtcAudioSessionConduit] AudioConduit.cpp:716: GetAudioFrame GetAudioFrame:Got samples: length 320 
> {code}
> But no audio is played until some (random) number of seconds pass, and this logs shows up:
> {code}
> 261443584[7f89265334a0]: Flow[568ce410feebc53d:0,rtp(none)]; Layer[dtls]: PacketReceived(2001)
> 261443584[7f89265334a0]: Flow[568ce410feebc53d:0,rtp(none)]; Layer[dtls]: Checking digest, algorithm=sha-256
> 261443584[7f89265334a0]: Flow[568ce410feebc53d:0,rtp(none)]; Layer[ice]:  SendPacket(75) succeeded
> 261443584[7f89265334a0]: Flow[568ce410feebc53d:0,rtp(none)]; Layer[dtls]: ****** SSL handshake completed ******
> 261443584[7f89265334a0]: Flow[568ce410feebc53d:0,rtp(none)]; Layer[dtls]: ALPN not negotiated, selecting default
> 261443584[7f89265334a0]: /builds/slave/m-rel-m64-00000000000000000000/build/src/media/mtransport/transportlayerdtls.cpp:865: Flow[568ce410feebc53d:0,rtp(none)]; 
> {code}
> EDIT: I forgot to mention that looking at the output from chrome://webrtc-internals, I noticed that during the delay the browser is stalled at ICEConnectionStateChecking. As soon as the audio is connected, it goes to ICEConnectionStateConnected.
>  
> Without changing any browser or network settings whatsoever either in the Asterisk Box or the browser's box, sometimes it just works. But most of the time the delay is present.
> With FreeSWITCH (cec0cb39830546a3a1c1df7ad7a05b05f14b8975 - Fri Oct 28 15:38:25 2016 -0500) works perfectly, every single time.
> Any help is greatly appreciated!
> Thank you.
> Best regards,

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