LGTM2 Thank you Henrik for the worked example. Being able to ensure consistent SDP (with m=application first) and avoid renegotiation makes a lot of sense. It's unfortunate that predictable behavior is an opt-in, but I guess that's necessary since otherwise m=application would always be in the SDP even when not requested, which would be weird and risky too.
On Tue, Feb 10, 2026 at 12:55 PM 'Henrik Boström' via blink-dev < [email protected]> wrote: > I'll also shime in to try to explain how this works, example: > > const pc = new RTCPeerConnection({alwaysNegotiateDataChannels:true}); > pc.addTransceiver('video'); > await pc.setLocalDescription(); // Creates SDP offer > console.log(pc.localDescription.sdp); // Prints the resulting SDP > > This will print SDP with the following m= sections and in the following > order (note that real SDP contains more text, but this is the relevant part > of it all): > m=application > m=video > > The benefit of negotiating the m=application first like this is that upon > completing the offer-answer dance with a remote endpoint, it is possible > for either endpoint to perform pc.createDataChannel() and for that data > channel to show up on the other side (via the pc.ondatachannel event > handler). Once the m-line is negotiated, we can create any data channels > without having to re-negotiate the SDP. This does not happen if SDP was > negotiated without the m=application line. > > Today, to force the m=application line to show up, you have to > createDataChannel *before* creating the SDP offer. E.g. > > const pc = new RTCPeerConnection(); > pc.createDataChannel(...); > pc.addTransceiver('video'); > await pc.setLocalDescription(); > > Here the order, while well define, is less predictable to the web > application, and the result is - mostly for historical reasons - > surprisingly reversed from the API call order: > m=video > m=application > > So if you want the m=application line to not depend on how many > transceivers you happened to have had at the time when you created the > initial offer, you'd have to actually may two separate SDP offer-answer > exchanges, adding both complexity and another round-trip time to your call > setup just for the sake of locking in an order that shouldn't really > matter, but due to its unpredictable nature could cause application bugs > (Google Meet being an example of who had a bug here). > > const pc = new RTCPeerConnection(); > pc.createDataChannel(...); > await pc.setLocalDescription(); // Lock in m= application first > /* ... complete negotiation to remote endpoint */ > pc.addTransceiver('video'); > await pc.setLocalDescription(); // Follow-up offer... > > Note that this headache is just for the local endpoint that is creating > the SDP offer. The remote endpoint (whether they support > alwaysNegotiateDataChannels or not) is able to process SDP regardless of > the m-line order, which is why I don't think there are any backwards/cross > compatibility issues with this beyond the usual of having to feature detect > with pc.getConfiguration(). And once the order is "locked in", it stays > that way for both endpoints, regardless of who creates the next offer. > > So in short, this API makes life a little less complex, saying you're > interested in data channels whether or not you want to create that data > channel now or later (without re-negotiating). > > On Monday, February 9, 2026 at 8:11:56 PM UTC+1 Alex Russell wrote: > >> Thanks, this is helpful. LGTM1 conditional on getting this example and >> the value it provides into an Explainer. >> >> Popping up a level, we need the WebRTC community writ large to get more >> comfortable with writing out this sort of example code to explain problems >> and solutions. Without it, we're always going to be delayed when Chromium >> is asked to ship first. We're judging our compat risk for changes in light >> of first-mover disadvantage, and so we need collateral of this sort to >> ensure that both the API OWNERSD and web developers overall can follow the >> thread of "why is this here?" >> >> Best, >> >> Alex >> >> On Monday, February 9, 2026 at 1:47:19 AM UTC-8 [email protected] >> wrote: >> >>> Hey Alex, >>> >>> Am Mi., 4. Feb. 2026 um 17:16 Uhr schrieb Alex Russell < >>> [email protected]>: >>> >>>> Hey all, >>>> >>>> Thanks for the replies. I'm mostly confused about how intently we need >>>> this. What applications does this improve? How? >>>> >>> >>> Take mediasoup, a popular opensource WebRTC server. It spends, because >>> this has been a problem since 2017 as described under "Never disable audio" >>> https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/ >>> a lot (well, more than setting a boolean) of effort to make sure the >>> datachannel m-section is placed first in the SDP. >>> mediasoup could add a "chrome 148 handler" here >>> <https://github.com/versatica/mediasoup-client/tree/v3/src/handlers> that >>> sets the boolean and reduces the number of renegotiations. >>> >>> Google Meet too, not creating the "ignored" data channel will save ~213 >>> bytes per second on getStats memory (usually every second) ;-) >>> >>> This whole mess is due to the backward compat rules from ~2012. Created >>> headache in 2017. Still a footgun in 2025. Less so moving forward hopefully. >>> >>> Seeing a block of before/after example code that shows the problem in >>>> situ is usually how we get a minimal sense of how this will play out for >>>> customers. >>>> >>> >>> The most visual example I could come up with is this: >>> https://jsfiddle.net/fippo/9f0gte7x/3/ >>> Negotiates a connection, adds audio/video/data. Then stops the audio >>> transceiver and renegotiates with a delay. >>> You'll see the video freeze for four seconds (which is measured in the >>> statistics too). >>> Stopping the transceiver associated with the transport stops the video >>> flow to the remote and causes a freeze on the remote end until >>> renegotiation happens. >>> With the constraint that does not because the transport (associated with >>> the datachannel) is not affected by stopping the transceiver. >>> >>> Not having that, and being asked to ship this first, raises the risk, >>>> particularly absent customers/developers telling us how this is going to >>>> make lives better. >>>> >>> >>> Chromium "shipping first" is inevitable in WebRTC. Looking at the commit >>> counts of libWebRTC which is what all major engines use for the last five >>> years (data from October here >>> <https://github.com/w3c/webrtc-extensions/issues/213#issuecomment-3396184330> >>> ): >>> Google: 10000+ commits >>> Microsoft: 234 >>> Firefox: 34 >>> Safari: 0 >>> "web developers" have obviously noticed that too. >>> >>> cheers >>> >>> Philipp >>> >> Best, >>>> >>>> Alex >>>> >>>> On Wednesday, February 4, 2026 at 4:41:30 AM UTC-8 PhistucK wrote: >>>> >>> > 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/576c13ae-6ee8-4b08-bc6d-cceb3007fd3an%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/576c13ae-6ee8-4b08-bc6d-cceb3007fd3an%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/CAARdPYfOOqS9ayMLOJ-pEJVQ1J%2BcMmBQhQ9Q3Fg2mbFQQteBSA%40mail.gmail.com.
