Re: ICE freezing and Bandwidth Estimation

On Thu., 24 May 2018, 11:14 am Bernard Aboba, <Bernard.Aboba@microsoft.com>
wrote:

> On May 23, 2018, at 16:49, Peter Thatcher <pthatcher@google.com> wrote:
> >
> > I'm not saying anyone would do it, because it's kind of madness.  But
> it's a theoretically-possible madness.
> >
> > Here's a simple proof:  we know that unbundled m-lines can have
> transports connected to different hosts (with different DTLS certs, etc).
> And those hosts can be browsers, and those browsers would be different
> PeerConnections.
> >
> > The congestion control might not work well, but ICE will.
>
> [BA] In a small conference use case, it is common for a browser to have
> multiple PeerConnections, each to a different mesh participant.  Since many
> conferences are in practice small (less than 4 participants), this is quite
> a practical scenario.
>
> An expeditious way to establish such a mesh conference is to send an Offer
> that can be responded to by multiple mesh participants (e.g. broadcast the
> Offer to a Room, and have other participants respond to the Offerer) so
> that the conference can get started in a single RTT.  Requirements:
>
> a. Support for parallel forking.  This is what lead to the
> IceGather/IceTransport separation in ORTC.
> b. Need to be able to construct multiple DtlsTransports from the same
> local certificate.
> c. Need to restrict aggregate outgoing bandwidth for all mesh connections.
>

What's the advantage of this over sending multiple offers in parallel in
JavaScript (asynch)? In my opinion this is needlessly complicating things -
you need to manage the connection with each endpoint separately anyway.

Just my 2c worth...

Cheers,
Silvia.

>