Direct Dial not working

Direct Dial isn’t working for me. I just installed the newest TrixBox 2.8.0.3, got all of our company’s IVR’s added, and everything. Here’s the flow of the “not working” part:

  1. XXX-XXX-XXXX - Our company’s toll-free number
  2. The IVR picks up… "Thank you for calling. If you know your party’s extension, please enter it at any time. Press 1 for Tech Support, Press 2 for Customer Service.
    In this first IVR, I have “Enable Directory” & “Enable Direct Dial” checked. Also the number 1 for the first option and 2 for the second… they’re both going to a Queue.
    If I press 1, the PBX comes back with, “Sorry, that’s not a valid extension, please try again.” If I press my extension number, the PBX says the same thing. Here is the output from the Asterisk CLI:

Connected to Asterisk 1.6.0.10-FONCORE-r40 currently running on pbx (pid = 2875)
Verbosity is at least 3
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
== Using SIP VRTP TOS bits 136
== Using SIP VRTP CoS mark 6
– Executing [xxxxxxxxxx@from-pstn:1] Set(“SIP/64.152.60.74-b7640608”, “__FROM_DID=xxxxxxxxxx”) in new stack
– Executing [xxxxxxxxxx@from-pstn:2] Gosub(“SIP/64.152.60.74-b7640608”, “app-blacklist-check,s,1”) in new stack
– Executing [s@app-blacklist-check:1] GotoIf(“SIP/64.152.60.74-b7640608”, “0?blacklisted”) in new stack
– Executing [s@app-blacklist-check:2] Return(“SIP/64.152.60.74-b7640608”, “”) in new stack
– Executing [xxxxxxxxxx@from-pstn:3] ExecIf(“SIP/64.152.60.74-b7640608”, “1 ?Set(CALLERID(name)=xxxxxxxxxx)”) in new stack
– Executing [xxxxxxxxxx@from-pstn:4] Set(“SIP/64.152.60.74-b7640608”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
– Executing [xxxxxxxxxx@from-pstn:5] Set(“SIP/64.152.60.74-b7640608”, “CALLERPRES()=allowed_not_screened”) in new stack
– Executing [xxxxxxxxxx@from-pstn:6] Goto(“SIP/64.152.60.74-b7640608”, “timeconditions,1,1”) in new stack
– Goto (timeconditions,1,1)
– Executing [1@timeconditions:1] GotoIfTime(“SIP/64.152.60.74-b7640608”, “10:00-15:59|sat-sun||?ivr-2,s,1”) in new stack
– Executing [1@timeconditions:2] GotoIfTime(“SIP/64.152.60.74-b7640608”, “09:00-19:29|mon-fri||?ivr-2,s,1”) in new stack
– Goto (ivr-2,s,1)
– Executing [s@ivr-2:1] Set(“SIP/64.152.60.74-b7640608”, “MSG=custom/DayMenu”) in new stack
– Executing [s@ivr-2:2] Set(“SIP/64.152.60.74-b7640608”, “LOOPCOUNT=0”) in new stack
– Executing [s@ivr-2:3] Set(“SIP/64.152.60.74-b7640608”, “__DIR-CONTEXT=default”) in new stack
– Executing [s@ivr-2:4] Set(“SIP/64.152.60.74-b7640608”, “_IVR_CONTEXT_ivr-2=”) in new stack
– Executing [s@ivr-2:5] Set(“SIP/64.152.60.74-b7640608”, “_IVR_CONTEXT=ivr-2”) in new stack
– Executing [s@ivr-2:6] GotoIf(“SIP/64.152.60.74-b7640608”, “0?begin”) in new stack
– Executing [s@ivr-2:7] Answer(“SIP/64.152.60.74-b7640608”, “”) in new stack
– Executing [s@ivr-2:8] Wait(“SIP/64.152.60.74-b7640608”, “1”) in new stack
– Executing [s@ivr-2:9] Set(“SIP/64.152.60.74-b7640608”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3
– Executing [s@ivr-2:10] Set(“SIP/64.152.60.74-b7640608”, “TIMEOUT(response)=10”) in new stack
– Response timeout set to 10
– Executing [s@ivr-2:11] Set(“SIP/64.152.60.74-b7640608”, “__IVR_RETVM=”) in new stack
– Executing [s@ivr-2:12] ExecIf(“SIP/64.152.60.74-b7640608”, “1?Background(custom/DayMenu)”) in new stack
– Playing ‘custom/DayMenu.slin’ (language ‘en’)
– Invalid extension ‘555’ in context ‘ivr-2’ on SIP/64.152.60.74-b7640608
== CDR updated on SIP/64.152.60.74-b7640608
– Executing [i@ivr-2:1] Playback(“SIP/64.152.60.74-b7640608”, “invalid”) in new stack
– Playing ‘invalid.gsm’ (language ‘en’)
– Executing [i@ivr-2:2] Goto(“SIP/64.152.60.74-b7640608”, “loop,1”) in new stack
– Goto (ivr-2,loop,1)
– Executing [loop@ivr-2:1] Set(“SIP/64.152.60.74-b7640608”, “LOOPCOUNT=1”) in new stack
– Executing [loop@ivr-2:2] GotoIf(“SIP/64.152.60.74-b7640608”, “0?hang,1”) in new stack
– Executing [loop@ivr-2:3] Goto(“SIP/64.152.60.74-b7640608”, “ivr-2,s,begin”) in new stack
– Goto (ivr-2,s,9)
– Executing [s@ivr-2:9] Set(“SIP/64.152.60.74-b7640608”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3
– Executing [s@ivr-2:10] Set(“SIP/64.152.60.74-b7640608”, “TIMEOUT(response)=10”) in new stack
– Response timeout set to 10
– Executing [s@ivr-2:11] Set(“SIP/64.152.60.74-b7640608”, “__IVR_RETVM=”) in new stack
– Executing [s@ivr-2:12] ExecIf(“SIP/64.152.60.74-b7640608”, “1?Background(custom/DayMenu)”) in new stack
– Playing ‘custom/DayMenu.slin’ (language ‘en’)
== Spawn extension (ivr-2, s, 12) exited non-zero on ‘SIP/64.152.60.74-b7640608’
– Executing [h@ivr-2:1] Hangup(“SIP/64.152.60.74-b7640608”, “”) in new stack
== Spawn extension (ivr-2, h, 1) exited non-zero on ‘SIP/64.152.60.74-b7640608’

(xxxxxxxxxx=hidden phone numbers)
The extension I just typed in on my phone was “5510” and as you can see, Asterisk is seeing extension “555” …I don’t have an extension “555” …so that’s where my issue is. But… WHY??? Also, if I uncheck the Direct Dial option on the IVR and choose 1 for Tech Support, it works fine and I get dropped into the Queue. So it’s just the Direct Dial option that’s giving me grief.
Thanks for any help this awesome forum can give me!

If this is a configuration problem, rather than a bug, it is a sip.conf problem, not a dialplan one. There are various issues on the issue tracker about unreliable DTMF handling, but first you need to indicate which DTMF options you are using.

Under the TRUNKS section, I’m using these settings: (It’s a SIP trunk by the way)

OUTGOING SETTING:
PEER Details:

context=from-pstn
dtmfmode=rfc2833
host=xxx.xxx.xxx.xxx
type=peer

INCOMING SETTING:
USER Details:

context=from-pstn
dtmfmode=rfc2833
host=xxx.xxx.xxx.xxx
type=user

I have tried both “dtmfmode=inband” and “dtmfmode=auto” and neither work… actually inband doesn’t pass any tones through at all. I also tried to add “relaxdtmf=yes” into my sip_custom.conf and still double or even triple digits being caught by the IVR. I type in extension 5510 and it picks up 555… or I type in 1 and it picks up 11. Weird.

Our setup is from our provider BroadVox, they send calls to an IP which is sent to a SHOUT system we have. The from the SHOUT we forward the incoming numbers to the TrixBox. From the TrixBox we add “Incoming Routes” and point them to IVR’s, Ring Group’s, Queue’s, etc… It’s only when we use IVR’s with the option “Direct Dial” we get this problem.

inband will only really work with G.711. G.729 and GSM are only suitable for speech, although they might still transmit garbled DTMF.

I think you need to look at issues.asterisk.org, as there are quite a few issues about unreliable DTMF handling, including duplicated digits. However, I’m not sure which have been resolved and in which version.

Do you think that this has anything to do with the way my sip_general_custom.conf is configured… since you said codecs have something to do with this issue?

sip_general_custom.conf
context=from-trunk
tos=0x68
disallow=all
allow=g729
;allow=ulaw
;allow=alaw
;allow=h263
;allow=h263a
;allow=h264

I checked issues.asterisk.org and I can’t find anything regarding the issue I’m having.

you do not mention what phone you are using to conduct the tests. I encountered this problem when one of our IVR developers started using an Apple iPhone to test out his work. After a while we were able to show the iPhone was sending repeat DTMF …so 507 would show up as 550077. The iPhones were were transmitting tones that were long [barely in specification] and were triggering asterisk to see the tones as double. There are a number of posts relating to this on Apple developer forums.

Well… I’ve tried calling in with my Blackberry Storm 2, an iPhone, and a BlackBerry Pearl. None of those work. But, if I pick up one of the extensions behind the same PBX, dial out (which goes out using our provider and back in), type in the extension I want… it works!

I’ve also tried dtmfmode=inband with:

disallow=all
allow=ulaw

It works right with any phone I use… but then I can not make outgoing calls. I think that’s because we have all of our phones set to use G.729 specifically. (We moved from an older PBX to this in just a “swap” kind of way… we’re trying to just get it working with the way our phones are set now.)