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

Michael Tuexen <> Thu, 14 February 2013 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 891E221F86C8 for <>; Thu, 14 Feb 2013 14:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HAxAEYVBA+cz for <>; Thu, 14 Feb 2013 14:58:40 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 5ADE621F897A for <>; Thu, 14 Feb 2013 14:58:40 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id C9FAA1C0C0BF3; Thu, 14 Feb 2013 23:58:36 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <>
In-Reply-To: <>
Date: Thu, 14 Feb 2013 23:58:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <>, "" <>
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:58:41 -0000

On Feb 14, 2013, at 11:34 PM, Martin Thomson wrote:

> 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
> established.
>> 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.
You could use the PPID of SCTP and would not need the in-band messages...

However, assuming datachannel are bidirectional, I really think we need some
sort of signaling to set them up to avoid collisions. The JS user should
have a clearly defined behavior. So I think the 1.5 RTT solution is the base.
The additional SDP solution is only an acceleration for providing initial
datachannels in 0-RTT. However, allowing the 0-RTT in-band option provides
the same speed-up and isn't restricted to the initial data channels.
So the purely in-band solution with the 0-RTT option seems to be the best
for me. But as Randell pointed out: We had this discussion already and I'm
not sure what we get if we open up it again. New arguments doesn't seem
to come up...

Best regards
>> 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.
> _______________________________________________
> rtcweb mailing list