W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling)

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Tue, 18 Oct 2011 13:18:59 +0200
Message-ID: <CALiegfkPk=o0YvmUCocmUOeL_hp37UogeYkv9vE=KQqQESRcKg@mail.gmail.com>
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.


Iñaki Baz Castillo
Received on Tuesday, 18 October 2011 11:19:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:22 UTC