Re: [rtcweb] Data Channel Negotiation

[Martin Thomson <[e-mail]>]

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.

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

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

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

>> 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
number of channels to the lower of the two stream limits.  I prefer
the latter.

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.

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