Re: ICE freezing and Bandwidth Estimation

On 05/24/2018 01:44 AM, Peter Thatcher 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. 

I think that doing so with browsers would require you to rewrite the SDP
between the initiating and responding browsers so that the two
responding browsers each see only the m-line they're responsible for
replying on, and you would have to reassemble the response from those
two browsers in order to have something to pass to setRemoteDescription
on the intiating browser.

And the resulting response would have two different a=fingerprint
fields, of course - should be ok, since it's mux-class TRANSPORT.
But has it been tested?

These are the kinds of issues that make me ask "has this actually been
done successfully".

>
> The congestion control might not work well, but ICE will.  
>
>
> On Wed, May 23, 2018 at 12:15 PM Harald Alvestrand
> <harald@alvestrand.no <mailto: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.
>
>
>