DTLS handhake problem in WebRTC

[Fedor Sumkin]

What steps will reproduce the problem?

1. Try the one2many Kurento tutorial with Chrome (43.0.2357.81 m)
   
2. In one tab start "master" session, in other tab start "viewer session".
   

What is the expected result?

Media traffic exchange must start always

What do you see instead?

Sometimes after SDP exchange media exchange is not started at all.

What version of the product are you using? On what operating system?

We use Chrome (43.0.2357.81 m), Windows 8 (64 bit), Kurento latest version (5.1.0)

Please provide any additional information below.

We analyzed network traffic with Wireshark and realized that DTLS handshake is not successful in come cases.

There are 2 interesting types of dtls messages: "Change Cipher Spec" and "Certificate Verify". Each of them has its own sequence number (SN).

We checked, Kurento Media Server generates SN correctly, i.e. "Change Cipher Spec" has SN greater than "Certificate Verify" message SN.

But on the client side (in browser), these 2 messages are received in reverse order. I mean, "Certificate Verify" is received after "Change Cipher Spec" message.

These causes troubles, because WebRTC uses openssl, but openssl expects "Finished" message right after "Change Cipher Spec" message.

These problem is described here:

1. https://code.google.com/p/chromium/issues/detail?id=447431
   
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775502
   

I also attached 2 dropbox links to Wireshark dumps, maybe it will help. You can filter logs by "dtls" keyword to see the problem.

1. error dump
2. success dump

Below are links to SDPs:

1. Client2Kurento
2. Kurento2Client

[Fedor Sumkin]

Hi all,

Has somebody encountered with this or similar type of problem? Any ideas how to fix incorrect behaviour?

 

[Christoffer Jansson]

On Thursday, June 4, 2015 at 1:54:39 PM UTC+2, Fedor Sumkin wrote:

Hi all,

Has somebody encountered with this or similar type of problem? Any ideas how to fix incorrect behaviour?

The bug was fixed very recently, have you tried the same scenario in the latest Chrome Canary? If not please do and report back the result.  

 

[Fedor Sumkin]

Hello Christoffer,

We already tried the same scenario in Canary (45.0.2419.0) few days ago, you can see our post here.

[Christoffer Jansson]

There has been some activity in the bug you linked, please check it out and see if it answers your concern.