The Allow Recording DTMF Detection system setting explained

Allow Recording DTMF Detection is a single system-wide switch, and it is the one most people forget. It decides whether the platform listens for keypad tones during an active recording at all. Every per-campaign and per-group mute value depends on it. Leave it off and you can set mute seconds all day long with nothing happening, because the system never notices the tones in the first place.

What the setting controls

Keypad tones, known as DTMF signals, are the sounds a phone makes when someone presses a digit. This system setting turns on detection of those tones while a recording is running. On its own it does not mute anything. It is the sensor, not the action. The muting itself is driven by the per-campaign and per-In-Group values, which only mean something once the sensor is live. Think of detection as the platform-level enable and the mute seconds as the local behavior.

Because it is a system setting, it applies to the whole platform at once. You flip it on in one place and it makes tone-based DTMF muting possible everywhere. That is convenient, but it also means the switch carries weight: every campaign and group that wants muting is relying on this one flag being on.

How it works with campaigns and groups

flowchart TD
  A[Allow Recording DTMF Detection] -->|Off| B[No tone detection anywhere]
  A -->|On| C[Platform listens for tones]
  C --> D[Campaign mute seconds apply]
  C --> E[In-Group mute setting applies]
  D --> F[Outbound recordings muted]
  E --> G[Inbound recordings muted]
  B --> H[Tones recorded as audio]

Detection is global; muting is local. With the system setting on, a campaign mutes its recordings for the number of seconds set in its Recording DTMF Muting field after the first tone is detected. The same logic runs per In-Group for inbound calls. Turn the system setting off and all of those local rules go quiet, no matter what they are set to. This split is deliberate: you decide platform-wide whether tone detection is even allowed, then decide call-by-call group how aggressively to mute.

A practical consequence: if you are rolling out payment-safe recording, this is the first switch to flip, before you touch any Campaign values. Doing it in the other order leads to a frustrating round of testing where nothing mutes and the campaign settings look correct.

When you would leave it off

If you never take card numbers or other sensitive digits over the phone, you can leave detection off and accept that any tones land in the recording. Some teams prefer that because tone detection adds a small amount of processing to every recorded call. But if any campaign needs the data kept out of recordings for PCI work, the setting has to be on platform-wide, and the cost is negligible against the compliance benefit. The tradeoff is rarely close once payments are involved. Remember too that this is a single shared flag: once it is on for the payments campaign, it is on for every campaign and group at once, so the only place muting actually differs is in the per-group second values. Treat the system switch as the always-on foundation and tune the rest locally.

Once detection is on, the per-campaign behavior is covered in Recording DTMF Muting for PCI, and the bigger recording picture is in our call recording guide. To get a platform with these controls set up for you, see our pricing.