Intermittent IVR failure

I am new to FreePBX and have used it for a simple small office setup with a dozen Sangoma phones. An IVR has been set up to require any inbound calls to press a “0” to get through to the reception ring group, in an attempt to reduce annoyance calls, which has worked well.

Unfortunately, inbound callers complain intermittently of pressing “0” and looping back to the IVR at least once before either 1) getting to the reception ring group or 2) being hung up on. I have wireshark gathered for both expected and unexpected IVR behaviors, and a verbose Asterisk log during a recent “0” double loop test call.

What config files should I investigate to understand why the problem is intermittent?

Common causes:

On an analog line, there may be echo or doubletalk issues such that pressing a key during the announcement results in garbled DTMF that can’t be decoded. If this is your issue, key presses after the announcement ended would be reliable.

Also on an analog line, receive gain may be too high or too low. When outside callers do get through, do you hear them at normal volume?

On a VoIP trunk, using the wrong DTMF mode, or using g729 with inband DTMF.

Set up a Misc Application pointing to your IVR. Call it from an internal extension and test. If that works reliably, the trouble is likely on the trunk side.

Please describe your trunks, including channel type (pjsip, chan_sip, iax, dahdi) and any cards or gateways. If analog lines are involved, describe source (copper pair from CO, cable MTA, fiber ONT, etc.) If using any non-default DTMF settings, please explain.

VoIP trunk service is provided by Fusion which uses rfc2833. Outgoing sip settings Peer Details include dtmfmode=rfc2833, Incoming User Context and Details are both blank.

Chan sip settings use NAT to a static IP on our WAN switch. I believe DTMF is standard, not sure how to verify that though.

We have three inbound routes, CCI being the main one. I adjusted today the CCI inbound by turning Signal Ringing on, as the wiki suggested that may help. I also adjusted the CCI-Day IVR Force Strict Dial Timeout from Yes to No, as “0” is the button that virtually all our wanted callers press to talk to reception.

The wireshark pcap call flow DTMF shows “0” was sent four times, but it was just one press on my cell phone test call. When I listen to the RTP stream, there is a click when i pressed “0”, not an audible tone confirming rfc2833 is in use I think.

I wrote a ping script to make sure the FreePBX server ip was up and ran it from a linux box in Singapore. Only a few pings were dropped in about five days of testing so I think the connection is solid.

RFC2833 sends the start of a keypress multiple times (in case of packet loss) and also flags the end multiple times. I don’t know how the call flow interprets that. Look at the actual RTP packets to see what’s there. If they are properly formatted but the IVR didn’t ‘hear’ the press, something is wrong at the Asterisk level. Turn on DTMF logging in Asterisk Logfile Settings and report whether the missed keypresses appear in the log.

Thank you Stewart1 for the advice. I will have to learn how to look at the actual RTP packets tomorrow with Wireshark. I will set up the Asterisk DTMF logging first, then capture packets on the FreePBX server whilst making a test call also tomorrow, I am at the end of my day. Cheers.

Here are the abbreviated results of a “good” call, where dialing “0” gets you to the reception ring group as expected.
Packet capture (tcpdump -s0 -i eth0 -w ORL_inbound_good_rtp.pcap udp)

Asterisk log (with DTMF logging on)>

[2019-06-12 18:38:01] VERBOSE[10347][C-0000034d] pbx.c: Executing [s@ivr-2:11] ExecIf("SIP/FusionOut-0000065b", "1?Background(custom/Ortho_Reasearch_Open)") in new stack
[2019-06-12 18:38:01] VERBOSE[10347][C-0000034d] file.c: <SIP/FusionOut-0000065b> Playing 'custom/Ortho_Reasearch_Open.slin' (language 'en')
[2019-06-12 18:38:06] DTMF[10347][C-0000034d] channel.c: DTMF begin '0' received on SIP/FusionOut-0000065b
[2019-06-12 18:38:06] DTMF[10347][C-0000034d] channel.c: DTMF begin ignored '0' on SIP/FusionOut-0000065b
[2019-06-12 18:38:06] DTMF[10347][C-0000034d] channel.c: DTMF end '0' received on SIP/FusionOut-0000065b, duration 135 ms
[2019-06-12 18:38:06] DTMF[10347][C-0000034d] channel.c: DTMF end passthrough '0' on SIP/FusionOut-0000065b
[2019-06-12 18:38:09] VERBOSE[10347][C-0000034d] pbx.c: Executing [0@ivr-2:1] Set("SIP/FusionOut-0000065b", "__ivrreturn=0") in new stack
[2019-06-12 18:38:09] VERBOSE[10347][C-0000034d] pbx.c: Executing [0@ivr-2:2] Goto("SIP/FusionOut-0000065b", "ext-group,501,1") in new stack
[2019-06-12 18:38:09] VERBOSE[10347][C-0000034d] pbx_builtins.c: Goto (ext-group,501,1)

