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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

>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.
[Raju] The whole discussion is about “Prevent DATA_CHANNEL_OPEN glare”. I don’t think we should call it a general “glare” situation. DCP just provides a way to open raw data channels with both sides using same stream id, that’s all. Rest of the semantics for tying a data channel to a particular use is completely defined by application. The “protocol” field itself is not sufficient to have uniqueness at the application level as there could be multiple data channels using the same protocol. MSRP application is an example where MSRP could be used for chat, file transfer etc. The label can be used by application to have uniqueness. But the smarts need to be in the application in general as when to open data channels and what do they mean? Some applications like MSRP do not need to know if the data channel sub-protocol+labels are unique or not. Other applications like gaming may have a need for one quique game control channel, opened by either side. To achieve this, the application needs to have a deterministic algorithm with either out-of-band signaling (could be using one of the data channels as master control channel by initiator) or by a simple “offerer opens the control channel”.

So, in summary I don’t think any specific notes are needed in DCP for this other than saying “it is upto the application to tie semantics of data channel use”, which I think is inherent by default.

-Raju