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

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

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

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

I have opened a new issue for handling that:
https://github.com/murillo128/webrtc-http-ingest-protocol/issues/10


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

Initially my idea was to not include stun/turn configuration on WHIP/WISH
and let the end user configure it manually. However, I see the value of
trying to cover that part too.

Providing the ice servers urls on the WHIP request is not possible, as it
would have to already have created the peerconnection to retrieve the SDP
offer, so maybe it is time to bring back to live Justin's proposal:
https://datatracker.ietf.org/doc/html/draft-uberti-behave-turn-rest-00


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

Yes.

Best regards
Sergio