W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

Re: ICE freezing and Bandwidth Estimation

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 25 May 2018 05:59:55 +1000
Message-ID: <CAHp8n2=61ieAkbH3hpSJO_4k2St=cidxCh3k39tZm9ju72aVLA@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Peter Thatcher <pthatcher@google.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.

>
Received on Thursday, 24 May 2018 20:00:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC