Re: [rtcweb] Proposal for PeerConnection cloning

["Ejzak, Richard P (Richard)" <[e-mail]>]

Hi Martin,
I'm not sure that separating the ICE and media state machines would help very much.  ICE has to handle all the streams and components of a PeerConnection at the same time anyway.

Once cloning occurs, operations on them (in my proposal) are independent except in the sharing of resources allocated to the parent at the time of cloning.

If we accept Christer's simplification then we should never need to fail the cloning operation due to lack of resources.  I didn't think that reporting failure would be a problem (if necessary).

You suggest that creating a separate PeerConnection and "binding" it to the parent is somehow a better alternative for cloning.  I look forward to reviewing an alternative proposal with sufficient detail to make a comparison (as Harald challenged me to do).  I took my best shot and certainly didn't "avoid" any alternatives that I was aware of and thought might be superior.

Richard

________________________________
From: Martin Thomson [mailto:[e-mail]]
Sent: Sunday, May 06, 2012 5:20 PM
To: Ejzak, Richard P (Richard)
Cc: [e-mail]
Subject: Re: [rtcweb] Proposal for PeerConnection cloning


Such a complicated process would not be necessary if the PeerConnection object were not home to two largely independent state machines.

Nor would it be necessary if this scenario were considered out of scope.

Certainly, if you consider the scenario interesting enough to do something about (I don't), then you news some support from the browser in setting up two ICE associations on the same local port, but that is easier without having to worry about the state of the media negotiation.

Let's assume you could have transport and media separate. Then what you need is a clone operation for the transport object. You can simply start the media negotiation, as if from scratch on the cloned transport.

The state of the media has no real bearing on this then, and Christer's concern becomes irrelevant.  ...Though it is certainly valid given the current proposal.

Other considerations:
-does the clone get a copy of local streams if they are added to the original? I'm guessing not.
-the transition from PR_ANSWER to OFFER will be difficult given that this is the obvious way to implement this
-how does the application learn that cloning fails due to lack of resources? Normally, an offer can't include capabilities that cannot be provided, but this implies it.

An alternative, within the constraints offered by JSEP, is to create a new PeerConfection and bind it to an existing one. What reasons can you offer for avoiding this choice?

--Martin
On May 6, 2012 11:54 AM, "Ejzak, Richard P (Richard)" <[e-mail]<mailto:[e-mail]>> wrote:
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


_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb