Re: [rtcweb] Another consideration about signaling

Iñaki Baz Castillo <> Mon, 10 October 2011 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4B5621F8CD0 for <>; Mon, 10 Oct 2011 13:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.275
X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.402, 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 vFD8nqm4Cd6L for <>; Mon, 10 Oct 2011 13:35:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2677021F8CCA for <>; Mon, 10 Oct 2011 13:35:00 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so6152953vcb.31 for <>; Mon, 10 Oct 2011 13:34:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e2mr15173923vdj.52.1318278898305; Mon, 10 Oct 2011 13:34:58 -0700 (PDT)
Received: by with HTTP; Mon, 10 Oct 2011 13:34:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 10 Oct 2011 22:34:58 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Ted Hardie <>
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 20:35:00 -0000

2011/10/10 Ted Hardie <>om>:
> 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.

Hi Ted. We should come to the reality:

This is about establishing media sessions, and this is based on SDP,
and SDP works as follows:

- Alice sends, via some signaling protocol, a SDP offer to Bob.
- Bob prompts the human user and replies a SDP anwser (if it accepts the call).
- After that media session(s) starts.
- At some point, Alice or Both could send a new SDP offer to modify
the session(s) (for example, for adding video, putting on hold or

And that's all. SIP and XMPP/Jingle do that at the end. Both have
different semantics but similar target (exchange SDP information).

That's the only we need to assume for RTCweb.

Iñaki Baz Castillo