I have not been able to capture a “bad” call yet today. I will post this type of info again when I do.

Finally got a “bad” call logged. Pressed “0” twice and got hung up on.
Wireshark filtered packets just rtp events (DTMF):

Asterisk log excerpt:

[2019-06-12 20:37:03] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:11] ExecIf(“SIP/FusionOut-0000066c”, “1?Background(custom/Ortho_Reasearch_Open)”) in new stack
[2019-06-12 20:37:03] VERBOSE[29537][C-00000352] file.c: <SIP/FusionOut-0000066c> Playing ‘custom/Ortho_Reasearch_Open.slin’ (language ‘en’)
[2019-06-12 20:37:15] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:12] Read(“SIP/FusionOut-0000066c”, “IVREXT,0,3”) in new stack
[2019-06-12 20:37:17] DTMF[29537][C-00000352] channel.c: DTMF begin ‘0’ received on SIP/FusionOut-0000066c
[2019-06-12 20:37:17] DTMF[29537][C-00000352] channel.c: DTMF begin ignored ‘0’ on SIP/FusionOut-0000066c
[2019-06-12 20:37:17] DTMF[29537][C-00000352] channel.c: DTMF end ‘0’ received on SIP/FusionOut-0000066c, duration 140 ms
[2019-06-12 20:37:17] DTMF[29537][C-00000352] channel.c: DTMF end passthrough ‘0’ on SIP/FusionOut-0000066c
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] app_read.c: User entered ‘0’
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:13] GotoIf(“SIP/FusionOut-0000066c”, “0?t,1”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:14] GotoIf(“SIP/FusionOut-0000066c”, “1?i,1”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx_builtins.c: Goto (ivr-2,i,1)
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:1] Set(“SIP/FusionOut-0000066c”, “INVALID_LOOPCOUNT=1”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:2] GotoIf(“SIP/FusionOut-0000066c”, “0?final”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:3] Set(“SIP/FusionOut-0000066c”, “IVR_MSG=custom/Ortho_Reasearch_Open”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:4] Goto(“SIP/FusionOut-0000066c”, “s,start”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx_builtins.c: Goto (ivr-2,s,10)
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:10] Set(“SIP/FusionOut-0000066c”, “TIMEOUT(digit)=3”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] func_timeout.c: Digit timeout set to 3.000
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:11] ExecIf(“SIP/FusionOut-0000066c”, “1?Background(custom/Ortho_Reasearch_Open)”) in new stack
[2019-06-12 20:37:20] VERBOSE[29537][C-00000352] file.c: <SIP/FusionOut-0000066c> Playing ‘custom/Ortho_Reasearch_Open.slin’ (language ‘en’)
[2019-06-12 20:37:33] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:12] Read(“SIP/FusionOut-0000066c”, “IVREXT,0,3”) in new stack
[2019-06-12 20:37:34] DTMF[29537][C-00000352] channel.c: DTMF begin ‘0’ received on SIP/FusionOut-0000066c
[2019-06-12 20:37:34] DTMF[29537][C-00000352] channel.c: DTMF begin ignored ‘0’ on SIP/FusionOut-0000066c
[2019-06-12 20:37:34] DTMF[29537][C-00000352] channel.c: DTMF end ‘0’ received on SIP/FusionOut-0000066c, duration 140 ms
[2019-06-12 20:37:34] DTMF[29537][C-00000352] channel.c: DTMF end passthrough ‘0’ on SIP/FusionOut-0000066c
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] app_read.c: User entered ‘0’
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:13] GotoIf(“SIP/FusionOut-0000066c”, “0?t,1”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@ivr-2:14] GotoIf(“SIP/FusionOut-0000066c”, “1?i,1”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx_builtins.c: Goto (ivr-2,i,1)
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:1] Set(“SIP/FusionOut-0000066c”, “INVALID_LOOPCOUNT=2”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:2] GotoIf(“SIP/FusionOut-0000066c”, “1?final”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx_builtins.c: Goto (ivr-2,i,5)
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [i@ivr-2:5] Goto(“SIP/FusionOut-0000066c”, “app-blackhole,hangup,1”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx_builtins.c: Goto (app-blackhole,hangup,1)
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [hangup@app-blackhole:1] NoOp(“SIP/FusionOut-0000066c”, “Blackhole Dest: Hangup”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [hangup@app-blackhole:2] Hangup(“SIP/FusionOut-0000066c”, “”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Spawn extension (app-blackhole, hangup, 2) exited non-zero on ‘SIP/FusionOut-0000066c’
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] app_stack.c: SIP/FusionOut-0000066c Internal Gosub(crm-hangup,s,1) start
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:1] NoOp(“SIP/FusionOut-0000066c”, “Sending Hangup to CRM”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:2] NoOp(“SIP/FusionOut-0000066c”, “HANGUP CAUSE: 16”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:3] ExecIf(“SIP/FusionOut-0000066c”, “0?Set(__CRM_VOICEMAIL=)”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:4] NoOp(“SIP/FusionOut-0000066c”, “MASTER CHANNEL: 1560371822.1754 = 1560371822.1754”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:5] GotoIf(“SIP/FusionOut-0000066c”, “0?return”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:6] Set(“SIP/FusionOut-0000066c”, “__CRM_HANGUP=1”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:7] AGI(“SIP/FusionOut-0000066c”, “sangomacrm.agi”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] res_agi.c: Launched AGI Script /var/lib/asterisk/agi-bin/sangomacrm.agi
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] res_agi.c: <SIP/FusionOut-0000066c>AGI Script sangomacrm.agi completed, returning 0
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] pbx.c: Executing [s@crm-hangup:8] Return(“SIP/FusionOut-0000066c”, “”) in new stack
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] app_stack.c: Spawn extension (app-blackhole, hangup, 2) exited non-zero on ‘SIP/FusionOut-0000066c’
[2019-06-12 20:37:37] VERBOSE[29537][C-00000352] app_stack.c: SIP/FusionOut-0000066c Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=

