Re: [rtcweb] Proposal for PeerConnection cloning

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 07 May 2012 10:58 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD11D21F85A8 for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 03:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level:
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+-0RHR4-nbd for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 03:58:25 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8D21F85A7 for <rtcweb@ietf.org>; Mon, 7 May 2012 03:58:24 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-63-4fa7aacd3497
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E4.40.25560.DCAA7AF4; Mon, 7 May 2012 12:58:21 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 7 May 2012 12:58:21 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Mon, 07 May 2012 12:58:19 +0200
Thread-Topic: [rtcweb] Proposal for PeerConnection cloning
Thread-Index: Ac0sJEaKMJOs9oEHT4WtRJmOhKxv1gAG2KQA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se>
References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org>
In-Reply-To: <4FA77B77.1020806@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Proposal for PeerConnection cloning
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2012 10:58:25 -0000

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.

I didn't say you can't do it with CPC, I simply said that you would have issues if doing it with SIP. But, of course you can use whatever protocol on the wire.

Maybe there could be an API parameter to indicate, when a final answer is provided to the browser, whether it should do a CPC "clean-up". It would make life easier for the JS App developers in non-mesh-conf cases.

Regards,

Christer