Subject: Re: [Wish] New draft changes

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 4 Oct 2021 12:33:53 +0200

El jue, 30 sept 2021 a las 14:26, Juliusz Chroboczek (<[email-masked]>)
escribió:

> Thanks a lot for your work, Sergio.
>
> > If the WHIP client gathers additional candidates (via STUN/TURN) after
> > the SDP offer is sent, it MUST send a STUN request
>
> I'm confused about this requirement.
>
> Suppose that the client gathers an initial set of candidates and gets the
> media flowing.  The ICE gatherer is still running in the background, and
> produces new (presumably useless) candidates.  What needs to be done with
> these candidates in order to satisfy the requirement above?
>

Send a new STUN request from the new gathered candidates to the server
ones. This is the standard behaviour anyway, so not sure if we should
remove the phrase to avoid confusion.

>
> > As the HTTP PATCH request sent by a WHIP client may be received out of
> > order by the WHIP resource, the WHIP resource MUST keep track of the
> > previous values of the ICE username fragment and client used by the WHIP
> > client. If an HTTP PATCH request is received with a previously used ICE
> > username fragment and password by the client, the WHIP endpoint SHALL
> > not perform and ICE restart but reject the request with a 409 Conflict
> > response instead.
>
> Is there consensus for this approach?  It's not too onerous to implement,
> but it requires potentially unbounded amounts of server-side per-session
> state, which is always error-prone and difficult to debug.
>

We could relax the MUST to SHOULD.

>
> Presumably, the client knows whether it's requesting an ICE restart or
> trickling a candidate.  How difficult would it be for clients to
> explicitly indicate whether an SDP fragment requests an ICE restart,
> perhaps in an HTTP header or a custom SDP attribute?
>

We would need to extend the ABNF grammar of the sdp fragment and change the
mechanisms in RFC8840.

I am ok with that, but not sure if we are allowed to do that.

> > WHIP clients SHALL support HTTP redirection via the 307 Temporary
> > Redirect response code.
>
> Does this requirement apply to both the WHIP and the resource endpoint, or
> just to the WHIP endpoint?  I'm fine with either alternative, but I think
> this should be made explicit.
>

I think this should be only applicable to the initial WHIP request. The url
of the whip resource should be a final one.

>
> > the WHIP endpoint SHALL
>
> This document uses both MUST and SHALL, which, as far as I recall, mean
> the same thing.  I feel it would be less confusing if MUST were used
> everywhere.
>

Fine for me too, not sure what are the best editorial practices though.

>
> > The WHIP Endpoing SHALL gather all the ICE candidates
>
> Typo.
>

Thanks, fixed!

Best regards
Sergio

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 06 Oct 2021 17:52:07 +0200

> This is the standard behaviour anyway, so not sure if we should remove the
> phrase to avoid confusion.

Yes, please remove it.

> We could relax the MUST to SHOULD.

I'm not sure how that would work.  If the server receives an SDP fragment,
and cannot distinguish between an ICE restart and an out-of-order ICE
candidate, how should it behave?

> I am ok with that, but not sure if we are allowed to do that.

Alternatively, we could encode the information in a custom HTTP header, or
as a query in the URL.  I don't understand REST well, and I'm not sure what
the consequences are.

-- Juliusz