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

[Juliusz Chroboczek <[e-mail]>]

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

It was not clear to me that there are two URLs, the "WHIP Endpoint URL"
and the "WHIP Resource URL".  Everything is clear now.

> How do you think it should be further explained?

Perhaps the fact that there are two distinct URLs could be stated in
Section 3?

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

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

How did the client acquire the TURN server's address and credentials in
the first place?  You're assuming that this has happened out of band
before the first WHIP interaction, by some means not specified by this
protocol, right?

If so, that's fine with me, I just think that it should be stated explicitly.

>     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] regardless if the

Aha, I see.  You're assuming that either the server is accessible from the
Internet, or it implements trickling of client candidates.

Makes perfect sense, thanks.

-- Juliusz