[ortc] DTLS "auto" role and possible DTLS conflicts

ibc has just created a new issue for https://github.com/openpeer/ortc:

== DTLS "auto" role and possible DTLS conflicts  ==
According to the spec, if no remote DTLS parameters are yet given the 
browser assumes a DTLS role based on its ICE role. IMHO this can 
become a problem when in the following scenario:

* Alice and Bob successfully negotiate and establish ICE (Alice 
becomes "ICE controlling" and Bob becomes "ICE controlled").
* For X reason, Bob is not yet provided with Alice's DTLS params, so 
based on its "ICE controlled" role it acts as DTLS client and sends a 
ClientHello request to Alice.
  * **CONCERN 1:** At this point Alice receives the DTLS ClientHello 
so, according to the spec, it becomes DTLS server.
* Later, DTLS parameters are given to both endpoitnts: Alice is told 
that Bob is DTLS server and Bob is told that Alice is DTLS client.
* Since DTLS was already started in opposite direction, both must 
reset their DTLS session.
  * **CONCERN 2:** If previous DTLS connection succeeded (all but the 
not yet given remote fringerprint) should both Alice and Bob send a 
DTLS alert when reseting their DTLS sides?

And the **main concern** is that current Chrome version (I mean WebRTC
 1.0 of course) fails in the above scenario in which it receives a 
DTLS ClientHello and later is told to become DTLS client (Chrome does 
not send a ClientHello after that).

Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/318 using your GitHub account

Received on Monday, 4 January 2016 09:32:04 UTC