Re: [rtcweb] Current state of signaling discussion

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2313B21F8BF4 for <>; Tue, 18 Oct 2011 14:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sc6P51BhQOCO for <>; Tue, 18 Oct 2011 14:05:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 815A521F8BDC for <>; Tue, 18 Oct 2011 14:05:05 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 18 Oct 2011 17:05:04 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 17:05:04 -0400
From: Hadriel Kaplan <>
To: Eric Rescorla <>
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjdmb9USwkyocF0KQH5G/+0/FIA==
Date: Tue, 18 Oct 2011 21:05:03 +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:05:06 -0000

In the abstract it states:
"The protocol focuses solely on media negotiation and does not handle call control, call processing, or other functions."

Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignoring "phone" stuff) is fine.

BUT, for an actual session protocol to work for even a gaming app, you need to do the following:
1) determine a target for the ROAP message (ie, who's this OFFER going to in the end?)
2) define how that target identity is conveyed (ie, how does the web server know which browser to give this ROAP OFFER to?)
3) define a source identity model, possibly with authentication (ie, who are you?)
4) define how the source identity is conveyed (ie, how does the server/far-end-browser know who's calling?)
5) define a end-of-session indication
6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply

And I've probably missed some other things.


On Oct 18, 2011, at 4:50 PM, Eric Rescorla wrote:

> 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
> implementations."
> 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
> PeerConnection
> 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...
> -Ekr
> -Ekr