New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 30
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

WebRTC DTLS handshake error handling

Reported by xytis2...@gmail.com, Oct 7 2014 Back to list

Issue description

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?

 
Attaching pcap with failed negotiation.
negotiate.pcap.gz
2.3 KB Download
Project Member

Comment 2 by braveyao@webrtc.org, Oct 8 2014

Cc: jiayl@webrtc.org braveyao@webrtc.org
Owner: juberti@webrtc.org
Could you please provide a whole DTLS negotiate pcap, from call begining, with hold/resume, until failure.

@justin, any comment?
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.
Project Member

Comment 4 by juberti@webrtc.org, Oct 8 2014

You should not be renegotiating DTLS upon hold/resume - I suspect this is part of the problem.
Project Member

Comment 5 by juberti@webrtc.org, Dec 16 2014

Labels: Area-Network
Project Member

Comment 6 by pthatcher@webrtc.org, Jan 12 2015

Labels: IceBox EngTriaged
Project Member

Comment 7 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 8 by anatolid@chromium.org, Dec 5 2016

Status: Assigned
[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.
Project Member

Comment 9 by deadbeef@chromium.org, Mar 30

Status: WontFix
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