Subject: [Wish] Setup:active

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Sep 2021 21:00:15 +0200

Hi,

In Section 4.2, I see the following mysterious passage:

   Unlike [RFC5763] a WHIP client MAY use a setup attribute value of
   setup:active in the SDP offer, in which case the WHIP endpoint MUST
   use a setup attribute value of setup:passive in the SDP answer.

After checking 5763, my understanding is that the offerer may choose to
open the DTLS session, while in WebRTC the answerer chooses the party that
opens the session, with the answerer being preferred.  Not a big deal, but
requires some tweaks to WebRTC libraries for use with WHIP, and requires
more testing.

May I most humbly request an explanation of what advantages this is
believed to provide?

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 9 Sep 2021 22:03:59 +0200

The idea is not to force the whip clients to implement both active and
passive DTLS setup in order to reduce the requirements and cost of
implementation. If we do not do that, we take the risk that most clients
will adhoc rtp stacks will only implement the most common one and fail if
the server returns the other mode.

Note that this is a MAY, webrtc clients acting as whip clients can send a
setup:actpass as normal. Also receiving a value different than actpass in
the server side MUST be supported according to JSEP RFC 8829:

Offers from non-JSEP endpoints MAY send other values for "a=setup", in
which case the answer MUST use a value consistent with the value in the
offer.

Best regards
Sergio

El jue, 9 sept 2021 a las 21:00, Juliusz Chroboczek (<[email-masked]>)
escribió:

> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Sep 2021 22:55:43 +0200

> The idea is not to force the whip clients to implement both active and passive
> DTLS setup in order to reduce the requirements and cost of implementation. If
> we do not do that, we take the risk that most clients will adhoc rtp stacks
> will only implement the most common one and fail if the server returns the
> other mode.

Perfectly clear, thanks.  Perhaps this should be explained in the document?

> setup:actpass as normal. Also receiving a value different than actpass in the
> server side MUST be supported according to JSEP RFC 8829:

Ah, so there's nothing special to do, assuming the WebRTC stack is
compliant?  Cool, thanks.

-- Juliusz

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Sep 2021 09:38:34 +0200

FWIW, Chrome was handling this wrong (rejecting a=setup:active) until 
August 18.

https://crbug.com/webrtc/12933 - 95.0.4617.0 was the first version with 
the fix.

So we can say with some confidence that we don't have many clients 
sending "active".