RE: DataChannel: negotiated behaviour appears to be not possible to implement (#233)

Encoding some presumed additional meaning into the DataChannel label to be stripped off before exposing to the value to the app developer is possible (but problematic). If we were only talking ORTC to ORTC this could be possible; but to be compatible this interpreted meaning would have to be defined as part of the IETF wire spec for all implementations or I don’t think it should be done. Just my $0.02.

-Robin


On September 8, 2015 at 8:51:45 AM, Justin Skinner (skinnzer@live.com) wrote:

Perhaps somewhat 'hacky', but I see no reason beyond elegance that the negotiated state cannot be tacked onto the label, such as MESSAGENAME--Negotiated or some more obtuse character string, unless there's an expectation that this field will exceed 65,000 characters.
 
Just my two cents.
 
From: Bernard.Aboba@microsoft.com
To: public-ortc@w3.org
Date: Mon, 7 Sep 2015 16:34:32 +0000
Subject: DataChannel: negotiated behaviour appears to be not possible to implement (#233)

From: Robin Raymond

The first way is to construct an RTCDataChannel at one of the peers with the RTCDataChannelParameters.negotiated attribute unset or set to its default value false. This will announce the new channel in-band and trigger an ondatachannel event with the corresponding RTCDataChannel object at the other peer. The second way is to let the application negotiate the RTCDataChannel. To do this, create an RTCDataChannel object with the RTCDataChannelParameters.negotiated dictionary member set to true, and signal out-of-band (e.g. via a web server) to the other side that it should create a corresponding RTCDataChannel with the RTCDataChannelParameters.negotiated dictionary member set to true and the same id.
The trouble is that constructing a DataChannel with negotiated = true appears to have a race condition. If the local side constructs with negotiated as true, the DATA_CHANNEL_OPEN message (http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09#section-5.1) is sent to the remote side immediately. This will cause an "ondatachannel" with a new DataChannel event to happen remotely if the remote side did not pre-create a DataChannel with the same ID in advanced to receiving the in-band signalling. The remote side has no way to tell if this newly incoming channel had the negotiated flag set to true or not (as the negotiated field is not carried in the DATA_CHANNEL_OPEN message to know). If the remote side pre-creates the object, then it will also send the DATA_CHANNEL_OPEN and then t he local side doesn't know in advance that this is a negotiated channel. Thus both sides must create the DataChannel while the DATA_CHANNEL_OPEN is still shuttling over the wire or the ondatachannel event will occur. There appears to be no way to suppress this behaviour.