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

Martin Thomson <> Thu, 14 February 2013 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 935D021F867D for <>; Thu, 14 Feb 2013 14:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=-1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6UWTJaM-u9kK for <>; Thu, 14 Feb 2013 14:34:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0202F21F85B4 for <>; Thu, 14 Feb 2013 14:34:32 -0800 (PST)
Received: by with SMTP id fn15so2386871wgb.32 for <>; Thu, 14 Feb 2013 14:34:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DAgOaksWyqU2aujwWvCuRCAbH66u7E4BSQnxz2SsHp8=; b=m9+RXXy93w6BsL7XGqAJYqPoOp54dDYHumwBYuZXNhc+iBnfQMr/Toe7Zsq7HPQRcO xbeMVX4EPBVhs7s0bMA4rzcn+fr0gmodE2jO3cLQxjwXy2iv32VFFuZPh47FBeIv3iOY dLKm/SI3f0uPa29EHxJkrcHC4pTQqX9SQHMM0hjSMMtRpLqvqGDBoH5uMUiOscsL9zOR O16cwn4Onx3/H9LcGE6GCdQoBaqrv40kd3ISREFGNkvkj/DtR1/I63B+ykHOh/FE2szZ QCe9CoasJ7GbBnINK2kx50vt/D24DEt8hAYby1cynPiq4ITuHAHbbStiPKwS9hyys+1v rPuQ==
MIME-Version: 1.0
X-Received: by with SMTP id o9mr2421140wiw.16.1360881271821; Thu, 14 Feb 2013 14:34:31 -0800 (PST)
Received: by with HTTP; Thu, 14 Feb 2013 14:34:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 14 Feb 2013 14:34:31 -0800
Message-ID: <>
From: Martin Thomson <>
To: Randell Jesup <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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 22:34:41 -0000

I should probably collate responses.

On 14 February 2013 01:44, Randell Jesup <> wrote:
>> None of what I suggest would change the API.
> I think the no-negotiation proposal would require various API changes if you
> work out the details.

Sure, some changes, but nothing that would prevent channels from being
used interchangeably with websockets.  That is, once they are

> 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?  ;-)

Presumably you bought all those other parts of the stack.

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

I was under the impression that the SDP code was already needed.  That
was the premise behind making the suggestion - if we're not using SDP
to negotiate channels ever, then I might be tempted to revise that.

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

The least complex is to have the application just use channels with no
in-band messages at all.  But we can't do that because we need to have
messages tagged as being "binary" or "text" to further propagate the
mistake that the websockets design made.

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

Yeah, I understand the frustration.  I used to get frustrated with
this sort of thing too.