Re: [rtcweb] Proposal for PeerConnection cloning

[Randell Jesup <[e-mail]>]

On 5/6/2012 4:40 PM, Ejzak, Richard P (Richard) wrote:
> Hi Christer,
> Question 1: I agree that for parallel forking, as long as a PC is cloned before the unused parent resources are released, it is not necessary to allow cloning later.  I would be ok to remove this feature.  I threw it in because it seemed not too expensive to implement (others have to comment on this) and it might be useful to allow delaying of cloning to the last possible instant (and for potentially other applications).

> Question 2: I do not think we want to automatically remove all related PCs when one gets a final answer, else we could not support Partha's nested O/A scenario.  I propose that this be done manually (so it is not mentioned in the proposal).  This allows ICE and DTLS to progress independently with multiple targets until a winner is selected and the others are closed.

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.

Using CPC, the sequence would be to:  ClonePeerConnection(), apply the 
new answer to the new CPC-created PeerConnection.  Nothing requires you 
to do so; you can reject the new answerer because you have a final 
already (or if the PeerConnection was made speculatively, you could 
close them if any other one of the clones received an answer).  I 
*think* that CPC will reduce the amount of ICE traffic (in some cases) 
and the number of external ports used (depending on NATs), and therefore 
might reduce call setup-time overhead.

Without CPC, the server will need to be able to ask endpoints to 
generate offers in anticipation of using later, or even immediately 
("send me an offer *now* to forward to the new user, or "send me 8 more 
offers just like that one to send of existing users").

p.s. Thanks for the concrete proposal about how to handle this!  We've 
been talking about it (on occasion) for a year-ish, but no one has 
proposed an actual set of semantics for it.

>
> BR, Richard
>
> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Sunday, May 06, 2012 2:01 PM
> To: Ejzak, Richard P (Richard); [e-mail]
> Subject: RE: [rtcweb] Proposal for PeerConnection cloning
>
> Hi Richard,
>
> Interesting proposal.
>
> In bullet 11, you say that, if a final answer has been received (and unused resources released), resources would have to be reallocated once a clone is created.
>
> A couple of questions:
>
> 1. Is there a need to allow cloning once a final answer has been received?
>
> 2. Once a final answer is received on a given PC, would it automatically remove all associated CPCs?
>
> The basic question is really whether there is a need for clones once a final answer has been received. After all, there is a reason we call it "final" :)
>
> Regards,
>
> Christer
>
> ________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Ejzak, Richard P (Richard) [[e-mail]]
> Sent: Sunday, May 06, 2012 9:54 PM
> To: [e-mail]
> Subject: [rtcweb] Proposal for PeerConnection cloning
>
> Harald asked for a proposal for PeerConnection cloning, so here it goes:
>
> I propose to create a new constructor "ClonePeerConnection" (CPC below) with the following semantics.
>
>
>   1.  CPC will create a new PeerConnection object when successful.  The resulting PC behaves just like any other PC except as described below.
>   2.  CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration or IceCallback parameters).
>   3.  CPC can clone any other PC (including a cloned PC).  The sequence of cloning is not important and parents have no particular status different from any generation of clone.
>   4.  CPC will fail if either the local description of the parent PC is not set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state.  The parent PC can be in the OPENING or ACTIVE state.
>   5.  The CPC object will inherit the local streams, local ICE candidates, and local description of the PC.
>   6.  The remote streams and remote description for the CPC object will be set to empty.
>   7.  The CPC object will be set to the OPENING state to reflect that only the local description is set.
>   8.  The ICE states other than CLOSED and GATHERING will be handled independently for each PC and its clones (as is true in standard forking scenarios).
>   9.  The ICE state for this clone will be set to ICE_WAITING to reflect that all candidates are available but the remote configuration is not yet set.
>   10. The PC and its clone(s) use a common pool of media resources.
>   11. If the parent PC object has already released unused resources (final ANSWER), resources are reallocated as available to reflect the capabilities for each stream (as they would be reflected in a createOffer).
>   12. The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.
>   13. The application should manage the directionality attributes for remote streams from different targets to avoid resource conflicts.
>
> CPC will be used primarily if forking is anticipated or actually occurs.  It can also be used to clone a stable PC if desired for other reasons.  When used for SIP forking, creation of the clone can be delayed until an ANSWER actually arrives from a 2nd target as long as final ANSWER hasn't been applied to the parent (PRANSWER is OK).  The parent always handles the first target; the first clone handles the 2nd target; etc.  The application can even try to clone for forking after the first ANSWER is applied to the parent and resources are released, as long as the local description has not changed, at the risk that some resources needed for the 2nd target are no longer available and must be renegotiated.
>
> Comments on this proposal are welcome.
>
> Richard

-- 
Randell Jesup
[e-mail]