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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAB8821F8581 for <>; Thu, 14 Feb 2013 14:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.24
X-Spam-Status: No, score=-5.24 tagged_above=-999 required=5 tests=[AWL=-1.641, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4cFPdU2i684W for <>; Thu, 14 Feb 2013 14:22:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1F8FB21F890E for <>; Thu, 14 Feb 2013 14:22:15 -0800 (PST)
Received: by with SMTP id fm10so2255393wgb.33 for <>; Thu, 14 Feb 2013 14:22:15 -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=LTUkWr0nBO1YWVG/b4R7DxgVMkLPdlH6y6hndHaUuIE=; b=lQy0V6F7SiULVC1kz+QUPWM+QHBS7c6sweG21tVavieCvC46Wh9r8xU8vTpv4BxnjV XpDSENIWJIb4AbOh78ow11fxejmCnWN7oYCWH8Oi6Mq7XDkvImoOQApY7izae/T7jbvh FbNZv4KRkjAQszaPtzpmDFSBMHKr82Tj2K8UIVK3ohOavtLrgHfEHp29/cn+sI7ILbyZ 7OrDMzGsf1+zRBPjUG9aEQGPbPx9qggHEP5pbHppNOYi3GEBccdGrUYZpRuBNLn1qe/A V3aDj+Sdcj2YCXqVDNNJwd7QltK+DzGartFBC53GlmInQ6AWdoq7knMgaKs3Ps4AG9+3 omsA==
MIME-Version: 1.0
X-Received: by with SMTP id i20mr550554wiw.9.1360880535113; Thu, 14 Feb 2013 14:22:15 -0800 (PST)
Received: by with HTTP; Thu, 14 Feb 2013 14:22:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 14 Feb 2013 14:22:15 -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:22:27 -0000

On 14 February 2013 01:04, Randell Jesup <> wrote:
> Not sure what's going on here with Stream X - is there a missing assumption
> of SDP negotiation of Stream X?

Yes, I was in a hurry and assumed you'd guess that.

> The strong exposure of Stream numbers here
> implies they're surfaced to the application, no?

Stream numbers are already exposed as soon as you have SDP
negotiation.  This assumes that you use the same number in both
directions for the one channel.

> Or is it totally dependent
> on ordering of opens, and in the glare case they get cross-connected as one
> DataChannel with no notification of this (neither side gets onDataChannel).

In the glare case, yes, streams can get cross-connected.

> For StreamY from bob->alice (the "reply" direction): what are the
> properties?  This also implies that the JS API has to change to let you set
> transport properties on a channel that came from onDataChannel.

Properties would be set to some defaults by the browser.  And yes, the
properties should be mutable - SCTP certainly doesn't prevent that (I
covered this in my first email).

> Obviously there's no way to know anything about an incoming "onDataChannel"
> event not due to SDP; I'm sure your comment would be "if that matters,
> negotiate it".   How does the application cause negotiation to happen?
> (More JS API change I assume).

Yes, as above: properties have to be assigned defaults for the
ondatachannel event.  and yes, my response would be "if properties
matter, negotiate them".

An application can negotiate by doing offer/answer.

> I think there are unexplored interactions between SDP negotiation (and
> stream number selection) and this (dynamic no-negotiation creation).  You
> might need to fail SDP requests to open stream X if the answerer has opened
> a channel on Stream X before seeing the SDP, or have the answerer pick the
> stream (but that causes problems when data from the answerer arrives before
> the Answer).

I don't think that this is a concern.  Once you allow for mismatched
channel properties, this all becomes easy.  The answer can use the
channel it has open to stream X.

One thing that might help with consistency is to define how browsers
select stream identifiers.  e.g., start at the lowest available
identifier.  This should help applications do zero-negotiation uses
without surprising behaviour.

>>   (Not just because
>> eventual consistency is web-scale.)
> I'm not sure exactly what the last statement here means.

Sorry, that's a random synapse misfire.  I've been doing too much
eventual consistency stuff recently.  If you can suffer the