Re: [rtcweb] Current state of signaling discussion

Eric Rescorla <> Tue, 18 October 2011 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6B3D21F8772 for <>; Tue, 18 Oct 2011 13:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.947
X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7QhoN4hGfPkn for <>; Tue, 18 Oct 2011 13:50:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F4B621F84A5 for <>; Tue, 18 Oct 2011 13:50:43 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1110862vcb.31 for <>; Tue, 18 Oct 2011 13:50:41 -0700 (PDT)
Received: by with SMTP id es3mr4278072vdb.63.1318971041112; Tue, 18 Oct 2011 13:50:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Oct 2011 13:50:01 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Tue, 18 Oct 2011 13:50:01 -0700
Message-ID: <>
To: Hadriel Kaplan <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>
Subject: Re: [rtcweb] Current state of signaling discussion
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 20:50:44 -0000

On Tue, Oct 18, 2011 at 1:30 PM, Hadriel Kaplan <> wrote:
> Dear Chairs,
> I have a question of clarification on your request for "signaling" proposals/drafts.
> Which *type* of "signaling" do you mean?  What purpose/problem-solution are these candidate drafts meant to address?
> In the email below, you indicate draft-jennings-rtcweb-signaling is one of the drafts that provides a solution, but as far as I can tell it is not a session signaling protocol; it is just a protocol for SDP offer/answer.  It is not a sufficient solution for sessions, and it admits that within its own text.  It would not, for example, let one write a RTCWeb-based communication application in "20 lines of code".

Is this actually correct? The introduction of that draft suggests otherwise:

"The protocol is designed to operate between two entities (browsers
for example), which exchange messages "directly" - meaning that a
message output by one entity is meant to be directly processed by the
other entity without further modification. In practice, this means
that a web server can treat ROAP messages as opaque and just shuffle
them between browser instances. This allows for simple

If we take the PeerConnection API as our point of reference, isn't the
idea here that
you would instantiate callbacks that take messages coming out of the
API and push them to the Web server and messages coming from the Web server
and push them to the PeerConnection instance. I don't know if this is 20 lines
of code (though with JS minimization it might be one line of code :)),
but it does
seem comparatively trivial...