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. 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 <[email protected]> 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 <[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. >>>>> >>>> > 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? > > 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/fdeaf5bd-978e-4415-9ae5-81dfeae641d9n%40chromium.org.
