> But you're saying that I have no way of knowing up front if it's one or
the other.
I think there is, but it is not pretty - calling
peerConnection.createOffer() will generate that SDP message and you can
parse it a bit to see if the data channel (m=application) shows up first -
that means the boolean worked.
Of course, parsing the SDP is a pretty big hammer just for knowing whether
the boolean is supported...
Looks like new RTCPeerConnection({alwaysNegotiateDataChannels: true}) does
not fail to create a peer connection at the moment, so unsupported
constraints cannot easily be feature-tested.
Perhaps using a getter rather than a simple true ({get
alwaysNegotiateDataChannels()
{ isConstraintSupported = true; return true; }}) would also work.☆*PhistucK* On Wed, Feb 4, 2026 at 4:20 AM Yoav Weiss (@Shopify) <[email protected]> wrote: > A potentially silly question, due to my complete ignorance of WebRTC > protocol negotiations: > If I'm planning to use this new boolean, that means that I may or may not > want to negotiate a data channel. > If the other side doesn't support the boolean, I need to create a dummy > data channel. If it does, I don't need to create one. > But you're saying that I have no way of knowing up front if it's one or > the other. > > So how would developers know if they need to create a dummy channel? Is > there some response to this boolean that indicates support or lack-thereof? > If so, presumably it's not too late to create the dummy channel at that > point? > > > > On Tuesday, February 3, 2026 at 1:57:19 PM UTC+1 [email protected] > wrote: > >> 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 >> >> >> Am Mo., 2. Feb. 2026 um 21:04 Uhr schrieb Alex Russell < >> [email protected]>: >> >>> 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/44ea71a3-1710-4b0f-97f7-6df551fbe7efn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44ea71a3-1710-4b0f-97f7-6df551fbe7efn%40chromium.org?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/CABc02_JeLQ820PS4%3D5gPyQ7UvZFgy7U22sVfreii0JNzSssgXg%40mail.gmail.com.
