FreePBX: IVR never goes to invalid (trying to implement an "access code" menu)

Hi there,

let me quickly describe first what I’m trying to do: I’m trying to set up an IVR that should simply act as some kind of access code menu. The idea is that when entering this IVR there is a voice prompt to enter a numeric code which then leads to another IVR.

(For the inevitable questions about my reasoning: The 2nd IVR allows reaching certain peoples extensions directly and the access code is to prevent “everyone” from doing it. It doesn’t need to be super secure, the worst thing that can happen here would be a loss of time for the callee)

Anyway, so I set up this IVR as follows:
Direct dialing is disabled.
Timeout retries are set to 0, timeout destination is hangup.
There is one entry, the 4 digit “access code” that leads to another IVR.

What I intended was that the caller gets 3 tries to enter the code. But: Any entries other than the code (this part works) lead to the timeout announcement and a hangup.

What I expected was that entering any other number would lead to the “Invalid” announcement.

So when I e.g. enter 7896 it shows up as follows in the log:

[2019-07-06 16:35:02] VERBOSE[3897][C-0000001d] pbx.c: Executing [s@ivr-1:12] ExecIf(“PJSIP/sip-mobile-00000020”, “1?Set(DIGITS=7896)”) in new stack
[2019-07-06 16:35:02] VERBOSE[3897][C-0000001d] pbx.c: Executing [s@ivr-1:13] While(“PJSIP/sip-mobile-00000020”, "1 ") in new stack
[2019-07-06 16:35:02] VERBOSE[3897][C-0000001d] pbx.c: Executing [s@ivr-1:14] Read(“PJSIP/sip-mobile-00000020”, “IVREXT,1,0,10”) in new stack
[2019-07-06 16:35:02] VERBOSE[3897][C-0000001d] app_read.c: Accepting a maximum of 1 digits.
[2019-07-06 16:35:12] VERBOSE[3897][C-0000001d] app_read.c: User entered nothing.

When I enter the code (1234) it logs as follows:

