Subject: [Wish] Comments about draft-murillo-whip

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 31 Jul 2021 02:52:32 +0200

I made four comments at today's meeting, the last one unplanned.

1. The current draft allows the server to refuse trickle ICE and ICE
   restarts.

I think this is backwards -- it makes the server's life easy, at the cost
of requiring every single client to implement two fallback paths.  This
will lead to every single client having to implement fallback paths, which
will receive little testing and probably be buggy.  The result is that
every server will need to implement ICE restarts and trickle ICE, but the
client implementers will still worry about the fallbacks.

I suggest we put the requirement of the server to support trickle ICE and
ICE restarts, which will make the clients significantly simpler.  I am
fairly confident that server implementers will have no problem with that.

If that is not an option, then I support Lorenzo's suggestion to make it
possible for the client to discover in advance whether the server supports
trickle ICE.  However, this is plan B -- it is both simpler and more
efficient to require support for trickle and restarts from all WHIP servers.

2. We need a reference client

I'm quite willing to implement support for WHIP in Galene, and I'm sure
that so are a number of other server implementers.  In order to test
interoperability, we need a reference client that does not depend on 42
different GUI libraries.

3. Screensharing on mobile is the killer app

Most WebRTC servers have a competent web interface (Galene is an exception,
our web client sucks).  In order to make WHIP popular, we need a killer app.

Adam has spoken about broadcast, I'm not sure that's likely to make WHIP
widely known.  I think that screensharing on iPads and Android tablets is
the application that is likely to be useful to large numbers of people.

If you're competent at iOS or Android, please make a small app that shares
your tablet over WHIP.  A number of my colleagues will be grateful.

4. Communicate ICE servers to the client

On networks that block UDP, or networks that only allow UDP to selected
ports, a TURN server is necessary.

Some WHIP clients will come with a preconfigured TURN server.  Others,
however, will need to learn a working ICE configuration from the server.
As Sergio has noted, this information needs to be available before the
first WHIP offer.

In order to be useful in restrictrive environments, WHIP needs to be able
to communicate a list of ICE servers before the first offer.

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 10:27:52 +0200

Regarding trickle ICE support, note that media servers may not require to
be signaled the new candidates to do ICE trickle. If the media server ports
are reachable to the client, it can learn directly the new candidates from
the stun requests received.

Anyway, it would be trivial for those servers to accept the htto request
and ignore the contents. So we can make it mandatory.

What I am not in favor of making ice restart mandatory on server side, so a
media server should be able to reject the restart. That would cause the
client to trigger a new session from scratch.

Best regards
Sergio

El sáb., 31 jul. 2021 2:52, Juliusz Chroboczek <[email-masked]> escribió:

> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 31 Jul 2021 14:30:08 +0200

> Regarding trickle ICE support, note that media servers may not require to be
> signaled the new candidates to do ICE trickle. If the media server ports are
> reachable to the client, it can learn directly the new candidates from the
> stun requests received.
> 
> Anyway, it would be trivial for those servers to accept the htto request and
> ignore the contents. So we can make it mandatory.

Ok.

> media server should be able to reject the restart. That would cause the client
> to trigger a new session from scratch.

That's okay, restarting the RTP session should not be prohibitive, but it
still involves having two paths in the client, one of which will receive
very little testing.

Sergio, could you please explain what it is that you are worried about?
Servers using WebRTC libraries that don't support restarts?  Or something
else?

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 14:40:13 +0200

El sáb., 31 jul. 2021 14:30, Juliusz Chroboczek <[email-masked]> escribió:

> and

For example i don't support ice restart. I understand that for a
conferencing service which has a lots 9f tracks opened in both ways,
restarting all the conferencing state would be cumbersome.

But when you have a single unidirectional stream, doing a full session
restart is not much more cumbersome than the ice restart.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 14:43:56 +0200

> restart is not much more cumbersome than the ice restart.

Also, side question, the client should gather the turn server credentials
and update the peerconection configuration before doing the ice restart to
ensure that the short term credentials have not expired, right?

Best regards
Sergio