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

[Martin Thomson <[e-mail]>]

On 14 February 2013 01:04, Randell Jesup <[e-mail]> 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
digression: http://www.youtube.com/watch?v=b2F-DItXtZs