WebRTC DTLS handshake error handling
Reported by xytis2...@gmail.com, Oct 7 2014
Setup: mediaproxy-ng as RTP <-> SRTP bridge kamailio as registrar and wss endpoint Google Chrome > v39 as client What steps will reproduce the problem? 1. call WebRTC client (I use SipML5 as SIP library) 2. wait until DTLS negotiation completes, on success, do hold/resume and repeat this step 3. DTLS negotiation sometimes fail while decrypting 'Client Finish'. Server responds by DTLS encrypted alert. Chrome: [22230:42247:1007/114449:VERBOSE4:dtlstransportchannel.cc(422)] Jingle:Channel[audio|1|__]: DTLSTransportChannelWrapper: channel writable state changed. [22230:42247:1007/114449:VERBOSE3:dtlstransportchannel.cc(573)] Jingle:Channel[audio|1|__]: DtlsTransportChannelWrapper: Started DTLS handshake [22230:42247:1007/114449:VERBOSE4:dtlstransportchannel.cc(410)] Jingle:Channel[audio|1|__]: DTLSTransportChannelWrapper: channel readable state changed. ... [22230:42247:1007/114451:VERBOSE3:dtlstransportchannel.cc(557)] Jingle:Channel[audio|1|__]: DTLS channel error, code=1 Mediaproxy-ng: Oct 7 11:44:52 SSL error: SSL_connect:error in SSLv3 read server session ticket A Oct 7 11:44:53 SSL alert: read:fatal:decrypt error Oct 7 11:44:53 SSL error: SSL_connect:failed in SSLv3 read server session ticket A Oct 7 11:44:53 DTLS error: 1 (tlsv1 alert decrypt error) What is the expected result? DTLS negotiation should be retried if error occurs. What do you see instead? DTLS negotiation fails and is net retried. What version of the product are you using? On what operating system? Chrome > v39 Please provide any additional information below. Please provide insight where this problem could be resolved. As far as I can tell mediaproxy-ng does not handle failed DTLS handshakes. When mediaproxy encounters handshake failure it destroys SSL_CTX structure and does not retry renegotiation. May I avoid destruction of SSL_CTX and send only 'close notify' via SSL_shutdown? Then reinitiate the DTLS handshake via SSL_accept | SSL_connect ? In general case, how should mediaproxy handle DTLS encrypted alerts? How does WebRTC handles them?
Oct 7 2014,
Attaching pcap with failed negotiation.
Oct 8 2014,
Could you please provide a whole DTLS negotiate pcap, from call begining, with hold/resume, until failure. @justin, any comment?
Oct 8 2014,
Sometimes the call fails on first connect. Such pcap is attached above. Unfortunately dtls failure is somehow time correlated (I can reproduce it ONLY after lunch.) As fun as it sounds, but I am trying for more than 40 minutes of call/hold/resume/.../hangup cycles, and no luck.
Oct 8 2014,
You should not be renegotiating DTLS upon hold/resume - I suspect this is part of the problem.
Dec 16 2014,
Jan 12 2015,
Nov 8 2016,
Dec 5 2016,
[bulk-edit] This issue appears to have been triaged (as evidenced by the presence of the EngTriaged label) and also has an Owner -- hence, changing its status to Assigned. If the currently set Owner is wrong, then please re-assign to a correct Owner, or remove Owner and set status to Available.
Mar 30 2018,
Closing, since automatically retrying a DTLS association on an error is not part of the dtls-sdp standard: A new DTLS association can only be established as a result of the successful SDP offer/answer exchange. Whenever an entity determines that a new DTLS association is required, the entity MUST initiate an SDP offer/answer exchange, following the procedures in Section 5. So, I think the only proper way to do this would be to detect the error using the RTCDtlsTransport state (when that's available), then set a description with a new "dtls-id" (once that's implemented).
Sign in to add a comment