IETF Logo Mail Archive

Re: [rtcweb] Let's define the purpose of WebRTC

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 15 November 2011 00:44 UTC

Return-Path: <matthew.kaufman@skype.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 380F721F8E3E for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 1m8ty2zBjDnI for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:44:37 -0800 (PST)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 45CEB21F8E39 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 16:44:37 -0800 (PST)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 911CA16F5; Tue, 15 Nov 2011 01:44:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=xUsvqZmMB7/Yok O55s0SuLfGBaU=; b=SvCI9GxaXhIKTuaoLFdIMLlX9OEEQg+HlNoBlvMOA3fFE2 Nnvsz8SIaB74V9/1934CpzG5L87MCfabgX8Gn035pTiEaQ6gK5wLWIbq5OVymfib uBbCcPGRHo0qYuIfmcZGDVdvEsUEWkYcCC7TcfOBb50AVORaj+G1y5dQXX2qs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=ONXuA4vimpfyQiklhNGolb qsSOwW2XF3U3xfgiHaUkQNU/2mefZ2VlKWGPmWyW+zJx13vVV/imGKErYdLzib7L sCX29EtdXlSBhymPb5dxEj+g0ikCQH7gUg/dzy7jFLZPcAdEdS8aGbW6sEaxFJ8N p95UgjEmotVbUZBktm6NA=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8F9327EB; Tue, 15 Nov 2011 01:44:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 4982A1672681; Tue, 15 Nov 2011 01:44:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oncwlDhnR9p; Tue, 15 Nov 2011 01:44:35 +0100 (CET)
Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id A7B2F3506E8F; Tue, 15 Nov 2011 01:44:33 +0100 (CET)
Message-ID: <4EC1B5F1.1090604@skype.net>
Date: Tue, 15 Nov 2011 08:44:33 +0800
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Iñaki Baz Castillo <ibc@aliax.net>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxt=k_Mon_GMs1w-bGMgpk12h6ZQ=FkoRVsTp4271iMSLA@mail.gmail.com> <CABcZeBNMTgwH-R_jd-AiEJ8tELTeFMNm-bAJohRg2RxD5e+kZQ@mail.gmail.com> <CAD6AjGRBmrAqB3CEWxtaXnryPA5App13S2jJPAt+7HwWZsQFzA@mail.gmail.com> <CABcZeBNtoizuRymVMxF4CdiLu1Nju63C0xkWJHjoarpxeLXjyA@mail.gmail.com> <CALiegfk=oJJ20GhKQBKA7aspHhUyQ-s+DR-qSi4XV455Nj718w@mail.gmail.com> <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <CAAJUQMihjTRgpO8hjgiYz5iLbWTncdXFO8nnRE9VDRND36-b2w@mail.gmail.com> <CALiegfmhst-2anmO1HMO1MVp=GFEjqOoG50wVKKMQic3AjxUsA@mail.gmail.com>
In-Reply-To: <CALiegfmhst-2anmO1HMO1MVp=GFEjqOoG50wVKKMQic3AjxUsA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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, 15 Nov 2011 00:44:38 -0000

On 11/7/11 11:50 PM, Iñaki Baz Castillo wrote:
> 2011/11/7 Wolfgang Beck<wolfgang.beck01@googlemail.com>:
>
>> Do you really need forking to achieve this? Couldn't you just return
>> references to those devices back to the caller
>> which can then decide how to call them? A redirect server instead of a
>> forking proxy?
> That's a limitation rather than a simplification, and would make lot
> of scenarios just harder. Don't think just in SIP. Any future *pure*
> WebRTC scenario could desire to fork a call into multiple N
> destinations without making the *JavaScript* client code to deal with
> N different sessions.
>
>
Why *wouldn't* you want the JavaScript client code to participate in 
this decision?

Matthew Kaufman

v2.23.0 | Report a Bug | By Email