Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare

[Michael Tuexen <[e-mail]>]

On Feb 10, 2014, at 11:21 AM, Christer Holmberg <[e-mail]> wrote:

> Hi,
> 
>>> As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received.
>>> 
>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the same time, using different stream id values, the result may be TWO data channels, with data sent on both.
>>> 
>>> However, as is also indicated, the draft does not provide a mechanism to prevent/handle such glare situation.
>>> 
>>> I personally think there shall be a way to prevent such situation, or otherwise I'm sure we are going to end up with interoperability problems.
>>> 
>>> Couldn't we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value.
>> Section 4 reads:
>> 
>>  To avoid glare in opening Channels, each side MUST use either even or
>>  odd Streams when sending a DATA_CHANNEL_OPEN message.  The method
>>  used to determine which side uses odd or even is based on the
>>  underlying DTLS connection role when used in WebRTC, with the side
>>  acting as the DTLS client using even stream identifiers.
>> 
>> So there is no problem in setting up data channels.
>> 
>> This should not be confused by both sides setting up a data channel with the same Label. This ends up in two data channels with the same label.
>> You can even create more data channels with the same label.
> 
> My point is that I don't want to end up with more than one channel.
And you won't, see above. However, there is no mechanism to ensure
uniqueness for labels. The WebRTC API already allows one side
to create n data channels with the same label.

Best regards
Michael
> 
> Regards,
> 
> Christer
> 
>