Re: [rtcweb] Current state of signaling discussion

Hadriel Kaplan <> Tue, 18 October 2011 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7291721F8C17 for <>; Tue, 18 Oct 2011 13:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1khnIZseXa6e for <>; Tue, 18 Oct 2011 13:30:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D07B21F8BA0 for <>; Tue, 18 Oct 2011 13:30:10 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 18 Oct 2011 16:30:09 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 16:30:09 -0400
From: Hadriel Kaplan <>
To: "" <>
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjdS59USwkyocF0KQH5G/+0/FIA==
Date: Tue, 18 Oct 2011 20:30:08 +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 20:30:11 -0000

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".

So are you only talking about how to handle media-plane setup between two Browsers? (ie codec negotiation, ICE, etc.)  OR do you mean the whole shebang?

There have been a lot emails floating around the past few days so if I've missed the relevant clarification please excuse the question. (but direct me to the answer :)


On Oct 18, 2011, at 8:55 AM, Magnus Westerlund wrote:

> WG,
> This is an attempt of me as WG chair to try to summarize the state of
> the discussion as it was when I wrote this. As usual please speak up
> against any miss-characterization of the state from my side.
> The Chairs request for identifying who like to provide input for a
> signaling discussion two weeks and to follow up this with a Internet
> draft has resulted in that we now have two drafts.
> a) RTCWeb Offer/Answer Protocol (ROAP)
> b) RTCWeb standard signaling protocol
> We also have a third proposal that want to be included in the
> considerations:
> c) RTCWEB does not define any signaling behavior at all, instead W3C is
> tasked to develop an API that allows the application to establish the
> media session between peers.
> I have as WG chair requested that the proponents for C to produce a
> Internet draft that provides requirements on the API and its capability.
> This is to ensure that this proposal can be properly evaluated. So far
> no such contribution has occurred. Without a willingness from the
> proponents of this style of solution to contribute and evolve their
> thinking in such way that the other WG members can gain a better
> understanding of the implications of this solution I find it difficult
> for us include it in the up coming consensus call.
> We intended to have a phone conference on Friday to enable some direct
> discussion on the topic of signaling between the WG members. Details to
> follow. This is not an interim, only a possibility for the WG members to
> further their understanding in preparation for the decision.
> In addition to signaling proposals the WG have received two other I-Ds.
> 1) Real-Time Web Communication Simplified Interconnection
> Which I interpret as a discussion piece around the federation and
> interconnect usages.
> 2) WebSocket Transport for Session Initiation Protocol (SIP)
> This is a demonstration that SIP could be implemented in Java script and
> be transported over web-socket to enable the cases where SIP want to be
> used between a browser instance and a SIP system and its user agents.
> This has some requirements on the API to either provide SDP in O/A style
> or something that enables the SIP stack to create SIP messages with SDP
> O/A messages.
> There has been lively discussion around these documents which I hope
> continues but it does need to come to some conclusions.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list