Re: [Wish] WG Last Call for draft-ietf-wish-whip

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

Hi Juliusz, see my comments inline below

On Sun, Jan 29, 2023 at 4:11 PM Juliusz Chroboczek <[e-mail]> wrote:

> 1. No reliable way to discover ICE servers
>
> ICE servers are communicated to the client in the answer to the initial
> offer.  I must be missing something, but I believe that by the time the
> offer has been sent, it is too late to update the PeerConnection's
> configuration: for example, if the client uses the W3C WebRTC API, any
> call to pc.setConfiguration will have no effect after ICE gathering has
> started.
>
> A workaround would be to request the list of ICE servers before generating
> the initial offer, but support for doing that is NOT RECOMMENDED (Section
> 4.4
> of the draft).
>
>
We have already discussed about this in here:
https://github.com/wish-wg/webrtc-http-ingest-protocol/issues/66

Basically, the suggested proposal is to use this code flow:

offer = pc.createOffer();
[answer,iceServers] = POST(offer)
pc.setConfigutation({iceServers});
pc.setLocalDescription(offer);
pc.setRemoteDescription(answer);

This is guaranteed to work on all JSEP compatible clients. In fact in
Chrome (IIRC), you can even do the SLD before POST and it would still work.

The only case where it would not work is when the client doesn't support
trickle ICE, but it still supports STUN/TURN, when you want to wait for the
full local description with all the candidates before doing the POST.

In that case, if the media server has publicly addressable ICE candidates,
the WHIP client will be able to successfully connect to the media server
even if NO candidates are signaled on the SDP offer.

So, the only case in which the connection will be unsuccessful is if both
the whip client and the media server are behind restrictive NATs, which is
a very uncommon corner case.



> 2. No way to discover whether Trickle ICE is available
>
> Trickle ICE is optional in the client->server direction.  However, the
> document does not specify what the client is to do if it sends an initial
> offer with only host candidates, and later gathers additional candidates
> only to discover that the server does not support Trickle ICE.
>
> More precisely, the draft does not specify how a client should behave
> after the following exchange:
>
>   C: POST /endpoint
>   S: 201 Created (Location: /resource)
>   C: PATCH /resource
>   S: 405 Not Implemented
>   C: ???
>

Even if the media server doesn't support ICE trickle candidate signaling,
the ICE connection may still be successful, as the media server should
support receiving STUN binding requests from unknown ips:ports as long as
the ice username/fragments are correct.

Trickle ICE is only needed in case that the media server is behind a NAT
and we need to do nat hole punching.

Best regards
Sergio