Thanks for the simple examples!
> 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().
If this works regardless could we make your simple example work when you
create the data channel first?
const pc = new RTCPeerConnection();
pc.createDataChannel(...);
pc.addTransceiver('video');
await pc.setLocalDescription();
Or is there a reason this would not be compatible, besides not matching the
prior spec?
> 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).
This is where I feel like we could have done with a shorter name, e.g. just
dataChannels: true or something.. If it's something that most developers
will always want to use, then it would be nice to be as simple as possible.
On Tue, Feb 10, 2026 at 7:03 AM Philip Jägenstedt <[email protected]>
wrote:
> 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/CAJh39TNfJYE8R%2BL3QjHeTd5KTpqJNkCXEV7tx86REecLxntJLQ%40mail.gmail.com.
