Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Wolfgang Beck <> Mon, 24 October 2011 11:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2A9221F8C22 for <>; Mon, 24 Oct 2011 04:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1AeGcqb+1Ozw for <>; Mon, 24 Oct 2011 04:33:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D7B2B21F8C1E for <>; Mon, 24 Oct 2011 04:33:11 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so6807077ggn.31 for <>; Mon, 24 Oct 2011 04:33:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OU0j+FCyM7Dh9zYAatXMX3b4pCYPTwaLAAjGEQdIbq0=; b=U1oHz4oPAaC47yiEtg0jyzRkTUBLEfr9ohKVjCP4hGAJM2pzdMUfHQTO4QTfjoPoS4 1lBuUGUork/4heV+OYtH76dxDofdvrbxxe28Nf7hazVdDewNEQLhYxNUorXwgUdRfJeZ Z9N65AWD3hfhe92yhq9qeFNrcqziA8/1hYeQo=
MIME-Version: 1.0
Received: by with SMTP id o5mr48499106pbh.9.1319455991215; Mon, 24 Oct 2011 04:33:11 -0700 (PDT)
Received: by with HTTP; Mon, 24 Oct 2011 04:33:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 24 Oct 2011 13:33:10 +0200
Message-ID: <>
From: Wolfgang Beck <>
To: Iñaki Baz Castillo <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <>,
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Oct 2011 11:33:12 -0000

On Mon, Oct 24, 2011 at 12:38 PM, Iñaki Baz Castillo <> wrote:
> Hi Wolfgang. When you send a text message via Facebook or via Twitter,
> can you check later all those messages *together* in some "messages
> history" section within your browser? If the answer is not (and it is
> not), why do you expect that it should be different for calls?
Sure with text message it is difficult to have a local history. But it
is different for voice/video calls.
Very few phones routinely store the entire call. A browser
implementation could do this, just like
it provides bookmark and browsing history functions.

> Also, what do you expect such "call history" to show you? In case you
> make an audio call in Facebook its entry in the call-history list
> would display your Facebook id as originator and the receiver Facebook
> user as destination. But in case you join a web game in which RTCweb
> is used for *automatically* receive audio from other gamers, what do
> you expect the entry in the call-history to display?
My point was to show Randell that the single server model can provide
phone book and call history
functions if you need this. Either through the browser itself or
through some extra web site.

Even the trapezoid model can't guarantee that a phone book/call
history will always work
as expected. If a caller decides to suppress her caller ID, you'll
just see that someone unknown called.
If you call some company's number you can't be sure that you will be
connected to the same phone that
you reached during your last call.

If we stick to the trapezoid model, the intra-server protocol will be
a serious barrier to innovation. If you need something that doesn't
translate well to and from SIP, it won't work between your different
JS applications. Tunneling a protocol through SIP just shifts the
problem to this new protocol, which would need to be standardized as