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.
