Re: [rtcweb] Proposal for PeerConnection cloning

Randell Jesup <randell-ietf@jesup.org> Mon, 07 May 2012 13:45 UTC

Return-Path: <randell-ietf@jesup.org>
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 39C5221F864E for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 06:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599]
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 ZwncGIHU57M3 for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 06:45:57 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9921F8652 for <rtcweb@ietf.org>; Mon, 7 May 2012 06:45:55 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SROGA-0000iv-4b for rtcweb@ietf.org; Mon, 07 May 2012 08:45:54 -0500
Message-ID: <4FA7D1CC.3070004@jesup.org>
Date: Mon, 07 May 2012 09:44:44 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: rtcweb@ietf.org
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> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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 13:45:58 -0000

On 5/7/2012 8:31 AM, Ejzak, Richard P (Richard) wrote:
> Hi Christer,
> As I mentioned in a previous response to you, you cannot mandate that clones be cleared out once a final ANSWER is applied since that prevents you from applying independent offer/answer sequences to each clone (as required in some SIP scenarios).  The optional "cleanup" indicator you propose to associate with final ANSWER will not work in the case where a final ANSWER has already been applied to a clone to allow another offer/answer sequence on that clone before a final "winner" is selected.  I would prefer to just clean up the "losers" manually or create a new method for this.

It doesn't have to be via this mechanism, but we could have an onfinal 
notification, or a manually polled jsepState checked (on all 
PeerConnections the app has) after installing an answer on one.  (Unless 
the app knows that all it has are clones, in which case it could just 
kill off the others).  jsepState is probably all that is needed (and 
probably needed even with onfinal, unless it gives a list of all clones 
of a finalized PC).

-- 
Randell Jesup
randell-ietf@jesup.org