Re: [rtcweb] Proposal for PeerConnection cloning

Roman Shpount <roman@telurix.com> Mon, 07 May 2012 16:18 UTC

Return-Path: <roman@telurix.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 ED59C21F8631 for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 09:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.879
X-Spam-Level:
X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 aWvYSKmvWIt9 for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 09:18:17 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F621F85D6 for <rtcweb@ietf.org>; Mon, 7 May 2012 09:18:16 -0700 (PDT)
Received: by wgbds11 with SMTP id ds11so1442028wgb.1 for <rtcweb@ietf.org>; Mon, 07 May 2012 09:18:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wbtj3Ak1V79YOvQ8m6fPNTNpOry7OwUzJkKLuPCyCUs=; b=MhBvAAoWmKTWAinLIbIGzOhzezAj7BOVfP4YUoVGK0UqQdTh1SgkopkIm3wegL01Gl 7iyOyUK5kJM7MJY5VR16QnQys3iQzSMzalzcbFiTokzLPpfOqA32rABwq2STU6LnlX2q OFJdMF/xQtS8X85mtFuH0fmxmh6ffAt53V/XyzgaVgcOrnxs5M+/GnohuoHFuGbiRLaP rGRfCVGgoO6ZFPh01u40M6RXiwR4Yy4b+pcsbtaaA/VncO+In4MObHeL6JH4MkvPvaEp uH72tv3esmMO3EFPxfJoBvY1F2YnS1NxgzpcAeRolrJz7Jeg9uyqr5P+yucwyuzFuM3R ceRA==
Received: by 10.180.99.72 with SMTP id eo8mr35841073wib.10.1336407495822; Mon, 07 May 2012 09:18:15 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id j3sm35491577wiw.1.2012.05.07.09.18.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 09:18:15 -0700 (PDT)
Received: by bkty8 with SMTP id y8so4674438bkt.31 for <rtcweb@ietf.org>; Mon, 07 May 2012 09:18:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.155.69 with SMTP id r5mr5581475bkw.67.1336407493588; Mon, 07 May 2012 09:18:13 -0700 (PDT)
Received: by 10.205.117.146 with HTTP; Mon, 7 May 2012 09:18:13 -0700 (PDT)
In-Reply-To: <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> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se>
Date: Mon, 07 May 2012 12:18:13 -0400
Message-ID: <CAD5OKxvRxhVaLBscL3a4vYzTYCqwPqh4_ENEdHrRcOZ6gDFnmA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="0015175cfd18ee37c304bf749dad"
X-Gm-Message-State: ALoCoQmYLoEysZkLraEvIFXoyZX7fjW2fsi/Nb6iFjd/pr8YraoxmTh4qf8A4FREOH5nlQgq7eHs
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
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 16:18:18 -0000

On Mon, May 7, 2012 at 6:58 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> > 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.
>
>
First of all, even in classic SIP use case, proxy will not hang up or
cancel other call legs when 200 OK is received. You can setup a mesh
conference this way if your end point supports this. Most of the end points
do not, so they hang up the calls, but I have dealt with a few that
actually start multiple calls this way and allow user to switch between
them or conference them together.

Second, you do need to be able to provide a final answer on the primary or
cloned peer connection to implement Partha's scenario, since for this
scenario you need to process another O/A while the original O/A is still in
progress. This means you need to provide a final response on the call leg
where you received the offer, but still be able to receive answers on other
call legs.

_____________
Roman Shpount