- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Tue, 18 Oct 2011 13:18:59 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Roman Shpount <roman@telurix.com>, Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
2011/10/18 Harald Alvestrand <harald@alvestrand.no>: >> Said that, I strongly like your option 2 "Creating a new >> PeerConnectionFactoryWithOffer". If I understand it properly, when a >> RTCweb environment allows media forking, the RTCweb client should >> create a PeerConnectionFactoryWithOffer object rather than a >> PeerConnection. Then it sends the offer over the wire. Upon receipt of >> each response with different ROAP/SDP answer, the object would >> internally generate different PeerConnection objects (but the state of >> all of them are governed by the PeerConnectionFactoryWithOffer >> object). Am I right? > > Yes, that's right. > > One advantage of this approach is that the new class comes in addition to > the normal PeerConnection class, so the interface for this functionality > does not clutter up the interface for applications that don't want to deal > with forking; they just never create such objects, and will reply to > subsequent answers with "ERROR" (as they're always free to do). I like the idea. > There are a number of additional details that need specification before this > can be implemented, of course; we might want to delay that functionality > beyond the first wave of releases. As you noted, the point is that this advanced feature can be added later over the existing stack. So I support this proposal. Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Tuesday, 18 October 2011 11:19:28 UTC