Re: Issue 167: DTLS role versus RFC 4145 SDP setup attribute

Robin Raymond said: 

"I think this suggestion is reasonable. It adds a bit of complexity though. Not too much for my liking but I think that’s worth pointing out that it does… I agree it would be more robust."

[BA] Below is an attempt to encapsulate your suggestions and those of Roman and Inaki.  Comments welcome. 

Addition to Section 2.3.2: 
While a newly constructed RTCDtlsTransport must listen for incoming DTLS packets before start() is called, to complete the negotiation it is necessary to verify the remote fingerprint, which is dependent on remoteParameters, passed to start().

Revised text for RTCDtlsRole:

RTCDtlsRole indicates the role of the DTLS transport.

auto	
The DTLS role is determined based on the resolved ICE role: the 'controlled' role acts as the DTLS client, the 'controlling' role acts as the DTLS server. Since RTCDtlsRole is initialized to "auto" on construction of an RTCDtlsTransport, transport.getLocalParameters().RTCDtlsRole will have an initial value of "auto".

client	
The DTLS client role. A transition to "client" will occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "server". If RTCDtlsRole had previously had a value of "server" (e.g. due to the RTCDtlsTransport having previously received packets from a DTLS client), then the DTLS session is reset prior to transitioning to the "client" role.

server	
The DTLS server role. If RTCDtlsRole has a value of "auto" and a DTLS client initiates a connection, RTCDtlsRole will transition to "server", even before start() is called. A transition from "auto" to "server" will also occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "client".

Question:  Do we need an RTCDtlsRoleChangedEvent?

Received on Friday, 9 January 2015 22:36:32 UTC