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 On Friday, January 30, 2026 at 2:16:03 AM UTC-8 [email protected] wrote: > Am Di., 27. Jan. 2026 um 09:27 Uhr schrieb Henrik Boström <[email protected] > >: > >> 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 <[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. >>>>> >>>> > 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 <https://github.com/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 > >> >>>>> >>>>> >>>>> 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/c47d5449-1c51-49d3-a054-7d8983ba393cn%40chromium.org.
