Subject: [Wish] New draft changes

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Sep 2021 12:16:31 +0200

Hi all,

I have been working on adding the feedback received since the publication
of the first WHIP draft as well as the issues found during the initial
implementations:

https://raw.githubusercontent.com/wish-wg/webrtc-http-ingest-protocol/master/draft-ietf-wish-whip.md

Please, review it to see if I have missed any feedback that should be
included in the next version of the draft.

Best regards
Sergio

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 21 Sep 2021 12:27:02 +0200

On Tue, 21 Sep 2021 12:16:31 +0200
Sergio Garcia Murillo <[email-masked]> wrote:

> Hi all,
> 
> I have been working on adding the feedback received since the
> publication of the first WHIP draft as well as the issues found
> during the initial implementations:
> 

I had some problems figuring out the specific changes, so I crafted a
diff url from the last 9th June version, that I'm sharing in case it
will be of help to others too:

https://github.com/wish-wg/webrtc-http-ingest-protocol/compare/56112c8..47d8ab5

I'll have a look and provide feedback ASAP, thanks!
Lorenzo

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Sep 2021 12:43:32 +0200

Thanks Lorenzo!

Probably using the rich view would be even easier to follow the changes:

https://github.com/wish-wg/webrtc-http-ingest-protocol/compare/56112c8..47d8ab5?short_path=6ca9ae6#diff-6ca9ae63875a605dbaf6d8e45c08b5945951d62135ae0661065b7fe9ebb04d84

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 21 Sep 2021 13:30:39 +0200

On Tue, 21 Sep 2021 12:43:32 +0200

> https://github.com/wish-wg/webrtc-http-ingest-protocol/compare/56112c8..47d8ab5?short_path=6ca9ae6#diff-6ca9ae63875a605dbaf6d8e45c08b5945951d62135ae0661065b7fe9ebb04d84

That's much more readable than mine, thanks!

Lorenzo

> 
> El mar, 21 sept 2021 a las 12:27, Lorenzo Miniero
> (<[email-masked]>) escribió:
> 
> > > Please, review it to see if I have missed any feedback that
> > > should be included in the next version of the draft.
> > >
> > > Best regards
> > > Sergio  
> >
> >
> > I had some problems figuring out the specific changes, so I crafted
> > a diff url from the last 9th June version, that I'm sharing in case
> > it will be of help to others too:
> >
> >

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 30 Sep 2021 14:26:11 +0200

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?

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

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?

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

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

> The WHIP Endpoing SHALL gather all the ICE candidates

Typo.

Thanks again,

-- Juliusz