Re: [rtcweb] Proposal for PeerConnection cloning

Roman Shpount <roman@telurix.com> Tue, 08 May 2012 13:40 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 4F83221F84F0 for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 06:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level:
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 u4rI-6CiniXc for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 06:40:34 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9E21F847F for <rtcweb@ietf.org>; Tue, 8 May 2012 06:40:34 -0700 (PDT)
Received: by werf13 with SMTP id f13so3408857wer.31 for <rtcweb@ietf.org>; Tue, 08 May 2012 06:40:33 -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=vXNCIMjurtGkfVcH7mdAeS3lCxNyU1o/i2NiMH39+bg=; b=e4wPA9EXS6zaxjlJPae2m1NfbakJH/ZglVvnJ+E5zmFbXX2GSKLmrUVasajvZ/S7fc kwPW/YVzGpGOq2FXi2g3aqSVuDQ/qmxJ2fAPmbpHmfGkyAMbirudazOUWtOlmV7kgAwG m6/8/G/fY8dmtbgbSIVsKAMLE5wXECs485dFYy2/s2oWgtQobm6ywMsADwYqilH43qIS W0jxX+KtZBFYrvFdroR8AMIzHx0wqVpezNtQtVssMU1DpSj047OrBazpkooXfVqTGtBq ddie4iIfaFq6SmnVI62ne4lLt2USjAhgJ3boo7oeDTkUqMq9UPUuAA+6L0Eyy8O2yb+D B+jg==
Received: by 10.180.89.9 with SMTP id bk9mr44804049wib.11.1336484433532; Tue, 08 May 2012 06:40:33 -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 fo7sm27784807wib.9.2012.05.08.06.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 06:40:31 -0700 (PDT)
Received: by bkty8 with SMTP id y8so5586705bkt.31 for <rtcweb@ietf.org>; Tue, 08 May 2012 06:40:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.157.144 with SMTP id b16mr6995701bkx.12.1336484430625; Tue, 08 May 2012 06:40:30 -0700 (PDT)
Received: by 10.205.117.146 with HTTP; Tue, 8 May 2012 06:40:30 -0700 (PDT)
In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <CAD5OKxsLLPquzWwNSJCUnysD6-KT8FfnM4=N7PjhZkWLunZ2Xw@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
Date: Tue, 08 May 2012 09:40:30 -0400
Message-ID: <CAD5OKxt7asQ2g33T3V3KW=7MR0oR46UJSCYxHAY33Mhjetvdyg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="0015175cd0dabc3c2304bf868771"
X-Gm-Message-State: ALoCoQk0GMjFunjlMIzaUih2stPx/EjIMML7IhamzNXaluiloIBMCTyLZaO+C8dTFiUxMUjy9TLc
Cc: "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: Tue, 08 May 2012 13:40:35 -0000

On Mon, May 7, 2012 at 10:10 PM, Ejzak, Richard P (Richard) <
richard.ejzak@alcatel-lucent.com> wrote:

>  You raise a good point since some candidates may be released before
> cloning occurs.  So this is another bug in the procedure.  I would suggest
> that the configuration also be passed to the CPC and that if any of the
> required candidates are released before cloning occurs that they be
> reallocated.****
>
> ** **
>
> Alternately, we could recommend that candidates be kept allocated longer
> than usual and that if cloning is attempted after any of the candidates are
> released then the cloning procedure fails.****
>
> ** **
>
> The latter approach should be sufficient for SIP forking scenarios, but
> others may prefer the generality of the former.  Or maybe both?  Any votes?
> ****
>
> ** **
>

My suggestion was that instead of the clone method to have a method that
returns reference to the offer object. This separate object holds the
candidates while references to it exist. When this object is passed during
creation of peer connection, peer connection is initialized as a clone of
an existing peer connection This way application has the explicit control
of the ICE candidate lifetimes. I would think this would be the most
flexible.
_____________
Roman Shpount