Failed by DTLS error

Hello, I'm facing a rather weird situation of random "Failed by DTLS error" error. It happens from time to time and can't be tracked as to what's happening or what's wrong. I'm using WCS on a local network. First attachment is a successful stream publishing, second attachment - failed. The only difference is that at the end of the file the successful stream executes this line while failed doesn't

17:59:33,533 INFO FlashphonerTlsClient - Stun-Clbk-thread udp//192.168.0.16:31010 Received server certificate chain of length 1

The application code is exactly the same: the only difference is that it didn't fail but now it does.

Thanks,
P
 

Attachments

Max

Administrator
Staff member
Good day.
Seems like in failure case WCS waits for certificate chain from publisher, but does not receive it (missing a Server Hello packet). Please try to switch to TCP transport to prevent a packets loss.
You can also collect a traffic dump and check if DTLS flow is correct: DTLS traffic
 
Thanks for an update. That was my bad. As I'm using custom handler for all of the events I'm interested in (connect, ConnectionStatusEvent, etc.) I thought that it was enough only to handle "sessionId" and optionally "appKey". This was working fine for mobile clients, but it turned out that there was other property I missed for the web client - "clientBrowserVersion". With WireShark, I figured out that if you don't include this property in post request/response then WCS (by default) uses DTLSv1.0, while contemporary web clients are already using DTLSv1.2 (as was mentioned in the previous forum threads). Hence, WCS couldn't have communicated with the client using v1.0 as it needed v1.2. The interesting part is that it was working fine with the web client for the past 3-4 months and only starting with 1434 has it begun malfunctioning.
 

Max

Administrator
Staff member
Yes, the clientBrowserVersion is used to detect a browser and then use a proper DTLS. That's because WCS initiates DTLS handshake, not browser (WCS sends Client hello), threfore the only way to predict a DTLS version supported is browser version. So you should keep this field untouch in backend server response to WCS.
Usually we recommend to keep all of the fields as is when handling /connect REST hook, just add restClientConfig if necessary.
 
Top