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

I am not sure that "auto" means that DTLS role is determined based on
resolved ICE role. If it corresponds to actpass, then per RFC 5763 (
https://tools.ietf.org/html/rfc5763#section-5):

The endpoint MUST use the setup attribute defined in [RFC4145].
The endpoint that is the offerer MUST use the setup attribute value of
setup:actpass and be prepared to receive a client_hello before it receives
the answer.  The answerer MUST use either a setup attribute value of
setup:active or setup:passive.  Note that if the answerer uses
setup:passive, then the DTLS handshake will not begin until the answerer is
received, which adds additional latency. setup:active allows the answer and
the DTLS handshake to occur in parallel.  Thus, setup:active is
RECOMMENDED.  Whichever party is active MUST initiate a DTLS handshake by
sending a ClientHello over each flow (host/port quartet).

This also states that client_hello must be processed before answer is
received and RTCDtlsTransport.start is called.

Finally, we need also to deal with forking, where multiple negotiations can
start on the same receiving host/port with different roles.

_____________
Roman Shpount

On Mon, Jan 5, 2015 at 5:08 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  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?
>
>
>
>
>