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

Wolfgang Beck <wolfgang.beck01@googlemail.com> Tue, 08 November 2011 09:43 UTC

Return-Path: <wolfgang.beck01@googlemail.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 5E0CB21F8CCA for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 01:43:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.931
X-Spam-Level:
X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Cd6dx0a28-YJ for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 01:43:10 -0800 (PST)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id AD32821F8CC8 for <rtcweb@ietf.org>; Tue, 8 Nov 2011 01:43:10 -0800 (PST)
Received: by pzk4 with SMTP id 4so953467pzk.9 for <rtcweb@ietf.org>; Tue, 08 Nov 2011 01:43:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o5jNpkgVZHHP4Mg+GMn0bPpVx2dSITA9ZdISQ8ZWfwg=; b=XsRWub1p6RzdPg/y0UmNYKWuAgSaFoRV/LcM/lR5EDbPNddSNcyHIPBO17Zvq1B0De LvGWrUGQkXtNpLGsByTCCysfL/lAHXMy5ogye7ktDFD6uZujarS+sJVWbUduDzIKi1AG PRahCXNyeMkfkDTiTftlssw9KvOnmlffdm214=
MIME-Version: 1.0
Received: by 10.68.52.134 with SMTP id t6mr6422322pbo.96.1320745390385; Tue, 08 Nov 2011 01:43:10 -0800 (PST)
Received: by 10.68.64.66 with HTTP; Tue, 8 Nov 2011 01:43:10 -0800 (PST)
In-Reply-To: <4EB816D1.1040708@jesup.org>
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> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> <CAAJUQMjcoR+epj03GWyAmZbdLPt87KHACEGH7oQubaGm7CTZUQ@mail.gmail.com> <4EB816D1.1040708@jesup.org>
Date: Tue, 8 Nov 2011 10:43:10 +0100
Message-ID: <CAAJUQMjEErTx-kinq+j06q8Us+nvZcwpXiDnO7_6=Z9DUV4+ng@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: 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, 08 Nov 2011 09:43:11 -0000

On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
> On 11/7/2011 11:53 AM, Wolfgang Beck wrote:
>>
>> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand<harald@alvestrand.no>
>>  wrote:
>> [on SIP-style forking]
[..]
> And I disagree with Harald here; telling the clients they should open
> connections to the "caller" is exactly what parallel forking by the server
> does.  It tells them "here's the offer and ICE candidates, open a connection
> to the "caller" and complete negotiation."  It'd be silly not to include the
> OFFER in the message to the "callee's", since we have to send them the ICE
> candidates anyways - plus, the "callee's" may need that info for alerting,
> etc, and not providing it would add more round-trips.  Never forget that
> even half-round-trips can be PAINFUL to some applications!  And don't forget
> that this might get used on links that bounce off a satellite (or two!), or
> transit low-bandwidth wireless networks or mesh networks, etc.  Now there's
> RTT... ;-)
>
If you are on satellite links, the signaling round trip time is not
your most pressing problem.

Is forking really essential or is it just a way to optimize call setup
time under certain conditions?
Has forking still an advantage if you want to do multiple early media?

[suppressing a remark how overlap dialing could speed up call setup
times in some interop scenarios, too]


Wolfgang Beck