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

Tue Nov 1 13:38:09 CDT 2016

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

Rusty Newton updated ASTERISK-26544:
------------------------------------

    Description: 
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,

  was:
Hello,