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
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.
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)
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.
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.