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.