Failed by DTLS error

[Petro O. Bochan]

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

 

[Max]

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

 

[Petro O. Bochan]

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]

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.