absorbDTMF is not working as expected

Asterisk Asterisk APIs
1

From what I understand after referring multiple threads and docs of asterisk is, In a bridge if we want to suppress the audio of DTMF(or to enable uniform tone of of DTMF) there is a parameter called absorbDTMF, If we add channel with this parameter the DTMF entered should not be audible(or uniform tone is heard) by other parties in the bridge. But this is not working as expected (using asterisk version 18.x.z).

Please let us know what are all the configurations should be used to achieve this.
DTMF type, bridge type and parameters, absorbDTMF flag while creating channel –> All possible values for these and also other parameters if I missed.

2

absorbDTMF in ARI prevents passing through of the DTMF frame, not of the audio. Audio should be stripped out before it gets to the bridge. If you’re hearing DTMF then you need to provide more information. What channel driver is in use? What is the configuration?

3

Drivers being used –>

Module Description Use Count Status Support Level

chan_audiosocket.so AudioSocket Channel 0 Running extended

chan_bridge_media.so Bridge Media Channel Driver 0 Running core

chan_iax2.so Inter Asterisk eXchange (Ver 2) 0 Running core

chan_mgcp.so Media Gateway Control Protocol (MGCP) 0 Running extended

chan_oss.so OSS Console Channel Driver 0 Running deprecated

chan_phone.so Linux Telephony API Support 0 Running deprecated

chan_pjsip.so PJSIP Channel Driver 0 Running core

chan_rtp.so RTP Media Channel 0 Running core

chan_skinny.so Skinny Client Control Protocol (Skinny) 0 Running extended

chan_unistim.so UNISTIM Protocol (USTM) 0 Running extended

Please let me me what configuration is needed from our end.

4

I’m going to assume you are using chan_pjsip. What is the configuration of the PJSIP endpoint? What DTMF method is in use? Is it the correct one? Do you hear a full tone of DTMF or a tiny blip?

5

pjsip endpoint configuration –>

[airtel.sip.com]

type = wizard

sends_auth = no

sends_registrations = no

remote_hosts = <a.b.c.d>

endpoint/direct_media = no

endpoint/disable_direct_media_on_nat = yes

server_uri_pattern = sip:${REMOTE_HOST}\;transport=udp

client_uri_pattern = sip:${REMOTE_HOST}\;transport=udp

contact_pattern = sip:${REMOTE_HOST}\;transport=udp

outbound_auth/username = dispatcher

endpoint/rtp_keepalive = 1 ;; adding this to prevent call drop when there is no media being sent

endpoint/context = from-internal ;;; change later

endpoint/disallow = all ;;; change later

endpoint/allow = ulaw ;;; change later

endpoint/allow = alaw ;;; change later

endpoint/dtmf_mode=rfc4733

endpoint/media_address=<a.b.c.d>

aor/qualify_frequency = 30

I am able to hear sounds clearly and able to clearly differentiate between the sounds.

6

This would mean that Asterisk is expecting DTMF to come in as RFC4733, which is not audio. It is up to the remote side to strip out the audio. If this isn’t happening, or is poorly done, then audio can continue to get passed through because Asterisk has no idea that it is DTMF. I would suggest doing either a packet capture OR using Record() as a test to record the audio stream. If the DTMF appears in the audio of either, then it is the remote side.

7

I have played audio and observed that I am not hearing any DTMF tones in the recorded audio. Just some kind of minimal uniform tones are heard but surely we cannot recognise it as DTMF.

8

Okay, so next up is to confirm Asterisk is not absorbing DTMF and is passing it through. What is the endpoint for what DTMF is going out on that you are hearing? If configured for RFC4733 DTMF mode do you see the DTMF in “rtp set debug on” going to it? If you do, have you confirmed that the ARI HTTP requests really do contain absorbDTMF?