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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer