When connecting to a peer using createDataChannel...
peer.dataChannel = peer.connection.createDataChannel("data", { negotiated: true, id: connection_id});
The connection remains in a perpetual readyState of "connecting" and never reaches the "open" state, effectively blocking data communication with the peer. There is no similar blocking for audio or video tracks. This started happening within the last two weeks using Chrome 114.0.5735.133. It does not happen on any other non-Chromium-engine based browser. For example, Safari and Firefox do not show this behavior.
In testing earlier Chromium builds, the problem appears to have surfaced between builds
114.0.5735.0 and 114.0.5735.2
When running the affected code, there are no error messages shown on the debug console or in looking at ://webrtc-internals. Everything appears normal except the data channel connection is never established.
One point worth noting is that this happens almost every time. For some unknown reason, occasionally the connection block does not occur. But then, immediately after, on a second try, it re-occurs.
Also -- very reliably -- If I pause the debugger on the line before the connection is created, I never see the problem... so it appears to be a timing issue... BUT if I put a synchronous wait (for testing purposes only) before the connection is created, the problem remains... even if I specify to wait only on one side of the connected peers -- which would happen when pausing the debugger, which is also strange. Here is the code for testing with a synchronous wait:
function synchronousWait(milliseconds) {
const startTime = Date.now();
while (Date.now() - startTime < milliseconds) {
// Do nothing, wait for the specified time to pass
}
}
function initializePeer(id, polite) {
// if( polite == true ) synchronousWait(100);
const d = new Date();
let ms = d.getMilliseconds();
console.log("id:"+id+" polite:"+polite+" ms:"+ms+ " date:"+d);
$peers.set(id, {
connection: new RTCPeerConnection($self.rtcConfig),
selfStates: {
isPolite: polite,
isMakingOffer: false,
isIgnoringOffer: false,
isSettingRemoteAnswerPending: false,
isSuppressingInitialOffer: false
}
});
}
It does look like some change in the latest version of Chrome is at the root of the problem, but what that is is for now, a mystery
I tried the same code on various different browsers. If the problem was due to a programming error, I would expect that the problem would be evident on all browsers. However, only Chromium-engine based browsers show this problem, for example: Chrome, Chrome-Canary, Chromium, Microsoft Edge, Brave all show this behavior and none of them showed it in the recent past.