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

[Randell Jesup <[e-mail]>]

On 4/9/2012 7:02 AM, Harald Alvestrand wrote:
> 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".

Right, and there would be complication when a new "hanging offer" hadn't 
yet been sent when another member joins (and it would be very easy for 
bugs to creep in there, as it's evil race-condition testing).  "hanging 
offers" is not a protocol that I would like to implement.

> 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).

And removes a whole passel of error paths and handling.

> 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?

This certainly needs investigation; I could see it needing some type of 
occasional "still holding it" notification from the server anyways to 
keep the state active in the client.


-- 
Randell Jesup
[e-mail]