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

Can you describe the "simple protocol to realize bi-directional data channels by combining two uni-directional streams" without referring to any of what now appear to be unresolved issues?

Matthew Kaufman

Sent from my iPad

On Feb 16, 2013, at 7:23 AM, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de> wrote:

> On Feb 15, 2013, at 10:56 PM, Matthew Kaufman (SKYPE) wrote:
> 
>> None if this would be a problem if we weren't making the mistake of using SCTP, which itself made the mistake of doing full-duplex channels instead of unidirectional channels with optional one-to-one or even many-to-one associations (as RTMFP has, as an example)
> SCTP streams uni-directional. That is why we use a simple protocol to realize bi-directional
> data channels by combining two uni-directional streams.
> SCTP association, however, are point-to-point. The API (1-to-many style) allows sending
> a single messages (a single send() call) on all associations belonging to that socket.
> 
> Best regards
> Michael
>> 
>> Matthew Kaufman
>> 
>> (Sent from my iPhone)
>> 
>> On Feb 15, 2013, at 1:16 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>> 
>>> On 15 February 2013 12:55, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>> I think I understand what you are proposing. But what happens, if
>>>> both sides at about the same time open want to open a data channel.
>>>> For both sides outgoing stream X is free, so they use this. So the
>>>> endpoints end up with one data channel instead of two.
>>> 
>>> Actually, I'd go further than that.  I'd require that browser
>>> implement the same algorithm for selecting the stream to use.  That
>>> implies that in all cases other than the rarest race conditions, you
>>> get the same data channel.
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 