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

[Richard Mudgett (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-26544:
---------------------------------------

    Attachment: jira_asterisk_26544_v14_test.patch

The freeswitch pcap shows that they are using DTLSv1.0 for the key exchange which sends smaller packets.  Asterisk is using DTLSv1.2 for the key exchange which is sending larger packets that get fragmented by the IP stack on the Asterisk server.  These fragments seem to be mishandled on the way to the far end.  Only when they successfully get passed to the far end does the audio connection get established.

[^jira_asterisk_26544_v14_test.patch] - Test patch to determine if setting the MTU will make any difference in how OpenSSL sends the key exchange packets.

Please test and get a pcap on the Asterisk side as you have a setup with a large certificate.  Thanks.

Apply the patch in the root source directory of Asterisk, recompile and install.
patch -p1 -i jira_asterisk_26544_v14_test.patch

> 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: 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_test.patch, 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)