Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Matthew Kaufman <> Wed, 05 October 2011 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D925E21F8B9D for <>; Tue, 4 Oct 2011 19:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.665
X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvSCDnCFYoqi for <>; Tue, 4 Oct 2011 19:39:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5715221F8B5C for <>; Tue, 4 Oct 2011 19:39:21 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 92BC716FD; Wed, 5 Oct 2011 04:42:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=EwOU94RVHKk43LQefOjbrvE9rL4=; b=cPFLp+ovC L+PLI6jHmf63Xu+fACx7HfX4pM8eCUliQYreVmPrhSg6tEP91nL+o4F5tHGEH5y8 6XRERWtYbk3i9bAX3aBFLjhBYAYn2ln3/OmulTld+2tbqzwFA3wAnWIH97npgzZY F/N7FSRQtvl8HiyZmieYiZ/YUqNcbdo7js=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=h0APliX22rk3hXYbqX9jH2flJovYeRvY9T4zdLsgsEp25rUE igyky7GWhv65xXKBZzyKw8K0kus/aF+NCIMS0w8gxY5Br+1DFGNjpBjetgAGxPxG KBTkiFk7gxfOdO4ekv8Oy4pgo5voCfpSOOtBBPdSVkrsMHySp4jKSmc3LSI=
Received: from ( []) by (Postfix) with ESMTP id 912E57F6; Wed, 5 Oct 2011 04:42:27 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D0863507097; Wed, 5 Oct 2011 04:42:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pdrhXDGiXm3u; Wed, 5 Oct 2011 04:42:25 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id EFBA93506FFD; Wed, 5 Oct 2011 04:42:24 +0200 (CEST)
Message-ID: <>
Date: Tue, 04 Oct 2011 19:41:11 -0700
From: Matthew Kaufman <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ted Hardie <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040706040308040406050808"
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Wed, 05 Oct 2011 02:39:25 -0000

On 10/4/2011 5:06 PM, Ted Hardie wrote:
> On Tue, Oct 4, 2011 at 3:32 PM, Iñaki Baz Castillo < 
> <>> wrote:
>     2011/10/4 Ted Hardie < <>>:
>     > At today's Chairs call, Cullen, Magnus and I had a discussion of
>     how to make
>     > progress on the signaling discussion.  We feel the mailing list
>     discussion
>     > needs to have more concrete proposals in order to make progress,
>     and so
>     > we're putting forward the following:
>     >
>     > 1) If you plan to put forward a draft proposing a concrete
>     solution in this
>     > space, please send your name to the mailing list with that
>     intent by October
>     > 7th *THIS FRIDAY*
>     Hi Ted, could you please explain what exactly are you looking for? a
>     concrete signaling mechanism within rtcweb? something native in
>     browsers? something carried by HTTP/WebSocket?
> Hi Iñaki,
> The chairs don't currently detect consensus on how signaling will be 
> handled for RTCWeb sessions.  We don't want to circumscribe the 
> solution space, but we do feel that there is a need to have concrete 
> proposals, rather than broad statements like, "it shouldn't be in the 
> component X".  Concrete proposals for how it will be handled are the 
> best way we see to make sure folks are coming to consensus on 
> something they understand, rather than on rhetoric.

See my earlier email. Concrete proposal is: This Working Group does not 
produce *any* standard for what travels on the wire (as signaling) 
between an RTC Web Browser and its associated Web Server. This Working 
Group also does not at this time produce *any* standard for what travels 
on the wire (as signaling) between two web servers that wish to have 
interoperating communities of RTC Web Browsers, though the working group 
*may* address this at a future time, noting that several existing 
protocols are usable in the interim.

>     If so, I think that this should not be covered by rtcweb, which
>     instead should define a good API for dealing with SDP bodies (plain or
>     XML), create some kind of JavaScript object for mantaining each
>     session status and information (negotiated streams, codecs,
>     local/remote address...).
> If you would like to make a concrete proposal for how that JavaScript 
> object is constructed, what it contains, and how it is shipped around, 
> that would be great.   Without a statement of what those details are, 
> however, the chairs worry that people will argue (for and against) 
> proposals that have not been made.

I believe that a concrete proposal for the JavaScript API and the 
associated objects is out of scope for the IETF WG. Thus the details, 
for the purpose of this working group, would be "this is out of scope".

Matthew Kaufman