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

[Juliusz Chroboczek <[e-mail]>]

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

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

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

-- Juliusz