Re: [rtcweb] Proposal for PeerConnection cloning

[Stefan Hakansson LK <[e-mail]>]

On 05/07/2012 11:53 PM, Randell Jesup wrote:
> On 5/7/2012 5:32 PM, Harald Alvestrand wrote:
>> Richard, thank you for doing this! It's definitely the most
>> thought-through proposal I've seen on this question!
>
> Ditto!
>
>>>   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?
>
> I would assume that personally, and that typically after cloning you'd
> do "appropriate" tweaking to new (and old).

As the APIs are designed right now, this is not possible AFAIK. The 
"local streams" is more or less just a list of the streams that has been 
added to the PeerConnection (PC) using "addStream". So if you have one 
PC with one MediaStream added, then clones the PC, the result would be 
that that MediaStream now has two consumers. And if you disable a track, 
that track would be disabled for all consumers.

I think a more flexible solution would be that the new PC does _not_ 
inherit the streams. This way the application can choose to clone the 
MediaStream's attached to the first PC, and add the cloned MS's to the 
new PC, and thereby get independent control of e.g. enable/disable 
state. After all, it is the application that initiates the PC cloning, 
so it knows exactly when it happens and the context, so adding the req. 
to the app to add the stream(s) that should be added would not make it 
more complex IMO.

The possible problem I can see with this approach is that if the set of 
MS's added to the cloned PC is not exactly the same as for the original 
PC, the number of ICE connections needed might not match. But is that 
problem not already there, and must be handled by the ICE agent? The 
cloned PC may connect to an endpoint that does not support multiplexing 
of RTP-streams, or new streams might be added to the cloned PC at any 
time after cloning.

>
>>>   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?
>
> Richard - do you mean "IP Multicast" (tm) or 'multicast' by sending the
> same encoded data to more than one destination in separate RTP streams?
>    (i.e. one encoding being used to simulcast to multiple receivers?)
>
> Simulcast is possible and useful (almost required for Mesh
> Conferencing); IP Multicast has been pretty much ruled out-of-scope IIRC.
>