Intent to Ship: WebRTC Datachannel: Always negotiate data channels

[Philipp Hancke]

tContact emails

h...@chromium.org, philipp...@googlemail.com

Specification

https://w3c.github.io/webrtc-extensions/#always-negotiating-datachannels

Summary

Implement https://w3c.github.io/webrtc-extensions/#always-negotiating-datachannels

Blink component

Blink>WebRTC

Web Feature ID

Missing feature

TAG review status

Not applicable (incremental addition to WebRTC)

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1335)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/599)

Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes, a WPT is part of https://chromium-review.googlesource.com/c/chromium/src/+/7080041

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/433898678

Estimated milestones

Shipping on desktop

146

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113419982307328?gate=6516338099093504

This intent message was generated by Chrome Platform Status.

[Robert Flack]

The specification just says "alwaysNegotiateDataChannels defines a way for the application to negotiate data channels in the SDP offer before creating a datachannel". I'm finding it a bit hard to reason about what this means for me as a developer. I.e. when should I set it and how does this change the connection? Does this mean that a data channel will be negotiated without calling createDataChannel? Will that requested datachannel result in a datachannel event or does my code still need to call createDataChannel? If the latter, is this a performance optimization? Would I choose this when data is more important to connect first rather than e.g. voice / video?

The linked tracking bug appears to be a chrome-only bug report with a particular demo that doesn't use the alwaysNegotiateDataChannels attribute and works on Firefox. I don't quite understand what the new configuration extension has to do with the original bug report.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKuE79-xWUFiO9NCy%2Big9Pvn1oi6fVbkdomFLo4--bJQw%40mail.gmail.com.

[Rick Byers]

This is generally why we require explainers. Part of the point of this launch process is ensuring we've got the public material for web developers to understand the feature. Harald can you post an explainer somewhere which includes answers to Rob's questions?

Thanks,

   Rick

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPTxV5evdFUMnmfQE3aP2siNXNSZVpBr8wBitT56-nFCQ%40mail.gmail.com.

[Philipp Hancke]

bear with me while I try to explain 15 years of history...

Am Mi., 21. Jan. 2026 um 16:39 Uhr schrieb Rick Byers <rby...@chromium.org>:

This is generally why we require explainers. Part of the point of this launch process is ensuring we've got the public material for web developers to understand the feature. Harald can you post an explainer somewhere which includes answers to Rob's questions?

Thanks,

   Rick

On Wed, Jan 21, 2026 at 9:30 AM Robert Flack <fla...@chromium.org> wrote:

The specification just says "alwaysNegotiateDataChannels defines a way for the application to negotiate data channels in the SDP offer before creating a datachannel". 

I'm finding it a bit hard to reason about what this means for me as a developer. I.e. when should I set it and how does this change the connection?

Lets say you create a RTCPeerConnection. Create an offer and call setLocalDescription. Send it to your peer. You get an answer from the peer and feed it into setRemoteDescription.

You might wonder why it does not result in a connection.

Next, you create a datachannel. Your datachannel never opens because after adding the datachannel (only the first!) you need to call createOffer/setLocalDescription and call setRemoteDescription with the answer.

"web developers" are notably confused:

  https://stackoverflow.com/questions/79737908/how-do-i-create-a-data-channel-in-webrtc-js-firefox-115-6-esr

Now your connection gets established. If you add another data channel you do *not* need to do this negotiation again (thankfully; adding audio or video tracks requires negotiation).

In this case using the boolean flag is saving you one round of negotiation.

In many applications you do not know if you want to use a datachannel but since you might, you preemptively create one and throw it away. You can see that e.g. in Google Meet which calls

   pc.createDataChannel("ignored", {reliable: true})

It never uses that channel but it shows up in the getStats API every time.

 

Does this mean that a data channel will be negotiated without calling createDataChannel?

The underlying SCTP association will be negotiated and can be used by subsequent calls to createDataChannel without renegotiation.

This currently means exchanging four packets over the network (but that upfront cost might go away later this year).

Everything is set up to just work.

 

Will that requested datachannel result in a datachannel event or does my code still need to call createDataChannel? If the latter, is this a performance optimization?

Part of it is a performance / ergonomics optimization. But behold, there comes the 2011 backward compat angle below.

 

Would I choose this when data is more important to connect first rather than e.g. voice / video?

Lets say you have a stream from getUserMedia with audio and video and would also like to have a datachannel.

You call pc.createDataChannel and then iterate over the MediaStream's getTracks and call pc.addTrack with each.

