Hi Guys,
Earlier today my IVR was working just fine, Incoming call gets redirected to different extensions (press 1 or 2) depending on what the caller presses during the IVR Message Playback. Suddenly a few mins ago (Without changing anything in the asterisk config) The only DTMF being detected is if the caller presses #2. How do I troubleshoot this issue. Any help will be appreciated…
Thanks in Advanced
What do you mean by IVR? This is not an Asterisk concept, although it is a FreePBX one.
Enable DTMF logging. Set Verbose level 5. Apart from that, details will depend on how you have implemented IVRs.
HI David551
I have this in my dialplan
[ivr]
exten => s,1,Answer()
exten => s,2,Background(/var/lib/asterisk/sounds/custom)
exten => s,n,WaitExten(5)
exten => s,n,Goto(ivr,i,4)
exten => 1,1,NoOP(Frontdesk)
exten => 1,n,Goto(frontdesk,200,1)
exten => 2,1,NoOP(Sales-Call)
exten => 2,n,Goto(sales,100,1)
exten => i,1,NoOp(Invalid-Option-Selected)
exten => i,2,Background(pm-invalid-option)
exten => i,3,WaitExten(5)
exten => i,4,Dial(${OPERATOR},30,r)
exten => i,5,Playback(all-circuits-busy-now&please-hang-up-and-try-again&goodbye)
exten => i,6,Hangup()
All inbound call are redirected to this context, however, when the caller presses 1, asterisk doesnt seem to detect it but if #2 is pressed the call proceeds properly.
How is DTMF being singalled along the whole path from the caller? What codecs are being used on each hop? What does the DTMF log show being detected?
on my sip.conf i have
dtmfmode=rfc2833
During the call, the caller pressed 1 when he wasnt redirected he pressed 2 then this showed on the
DTMF logs
DTMF{2147][C-00000014: Channel.c:3909 __ast_read; DTMF begin ‘2’ received on SIP/09112223333-000000037
DTMF{2147][C-00000014: Channel.c:3909 __ast_read; DTMF begin ignored ‘2’ received on SIP/09112223333-000000037
DTMF{2147][C-00000014: Channel.c:3909 __ast_read; DTMF end ‘2’ received on SIP/09112223333-000000037, duration 100 ms
The DTMF is being lost before being converted to RC2833.
Please confirm that this is end to end SIP, and all hops use RFC2833 or RFC4733, as the most likely cause of a list digit is the use of inband audio on one hop. Also the most likely cause of inband audio loss is the use of unsuitable codecs (almost anything other than A-Law or Mu-Law…
You will need to capture the RTP and confirm that there is no DTMF 1 present, then trace the call back through the network and work out where it is being lost.