Re: [rtcweb] Data Channel Negotiation

[Michael Tuexen <[e-mail]>]

On Feb 11, 2013, at 8:40 PM, Martin Thomson wrote:

> On 8 February 2013 09:43, Michael Tuexen
> <[e-mail]> wrote:
>>> Creating a new data channel triggers the onnegotiationneeded event.
>> The signaling channel might have a different RTT than the peer to peer
>> connections. So you prefer to do take always the signaling channel.
> 
> But since you have a short path for this, you can take that path.
> Some people may prefer to take the slower signaling path for this, but
> those that care about speed will use the data channel to do channel
> establishment (and they will probably do what I suggest below).
> 
>> Taking down a data channel is not signaled via SDP, right?
> 
> I believe that you are able to use in-band mechanisms (6525) for take-down.
Sure. The goal of my questions is to understand your proposal better...
> 
>> How do you handle a shortage in the number of streams? How do you
>> handle collisions if both sides want to open a data channel and
>> chose the same streams?
> 
> A shortage is easy, createDataChannel can throw an exception.
> 
> Collisions are also easy - if you care about consistency, then do an
> offer/answer, which has inbuilt glare resolution.  If you don't care
> about consistency, both sides can create and use channels without
> having to agree on the details.  (That's mostly based on the stuff
> below.
However, *if* data channels are bidirectional (which they currently are),
then you need to tie two streams together. This has to be done somehow.
I'm wondering how you envision this without using SDP and without the
data channel protocol...
> 
>> There is also a limitation of lifetime in milli seconds.
> 
> Sure, let's have that too.  All this is per-message, so consistency
> isn't really a required property.
OK.
> 
>> So basically a data channel is not symmetric anymore. Do you consider
>> it bidirectional or unidirectional?
> 
> Yes.  Depending on the needs of your application.  Inherently, they
> are unidirectional.  But if you care about the bidirectional property,
> then you are free to perform a signaling negotiation to ensure
> consistency (which is the only property that was provided by the
> negotiation as designed previously).
If we change to data channels being uni-directional, then most of
the stuff done by the data channel protocol is not required... I agree
with that conclusion.
However, currently that the bi-directional.
> 
>>> Firstly, the arrival of a packet on a stream that is not negotiated
>>> will require the creation of a data channel.  The properties of this
>> If you consider a data channel to be bidirectional, what makes sure
>> that a stream for the backwards direction is available? How do you
>> now the pairing?
> 
> There is no guarantee.  Two reasons for this, neither of which I find
> particularly dire:
> 
> a. I don't recall there being any signalling of the stream limit, so
> there is a possibility that the stream limit in one direction will
> exceed the limit in the other.  Streams with numbers that exceed the
> lower limit will of course be unable to be reciprocal.  Two solutions
> occur to me: 1. prevent the sending of return messages, or 2. cap the
Instead of "prevent sending the return message" which would one side
waiting forever, I would prefer sending some sort of error message
(which is currently not specified enough in the data channel protocol).
> number of channels to the lower of the two stream limits.  I prefer
> the latter.
As long as you know this limit... But RFC 6525 allows you to increase the
number of streams (unless the peer agrees to do so). 
> 
> b. There is no guarantee that the other side hasn't already created a
> data channel on the same number.  That's not a problem - you just end
> up with asymmetry.
This is a normal case with the current data channel protocol. The
stream identifiers might not be the same in both directions.
When testing with the current implementation in Firefox, this actually
happens a lot.
> 
> Note: deferring the allocation of a stream number until messages are
> sent on streams does allow the browser implementation some flexibility
> in how it manages assignment of streams.
> 
>> Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
>> a limit.
> Crossed wires :)
... that was my guess.
>