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
Status: Assigned
Owner:
Last visit > 30 days ago
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
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.
Sign in to add a comment