"t"-timeout is not honored by IVR

Beta Program Issues
1

i have
freepbx 2.9.0-beta1
asterisk 1.8.3
dahdi 2.4.1
ubuntu 10.10 kernel 2.6.32.16 ec2 at a xen vps

At IVR, “t” (timeout) extension is not honored.
Whatever is in t, either queue or extension, simply is not working.+
The extensions and queue are working if they are assigned to a dialed number, instead of the t.

The IVR after playing a welcome message stops, instead of following “t”.
The last log line that appears in asterisk console after the audio message playback is
Executing [s@ivr-7:13] WaitExten(“SIP/test-0000003e”, “,”) in new stack

I deleted the IVR and recreated but still the same.

I appreciate any help
thanks

2

thanks for fixing it.
ok, issue-ticketing is the way to go.

3

OK I filed a bug, #5094, as I don’t think anyone else has done so. In the future please do go ahead and file a ticket, it will result in much quicker fixes whether it’s our issue or Asterisk.

When the team goes through issues, we use the outstanding tickets as our guide/reminder.

So issues like this, even if there are long threads in the forums, get missed on each pass.

4

Sorry I did intend to open up a ticket but I just got busy with other stuff & forgot. Thanks for doing that and hopefully this can get fixed before 2.9 goes final.

5

please somebody help and tell us how we can troubleshoot this.
it is unbelievable

thanks!

6

In extensions_override_freepbx.conf put this

[general]
autofallthrough=no

7

tokotoko, I found that the system behaves properly for a certain number of hours after a dialplan reload (to my dismay) so I used cron to schedule an asterisk -rx"dialplan reload" towards the end of the day so our nighttime IVR’s “t” option works properly.

lsmir_S, this is from the sip.conf.sample

If autofallthrough is set, then if an extension runs out of things to do, it will terminate the call with BUSY, CONGESTION or HANGUP depending on Asterisk’s best guess (strongly recommended). If autofallthrough is not set, then if an extension runs out of things to do, asterisk will wait for a new extension to be dialed (this is the original behavior of Asterisk 1.0 and earlier).

I guess I can see the relevance here. I’ll give it a try, but I don’t understand why it works sometimes and not others.

8

Ismir_S this did not work.

neither diaplan reload helped.

any other proposal?

is this a matter of some internal timing machine, dahdi, dtmf, or some other configuation?

what part of the system is responsible for understanding the timeout?

9

Could you post the problematic IVR code?
Usualy, the timeout problem is related to autofallthrough option in general settings in extensions.conf. If you don’t wont your call goes to h extension you have to define WaitExten or set autofallthrough=no.

10

thanks ismir_s.
after all these i learned a bit more about how this system works.

i checked extensions_additional.conf
the problem was that waitexten was empty
exten => s,n,WaitExten(,)
i manually added a value like (2,0)
then at asterisk cli, dialplan reload
and my timeout extension works

The problem is that when i save any settings at freepbx (even not related to timeout/ivr), freepbx will wipe out the values again to the empty WaitExten(,).

i use latest freepbx 2.9. i had this problem with 2.8 too, and i upgrade in the hope to resolve this problem.

So this is probably a bug of freepbx in combination with something else.

I hope this will be resolved soon!

11

Has anyone bothered to check the Asterisk issue tracker, this sounds like an Asterisk bug.

The WaitExten has always had an optional timeout parameter and it defaulted to the TIMEOUT(response) value if not set.

Testing on 1.4 confirms this behavior. GIven that you are reporting it works for a while and then stops working, it’s something that should be fixed in Asterisk.

If setting the WatiExten() to the same value as the TIMEOUT(response) fixes the issue, we can look at adding that to the ivr code as a stop gap even though it should not be necessary, but if the behavior broke in Asterisk, it should be reported there and addressed.

12

I didn’t say that it works for a while. Alauppe said so.
Maybe alauppe’s problem is of different nature.

So where do we set the default TIMEOUT(response) value?

Why freepbx does not put the value that I define at its GUI, but just let an empty (,)?

Thank you

13

it is set in the TIMEOUT(response) variable which WaitExten() had always defaulted to in the past when not set.

Originally there wasn’t even a WaitExten() but when the autofallthrough behavior changed in 1.4, it was added to address the new behavior.

14

this guy seems to have similar problem.
http://www.freepbx.org/forum/freepbx/users/ivr-gui-not-writing-to-extensions-additional-conf
GUI not writing to extensions_additional.conf

At freepbx ivr GUI at Timeout field, i put the seconds (eg “1”), BUT this value is not written at extensions_additional.conf

Anyway, how and where i can set TIMEOUT(response) variable?

I did not understand how I can resolve my problem.

Thank you

15

where is this “it is set in the TIMEOUT(response) variable which WaitExten() had always defaulted to in the past when not set.” and how it is set?

thanks

16

It’s the Timeout option in the IVR, and it is set in the dialplan generated by the IVR prior to the WaitExten().

Have a look a the dialplan, it should be there.

17

I haven’t been able to key in here since Philippe joined the discussion. Philippe - thanks for your time on this.

What I found was that certain lengths of the timeout never worked (longer ones - 10+ seconds). I set the timeout to “1” in the UI, and it was honored in my tests. Then several hours later, it wasn’t working again. I did a reload and it started to work again. It was at this point that I cron’d a reload and haven’t had a problem since.

My impression was that it was a bug in Asterisk and that I was happy enough to have a work-around that ‘worked’ in the meantime. Of course I didn’t have a ton of time to look at it, so thats as far as I got.

18

Yup. Me too:
http://pbxinaflash.com/forum/showthread.php?t=10145

I don’t think WaitExten(,) is valid or if it is, it certainly seems like it should just set WaitExten to whatever the RESPONSE TIMEOUT of the IVR is set to. I manually changed my ivr code but of course every time I apply changed via the gui now it gets trashed. Hopefully this gets fixed asap!!

19

Patch is here

can someone say for sure whether this is a FreePBX issue or an Asterisk (1.8/SVN) one?

20

it will be lost, what’s the ticket number on it and has anyone reported it as a bug on the Asterisk forum.

The WaitExten is suppose to use the default timeout and always has, so if it stopped it’s an issue but if we have to we will fix it in FreePBX while waiting for Asterisk to get fixed, thus what’s the bug number so we can have a look and make sure it gets addressed.

Keep in mind, the reason it’s important to get these reported to the Asterisk team is that fixing it in FreePBX does not help the thousands of users who have custom dialplan added to FreePBX or just plane pure Asterisk users who get broken by this sort of bug introduced in Asterisk changes…