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. On Mon, Jan 26, 2026 at 7:31 AM Henrik Boström <[email protected]> wrote: > 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. > On Thursday, January 22, 2026 at 3:20:18 PM UTC+1 Philipp Hancke wrote: > >> bear with me while I try to explain 15 years of history... >> >> Am Mi., 21. Jan. 2026 um 16:39 Uhr schrieb Rick Byers < >> [email protected]>: >> >>> 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 <[email protected]> >>> 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 <https://issues.chromium.org/433898678> >>>> 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) >> >> >>>> On Wed, Jan 21, 2026 at 6:31 AM 'Philipp Hancke' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> *tContact emails* >>>>> [email protected], [email protected] >>>>> >>>>> *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 >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%22> >>>>> >>>>> *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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> 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 >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKuE79-xWUFiO9NCy%2Big9Pvn1oi6fVbkdomFLo4--bJQw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKuE79-xWUFiO9NCy%2Big9Pvn1oi6fVbkdomFLo4--bJQw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPTxV5evdFUMnmfQE3aP2siNXNSZVpBr8wBitT56-nFCQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPTxV5evdFUMnmfQE3aP2siNXNSZVpBr8wBitT56-nFCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMsJtfPyCKB%2BUOiH_Hm%3DiMjMy2sM9uHk3FMSt7NRQgbzQ%40mail.gmail.com.
