Re: [rtcweb] Proposal for PeerConnection cloning

[Harald Alvestrand <[e-mail]>]

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 2^nd 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 
> 2^nd 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 2^nd target are no longer 
> available and must be renegotiated.
>
> Comments on this proposal are welcome.
>
> Richard
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb