Data channels in workers get initialized on wrong thread

[jan-ivar]

The spec says:

• "Once an SCTP transport is connected, ... the user agent MUST queue a task that runs the following steps: ... 4. For each of connection's RTCDataChannel: ... 2. If channel.[[DataChannelId]] is null, initialize [[DataChannelId]] to the value generated by the underlying sctp data channel, according to [RFC8832]."

Here, the "For each of connection's RTCDataChannel" is extremely broad, reasonably read as including RTCDataChannels in workers (as opposed to iterating over connection.[[DataChannels]]).

It goes on to initialize each data channel's [[DataChannelId]] on main-thread, which is bad news if it's in a worker.

I think we need to either:

1. push this down into "3. ... announce the channel as open" which queues its own (correctly realm-targeted) task per RTCDataChannel — a potentially breaking change if anyone expects to read their datachannel.ids from their SCTPTransport statechange event listener. OR
2. exclude worker data channels in this for-loop and initialize them separately

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC July 2025 meeting – 15 July 2025 (Issue #3063: Data channels in workers get initialized on wrong thread):

RESOLUTION: continue discussion in issue based on implementation analysis

[docfaraday]

We probably need a [[MaxMessageSize]] slot on RTCDataChannel that is initted at the same time as [[DataChannelId]], whatever that ends up being, since the max message size is checked synchronously in RTCDataChannel.send().

[jan-ivar]

Thanks for catching that. [[MaxMessageSize]] is only updated in setAnswer() here so we can probably add some language there to queue a task on each worker that has at least one data channel (but it might be simpler to queue a task for each data channel instead like you suggest, and let UAs optimize).

[alvestrand]

We should probably try to go over carefully what properties of the datachannel need to be punched down, and when. It seems that the standardization of datachannel transfer was a bit rushed....

[jan-ivar]

Undoubtedly, though they're probably also learning pains in dealing with multiple realms, which requires more care with things like queuing tasks etc. As long as we agree on observable behavior, this seems like mostly spec work that needs to happen to make things clearer.

Adding to this list that we need fix the firing of the error event from setAnswer() as well: