Re: ICE freezing and Bandwidth Estimation

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.

Received on Thursday, 24 May 2018 01:10:38 UTC