and we had https://blog.mozilla.org/webrtc/dtmf-now-available-firefox/ (for a 2017 "now") that describes the migration
MDN should probably nuke the fallback it mentions: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_DTMF Am Mi., 16. Sept. 2026 um 17:13 Uhr schrieb Philip Jägenstedt < [email protected]>: > First a point of clarification, the API is *createDTMFSender*, > not createDTMF, right? > > Here's the code snipped from https://github.com/webrtc/samples/pull/873: > > ```js > function enableDtmfSender() { > dtmfStatusDiv.textContent = 'DTMF activated'; > if (localStream !== null) { > var localAudioTrack = localStream.getAudioTracks()[0]; > dtmfSender = pc1.createDTMFSender(localAudioTrack); > trace('Created DTMFSender:\n'); > dtmfSender.ontonechange = dtmfOnToneChange; > } else { > trace('No local stream to create DTMF Sender\n'); > } > } > ``` > > If there's an old migration guide somewhere that can be referenced, that > would be good enough I think. Failing that, can the guidance be written in > a few sentences and included in the release blog post? > > On Wed, Sep 16, 2026 at 4:44 PM Rick Byers <[email protected]> wrote: > >> Do we have any published guidance for developers relying on this API >> today? Like, to what extent does a library / API exist somewhere as a >> drop-in replacement? From a quick search, does RTCDTMFSender >> <https://developer.mozilla.org/en-US/docs/Web/API/RTCDTMFSender> accomplish >> all the same things this old API did, and so makes for an easy drop-in >> replacement? If you were a developer for one such call center app and >> started getting these exceptions with no idea what they meant, what >> resources would you likely find in a web search? >> >> I'm definitely supportive of removing this non-standard API, we just need >> to show we've done what we reasonably can to make it easy for people to >> understand and migrate to standards-based alternatives. >> >> Thanks, >> Rick >> >> On Mon, Sep 14, 2026 at 5:16 PM Alex Russell <[email protected]> >> wrote: >> >>> LGTM1 contingent on Philip's suggestion of a feature flagged rollout and >>> the requested reviews. >>> >>> On Wednesday, September 9, 2026 at 8:22:41 AM UTC-7 Philip Jägenstedt >>> wrote: >>> >>>> Can you upgrade the chromestatus entry to the "ship" state and fill out >>>> all of the reviews, notably the enterprise review chip? >>>> >>>> The use counter is at >>>> https://chromestatus.com/metrics/feature/timeline/popularity/1642 and >>>> is around 0.001-0.003%. >>>> >>>> The compat risk is that code that calls pc.createDTMFSender() would >>>> start throwing an exception, and the size of the breakage depends on >>>> whether the exception is caught and where in the code it happens. >>>> >>>> Given the very low usage it doesn't seem helpful to have a deprecation >>>> period first, but it will be important to use a runtime flag for this so >>>> that can be turned back on with Finch if there's a problem. >>>> >>>> On Wed, Sep 9, 2026 at 1:19 PM 'Philipp Hancke' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> https://github.com/webrtc/samples/pull/873 >>>>> removed the sample for createDTMF nine years ago. Anyone who has not >>>>> updated... >>>>> The usual suspects (sipjs, jssip and twilio's JS) prefer the spec >>>>> variant so this should be safe. >>>>> >>>>> Compared to setRemoteDescription the usage of DTMF is marginal: >>>>> >>>>> https://webrtchacks.github.io/chromestatus/?buckets=1642,2381,3451&start=2026-01-01 >>>>> The RTCRtpSender.dtmf isn't clearly winning but at least it is ahead. >>>>> >>>>> The use counters can not tell you about callcenters running >>>>> Chromebooks and still using the chrome-only method though. >>>>> >>>>> Am Mi., 9. Sept. 2026 um 12:52 Uhr schrieb Yoav Weiss (@Shopify) < >>>>> [email protected]>: >>>>> >>>>>> Generally it'd be good to expand a bit about the compatibility risk >>>>>> here. It'd odd that the section is missing. >>>>>> >>>>>> On Wednesday, September 9, 2026 at 12:51:34 PM UTC+2 Yoav Weiss wrote: >>>>>> >>>>>>> Are there any usecounters indicating usage? (Or another method of >>>>>>> estimating potential breakage) >>>>>>> >>>>>>> On Friday, September 4, 2026 at 12:21:47 PM UTC+2 Chromestatus wrote: >>>>>>> >>>>>>>> *Contact emails* >>>>>>>> [email protected] >>>>>>>> >>>>>>>> *Explainer* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Specification* >>>>>>>> https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection >>>>>>>> >>>>>>>> *Summary* >>>>>>>> This is a legacy and obsolete method that does not exist in the >>>>>>>> WebRTC spec and the only major engine implementing it is Blink. >>>>>>>> Removing it >>>>>>>> is part of Interop 2026. >>>>>>>> >>>>>>>> *Blink component* >>>>>>>> Blink>WebRTC>PeerConnection >>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%3EPeerConnection%22> >>>>>>>> >>>>>>>> *Web Feature ID* >>>>>>>> webrtc <https://webstatus.dev/features/webrtc> >>>>>>>> >>>>>>>> *Motivation* >>>>>>>> This is a legacy and obsolete method that does not exist in the >>>>>>>> WebRTC spec and the only major engine implementing it is Blink. >>>>>>>> Removing it >>>>>>>> is part of Interop 2026. >>>>>>>> >>>>>>>> *Initial public proposal* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Goals for experimentation* >>>>>>>> None >>>>>>>> >>>>>>>> *Debuggability* >>>>>>>> N/A >>>>>>>> >>>>>>>> *Requires code in //chrome?* >>>>>>>> False >>>>>>>> >>>>>>>> *Tracking bug* >>>>>>>> http://crbug.com/553274713 >>>>>>>> >>>>>>>> *Measurement* >>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/1642 >>>>>>>> >>>>>>>> *Estimated milestones* >>>>>>>> Shipping on desktop 160 >>>>>>>> Shipping on Android 160 >>>>>>>> Shipping on WebView 160 >>>>>>>> >>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>> >>>>>>>> https://chromestatus.com/feature/5160724576993280?gate=5985122343059456 >>>>>>>> >>>>>>>> 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/af35054b-bf48-43fd-9bcb-bb6a6cfc5682n%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af35054b-bf48-43fd-9bcb-bb6a6cfc5682n%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/CADxkKiJa6SqiyekJvCXw8qWZrn-O5KYcDnhsLGHvbT1URardHA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJa6SqiyekJvCXw8qWZrn-O5KYcDnhsLGHvbT1URardHA%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/87d9ae6f-ec0e-40ec-83d5-af43a5956f22n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87d9ae6f-ec0e-40ec-83d5-af43a5956f22n%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/CADxkKiK6iXz4FjZGCXUsEw8quZav6t0Pt7ueCrccrWj98a1EpA%40mail.gmail.com.
