Summary:	ASTERISK-06936: [patch] ability to detect unreachable or not working fastagi server
Reporter:	Alessandro Polverini (alessandro polverini)	Labels:
Date Opened:	2006-05-09 09:53:46	Date Closed:	2006-05-25 11:46:04
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_agi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 7121.patch ( 1) asterisk_7121_v2.patch ( 2) asterisk_7121_v3.patch ( 3) asterisk_7121_v4.patch ( 4) asterisk_7121.patch
Description:	It would be very useful to "understand" a fastagi server is not responding (maybe because the application server is down, or for a network error) so to have a fallback and continue the script in another way. Let's suppose I've a line: exten = x,n,Agi(agi://10.0.0.1/test.agi?par1=xyz) If the agi server is down the scripts stop with a warning and I can't handle the error. Having some kind of result code or jumping to a different priority would allow to understand that situation and follow another path, without having to stop the service, maybe just to signal the problem to the user
Comments:	By: Serge Vecher (serge-v) 2006-05-17 10:19:11 Alessandro: I believe a better course of action would to take this issue to a an asterisk-dev list for discussion. I'm leaving this open for a couple od days in case anybody wants to pick this up. By: Alessandro Polverini (alessandro polverini) 2006-05-20 13:04:59 I tried several times to post a message on the mailing list (yes, I'm subscribed) but it seems like I'm unable to. I tried also from several SMTP servers, without a better result. As a last resort I sent the message to kpfleming asking to forward it to the ML and he had the same problem! So, can please someone help me? Thanks, Alex By: Stefan Reuter (srt) 2006-05-21 06:52:23 The problem is that Asterisk just hangs up if there is a problem executing the AGI. This behavior does not allow any error handling in the dialplan. The attached patch (disclaimer on file) fixes this by always returning 0 (instead of -1 in case of a failure). Now the user can just set a channel variable in his AGI script (like AGI_RESULT) and check for that in the dialplan. P.S. patch is against latest SVN (rev 29163) By: Tilghman Lesher (tilghman) 2006-05-21 15:58:28 The problem with this for 1.2 is that it introduces a change in behavior.  If anybody is depending upon the fact that calls now hangup when the AGI is unable to connect, that would create a problem for them when calls fail to disconnect and instead wait for a new extension (when autofallthrough=no). If we change this at all, it's going to be in trunk only and probably only with a runtime option. By: Alessandro Polverini (alessandro polverini) 2006-05-21 16:06:34 And having it on 1.2 branch with a configuration parameter (off by default to preserve compatibility) would be an option? By: Stefan Reuter (srt) 2006-05-21 16:35:51 To be consistent with the other applications imho the "correct" behavior would be to set a channel variable (e.g. AGISTATUS) to either "FAILED" or "SUCCESS". Almost any application does it that way, why should this be different for AGI? Just hanging up is not very polite and leaves no chance to recover while with the approach suggested the user is still free to check for AGISTATUS and Hangup if he chooses to do so. I am not sure that backwards compatibility is much of an issue in this case. How many people depend on their AGI scripts being unavailable or their AGI server being down? I updated the patch to set the channel variable AGISTATUS. By: Alessandro Polverini (alessandro polverini) 2006-05-21 17:00:47 I tested the patch and it works great (I add to manually apply it to latest SVN revision tough). Could it be considered/discussed for 1.2.8 release? By: Tilghman Lesher (tilghman) 2006-05-21 22:32:40 Given that this is a new feature, it is highly unlikely to go into 1.2.  You're welcome to discuss with the 1.2 maintainer, however (russellb). By: Joshua C. Colp (jcolp) 2006-05-22 13:07:01 Meep Meep - backport to 1.2? meeeeep By: Russell Bryant (russell) 2006-05-23 16:49:24 I feel that this change should only be made in the trunk.  Please update the FastAGI application documentation to reflect the new variable we can get this merged into the trunk. Thanks By: Stefan Reuter (srt) 2006-05-23 17:42:29 added documentation as suggested by russel By: Stefan Reuter (srt) 2006-05-23 17:47:58 sorry - some spelling errors fixed in asterisk_7121_v4.patch hope we can get it into trunk now By: Russell Bryant (russell) 2006-05-23 17:52:37 After looking at this a little bit more, I think this patch will have to be slightly more involved.  The application will need to know the difference between different failure conditions.  For example: 1) The AGI script or connection to AGI server is successful, but we're exiting being the calling channel hung up.  In this case, the application still needs to return -1.  The AGISTATUS variable could be set to something like HANGUP in this case. 2) The AGI script could not be executed or the AGI server could not be reached.  This is the case which you desire to be different.  I think it's fine to return 0 in this case with AGISTATUS set to FAILURE. 3) The AGI script finished or the connection to the AGI server has been closed but the channel is still active.  We would want to return 0 and set AGISTATUS to SUCCESS. It's really only case #1 that is not being accounted for in this patch. By: Stefan Reuter (srt) 2006-05-23 18:30:45 How could we check for #1? is this currently done somewhere in res_agi? If yes, where? By: Russell Bryant (russell) 2006-05-25 11:46:03 I have committed an updated patch in revision 30272 that addresses the issues I brought up.  Thanks!