Re: [rtcweb] Proposal for PeerConnection cloning

Randell Jesup <> Mon, 07 May 2012 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 485E621F84E7 for <>; Mon, 7 May 2012 00:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.069
X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B3LKXYXx4pLv for <>; Mon, 7 May 2012 00:37:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 690B921F84E2 for <>; Mon, 7 May 2012 00:37:33 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1SRIVg-0002vu-6K for; Mon, 07 May 2012 02:37:32 -0500
Message-ID: <>
Date: Mon, 07 May 2012 03:36:23 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Proposal for PeerConnection cloning
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 May 2012 07:37:34 -0000

On 5/7/2012 3:08 AM, Christer Holmberg wrote:
> Hi,
>>>> If you want to support the usecase I suggested, where a single offer
>>>> can result in parallel forking, but where you don't want to lock down
>>>> to a single answerer: then you obviously need to support forking, and
>>>> likely you need/want to support it irrespective of the 'final' state of the original PeerConnection.  You *can* require cloning before the final answer is applied, though I would argue that you don't gain much by doing so.
>>>> So this is the usecase: you send a single offer (say to a conference
>>>> server controller, or to a game server) and you get a separate answer
>>>> from each other endpoint, such as in a mesh conference, or who are in
>>>> the same 'area' of the game, or in hearing (at that moment) in a VR environment.  You might get these answers well after the initial answer or burst of answers.
>>> Yes. And, my idea would be that each of those answers are provided to the browser as PRE_ANSWERS.
>>> Then, at some point, you decide that you are not going to accept any more answers, and you provide an ANSWER to one of the (C)PCs, which will release all other associated (C)PCs.
>> Sorry, I think you missed the point: the application wants to end up with N connected, active PeerConnections, not one.  This is a
>> mesh conference (for example), not a central-mixer conference.  And for added fun, we don't necessarily know there won't be more
>> coming later, perhaps much later (but that's a possibly-separable feature).
> Speaking in SIP terms, I don't think it is possible to implement mesh conference that way, because clients will normally, once they've received one 200 OK, ACK+BYE any additional ones. Or, a forking proxy will CANCEL all other forked legs once a 200 OK has been forwarded on one of them.

Why would SIP come into this?  Yes, classic PSTN telecom is focused on 
endpoint to one other connection, and any form of more complex 
arrangement is implemented with a mixing server or equivalent, and thus 
SIP flows are designed with that assumption in mind.  However, we are 
NOT constrained to mirror SIP, and we should be able to build 
applications that go beyond what SIP makes easy to do.

I gave some direct use-cases we've talked about since the beginning or 
near: Mesh conferencing, multiplayer games - where parallel forking 
(without collapse to a single session/connection) is desirable/useful.  
If there's an equally-usable way to implement those cases avoiding 
cloning, please detail that.  I think cloning makes initiation of these 
sorts of mesh connections much simpler.

Randell Jesup