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

[Sergio Garcia Murillo <[e-mail]>]

El vie, 28 may 2021 a las 14:43, Juliusz Chroboczek (<[e-mail]>)
escribió:

> > https://datatracker.ietf.org/doc/html/draft-murillo-whip-01
>
> Thanks.  Is anyone implementing a client to test against?
>

Implementing a WHIP client is trivially simple in web, you can check an
example here for the previous version:

https://medooze.medium.com/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7


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

A WHIP endpoint is an entity able to receive the HTTP POST request from a
client. The URL may be a "factory" one returning an unique url on the
Location header or have an unique URL for each stream. It is up to the
server implementation.

In any way, the WHIP resource URL must uniquely identify the flow.


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

That would be the same as having a normal webrtc client with no STUN/TURN
servers configured against one that have them, right?


>
> Have you actually implemented that?  How much surgery to your ICE stack
> was required?  In short, how painful was it?
>
>
I do ICE lite on servers, so I had to do nothing.. :)

In case you need to do full ice on the server and you don't have a way of
statically specifying the public ip address or requires collecting TURN
relay candidates, your server will have to delay sending the 201 response
with the SDP answer when all the candidates are collected.



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

Clients can trickle ICE normally. Anyway, on my implementation, I don't
even require to exchange candidates with the server in that case as the
server will learn the new candidates from the STUN requests sent by the
client.


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

That is the semantically correct method for updating a resource in HTTP:
https://datatracker.ietf.org/doc/html/rfc5789#page-4

2 <https://datatracker.ietf.org/doc/html/rfc5789#section-2>.  The PATCH Method

   The PATCH method requests that a set of changes described in the
   request entity be applied to the resource identified by the Request-
   URI.  The set of changes is represented in a format called a "patch
   document" identified by a media type



>
> > 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.
>
>
 I would say that a server should be either able to work in full ice, or
not require the trickle candidate exchange at all to not have to ask the
client to implement a fallback mode. In this case, the server may just
reject the PATCH request without any consecuence.

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

Yes, that's the rationale.

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

I don't think we should allow HTTP basic usage. Anyway, I am open to
discuss it.

Best regards
Sergio