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 <[email protected]> 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. > > 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/CAJh39TNgpETbU1xMFaFT9Ym9at%3DTQx75MUXVjRrp4T7Ga9gXTQ%40mail.gmail.com.
