Re: [rtcweb] Current state of signaling discussion

Hadriel Kaplan <> Tue, 18 October 2011 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 431ED1F0C76 for <>; Tue, 18 Oct 2011 14:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVEHPwGSlDNl for <>; Tue, 18 Oct 2011 14:53:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0209F1F0C7A for <>; Tue, 18 Oct 2011 14:53:04 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 18 Oct 2011 17:53:00 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 17:53:00 -0400
From: Hadriel Kaplan <>
To: Eric Rescorla <>
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjeBN9USwkyocF0KQH5G/+0/FIA==
Date: Tue, 18 Oct 2011 21:52:59 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 21:53:06 -0000

On Oct 18, 2011, at 5:18 PM, Eric Rescorla wrote:

> One might already have much of this stuff in your application to support
> whatever person-to-person communications (E.g., IM) you already
> have. When I heard "20 lines of code" I always assumed that it excluded that
> sort of routing-type stuff.

But that's the point exactly - OF COURSE that type of stuff might already be in your application, and could be conveyed in a URL or all be implicit or whatever.  Or it might not at all be in your app and need to added for this in some way.  

And that's the point many of us have been making: don't define a standard signaling protocol, because it's all application-specific to the web-app, which only the web-app developer would possibly know.

Thus, I'm asking the chairs what they mean when they use the word "signaling".  If they mean session signaling, then ROAP doesn't do it either.  If they only mean media-setup+negotiation signaling, that's a different problem scope. (I think that too is unnecessary, but if you put full SDP offer/answer state in the browser, then it's probably a fait accompli)