Re: [rtcweb] Proposal for PeerConnection cloning

[Harald Alvestrand <[e-mail]>]

On 05/07/2012 03:44 PM, Randell Jesup wrote:
> On 5/7/2012 8:31 AM, Ejzak, Richard P (Richard) wrote:
>> Hi Christer,
>> As I mentioned in a previous response to you, you cannot mandate that 
>> clones be cleared out once a final ANSWER is applied since that 
>> prevents you from applying independent offer/answer sequences to each 
>> clone (as required in some SIP scenarios).  The optional "cleanup" 
>> indicator you propose to associate with final ANSWER will not work in 
>> the case where a final ANSWER has already been applied to a clone to 
>> allow another offer/answer sequence on that clone before a final 
>> "winner" is selected.  I would prefer to just clean up the "losers" 
>> manually or create a new method for this.
>
> It doesn't have to be via this mechanism, but we could have an onfinal 
> notification, or a manually polled jsepState checked (on all 
> PeerConnections the app has) after installing an answer on one.  
> (Unless the app knows that all it has are clones, in which case it 
> could just kill off the others).  jsepState is probably all that is 
> needed (and probably needed even with onfinal, unless it gives a list 
> of all clones of a finalized PC).
>
It seems to me that

for each Pc in ClonedConnections {
   if (Pc !== winner)
      Pc.close()
}

is simple enough to code that we should simply say that "the JS has to 
do cleanup when he decides he only wants one of the PeerConnection".

Creating mechanisms for things to happen behind the scenes seems to me 
to make life for the programmer more complex, not less; "why did the 
voice of person 2 go silent? Oh - you applied an ANSWER instead of a 
PR-ANSWER to person 1"....