DTLS negotiation failure handling and other sound issues

[Vytis Valentinavičius]

Hi,

I am struggling with several 'sound loss' problems in production environment. This post might be a little out of scope for this group, but I need help resolving and tracking these problems.

Setup:

Chrome (39.0.2145.0) <-> mediaproxy-ng <-> asterisk

Issue 1: DTLS negotiation errors are not handled

https://code.google.com/p/webrtc/issues/detail?id=3900

Occasionally DTLS negotiation fails in final step (Decrypt Client Finish). How this case should be handled? Currently mediaproxy on received DTLS Encrypted Alert drops SSL_CTX structure and discontinues DTLS negotiation. Should it restart the negotiation if it is in client mode (SSL_connect)? How this is handled in WebRTC when WebRTC is in client mode? Should mediaproxy send 'close notify' alert?

What happens in WebRTC that Client Finish can not be decrypted? How can I debug this?

I tried to run Chrome with "--vmodule='*libjingle/*=9'", but the output is not really helpful (DTLS channel error, code=1).

Issue 2: Random incoming sound loss during active call

Active calls sometimes become 'muted'. My team found out that each time 'voice loss' is reported incoming voice channel contains in-band DTMF signal (mostly DTMF 'A'). But we found no valid reason why this happens. It appears that packets are delivered to clients and are dropped internally in WebRTC code. Are there any similar issues? (https://code.google.com/p/webrtc/issues/detail?id=3785 appears to be NOT connected)

Issue 3: DTLS failure time correlation

Issue 1 should be independent for each RTP stream, but it appears in batches. If one stream fails DTLS negotiation, so will the next for approx. 5-15 min (or more, I usually restart mediaproxy as soon as I see the issue 1 to reduce collateral damage).

Mediaproxy runs on:

Linux HOSTNAME 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

OpenSSL 1.0.1f 6 Jan 2014

Chrome clients are on separate Win7 machines connected by single switch.

Thank You for Your insights,

Vytis

[Justin Uberti]

#1 when DTLS fails, it's all over. This should not happen in normal use.

#2 this typically indicates a problem with RTP timestamps being wrong

#3 this is probably reusing a certificate serial number improperly