Re: ICE freezing and Bandwidth Estimation

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.


On Wed, May 23, 2018 at 12:15 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 05/23/2018 06:15 PM, Peter Thatcher wrote:
>
> Q4:
>>
>> While the WebRTC device may use different ICE agents for each stream, the
>> remote peer may not. Not sure how/if exactly that would impact things, but
>> it needs to be considered.
>>
>>
> That's already the case today if one side uses one PeerConnection and the
> other side uses multiple PeerConnections.  But given that almost all use of
> ICE is done with 1 components and one stream (because of BUNDLE), and it
> will probably continue to be thus, I think it's best to optimize for the
> overwhelming use case and not worry too much about bizarre scenarios people
> might setup.
>
>
>> Is there a successful example of one side using one PeerConnection and
> the other side using multiple PeerConnections at the same time?
> Offhand, I'd think that would be impossible in WebRTC 1.0, but if there's
> running code out there, I guess I'm wrong.
>
>
>
>