2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] app_read.c: User entered ‘4’
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [s@ivr-1:15] Set(“PJSIP/sip-mobile-00000021”, “IVR_MSG=”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [s@ivr-1:16] GotoIf(“PJSIP/sip-mobile-00000021”, “0?t,1”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [s@ivr-1:17] NoOp(“PJSIP/sip-mobile-00000021”, “”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [s@ivr-1:18] GotoIf(“PJSIP/sip-mobile-00000021”, “0?beforewhile:nodedial”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx_builtins.c: Goto (ivr-1,s,21)
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [s@ivr-1:21] Goto(“PJSIP/sip-mobile-00000021”, “1234,1”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx_builtins.c: Goto (ivr-1,1234,1)
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [1234@ivr-1:1] Set(“PJSIP/sip-mobile-00000021”, “__ivrreturn=0”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx.c: Executing [1234@ivr-1:2] Goto(“PJSIP/sip-mobile-00000021”, “ivr-2,s,1”) in new stack
[2019-07-06 16:35:46] VERBOSE[4128][C-0000001e] pbx_builtins.c: Goto (ivr-2,s,1)

Any pointers to what I might be doing wrong would be greatly appreciated! Thank you!

Some versions of the IVR module are buggy in this regard. I did a test with the latest version 14.0.9.4 and Force Strict Dial Timeout set to No. It worked properly. Try updating your module and retest. If you still have trouble, post another log.

Assuming that the DID is dedicated for this purpose, you may be able to eliminate the need to enter an access code. If only a few people will be using it, set up your Inbound Routes to check for those caller IDs and route directly to the second IVR. Or, route all calls to the second IVR, but use an intentionally misleading announcement, e.g. “Kein Anschluss unter dieser Nummer”. Tell the authorized users to dial the extension number during or immediately after this announcement.

Thank you for your reply.

I’m currently using version 15.0.14 of the IVR module and there seem to be no updates available for it.

Using the inbound caller IDs wouldn’t work for me because some of the people supposed to use this hide their caller ID by default (and “teaching” those people not to hide it for every call or simply not for these calls - well, that just “de facto impossible” :-))

To make things more complicated, these calls are not coming in through a nice SIP trunk with DID and everything but through a SIP-to-mobile gateway (which “auto connects” inbound calls to a (single) extension of my choosing).

Well that’s part of your problem. You’re on v15 which is still beta. Normal suggestions won’t apply as you’re using a version the majority haven’t gone to.

 fwconsole ma upgrade ivr --edge

# fwconsole ma list | grep ivr
| ivr                  | 15.0.19    | Enabled                           | GPLv3+      |
1 Like

You can almost certainly work around this with a ‘wholesale’ DID, most of which pass blocked calling numbers in the P-Asserted-Identity field. Two that IMO are suited to your situation:

  1. Voxbeam: Wholesale DIDs in Over 50 Countries . $6 setup + $1 per month. No charge for incoming calls, but limited to two channels and 10,000 minutes monthly.
  2. Anveo Direct: DID/DDI Wholesale prices . $6 setup + $0.50 per month + $0.004 per minute. No channel limitation.

Both provide a small credit at signup. It’s not enough to buy a DID, but you can confirm that the trunk works and make a few outgoing calls to check quality, before making a payment. I can’t be certain that the carrier they use for Germany (probably Voxbone) will pass P-Asserted-Identity, but my Voxbeam UK DID and AnveoDirect US DID both receive a valid header on calls from Germany with hidden caller ID.

What’s the make/model of the gateway? Some of them don’t play well with pjsip but you can have them register to a chan_sip trunk specifying host=dynamic. If your gateway has multiple SIMs it should be possible to have the user field of the SIP URI be different for each SIM, so you will get both the calling number (if not hidden) and called number on all incoming calls.

@lgaetz: Thank you so much for pointing out that was an updated version. It works now as intended. Guess I’m living on the edge now (or even more so as I was already using the beta version :()

@Stewart1: Interesting, I will test these providers if they do really pass the caller ID. I’m already using a SIP trunk from sipgate as the “main line” but I only get the number sporadically (I suppose I don’t know enough about telco networks to have an idea why that is - up until now, I actually thought the provider would not provide this information to the called party at all (or only in special cases, like e.g. you’re calling the police or other emergency services)).

Interesting. Do you see a pattern, e.g. only from some mobile operators, or only if the call is VoLTE?

I set up a number for you to test and will send it by PM. It plays the PAI in early media, so you shouldn’t be charged for the test calls. If the results are also sporadic, let us know which cases do and don’t work.

BTW, does sipgate allow you to send an arbitrary caller ID on outgoing calls? If not, you might find Voxbeam or AnveoDirect useful for Follow Me or other forwarding applications, to display the number of the original caller.

Hi Stewart! Thank you for setting this up! I tried it with my Sipgate account and, of course, it read my number back to me despite the hidden caller ID (which is interesting, because this is an account that belongs to a group of company accounts with assigned block of numbers - before calling, I deleted any extension number assignments (to be sure :)) and it still gave me the old number back (instead of the trailing “20” it could have been any number from 0 to 99)).

When I tested it with my mobile, it also knew my number. Hmm (Note to self: No more prank calls :-))

I tested it now (even with SIP logging on the console) with incoming calls from Sipgate and I didn’t get anything. The header only contains a line like this:

From: “anonymous” sip:[email protected];tag=1234bla

but nothing like P-Asserted-Identity or something related.

So it’s probably related to the way Sipgate handles this. I wonder why they obviously transfer my very secret number on outbound calls but I don’t get the same courtesy on inbound calls (maybe it’s a German telco regulation thing …)

I’ve written to Sipgate support, maybe they will say something about that.

(I’d even switch the SIP provider but if the transfer of the number block fails I would’ve made a big issue about a (comparably) minor inconvenience … I never really liked Sipgate :roll_eyes: )

And yes, Sipgate allows arbitrary caller IDs on outbound calls (the website says it must be one of the numbers assigned to the account but my tests say otherwise).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.