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

Justin Uberti said:

"Since actpass/active/passive are SDPisms, we decided to adopt the DTLS terminology of client/server.

Note that holdconn has no meaning in the DTLS environment, and actpass can be simulated by initially acting as a server, but then changing to a client if the other side says it wants to be the server."

Roman said:
"From what I can see there is no way to change the role for RTCDtlsTransport. Does it mean it will always start in auto and then switch to client/server based on the start call? "
"

[BA] We have RTCDtlsTransport.getLocalParameters() but no .setLocalParameters().  Since we have:

dictionary RTCDtlsParameters {
    RTCDtlsRole                  role = "auto";
    sequence<RTCDtlsFingerprint> fingerprints;
};

This means that getLocalParameters.RTCDtlsRole is always initially set to "auto" (DTLS role determined based on resolved ICE role).  However, the ICE role isn't resolved until RTCIceTransport.start() is called.

However, in the sample code examples (e.g. Section 4.4) RTCIceTransport.start() isn't called until after the capabilities are exchanged.

So at least in the sample code, the only possible value of RTCDtlsTransport.getLocalParameters.RTCDtlsRole exchanged between peers is "auto".

Presumably after the signaling is done, RTCIceTransport.start() is called.  After that point, it becomes possible for DTLS packets to flow between the peers (and also for RTCDtlsRole to change, reflecting the resolved ICE role).

Roman also said:

Second question, would RTCDtlsTransport accept DTLS packets before the start call? Currently, with SDP, an offer is sent with actpass, the client waits for answer, but will accept DTLS handshake packets, which will switch it into server mode. If answer is received which forces a client setup role, DTLS transport is reset and handshake is restarted as a client. Is this something supported by the current setup?

[BA] My assumption is that RTCIceGatherer needs to accept ICE connectivity checks before RTCIceTransport.start() is called (or even before an RTCIceTransport is constructed).  Similarly, it seems to me that RTCDtlsTransport needs to accept DTLS packets before RTCDtlsTransport.start() is called.  Note that by the time the RTCDtlsTransport receives a DTLS packet, the ICE role will have been resolved.  In theory, a peer with a resolved role of "client" should not be receiving incoming DTLS packets, since that would imply that the remote peer has a resolved role of "server" and yet is behaving like a "client".  But then the question is "what happens?"  Does the RTCDtlsRole change to reflect what is going on in the DTLS negotiation?