Re: [Wish] New draft version draft-murillo-whip-01

[Juliusz Chroboczek <[e-mail]>]

> https://datatracker.ietf.org/doc/html/draft-murillo-whip-01

Thanks.  Is anyone implementing a client to test against?

I'm a little confused about how multiple flows are handled.  Is a single
WHIP endpoint able to multiplex multiple flows, or does one WHIP endpoint
correspond to exactly one flow?  If the former, how are ICE restarts and
ICE requests correlated with the flow?  (If the latter, some use cases will
require a dynamic allocation subprotocol.)

> The initial offer by the WHIP client MAY [...] only contain local
> candidates or even an empty list of candidates.

> The WHIP endpoint SDP answer SHALL contain the full list of ICE
> candidates publicly accessible of the media server.

If I read this correctly, you're defining a new, asymmetric form of ICE:
the server collects all local candidates, then allows the client to do
Trickle ICE.  I think it's a good idea, but unless I'm mistaken, that's
a new mode of operation for ICE, one that I haven't seen described in any
other document.

Have you actually implemented that?  How much surgery to your ICE stack
was required?  In short, how painful was it?

On a related note, what happens if the client is on a restrictive network
that doesn't allow UDP?  Are you assuming it has learned the address of
a TURN server out of band, or are you relying on passive TCP candidates?
(Either would be fine, but it needs to be spelled out.)

> The WHIP client MAY perform trickle ICE or an ICE restarts [RFC8863] by
> sending a HTTP PATCH request

Why the uncommon request method?  I find the use of PATCH here suprising.

> A WHIP resource MAY not support either trickle ICE (i.e. ICE lite media
> servers) or ICE restart,

Does the client know beforehand whether that's the case?  For ICE
restarts, that's not a problem (you just attempt an ICE restart, and if
that fails, you tear down the flow and start a new one).

For Trickle ICE, on the other hand, the client needs to know beforehand
whether it can send an incomplete offer and then collect candidates or
whether it must send an offer with a full set of candidates.

Perhaps we could require that a server should reject an offer with
ice-options:trickle unless it can accept further ICE candidates?  That way
a client can fallback to non-trickle operation straight away.

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

I assume that is to simplify client implementations.  A short rationale
would be welcome.

> Authentication and authorization is supported by the Authorization HTTP
> header with a bearer token as per [RFC6750].

Is that a MUST?  What if my server doesn't do OAuth2, do I need to
implement it just to do WISH?  Or can I stick to HTTP Basic?

Thanks again,

-- Juliusz