This is a follow up to an earlier question here, where I’m trying to suppress DTMF in a bridge. If everything is 2833, things are fine. The events are properly suppressed by asterisk, and participants don’t hear each others’ tones in the bridge. The challenge comes when tones are (at least partially) sent in-band. I did a pcap on the SBC, and the audio from the carrier shows that there spikes with fragments of DTMF tones right before “inserted silence”, which means there’s enough coming through to discern what they are, which is a problem for my application. What I suspect is happening here is that the upstream carrier is attempting to convert in-band tones to 2833, succeeding at generating the events, but not doing a great job at suppressing the in-band audio.
Other platforms I’ve worked with (the current version of this app is written in UCMA for Skype for Business server) handled this. The AVMCU in SFB was able to suppress these partial tones, which implies some level of software signal processing happening in the mixer that can detect this. I know this component also handled things like automatic gain control and audio normalization. What I’m wondering is whether there’s anything else I should be investigating in Asterisk that might have already solved this problem. I took a look at the Denoise diaplan app, but that didn’t seem to help here. At this point I’m thinking that I could do this externally by sending media from a channel through an audiosocket (or RTP channel), through an in-memory signal processor, and then back to a bridge, but if there’s a better approach, I’m open to ideas.
OK, thanks. What about defining a filter on a channel before being mixed into a server-side bridge? I haven’t found an API that’ll let me do that, so is my only option to do this as an external media sink?
I’m not sure what you mean by filter. There is no such thing in Asterisk proper, there is the denoise thing you mentioned, and there is an internal DSP implementation but that’s not exposed for this use - and I’m not even sure it would work because it’s written to do DTMF detection and not removal of small chunks of tones.
Any filter that completely eliminates DTMF tones needs to have lookahead. That means that it needs add additional delay to the audio, so that it can blank audio from before the point when the detection was confirmed.
Also, if the tones have already been partially suppressed, and that has been done well, it won’t be possible to blank the remnants without also erroneously blanking normal audio.
You can only accurately measure frequencies if they are of infinite duration. If you make a measurement over a finite duration, the result on the spectrum is to convolute (spread) out the apparent input frequencies by the Fourier transform of the sampling envelope. If you, say, clipped to a single 20ms frame, the frequencies would be spread over a range of 200 Hz, to the first zero (the actual spreading is infinite, if have sharp edges to the sampling window. TheFourierTransform.com - Fourier Transform of the Box Function
By smoothing the edges of the sampling window, you can stop things going off to infinity, bu can’t stop spreading close in.
The minimum durations for DTMF tones will not leave a lot of margin in terms of reliably identifying the tones, and if you can’t identify the tones, it becomes difficult to determine that they were DTMF pairs.
If your concern is security, it is possible, given other clues as to what represent DTMF tones, to decode them even with blurred spectra (much like you can sometimes work out what the original was when people blur to obfuscate IP addresses, or only partially obliterate the characters). However, in that case you really need to stop them ever having been in-band, or have a human being find and remove them (which is obviously not a real time operation).
Thanks David-that’s actually kind of what I was thinking of (putting an application between the channel and the bridge and introducing a delay to process audio before it goes to the bridge). I didn’t anticipate it being easy, and your description reminds me just how much I’ve forgotten about signals. I know that Microsoft is doing it in the SFB MCU though, so it has to be possible.
Ideally, I’d be able to keep all in-band tones out, but it seems like certain carriers are sending those partially clipped tones. This was a call from a Bell mobile via an Allstream SIP trunk that’s configured as 2833, so if I had to guess it’d be inband on Bell and then converted by Allstream in between.
The concern is security though-we do this today in our contact center platform for DTMF based credit card capture. It means I can have a caller and agent on a call together, the caller can input a CC number through DTMF, and the agent and any attached call recorders can’t hear the tones. Given that the time frame for something like this is limited, my thought was to apply this delay/inspect/filter algorithm temporarily when a call is flipped into a “secure DTMF” mode, and stop when it’s not absolutely necessary by moving the channel back into the bridge.