Re: Moz/Cisco API proposal: multiple connections

On 7/13/11 12:51 PM, Ian Hickson wrote:
>> To me the most natural way would be to have one PeerConnection object
>> per peer. Then, if the same set of streams are sent to each peer, of
>> course there should be only one encoding, framing, packetization etc.
>> But this is an optimization that can be handled in the implementation,
>> and need not to be visible at the JS API level.
>
> I tend to agree. The only reason I would see to have PeerConnection have
> built-in knowledge of multiple peers is if ICE supported such a thing.
> However, I can't find anything in the relevant RFCs about 1:many
> processing in ICE agents.

ICE inherently does not support 1:many, but yes you use ICE for each 
peer to establish a unique PeerConnection with every other peer.

There's no reason that the PeerConnection object has to map the 
underlying ICE negotiation exactly, but even if it does, our 
PeerConnection factory proposal (PeerListener) allows for a web 
developer to express his intent to create multiple PeerConnection 
objects. In other words, it makes it easier for the developer to 
establish a 1:many stream without having to create each PeerConnection 
individually.

-Anant