Re: [rtcweb] Current state of signaling discussion

Iñaki Baz Castillo <> Tue, 18 October 2011 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0671F21F87FA for <>; Tue, 18 Oct 2011 14:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.635
X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, 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 UD-UQBGdU7Ox for <>; Tue, 18 Oct 2011 14:48:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DD6721F87C5 for <>; Tue, 18 Oct 2011 14:48:32 -0700 (PDT)
Received: by vws5 with SMTP id 5so984241vws.31 for <>; Tue, 18 Oct 2011 14:48:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e2mr4343954vdj.52.1318974072653; Tue, 18 Oct 2011 14:41:12 -0700 (PDT)
Received: by with HTTP; Tue, 18 Oct 2011 14:41:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 18 Oct 2011 23:41:12 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Hadriel Kaplan <>
Content-Type: text/plain; charset="UTF-8"
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 21:48:33 -0000

2011/10/18 Hadriel Kaplan <>:
> 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.

Hi Hadriel, if ROAP draft specifies all the points above it becomes an
entire signaling protocol, and AFAIK we don't want that. If I use SIP
over WebSocket I just want (and need) to use SIP for signaling. So the
JS client constructs an INVITE which tells the proxy/server who he
claims to be. The proxy (speaking SIP over WebSocket) acts as a normal
SIP proxy for routing requests and responses, requiring
authentication, performing authorization, registration (or routing the
REGISTER to a pure registrar server behind it...).

So I don't see the need for ROAP to become a on-the-wire signaling
protocol. In fact, I don't support that idea.

I'm happy if ROAP just covers the communication between the JS and the
browser RTCweb stack. How the signaling messages (including the SDP or
"like-SDP") are carried on the wire should be out of the scope of ROAP
(the draft already is defined for being singaling protocol agnostic).


Iñaki Baz Castillo