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

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

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

> > 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.
>
> Perfect.
>
> Could you please spell out the exact protocol you envision?  The server
> replies 200 with the SDP answer and a Location header, or the server
> replies 308 which causes the client to send the SDP offer again?
>
> This requires special-case handling in the client (candidates and restarts
> need to be sent to the right endpoint, not to the multiplexer), so please
> spell it out in the draft.
>

It is explicitly stated that the HTTP PATCH request with the sdp fragment
body containing the ICE candidates/restart info must be sent to the WHIP
Resource URI returned on the Location header of the 201 create response to
the original HTTP PUT request.

How do you think it should be further explained?


>
> >> 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.)
>
> > 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.
>
> What happens if the client is on a restrictive network that doesn't allow
> UDP?
>

When the client allocates a relay candidate on the TURN server to connect
on a restricted network, it will send a STUN request via it to the server
host candidates. The server will receive the STUN request and get the relay
candidate info from the remote ip address/port.


>
> >>> 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?
>
> > 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.
>
> Sorry if I'm being obtuse.  Client does trickle, so it sends an SDP offer
> with incomplete candidates.  After contacting its STUN server, it attempts
> to PATCH its offer, and receives 405.
>
> What should the client do in that situation?
>

It is stated on the draft:

   A WHIP client receiving a 405 response for an HTTP PATCH request
   SHALL not send further request for ICE trickle or restart.  If the
   WHIP client gathers additional candidates (via STUN/TURN) after the
   SDP offer is sent, it MUST send STUN request to the ICE candidates
   received from the media server as per [RFC8838
<https://datatracker.ietf.org/doc/html/rfc8838>] regardless if the



Murillo & Gouaillard    Expires November 20, 2021               [Page 5]

------------------------------

Internet-Draft                    whip                          May 2021


   HTTP PATCH is supported by either the WHIP client or the WHIP
   resource.



 Best regards
Sergio