- From: Anant Narayanan <anant@mozilla.com>
- Date: Tue, 19 Jul 2011 10:24:58 -0700
- To: public-webrtc@w3.org
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
Received on Tuesday, 19 July 2011 19:50:07 UTC