Re: [rtcweb] Another consideration about signaling

Iñaki Baz Castillo <> Mon, 10 October 2011 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21B7321F8B84 for <>; Mon, 10 Oct 2011 09:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.604, 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 OeSoQ0O9+iCs for <>; Mon, 10 Oct 2011 09:57:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 912CA21F8B80 for <>; Mon, 10 Oct 2011 09:57:51 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so5932722vcb.31 for <>; Mon, 10 Oct 2011 09:57:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id br10mr1441735vcb.41.1318265871023; Mon, 10 Oct 2011 09:57:51 -0700 (PDT)
Received: by with HTTP; Mon, 10 Oct 2011 09:57:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 10 Oct 2011 18:57:50 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: "Kevin P. Fleming" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
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, 10 Oct 2011 16:57:52 -0000

2011/10/10 Kevin P. Fleming <>om>:
> That's correct; the only reason I brought it up is that the choice of SIP as
> the RTCWEB signaling protocol, or something else, does not impact this at
> all. Choosing Jingle does not make this easier for the web application
> developer, and choosing SIP does not make it harder... in either case, they
> either *are* the signaling endpoint at the server end, or they aren't.
> Originally you had stated that if SIP was chosen, it would make this sort of
> application harder to build, because the application would not be likely to
> implement a SIP UA itself, and so it wouldn't have access to the session
> state information.

Not exactly, I meant that, in case the browser speaks *native* SIP
with a centralized SIP proxy, then it would be hard to get sessions
information in the web server (as it would require some custom and
complex communication with the SIP proxy). The same if it's a XMPP
server or whatever.

But if the signaling is carried via HTTP or WebSocket, the siteadmin
can choose to pass all the signaling through the web server so it
would be fully aware of the sessions status.

So I meant the server rather than the client. The client, of course,
must know the sessions he is involved in :)

> I'm not advocating that SIP be chosen... but for entirely different reasons

The fact is that nobody advocates for a specific signaling protocol
(well, just a person which insists and insists...). We need no default
signaling protocol at all, but just freedom for each siteadmin to
provide the signaling protocol it desired (of course, it should be
carried via HTTP or WebSocket, as those protocols are the ones that a
webbrowser can speak being controlled via JavaScript).


Iñaki Baz Castillo