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

[Harald Alvestrand <[e-mail]>]

On 04/02/2012 07:22 PM, Randell Jesup wrote:
> 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).

Hmm.... for one new member, I don't think d) is actually different from 
the case where the client sends an "extra" OFFER when he joins, and the 
server uses the "hanging OFFER" to signal the new member.
This is a windowing protocol, though - the client would need to send a 
new "hanging OFFER" after the current "hanging OFFER" has been "used 
up". Cloning allows you to connect multiple new conference mebers as 
fast as the Javascript can accept them. (Which may have issues with 
congestion, but that might be a price worth paying).

It's not clear to me whether hanging OFFERs work with NAT traversal; 
would the ICE machine send keepalives for an association that hasn't 
been associated yet?

                    Harald