Re: [rtcweb] Data Channel Negotiation and reopening of decisions

Randell Jesup <> Thu, 14 February 2013 09:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A256F21F8702 for <>; Thu, 14 Feb 2013 01:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xT64bDU1lewL for <>; Thu, 14 Feb 2013 01:46:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 07BAE21F86DD for <>; Thu, 14 Feb 2013 01:46:53 -0800 (PST)
Received: from ([]:2817 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1U5vP2-00091V-C9 for; Thu, 14 Feb 2013 03:46:52 -0600
Message-ID: <>
Date: Thu, 14 Feb 2013 04:44:44 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
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: Thu, 14 Feb 2013 09:46:53 -0000

On 2/13/2013 5:03 PM, Martin Thomson wrote:
> None of what I suggest would change the API.  At most, it would have
> removed the in-band handshake messages in exchange for loosening some
> of the guarantees.  And I've been trained to value the deletion of
> code highly.  That seemed like a good trade.

I think the no-negotiation proposal would require various API changes if 
you work out the details.

I understand the wish to reduce code.  (You do realize we're running 
over a lightweight stack like SCTP over DTLS over ICE/TURN over UDP, 
right?  ;-)

However, I'm not sure that you're actually reducing code by shifting to 
SDP (I think you're just moving the code/complexity, as the existing 
structures for negotiating m= lines can't be reused here I believe).  
And I think the SDP+no-negotiation-open proposal ends up with yet more 
complexity (and importantly, more application (JS) complexity).

The least complex IMHO is the 0-RTT in-band option, though it's similar 
in complexity to the current "pure" inband (without accelerated 
call-start creation via SDP - i.e. 1.5RTT for all opens).

> And timing?  It wasn't until you presented at the interim that I
> realized just how little value the in-band handshake was adding.

Which Interim?  This one (where I wasn't presenting the in-band 
protocol, though discussion moved there), or Stockholm, where it was 
presented (and again at Atlanta where we added the 'protocol' field, 
which was about the only major commentary).   I realize someone can (and 
will) object at any stage; I just wish objections of this fundamental 
nature were made (a lot) earlier.

> In terms of the specifics of your fast open proposal, what do you do
> with the message(s) that arrive on channels that you reject?  How does
> this surface in the API?

There is no rejection.  Creation of DataChannels (per the JS API) is 
purely declarative.  If you (as an application) wish to 'reject' a 
channel, either throw the object away or call .close() on it if you want 
to be nice to the sender.

> I'll do a blow-by-blow on your points below, if you want to continue
> the conversation.  If we're exchanging rhetoric bombs, I see little
> point.

No, I'm quite willing to continue the conversation; to an extent (how 
much to be determined by the WG) the snake has snuck out of the bag and 
we now have to deal with the comments (both yours and Justin/Peter's).  
I will concede I have an interest in retaining a solution similar to the 
one I've proposed (in-band or preferably 0-RTT), as I have it coded in 
Firefox, used in applications and largely debugged and on-track for 
release to production in 12-18 weeks or so (and major changes might 
cause problems with that and/or future version incompatibilities).  
That's the impact of revisiting issues; we considered DataChannels a 
critical component to have from the start of WebRTC and put a lot of 
effort into first discussing it on the lists and then implementing it.  
We began implementation a year ago, and have tracked changes from the 
lists and drafts since then.   But that isn't the only consideration.

Partly my comments were aimed at all instances where we go back (and go 
back again) with progress being elusive, not just this one issue.

Randell Jesup