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

This makes perfect sense to me.
_____________
Roman Shpount

On Wed, Jan 7, 2015 at 4:54 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Here are some thoughts on how interoperation might work with an
> implementation that behaves as described in RFC 5763.
>
>
>
> Let us assume that we have an ORTC API implementation talking over the
> wire to an RFC 5763 implementation.  ICE completes and the ORTC API peer
> ends up being controlling and the RFC 5763 peer is controlled.  At that
> point, does RTCDtlsRole transition to “client” for the ORTC API peer?  What
> if the the ORTC API peer signals a=setup:actpass in SDP and the legacy peer
> answers with a=setup:active and begins a DTLS negotiation with the ORTC API
> peer?
>
>
>
> It seems to me that even before RTCDtlsTransport.start() is called that
> the RTCDtlsTransport object needs to be listening for incoming DTLS
> connections, regardless of the value of RTCDtlsRole.  While it is not
> possible to complete the DTLS negotiation until RTCDtlsTransport.start() is
> called, the incoming DTLS packets can be queued for subsequent processing
> which may depend on the remote parameters passed im the start() call.
>
>
>
> As per this example, if RTCDtlsRole transitions to “client” and
> remoteParameters.RTCDtlsRole also has a value of “client” an exception
> might be thrown.  However, if we don’t insist on an immediate transition of
> RTCDtlsRole prior to calling start() then localParameters.RTCDtlsRole is
> “auto” and remoteParameters.RTCDtlsRole is “client” which could be ok.
>   This way we can both exhibit “auto” behavior when ORTC API peers talks to
> each other as well as interoperating with RFC 5763 clients.
>
>
>
> Does this make sense???
>
>
>
> *From:* Roman Shpount [mailto:roman@telurix.com]
> *Sent:* Tuesday, January 6, 2015 10:27 AM
> *To:* Bernard Aboba
> *Cc:* public-ortc@w3.org
> *Subject:* 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?
>
>
>
>
>
>
>