Re: [rtcweb] Proposal for PeerConnection cloning

Thanks, Harald, Randell.

Question 1: I have no strong opinion on whether each local stream should inherit its parent's state or get reset to a default value, but inheriting the state seems cleaner (today).  It must be possible to control the state of each cloned local stream separately.

Question 2: I should have been more careful in my choice of words.  Randell interpreted my meaning correctly.  My meaning is better indicated with the word "simulcast", as Randell suggests.  I NEVER intended the use of "IP multicast addressing".

Richard

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, May 07, 2012 4:32 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposal for PeerConnection cloning

Richard, thank you for doing this! It's definitely the most thought-through proposal I've seen on this question!

Two questions that are different from what others have raised:

On 05/06/2012 08:54 PM, Ejzak, Richard P (Richard) 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.
when it inherits the local streams, do you assume that unless the JS applies some setting, they will also inherit the "enabled/disabled" state, but that the "enabled/disabled" state can be changed independently for each PeerConnection's local streams after the cloning?

 1.
 2.  The remote streams and remote description for the CPC object will be set to empty.
 3.  The CPC object will be set to the OPENING state to reflect that only the local description is set.
 4.  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).
 5.  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.
 6.  The PC and its clone(s) use a common pool of media resources.
 7.  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).
 8.  The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.
So far, we've stayed away from anything that involves IP multicast. Are you sure it's worth the potential complexity to try to use this here?
Remember that using multicast changes a *lot* of things on both ends of the connections - the sender has to have IP multicast address allocations, he has to decide between SSM and ASM, the recipients have to use a multicast joining protocol, the infrastructure has to be present to carry the multicast groups, we have to have a fallback in case it isn't, the appropriate congestion control protocols are probably different ..... I would prefer to not bring this in scope for this round of WebRTC.
Is there a compelling reason you see for embarking on this particular adventure?

 1.
 2.  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

rtcweb@ietf.org<mailto:rtcweb@ietf.org>

https://www.ietf.org/mailman/listinfo/rtcweb