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

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 <jch@irif.fr> escribió:

> 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
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>