Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received

[Randell Jesup <[e-mail]>]

On 4/1/2012 11:21 PM, Justin Uberti wrote:

>     If the API provides a method where you can clone a current
>     peerConnection you can actually share the transport layer information at
>     one end-point for multiple peer connections assuming that the other
>     end-points transport addresses are different between the different
>     peerConnections being cloned.
>
>     This works as the complete ICE username is the concatenation of both
>     sides, as long as an secondary answer contains a different username and
>     has candidates with different transport addresses (address+port). Then
>     end-point A receiving the second answer can have the ICE stack accept
>     both usernames and if connectivity checks works then you create
>     different 5-tuple filter to divide any media streams to the right peer
>     connections media handler.


> Thanks Magnus. This sounds reasonable; it might even be possible to make
> cloning work using the existing API by taking the local description from
> one PC and installing it as the local description for a new PC; the
> browser could recognize that the candidates refer to existing ports and
> behave as you mention above.

Yes, this seems like it would work.

> However, given that this seems to be mostly an edge case, I think we can
> probably save this for v2.

So the question for me is "what scenarios/use-cases does this enable?"

1) Mesh Conferencing

While there are many ways to handle conferencing, if you have a mesh 
(full or partial), you need to create new PeerConnections for existing 
members of the mesh when someone joins.  There are two ways to do this:
a) somehow application-specific tell the new member who to send invites 
to, and then start N PeerConnection calls with some "I'm in the 
conference" token;
b)have them send N separate generic invites to the service provider 
which either forwards it to an existing member, or returns it with "it's 
ok, I've already forwarded invites for it);
c) somehow tell all the existing members to invite the new member; or
d) have the service provider fork the OFFER from the new member to all 
the existing members, and have all of them reply with ANSWERs.  This 
requires PeerConnection cloning to work well.

I strongly prefer d), and it also reduces conference join time (less 
round-trips, at least in theory - perhaps noticeably less by sharing the 
ICE candidate generation).

2) "Hanging" invites at a service provider

You send an OFFER, which is "held" at the service provider and then 
"forked"/forwarded to other clients when the server decides to.

This is of use in cases where there is external state (a game, virtual 
environment ala Second Life, virtual conference hall, etc) where 
something at the server decides when you should actually be connected 
and to whom (or multiple people).  Example (applies to several of 
these): as you move around a game/virtual-environment, your app is 
connected to other nearby players when they're in audible range.  This 
could be done by having the server tell your client to generate an OFFER 
(with attendant ICE discovery delay) on demand for each other person who 
comes in range, but that would be sub-optimal and again involve setup 
delay.  It also allows permission to be dealt-with up front and not 
delay actual connection.

I imagine there are others, but those are two which I think are pretty 
likely uses (we've been talking mesh conferences since the beginning, 
and this sort of environmental audio/teamspeak type stuff is an obvious 
use).  Our game-table demo showed chess, but other uses would involve 
more players (4 for bridge, etc) where you might want a full-mesh 
conference).

So, I'd really like to push to support cloning if possible.

-- 
Randell Jesup
[e-mail]