Because data channels were new and fancy in 2011 and backward compat was a concern this results in SDP (due to rules in RFC 8829) which puts the datachannel bits in the SDP after the audio and video bits (and in Safari the order of audio and video bits depend on the lexical ordering of the random uuid of the MediaStreamTrack) so the SDP looks roughly like this:

  v=0 (6 more lines)
  m=audio 9 UDP/TLS/RTP/SAVPF 63 111 (23 more lines) direction=sendonly mid=0
  m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 45 46 (63 more lines) direction=sendonly mid=1
  m=application 9 UDP/DTLS/SCTP webrtc-datachannel (9 more lines) direction=sendrecv mid=2

Which is ok but you are probably scratching your head why this order does not match the order of calls (or why in Safari you get video-audio-application half the time)

https://www.rfc-editor.org/rfc/rfc8829.html#name-initial-offers specifies this (search for "Lastly, ") but does not provide much of a rationale. https://github.com/w3c/webrtc-pc/issues/735 has some 2016 rationale.

Now that seems like an odd choice but had little consequence until...

The linked tracking bug appears to be a chrome-only bug report with a particular demo that doesn't use the alwaysNegotiateDataChannels attribute and works on Firefox. I don't quite understand what the new configuration extension has to do with the original bug report.

WebRTC added APIs that allow you to negotiate codecs at some point. This can result in a situation where you end up with a incompatible set of video codecs (see the bug) and if those happen to be first in the SDP this "m=" line will be marked as "rejected" and can not be used to convey the transport information anymore.

At best this results in another round of negotiation to satisfy

  https://datatracker.ietf.org/doc/html/rfc8843#name-rejecting-a-media-descripti

Now 

  https://datatracker.ietf.org/doc/html/rfc8843#section-7.2.1

actually provides a recommendation on how to avoid this: you pick something that is "unlikely to be rejected by the remote side".

The browser does not have an API that would lead to it rejecting a datachannel m= line (which can happen for audio and video)

So it would be great to pick this datachannel m= line as "offerer tagged" which avoids this headache.

But that requires (unless you want to risk more breakage) putting this m= line first which is conflicts with the rules of RFC 8829.

The alternative is going through at least two rounds of negotiation (which involves the remote end), the first datachannel only and then adding media.

Hence you need a way to opt-in which is the boolean in the RTCConfiguration.

Would you like to hear more about why WebRTC is so weird? (a lot of this boils down to "SDP is not an opaque blob)

[Henrik Boström]

This simple API plugs a missing piece of functionality: there is no way to tell WebRTC that you may want to use data channels at some point in the future without having to re-negotiate, so the only way to ensure you negotiate data channels unconditionally is to create these dummy data channels not to be intended for use that you have to manually ignore at the other endpoint, both with regards to events firing and when parsing statistics.

Creating dummy data channels is a workaround to a mistake in the API in my opinion, and I would support it even if all that it achieved was API ergonomics.

But it does achieve something more than the workaround is able to: placing the m= application line at the top. The fact that the order of m= sections is more predictable reduces the risk of application bugs. I believe Google Meet had a serious regression a few years ago where the m= section order was something not what we expected causing the SDP parser to fail and the call to be disconnected. It's also a good idea that the m= application line gets tagged, avoiding risk of rejecting the whole bundle if the wrong m= section is rejected.

[Robert Flack]

Thank you for the explanation. I definitely agree that this sounds very important. My concern remains that the parameter name and developer documentation does not convey this and without this context it's unclear why I should use this. As an example, the config parameter could just be called negotiateDataChannels, as a cue that this will ensure your connection is configured to support creating data channels. It would be worth also explaining why you want to do this, with a short snippet showing how a data channel can be added later.

The spec says that it is negotiated before audio or video but doesn't explain why you might want to do this - i.e. to ensure that you can negotiate a connection even if the audio or video channels fail to negotiate a compatible codec.

TLDR; I'm not opposed to this feature - after learning what it does and why, I agree we need it. I just think it would be very hard for someone reading about this to understand that they should use it to resolve these issues.

[Robert Flack]

Sorry, quick followup, keeping always in the name would make sense if it was explained that because this is negotiated first it ensures that we at least will always negotiate a data channel even if audio and video fail.

[Robert Flack]

It sounds like you're saying here that this may not be backwards compatible and if the other end doesn't support it you may not be able to establish a connection. If so, is it possible for the developer to feature detect whether the browser supports this so that they may determine whether both ends support this or not before setting it?

[Henrik Boström]

This feature is only needed by the endpoint that creates the initial offer and decides the m= section order, i.e. the other endpoint - whether they support this feature or not - will accept the m= section order that is on offer. Once the order is decided, it is "locked in" by both endpoints, as per old SDP rules. So it should be cross-browser compatible and backwards-compatible, here's me setting SDP with m= application line first and the offer is accepted: https://jsfiddle.net/henbos/oweu42yz/

As for if the browser that is creating this offer supports the feature, you can feature detect by testing it on a throwaway RTCPeerConnection object that you immediately close afterwards.

[Philipp Hancke]

Am Di., 27. Jan. 2026 um 09:27 Uhr schrieb Henrik Boström <hb...@google.com>:

This feature is only needed by the endpoint that creates the initial offer and decides the m= section order, i.e. the other endpoint - whether they support this feature or not - will accept the m= section order that is on offer. Once the order is decided, it is "locked in" by both endpoints, as per old SDP rules. So it should be cross-browser compatible and backwards-compatible, here's me setting SDP with m= application line first and the offer is accepted: https://jsfiddle.net/henbos/oweu42yz/

As for if the browser that is creating this offer supports the feature, you can feature detect by testing it on a throwaway RTCPeerConnection object that you immediately close afterwards.

Throwaway peerconnections are an antipattern too ;-)