Thanks in advance for any insight that these logs may hold.

Assuming that my inferences are correct:

In the good call, 0 was pressed 5 seconds into the announcement.

In the bad call, 0 was pressed (both times) after the announcement (which I believe is ~12 seconds long) ended. Of course, that shouldn’t matter but it seems that the dial plan code is either messed up or being executed wrong.

First, though your symptoms are very different, confirm that you don’t have one of the ‘bad’ Asterisk versions:

Next, see if you can replicate the problem by pressing 0 after the announcement is over.

If so, see if updating the IVR module helps. If not, adding a few seconds of silence to the end of the announcement may be a workaround, until we can find out what’s wrong.

If you still have trouble, please post a screenshot of your IVR settings, and the contents of the ivr-2 context.

Your inferences are correct. That is something that I had not considered, the timing of when a user presses “0”. I will capture logs and packets for “0” presses before and after the message has completed and post later today.

How do I examine the dial plan?

So this intermittent problem has been nagging us ever since the initial install six months ago. I update this server about every month, last time was last week before this recent round of testing we are discussing in this thread. Current version info follows:

Admin > Updates > Summary

Current PBX Version: 14.0.11
Current System Version: 12.7.6-1904-1.sng7

Admin > Updates > Module Updates

IVR: 14.0.4
Asterisk API: 13.0.2.5

Admin > Asterisk CLI > core show version

Asterisk 15.7.2 built by mockbuild @ jenkins7 on a x86_64 running Linux on 2019-03-19 23:19:26 UTC

How would I determine if I have 15.7.2-1, 15.7.2-2 or 15.7.2-3?

I would be happy to execute
yum install sangoma-devel &amp;&amp; yum upgrade
to get to the latest version and start over with testing.

Admin > Config Edit > Asterisk System Configuration Files > extensions_additional.conf

[ivr-2] ; ORL-Day
include => ivr-2-custom
include => from-did-direct-ivr
exten => fax,1,Goto(${CUT(FAX_DEST,^,1)},${CUT(FAX_DEST,^,2)},${CUT(FAX_DEST,^,3)})

