Re: [rtcweb] Another consideration about signaling

Ted Hardie <> Mon, 10 October 2011 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B063E21F8B2D for <>; Mon, 10 Oct 2011 11:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n5WP3-Xs-qAG for <>; Mon, 10 Oct 2011 11:51:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 737B721F8AF8 for <>; Mon, 10 Oct 2011 11:51:03 -0700 (PDT)
Received: by ywm3 with SMTP id 3so7003411ywm.31 for <>; Mon, 10 Oct 2011 11:51:03 -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; bh=ftDqjOBLUpFTXSk2HqulcOSOr/+DUaWtgJEiaeEhEU8=; b=lvXBSWSXd4H9P6JophE9x2/30ej0Lu+lW/dS6a1smQTNomr+Qv4x0gSqtwQl0U7/gC 48m/tSf5HVnymTnJOC55BRssM0CvOjflCd8b2APWNoPLtcBonAv4g9aygW/styU4oy68 2CjdruO4efiMR/vO8sEPm8fGwVHlDPF5Tg4bY=
MIME-Version: 1.0
Received: by with SMTP id f47mr25521710yhn.125.1318272662954; Mon, 10 Oct 2011 11:51:02 -0700 (PDT)
Received: by with HTTP; Mon, 10 Oct 2011 11:51:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Mon, 10 Oct 2011 11:51:02 -0700
Message-ID: <>
From: Ted Hardie <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=20cf303f6496cae41804aef64507
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 18:51:07 -0000

On Mon, Oct 10, 2011 at 9:57 AM, Iñaki Baz Castillo <> wrote:

> 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).
Taking off my various hats, I have to say I don't agree.   We're putting
together a system here in which a downloaded application must talk to the
server from which it is downloaded, the local system into which it is
downloaded, and the other endpoints with whom it wants to trade flows.  If
we decline to put any constraint at all on the signaling that goes between
the downdloaded system and the server, we are, in essence, forcing the API
between the downloaded code and the local environment to support any
possible signaling.  Since it is the local environment that will manage
codecs and emit RTP flows, that's a rough ask--especially if it has to
support signaling that might have radically different semantics.

If we agreed on a semantic approach (e.g. solicit/propose or offer/answer),
then the syntactic difference would be, I admit, largely a matter of taste.
I would see no real reason not to have a baseline syntax, but I would
probably agree to it being pseudo code of some sort.  But if we have no
agreed on *semantics* for the signaling, then the API between the downloaded
code and the  local system is unbounded.  That doesn't tend to make for
stable systems or interoperability.

If you must gateway between systems (something I agree is not job one),
unbounded semantics would also imply arbitrary complexity in the gateways.
Again, not good for stability or deployability.

Lastly, there are also some security issues here.  I had a chat with Jon
Peterson last week about why SIP identity went down the road it did
(something that, honestly, had always been a bit puzzling to me).  As he
walked me through it, one of the comments he made struck me as particularly
important:  if you are going to expect that you know who you are talking to
by anything other than the assertion of the intermediary, you must provide
both an assurance of identity and an assurance of the media path
destinations.  I'm not sure we do want this, honestly; the intermediaries in
our system are powerful enough that trying to provide anything better than
SSH-style identify may be foolish.  But if we do, we need a common method of
describing those destinations in order to get a common method of assuring
them.  That's a long, long way down the road to common signaling syntax;
having that without common semantics seems liable to some pretty funky

I am, personally, far from convinced that having no constraints on the
signaling is worth imposing unbounded complexity on the Javascrip/Browser
API and any gateway systems, as well as circumscribing our security
choices.  It may seem to be a dazzling amount of freedom, but it is only one
part of the system, and it ought to play well with others.

Just my personal opinion,

Ted Hardie