Re: [rtcweb] JSEP: Why always offer actpass?

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> >     o  The endpoint MUST use the setup attribute defined in [RFC4145
> <https://tools.ietf.org/html/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).
> 
> The section quoted seem to refer to the initial offer/answer, later in
> that document (section 6.6, with heading "Session Modification") there
> is wording that (to me at least) hints at keeping the established roles
> in subsequent offers.
> 
> A different question is the value of initially offering actpass when ICE
> is mandatory to use. ICE connectivity checks will happen before the DTLS
> handshake, so perhaps initially offering passive would make sense.
> (actpass is a MUST according to 5763, OTOH 5763 is only an informal ref
> to JSEP.)

<Raju>
Limiting it to "passive" would force the peer and/or intermediaries to support DTLS client functionality as well. IMHO, this may limit the success rate. If a peer or middlebox does not support DTLS client functionality then it can always return "passive", which may involve bit more delay in DTLS setup. But it is not that bad as the SDP offerer must wait for SDP answer (a=fingerprint is needed) before the DTLS can be setup successfully anyway.
</Raju>

BR
Raju