Hi, i’m new to asterisk but I red lots of documentation. After trying about two hour to figure out how to use the Set(TIMEOUT(response)) fonction, I’m asking you guys.
Here is a copy of my simple IVR (extensions.conf):
The problem is that after reading the greeting sound file, the channel hang up. The Set(TIMEOUT(digit)) is working well but not the response one. Any one could help ?
I don’t do anything EXACTLY like this, but I think I know what’s going on.
I think asterisk is falling off the end of the extension and just exiting. This is the behavior you get with the (new in 1.2) default setting of autofallthrough
(From the sample extensions.conf that comes with a new 1.2 installation):
; 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).
;
autofallthrough=yes
So… you could try setting autofallthrough=no (I think this will cause asterisk to just sit and wait for another extension to be dialed (and of course your context will need to handle whatever extension they dial, as well as handling timeouts and invalids… ask if you need help on any of that)).
An alternative is to use background to playback silence while you’re waiting for digits. Say your greeting takes 5 seconds. You want to leave room for another 5 seconds for the caller to enter an extension. You could add
exten => 40,n,Background(silence/5)
right after your Background(greeting) line.
All I meant was that I don’t think I have any cases where the Background command is the last command in an extension, so I don’t really have the case where execution “falls off the end” of an extension. As such, I didn’t notice any problems when changing from 1.0 to 1.2 (where the autofallthrough default setting changed).
Oh, one other thing. I quoted the example where it says “recommended” for autofallthrough=yes (at least that’s the way I read it), so you might want to investigate if there are any other “bad” side-effects of setting it to no. Since it appears to inconvenience this common case (your example), I assume there’s good reason for setting the default to yes. While setting it to no does workaround your problem, there may be some lurking side effect you need to be aware of. I just haven’t had occasion to research it. Maybe someone here knows and can comment?
This function has probably been implanted to avoid unresolved path in the dial plan. Like this quote suggest, I have turned the “autofallthrought” option on but I’m now using WaitExten(seconds) instead of Set(TIMEOUT)response. This way, I avoid lurking side effect if there are any.