I have an interesting issue with WebRTC, when a WebRTC client answers an incoming call immediately sound flows instantly, but the longer you wait to answer, longer it takes to get the sound flowing.
I’ve narrowed the issue to the DTLS handshake establishment.
Chrome is sending a Client Hello each second, then each 2 seconds, then each 4 seconds, then each 8 seconds etc.
Asterisk will answer with a Server Hello only after the call has been established and a new Clent Hello is received, so it can be 8, 16, 32 seconds until the sounds starts going.
In the mean time Chrome is logging: :
ERROR:dtlstransportchannel.cc(489)] Jingle:Channel[audio|1|__]: Received non-DTLS packet before DTLS complete.
Is this an issue with Chrome or Asterisk?
What’s the policy on the DTLS handshake, shouldn’t asterisk respond each time it receives a Client Hello message?
Imgur: The magic of the Internet - arrow points to the silence gap of a few seconds until Chrome sends the Client Hello again, handshake is done and sound starts flowing…
Software versions:
- Asterisk 13.7.2
- Applied ASTERISK-25265: [patch]DTLS Failure when calling WebRTC-peer on Firefox 39 - add ECDH support and fallback to prime256v1
- Asterisk configuration is the recommended sip, rtp settings for WebRTC, a signed ssl certificate.
- Chrome/49.0.2623.75 Electron/0.37.2
- sipml5 1.4.217
Everything works: audio both ways, no NAT issues, just this annoying handshake delay.