Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

Iñaki Baz Castillo <> Mon, 17 October 2011 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13A8B21F87E2 for <>; Mon, 17 Oct 2011 15:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.078, 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 vNeK8sT5wTcc for <>; Mon, 17 Oct 2011 15:41:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7631421F8593 for <>; Mon, 17 Oct 2011 15:41:06 -0700 (PDT)
Received: by vws5 with SMTP id 5so3649584vws.31 for <>; Mon, 17 Oct 2011 15:41:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id m6mr5850765vdv.18.1318891261698; Mon, 17 Oct 2011 15:41:01 -0700 (PDT)
Received: by with HTTP; Mon, 17 Oct 2011 15:41:01 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 18 Oct 2011 00:41:01 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Ravindran Parthasarathi <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Rosenberg <>,,
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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, 17 Oct 2011 22:41:07 -0000

2011/10/18 Ravindran Parthasarathi <>:
> I like your proposed idea as it is going in the direction of having
> "standard" signaling protocol for RTCWeb.

Please Ravindran, don't manipulate mails, text and draft given by
other persons in this WG. The draft *clearly* says:

The protocol specified here defines the state machines, semantic
behaviors, and messages that are exchanged between instances of the
state machines. ***However, it does not specify the actual on-the-wire
transport of these messages.*** Rather, it assumes that the
implementation of this protocol would occur within the browser itself,
and then browser APIs would allow the application's JavaScript to
request creation of messages and insert messages into the state
machine. ***The actual transfer of these messages would be the
responsibility of the web application, and would utilize protocols
such as HTTP and WebSockets.*** To facilitate implementation within a
browser, JSON notation is used to describe the message

No, this is not a draft about a "default signaling protocol" for
RTCweb. Wrong. This is just a protocol for communication between the
JavaScript code and the RTCweb stack in the browser. It does NOT
mandate how the signaling messages are sent on-the-wire.

So this has nothing to do with your insistent proposal of having a
"default signaling protocol" that all the RTCweb clients "should
implement". Sorry.

Iñaki Baz Castillo