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

Mon Dec 19 17:49:10 CST 2016

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

Richard Mudgett commented on ASTERISK-26544:
--------------------------------------------

The pcap you sent for the Freeswitch DTLS negotiation is not using the same cert as with the Asterisk pcaps.  The cert has "FreeSWITCH" strings in it and is a much smaller cert than the ones used in the Asterisk pcaps.  The Asterisk pcaps have certs with strings like "Greater Manchester" and "vip2phone.net" in them.

The last patch to force DTLSv1.0 did work as intended because the pcap showed us using DTLSv1.0 where we would have used DTLSv1.2.  The DTLSv1.0 vs DTLSv1.2 difference between Freeswitch and Asterisk therefor isn't significant.  Looking at the Freeswitch code, I don't see any significant differences in how they setup for DTLS.  Of more significance is that they are using the same OpenSSL BIO (BIO_s_mem).  This BIO does not support pre-fragmenting the DTLS packets and they pass these packets to the IP stack in a similar manner.  Therefore, you will have the same issue with Freeswitch when actually using the larger cert files.

Restating from earlier, the IP stack on the sending machine has to fragment the large cert exchange packets.  This is seen in the pcaps on the Asterisk side.  Not all fragments make it through to the other side.  When they do make it you get connected.  This is seen in the pcaps on the browser side.

> 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-capture-call-without-delay.zip, jira_asterisk_26544_v14_force_dtlsv1.patch, jira_asterisk_26544_v14_test.patch, res_rtp_asterisk.c.rej, 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)