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

[Michael Tuexen <[e-mail]>]

On Feb 15, 2013, at 7:04 PM, Ted Hardie wrote:

> On Thu, Feb 14, 2013 at 6:59 PM, Michael Tuexen
> <[e-mail]> wrote:
>> 
>> I consider each side managing only its outgoing streams. Therefore if
>> each side opens a data channel at about the same time, you end up
>> with two data channels. Assume that there are no data channels before that
>> and that you don't reserve any stream, chances are that each data channel
>> consists of out going stream with stream id 0 and incoming stream with
>> stream id 1.
>> 
> 
> Sorry for being dense, but if you get an INIT where the Stream
> Identifiers in the data
> chunk are already in use, why wouldn't you error out?  Alternatively,
Martin suggests to have no control protocol for opening data channels.
So there is nothing like an INIT message on a stream.
> can existing
> implementations keep that straight as a tuple of SCTP association,
> stream identifier?
> If the latter, then occasionally having two data channels instead of
> one does not
> seem to be that big a deal; am I missing something?
He would occasionally end up with one data channel instead of two.
Systems, not behaving as expected *occasionally*, is a bad thing for
me. I consider this a bug and it much harder to debug if it only
occurs occasionally. It is even worse, if the developer hasn't made
any mistake...

For me, it should be clear how a data channel is set up, used,
and teared down. Yes, things can go wrong on the wire (connection
drop or so), but the API provides error handling. But we shouldn't
come up with a solution which works most of the time. For specific
applications this might be most of the time or even always.

Best regards
Michael
> 
> regards,
> 
> Ted
>