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

Wolfgang Beck <> Mon, 07 November 2011 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED36B21F8B5D for <>; Mon, 7 Nov 2011 04:20:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.927
X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 57QY73Iiy9ct for <>; Mon, 7 Nov 2011 04:20:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0905621F8B5C for <>; Mon, 7 Nov 2011 04:20:03 -0800 (PST)
Received: by iaeo4 with SMTP id o4so7379355iae.31 for <>; Mon, 07 Nov 2011 04:20:03 -0800 (PST)
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=tgvR8bnBQwasxkioNl4OMLqesfTg630JgSenAHOBbeE=; b=Oq/2xHqD+1k5wl/1hT1pCY/kNlXZ/RFKzUP1yExaI1YgV70zBXDQaC4ZgwC+uLi5tK IRtJIEGWFp/mf+LeMYm/KOQSR657biTAwQvZH7Ldg9Z76IPyCaNmGjjyY9rLaNbM/ck8 CB5qhvAz1S/hYaOPqqb2n8xuZsQfnZxe4S8EQ=
MIME-Version: 1.0
Received: by with SMTP id o5mr47432066ict.34.1320668403699; Mon, 07 Nov 2011 04:20:03 -0800 (PST)
Received: by with HTTP; Mon, 7 Nov 2011 04:20:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 7 Nov 2011 13:20:03 +0100
Message-ID: <>
From: Wolfgang Beck <>
To: Randell Jesup <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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, 07 Nov 2011 12:20:05 -0000

On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup <> wrote:
> On 11/6/2011 9:01 AM, Tim Panton wrote:
>> [..]
> For example, you mention forking and glare.  Well, I've given very
> non-interop cases of where forking would be useful: contacting someone who
> has 2 desktops, a notebook, a tablet, and a phone all logged into the
> service, or some of the game scenarios, or a very non-standard-SIP-like mesh
> conference using forked invites.
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?

Forking is a good example how interop -- with SIP or with different
RTCWEB apps -- complicates things significantly.

> And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add
> video", and both turning it on.  No interop or SIP required for that to
> cause glare.
If your service requires this function, yes, you're right. It has
nothing to do with SIP and interop.

The question is: does a JS client have to deal with glare handling if
it can exclude conflicting offers by other means. My 'click here to
speak to a human' application might never need this at all.

> And RTP muxing? That's to avoid the startup-delay of having to
> ICE multiple ports (and the funny side-effects if they choose different
> paths).  Yes that does add some requirements to think about for interop;
> that's not subverting the charter or drifting from it.
RTP muxing has little to with RTCWEB. If it is a good thing, SIP and
other protocols using RTP/ICE should profit from it, too.

Wolfgang Beck