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

[Iñaki Baz Castillo <[e-mail]>]

2011/10/18 Harald Alvestrand <[e-mail]>:
>> 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
<[e-mail]>