Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Wolfgang Beck <> Tue, 18 October 2011 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74A7111E80D1 for <>; Mon, 17 Oct 2011 22:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 99XwVwejQZtK for <>; Mon, 17 Oct 2011 22:58:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 411E111E80D0 for <>; Mon, 17 Oct 2011 22:58:56 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so288354ggn.31 for <>; Mon, 17 Oct 2011 22:58:55 -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=HP6B9uYGlWrHCPzWsHVFS0ldBgsjWdprLxSFSUG0eaM=; b=DGpmpgfWLH3hkjZZBZFCJjvawtLCiV9g8uYFP+IOZ0rqfZAmaK7S4LgN+Vvg/Y0MSE W2V80qIHFpeNiybVejwHhcpiX7vw3LM7RBgIpDudnFVvVw3F40jJmPSVCRDGk7syO1CY i+VrGT6iI8Q0W4m/MdrM+NO9lKR5tpfbgqCys=
MIME-Version: 1.0
Received: by with SMTP id s7mr2687291pbk.33.1318917535233; Mon, 17 Oct 2011 22:58:55 -0700 (PDT)
Received: by with HTTP; Mon, 17 Oct 2011 22:58:55 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 18 Oct 2011 07:58:55 +0200
Message-ID: <>
From: Wolfgang Beck <>
To: Randell Jesup <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Tue, 18 Oct 2011 05:58:57 -0000

> You're making the argument that no federation is needed, because to contact
> someone on stackexchange you'd browse to stackexchange first.
> I don't think that handles the use-cases of, from within say gmail, you try
> to call someone on Stackexchange - or even more unavoidable, you try to
> invite someone from stackexchange to join your already-running call.  You
> can't exit out and load the stackexchange JS client.
Good point. Browsers have iframes and tabs in which I can render web
pages of different
sites in parallel. The browser has to deal with the case when more
than one JS client
tries to access the microphone or speaker.

Your first case is easy. I simply open a new tab or window and make the call.
Consultation calling should be easy, too: I have two browser windows,
one with party B, one
with party C. I could talk to them in turns by simply switching between windows.
Conferencing would require that the browser can move media streams
between its JS instances.

I'll go through this old list of IN services and check where my model fails.

I still refuse to understand RTCWEB as a MEGACO with javascript syntax..