Re: [rtcweb] Proposal for PeerConnection cloning

[Randell Jesup <[e-mail]>]

On 5/7/2012 2:22 AM, Christer Holmberg wrote:
>>
>> If you want to support the usecase I suggested, where a single offer can result in parallel forking, but where you don't
>> want to lock down to a single answerer: then you obviously need to support forking, and likely you need/want to support
>> it irrespective of the 'final' state of the original PeerConnection.  You *can* require cloning before the final answer is
>> applied, though I would argue that you don't gain much by doing so.
>>
>> So this is the usecase: you send a single offer (say to a conference server controller, or to a game server) and you get
>> a separate answer from each other endpoint, such as in a mesh conference, or who are in the same 'area' of the game,
>> or in hearing (at that moment) in a VR environment.  You might get these answers well after the initial answer or burst
>> of answers.
> Yes. And, my idea would be that each of those answers are provided to the browser as PRE_ANSWERS.
>
> Then, at some point, you decide that you are not going to accept any more answers, and you provide an ANSWER to one of the (C)PCs, which will release all other associated (C)PCs.

Sorry, I think you missed the point: the application wants to end up 
with N connected, active PeerConnections, not one.  This is a mesh 
conference (for example), not a central-mixer conference.  And for added 
fun, we don't necessarily know there won't be more coming later, perhaps 
much later (but that's a possibly-separable feature).

-- 
Randell Jesup
[e-mail]