exten => s,1,Set(TIMEOUT_LOOPCOUNT=0)
exten => s,n,Set(INVALID_LOOPCOUNT=0)
exten => s,n,Set(IVR_CONTEXT${CONTEXT}=${IVR_CONTEXT})
exten => s,n,Set(_IVR_CONTEXT=${CONTEXT})
exten => s,n,Set(__IVR_RETVM=)
exten => s,n,GotoIf($[“${CHANNEL(state)}” = “Up”]?skip)
exten => s,n,Answer
exten => s,n,Wait(1)
exten => s,n(skip),Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => s,n(start),Set(TIMEOUT(digit)=3)
exten => s,n,ExecIf($[“${IVR_MSG}” != “”]?Background(${IVR_MSG}))
exten => s,n,Read(IVREXT,0,3)
exten => s,n,GotoIf($[“${READSTATUS}” = “TIMEOUT” & “${IVREXT}” = “”]?t,1)
exten => s,n,GotoIf($[“${READSTATUS}” != “OK”]?i,1)
exten => s,n,GotoIf($[“${DIALPLAN_EXISTS(${CONTEXT},${IVREXT},1)}” = “0” & “${DIALPLAN_EXISTS(from-did-direct-ivr,${IVREXT},1)}” = “0”]?i,1)
exten => s,n,Goto(${IVREXT},1)

exten => 0,1,Set(__ivrreturn=0)
exten => 0,n(ivrsel-0),Goto(ext-group,501,1)

exten => i,1,Set(INVALID_LOOPCOUNT=$[${INVALID_LOOPCOUNT}+1])
exten => i,n,GotoIf($[${INVALID_LOOPCOUNT} > 1]?final)
exten => i,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => i,n,Goto(s,start)
exten => i,n(final),Goto(app-blackhole,hangup,1)

exten => t,1,Set(TIMEOUT_LOOPCOUNT=$[${TIMEOUT_LOOPCOUNT}+1])
exten => t,n,GotoIf($[${TIMEOUT_LOOPCOUNT} > 1]?final)
exten => t,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => t,n,Goto(s,start)
exten => t,n(final),Goto(app-blackhole,hangup,1)

exten => return,1,Set(IVR_CONTEXT=${CONTEXT})
exten => return,n,Set(IVR_CONTEXT${CONTEXT}=${IVR_CONTEXT
${CONTEXT}})
exten => return,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => return,n,Goto(s,start)

exten => h,1,Hangup

exten => hang,1,Playback(vm-goodbye)
exten => hang,n,Hangup

;–== end of [ivr-2] ==–;

yum list asterisk15

There have been recent changes to the IVR module, so I recommend you upgrade to edge and retest:

# fwconsole ma upgrade ivr --edge
# fwconsole ma list | grep ivr
| ivr                  | 14.0.9.3   |
1 Like

The dialplan code generated is IMO miscompiled, i.e. this is a FreePBX issue, not an Asterisk issue (and certainly not a trunk issue).

I believe that when
exten => s,n,Read(IVREXT,0,3)
is executed and the single digit 0 is entered, the value of READSTATUS returned is TIMEOUT; see
https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_Read
Then we execute
exten => s,n,GotoIf($["${READSTATUS}" = “TIMEOUT” & “${IVREXT}” = “”]?t,1)
and don’t take the timeout exit (because IVREXT is not null)
but then
exten => s,n,GotoIf($["${READSTATUS}" != “OK”]?i,1)
takes the invalid exit, which is a bug.

If 14.0.9.3 doesn’t fix it, please post a screenshot of the settings for the ORL-Day IVR, and well as the ivr-2 context if it’s changed.

Also, a couple of questions: Is this being actively used for fax? For dialing extensions directly? Any extension numbers beginning with 0?

BTW, think about switching to Asterisk 16 (or 13 if you must); see
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

SSH into FreePBX server > yum list asterisk15

15.7.2-1.sng7

Oh my! Well, I would prefer to update to Asterisk 16 instead of bumping up to 15.7.2-3.

Should I take IVR up to edge before or after updating to Asterisk 16?

What would be the yum command to update asterisk to 16.3.0?

Dealer’s choice, it makes no difference.

https://wiki.freepbx.org/display/PPS/Changing+Major+Asterisk+Versions+on+the+Fly

Stewart1,

