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

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

On Mon, Feb 6, 2023 at 12:29 PM Juliusz Chroboczek <[e-mail]> wrote:

> > We have already discussed about this in here:
> > https://github.com/wish-wg/webrtc-http-ingest-protocol/issues/66
>
> Sorry to bring it up again.
>
> > 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);
>
> I don't understand how that can work.  By the time ICE gathering is
> started (by createOffer), it is too late to change the ICE configuration.
>

Can you point me to where in th3 spec it describes that the ice gathering
phase is started in the createOffer. JSEP states the contrary:

https://www.rfc-editor.org/rfc/rfc8829.html#section-4.1.8-5
Calling this method may do things such as generating new ICE credentials,
but it does not change the PeerConnection state, trigger candidate
gathering, or cause media to start or stop flowing. Specifically, the offer
is not applied, and does not become the pending local description, until
setLocalDescription is called.

This is from the SLD in JSEP:

When a local description is supplied and the number of transports currently
in use does not match the number of transports needed by the local
description,
 the PeerConnection will create transports as needed and begin gathering
candidates for each transport, using ones from the candidate pool if
available.


>
> > This is guaranteed to work on all JSEP compatible clients.
>
> I'm probably mistaken, but I was under the impression that you need an ICE
> restart for the new configuration to have any effect.  Could you please
> present your evidence that that is not the case?
>

What kind of evidence do you need?


>
> >     2. No way to discover whether Trickle ICE is available
>
> [...]
>
> > 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.
>
> Could you please explain what happens if the client is behind a firewall
> that only allows outgoing TCP traffic, and only to a small set of
> well-known ports, which is sadly the case in many university networks?
>
>
Note that I am talking about the ICE trickle part, that is, sending the ICE
relay candidates from the client to the server, not the relay turn
allocation itself.

In this case, the client will send a STUN binding request through the TUR
UDP relay port to the signaled ICE candidates by the server on the SDP
answer. The media server will receive the binding request (as there is no
need to do hole punching) and the ICE session will be established normally.

Best regards
Sergio