[Home]

Summary:ASTERISK-06759: AGI behavior on fail
Reporter:Christian Müller (christianmueller)Labels:
Date Opened:2006-04-11 17:55:50Date Closed:2006-05-25 13:32:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When a local AGI call fails, e.g. Agi(getcallername.php|extension=${DID}) dialplan execution resumes with the next higher priority.

On the other hand whenever a remote AGI call fails, e.g. Agi(agi://192.168.4.3/getcallername.agi?extension=${DID}) when the 192.168.4.3 is down or the AGI server has crashed then Asterisk does its best to quit out of all macros and hangup the call as quickly as possible.

It would be good to have the same behavior in both cases, that is resume execution with the next priority, or at least have a switch to choose whether to continue or abort. The current situation is quite bad because I'm only running unessential services that might require a lot of time and need to be aborted before the waiting time is too long, but still complete in the background, like for example above mentioned reverse lookups on the WWW for phone number/name mappings.

Thank you for your great work on Asterisk so far and your attention to this matter.
Comments:By: Clod Patry (junky) 2006-04-11 22:09:49

exten => 6943,1,AGI(http://192.168.1.3/foo.agi);
exten => 6943,2,SayDigits(123);


will result with:
   -- Executing AGI("SIP/10-5902", "http://192.168.1.3/foo.agi") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/http://192.168.1.3/foo.agi
 ==  http://192.168.1.3/foo.agi: Failed to execute '/var/lib/asterisk/agi-bin/http://192.168.1.3/foo.agi': No such file or directory
   -- AGI Script http://192.168.1.3/foo.agi completed, returning 0
   -- Executing SayDigits("SIP/10-5902", "123") in new stack
   -- Playing 'digits/1' (language 'en')
   -- Playing 'digits/2' (language 'en')
   -- Playing 'digits/3' (language 'en')
 == Auto fallthrough, channel 'SIP/10-5902' status is 'UNKNOWN'


which is what you looking for no?
By: Tilghman Lesher (tilghman) 2006-04-12 00:34:14

junky:  Change your AGI to 'http://192.168.1.251/foo.agi'.  I suspect that this will emulate his problem (not being able to connect).
By: Christian Müller (christianmueller) 2006-04-12 01:43:56

To clarify what I'm talking about: When I have Asterisk contact an AGI server whose machine is physically down or just the AGI software itself has just crashed then Asterisk will exit out of every nested macro and break the call which is opposite to the behavior of calling a local AGI file which just resumes with the next priority.

I have captured the following from a test system to demonstrate:

   -- Executing AGI("SIP/192.168.4.2-081bccf8", "agi://192.168.4.2/blah.agi") in new stack
 == Spawn extension (from-sip-external, 33, 1) exited non-zero on 'SIP/192.168.4.2-081bccf8'

You see, whether or not the destination AGI server has crashed or the whole machine is unavailable I get "Spawn extension (context,extension,priority) exited non-zero on 'SIP/something' through all nested macro calls and then the call will be terminated.

What junky has shown is what I'm looking for. So far I have not set autofallthrough because the VoIP-Wiki said that if it is set Asterisk will terminate the call with Busy, Congestion or Hangup by Asterisk's best guess which is not at all what I want it to do.

Thank you for your ideas, I will go play with my test system now and see if this will help.

P.S.: I've set autofallthrough=yes in the [general] section of extensions.conf and even stopped and started Asterisk, but it didn't change anything.
junky: I just noticed now, but it seems your remote AGI invokation is not right. The documentation shows a different syntax for invoking remote AGI services, see here: http://www.voip-info.org/wiki-Asterisk+FastAGI
So the code in your example probably would have to look like this:

exten => 6943,1,AGI(agi://192.168.1.3/foo.agi);
exten => 6943,2,SayDigits(123);


By: Tilghman Lesher (tilghman) 2006-04-14 02:01:37

I know exactly why it's doing it.  The question now is whether it is ever desireable to have the current behavior or whether the current behavior should be regarded as a bug to be fixed.

If it's a bug, we can change it in 1.2.  If it's not a bug, it's restricted to trunk, and we need to have an option that controls which behavior is used.
By: Clod Patry (junky) 2006-04-14 07:09:40

i will take a deeper look at this.
By: BJ Weschke (bweschke) 2006-05-08 09:46:47

My personal feeling on this is we should probably have a setting/option on what to do on AGI failure. We could have a default/global setting and then that could be overidden by way of setting a channel variable prior to AGI execution. This is probably going to be /trunk work, but I do agree with the original poster's comments that behavior on failure should be consistent between the two.
By: Clod Patry (junky) 2006-05-08 10:01:23

Ive worked on AGISTATUS few months ago.
I'll try to release it this week.
By: Russell Bryant (russell) 2006-05-25 11:51:22

I just committed a patch for issue 7121 that adds an AGISTATUS variable.  In theory, the channel should only be hung up now if the channel actually requested hangup during the execution of the AGI.
By: Russell Bryant (russell) 2006-05-25 13:32:13

Please open a new issue if you experience any problems in the current implementation.  Thanks!