DTMF not consistent and stable

Asterisk Asterisk Support
1

Hello everyone,

In my Asterisk CLI. The DTMF is not working when I set it on the sip.conf file to rfc2833 so in my dialplan use this method to force the SYSTEM to use DTMF

same => n,SIPDtmfMode(RFC2833)

It has been manageable even when I know it should not have been like that. But recently I realized some numbers are not detected instantly unlike other numbers when entered

Executing [proceed@forward:1] NoOp(“SIP/46.19.209.14-000ec883”, “”) in new stack
– Executing [proceed@forward:2] SIPDtmfMode(“SIP/46.19.209.14-000ec883”, “RFC2833”) in new stack
– Executing [proceed@forward:3] Read(“SIP/46.19.209.14-000ec883”, “phonenumber,/var/lib/asterisk/sounds/es/enter_destination_pound,8,1,3”) in new stack
– Accepting a maximum of 8 digits.
– <SIP/46.19.209.14-000ec883> Playing ‘/var/lib/asterisk/sounds/es/enter_destination_pound.slin’ (language ‘es’)
> 0x7fc7e496e060 – Probation passed - setting RTP source address to 46.19.209.80:38414
– User entered nothing.
– Executing [proceed@forward:4] Read(“SIP/46.19.209.14-000ec883”, “phonenumber=”) in new stack
– User entered ‘51572368’

So it is already setting the variable phonenumber to empty before it realizes it. How do I resolve this

2

You would need to do an “rtp set debug on” to see when the DTMF is actually being received.

3

@jcolp Thank you for your reply. The rtp set debug on seems to show many responses. I dont know which is relevant

4

If it’s an active system then you have to figure out which IP address and port, and look based on that. Within that DTMF will stand out - it’s usually payload 96 or 101.

5

Look at what I am getting from the response

Sent RTP P2P packet to 46.19.209.79:42232 (type 18, len 000020)
Sent RTP P2P packet to 46.19.209.79:42232 (type 18, len 000020)
Sent RTP P2P packet to 209.51.192.170:14726 (type 18, len 000020)
Sent RTP P2P packet to 209.51.192.170:14726 (type 18, len 000020)
Sent RTP P2P packet to 209.51.192.170:14726 (type 18, len 000020)
Sent RTP P2P packet to 46.19.209.79:42232 (type 18, len 000020)
Sent RTP P2P packet to 46.19.209.79:42232 (type 18, len 000020)
Sent RTP P2P packet to 209.51.192.170:14726 (type 18, len 000020)

6

Those are audio, not DTMF.

7

Payload type 18 is G.729, which I think is a vocoded format,and therefore not suitable for DTMF.

I’m pretty sure that setting DTMF mode does not cause a re-INVITE, so will not change the incoming way that digits are received (rfc2833 causes DTMF not to be used, but rather special media frames).

You need to find out why dtmfmode, in sip.conf is not working, because that is your real problem. For incoming digits, changing it later, even if does cause a re-INVITE, is not going to help. The problem will lie with the peer, or its configurationi.

8

For my sip.conf file. This is what I have

[general]
context=newfoundcalls
allowguest=yes
alwaysauthreject=yes
srvlookup=yes
udpbindaddr=0.0.0.0
tcpenable=no
match_auth_username=yes
allowoverlap=no
allowtransfer=no
canreinvite=yes
disallow=all
allow=g729
allow=ulaw
allow=alaw
directmedia=no
dtmfmode=rfc2833
qualify=yes

9

@david551 I dont understand the above statement. I have tried to disallow the G729 in the sip.conf file

10

The DTMF is actually being received after the next executed program is executed. One issue I think that can fix this is if I can get DTMF to work at sip.conf file but I have no luck yet.