Inbound fax comes through trunk to extension 301 then into a registered Cisco SPA122 converter that is cabled to our fax machine.

The IVR message states that if you know the parties extension, you may dial it at any time, but no one uses it, they just press “0”. Extensions for people are 201 through 206, places are 301 through 304.

upgraded IVR to 14.0.9.3 and asterisk to 16.3.0-1.sng7.
[iv2-2] is different, dropping lines 3 13 16 17 and 19 and modifying a few Read, ExecIf and GotoIf lines nearby:

[ivr-2] ; ORL-Day
include => ivr-2-custom

exten => fax,1,Goto(${CUT(FAX_DEST,^,1)},${CUT(FAX_DEST,^,2)},${CUT(FAX_DEST,^,3)})

exten => s,1,Set(TIMEOUT_LOOPCOUNT=0)
exten => s,n,Set(INVALID_LOOPCOUNT=0)
exten => s,n,Set(IVR_CONTEXT${CONTEXT}=${IVR_CONTEXT})
exten => s,n,Set(_IVR_CONTEXT=${CONTEXT})
exten => s,n,Set(__IVR_RETVM=)
exten => s,n,GotoIf($[“${CHANNEL(state)}” = “Up”]?skip)
exten => s,n,Answer

exten => s,n(skip),Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => s,n(start),Set(TIMEOUT(digit)=3)
exten => s,n,Read(IVREXT,${IVR_MSG},0,3)

exten => s,n,GotoIf($[“${READSTATUS}” = “TIMEOUT” & “${IVREXT}” = “”]?t,1)
exten => s,n,ExecIf($[“${DB(DEVICE/${IVREXT}/user)}” != “”]?Set(LOCALEXT=1))
exten => s,n,GotoIf($[“${DIALPLAN_EXISTS(${CONTEXT},${IVREXT},1)}” = “0” & “${DIALPLAN_EXISTS(from-did-direct-ivr,${IVREXT},1)}” = “0”]?i,1)
exten => s,n,GotoIf($[“${LOCALEXT}” = “1”]?from-did-direct-ivr,${IVREXT},1)
exten => s,n,Goto(${IVREXT},1)

exten => 0,1,Set(__ivrreturn=0)
exten => 0,n(ivrsel-0),Goto(ext-group,501,1)

exten => i,1,Set(INVALID_LOOPCOUNT=$[${INVALID_LOOPCOUNT}+1])
exten => i,n,GotoIf($[${INVALID_LOOPCOUNT} > 1]?final)
exten => i,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => i,n,Goto(s,start)
exten => i,n(final),Goto(app-blackhole,hangup,1)

exten => t,1,Set(TIMEOUT_LOOPCOUNT=$[${TIMEOUT_LOOPCOUNT}+1])
exten => t,n,GotoIf($[${TIMEOUT_LOOPCOUNT} > 1]?final)
exten => t,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => t,n,Goto(s,start)
exten => t,n(final),Goto(app-blackhole,hangup,1)

exten => return,1,Set(IVR_CONTEXT=${CONTEXT})
exten => return,n,Set(IVR_CONTEXT${CONTEXT}=${IVR_CONTEXT
${CONTEXT}})
exten => return,n,Set(IVR_MSG=custom/Ortho_Reasearch_Open)
exten => return,n,Goto(s,start)

exten => h,1,Hangup

exten => hang,1,Playback(vm-goodbye)
exten => hang,n,Hangup

;–== end of [ivr-2] ==–;

I won’t be able to test the upgraded system for another hour, I will post results soon.

We have logged thirty test calls so far in the last day and all have been “good”, working as expected. We tried pressing “0” before the message completed and waiting for it to finish.

I am not sure if the IVR upgrade improved the rendering of the [ivr-2] script or moving to asterisk 16.3.0 (I imagine the former) but it seems to be working now.

I want to thank you both very much for your time and expertise, this ongoing, nagging, intermittent problem has been a thorn in my side for some time now.

Is there a reputation bump system or some other way of formally thanking you?

1 Like

It was the former, but also good that you got off 15.7.2 as part of your debug.

Just a click of the little heart button for those oh-so-sweet imaginary internet points.

1 Like

I’m glad to hear that you got it working.

Try setting Force Strict Dial Timeout to No. This will eliminate the delay after pressing 0 (or after entering an extension number). It should not be needed, because you have no extensions beginning with 0.

1 Like

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