Since RTCConfiguration is not exposed on window one can not feature detect upfront but one can call pc.getConfiguration() to see if this had an effect after creating the connection and then adapt if necessary (i.e. create the not-quite-throwaway channel)

Not sure I would bother with feature detection, the other side should support the resulting SDP both with the new behavior of datachannels being first or the current behavior so opt-in should be fine with fallback to the current status quo.

 

On Monday, January 26, 2026 at 4:46:05 PM UTC+1 Robert Flack wrote:

On Mon, Jan 26, 2026 at 10:25 AM Robert Flack <fla...@chromium.org> wrote:

Sorry, quick followup, keeping always in the name would make sense if it was explained that because this is negotiated first it ensures that we at least will always negotiate a data channel even if audio and video fail.

On Mon, Jan 26, 2026 at 10:23 AM Robert Flack <fla...@chromium.org> wrote:

Thank you for the explanation. I definitely agree that this sounds very important. My concern remains that the parameter name and developer documentation does not convey this and without this context it's unclear why I should use this. As an example, the config parameter could just be called negotiateDataChannels, as a cue that this will ensure your connection is configured to support creating data channels. It would be worth also explaining why you want to do this, with a short snippet showing how a data channel can be added later.

Negotiating datachannels is already an overloaded term - the SDP negotiates support and datachannels themselves are negotiated in-band but can also be negotiated out-of-band.

The spec says that it is negotiated before audio or video but doesn't explain why you might want to do this - i.e. to ensure that you can negotiate a connection even if the audio or video channels fail to negotiate a compatible codec.

TLDR; I'm not opposed to this feature - after learning what it does and why, I agree we need it. I just think it would be very hard for someone reading about this to understand that they should use it to resolve these issues.

The WebRTC samples have always been great for showing how a feature works but in this case even I have a hard time coming up with a good sample.

Adoption is more likely from opensource projects currently working around this like MediaSoup and then it trickles down from there. Who knows, maybe Google Meet might drive adoption just to get rid of the "ignored" datachannel ;-)

I have updated the description accordingly.

cheers

Philipp

[Alex Russell]

It's a little concerning that there's no explainer and no (reasonable?) example code. How can developers debug that they're getting the intended behaviour? Will they be surprised by the change(s) and/or across browsers?

Best,

Alex

[Philipp Hancke]

Alex,

this boils down to WebRTCs notion that the "SDP" is a " blob".  Which makes the API look easy but from the amount of fighting over the plan-b deprecation, "sdp munging" or even the question when inbound-rtp stats appear, this is causing trouble since this "blob" controls a ton of behavior.

Developers can parse the SDP, e.g. like 

  https://jsfiddle.net/fippo/kct3dy46/

which with the new option set should return ["application", "video"] instead of ["video", "application"].

The opt-in boolean avoids changing the default behavior so no surprises unless you use it.

If you opt in you also (implicitly) agree that you are ready to deal with the feature not being supported.

So the other end that is parsing and processing the SDP you generate is today receiving

  audio-video-data

without the opt-in and you ensure it works with

  data-audio-video

but you will still need to support the old way.

I am not worried about browsers where we deal with only two SDP parsers and both are well written robust enough to deal with.

cheers

Philipp