IETF Logo Mail Archive

Re: [rtcweb] Proposal for PeerConnection cloning

Iñaki Baz Castillo <ibc@aliax.net> Mon, 07 May 2012 13:12 UTC

Return-Path: <ibc@aliax.net>
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 EF83A21F85FF for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 06:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level:
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 3SV9yWS8dczD for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 06:12:32 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCAB21F85F6 for <rtcweb@ietf.org>; Mon, 7 May 2012 06:12:32 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so65023vbb.31 for <rtcweb@ietf.org>; Mon, 07 May 2012 06:12:31 -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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Olk/Ib2k6zXoXeeQcZT3K4JjT22ZfBf3uMQ5VHMq05A=; b=hmgm+/lVpTL5rOo5KtkwtSRgWl2TAliU90x2FjTBAh9/eMjNuHZW20QPhcDhMXdzyX NgKtn4ZUr3xIa7IrNzi7O5PDF5GFkc8X7HRiHcFIkvkBl3A1ZzhDeFEH8NDsZAxt7/xa noj7s1HHV9CoPOcmFkIhi9jLoFvi2sXl8dqvCcOxY8xyCnMJPTE423t+RGdqXOCLt8HI AvDcLwWuKTzu7CReHHzeqtPq7MSk9e44U92DB4me4/vHz82URZnR9Yi5mXRiOyx3gQ8T UrCymwh2r7AYuMpFs7kT5GAOc05bVa+9NGlGDhI9u6EL0ecLbcgDzXKzwqWZF4j6L2GE A/zA==
Received: by 10.52.67.208 with SMTP id p16mr1122177vdt.93.1336390416289; Mon, 07 May 2012 04:33:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.107.199 with HTTP; Mon, 7 May 2012 04:33:16 -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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 07 May 2012 13:33:16 +0200
Message-ID: <CALiegfkKsGGqg9QACSf1D4p5PchDB-x19BbM5Osbi5-TGPn66A@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlwR4l9ETlkVPZpLLDEAMcqPW6XuVzr4ctJZsGhhC10fp3sM1cxxT3NI0jjKNlaH9db3Xn5
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 13:12:33 -0000

2012/5/7 Christer Holmberg <christer.holmberg@ericsson.com>:
> 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.

I agree. IMHO it's much better if the API offers a simple mechanism
for building/imitating existing VoIP technologies (i.e. SIP and
XMPP-Jingle). Of course the API could be so powerful that it allows
receiving late responses and use them (something that makes no sense
in SIP world) but giving a simple parameter "just_one_final_response:
true" in the constructor of the first PC, or offering an API function
for discarding all the previous (C)PC's would be nice.

Regards.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.31.3 | Report a Bug | By Email | System Status