Changing the order without an opt-in flag like this has backwards compat
concerns, even if WebRTC allows other orders, the other endpoint might be a
server with hardcoded assumptions about order, or there could be other
app-specific reasons why order matters. So it needs to be opt-in. Basides,
creating dummy data channels and trusting that the remote endpoint doesn't
use them isn't very eloquent.
On Tuesday, February 10, 2026 at 3:06:07 PM UTC+1 Robert Flack wrote:
> 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/384dcb28-c77f-4a98-9cce-14e3e65af005n%40chromium.org.
