Re: ICE freezing and Bandwidth Estimation

I'm not saying we "remove" freezing. I'm saying we don't do anything in the
WebRTC 2.0/NV API to support it because it's not worth the complexity.

On Mon, May 28, 2018 at 4:33 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> I still fail to see how this is related to removing freezing. Sure, you
> can avoid freezing by using a separate PC for each stream, or to mandate
> BUNDLE, but why would it have to be removed?
>
> Regards,
>
> Christer
>
> From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> Date: Thursday 24 May 2018 at 22:59
> To: Bernard Aboba <Bernard.Aboba@microsoft.com>
> Cc: "pthatcher@google.com" <pthatcher@google.com>, Harald Alvestrand <
> harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
> Subject: Re: ICE freezing and Bandwidth Estimation
> Resent-From: "public-webrtc@w3.org" <public-webrtc@w3.org>
> Resent-Date: Thursday 24 May 2018 at 23:00
>
>
>
> 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.
>
>>