Asterisk AGI randomly returning 4 and failing to execute PHP AGI

Question

I've got a PHP script that I execute 2-3 times throughout a single calls life time, if it is inbound it will execute once for the queue, once for start of call and a last time for end of call. For outbound it skips the queue stage (obviously).

About 1 in every 1,000-2,000 calls the last event, end of call, errors, there does not seem to be a pattern in time or conditions of the call.

In the logs this is what I get (trimmed down the noise)

-- Executing [h@sub-queue-bookings:1] Set("SIP/CL-000298d4", "CALLWHEN=END") in new stack
-- Executing [h@sub-queue-bookings:2] AGI("SIP/CL-000298d4", "presence_2.php") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/presence_2.php
AGI Tx >> agi_request: presence_2.php
AGI Tx >> agi_channel: SIP/CL-000298d4
AGI Tx >> agi_language: en_AU
AGI Tx >> agi_type: SIP
AGI Tx >> agi_uniqueid: 1405038747.11111
AGI Tx >> agi_version: 1.8.5.0
AGI Tx >> agi_callerid: anonymous
AGI Tx >> agi_calleridname: NZ anonymous
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: anonymous
AGI Tx >> agi_rdnis: unknown
AGI Tx >> agi_context: sub-queue-bookings
AGI Tx >> agi_extension: h
AGI Tx >> agi_priority: 2
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode: 
AGI Tx >> agi_threadid: 139985928873744
AGI Tx >> 
-- AGI Script presence_2.php completed, returning 4

I added in a logging function on to the script to write to the script whenever it runs, before AGI library (PHPAgi) get's included, when this error occurs it does not write to the log. So I don't believe it has anything to do with the AGI communication on the script

The extension.conf that calls the script looks like this:

;Hangup Event
exten => h,1,Set(CALLWHEN=END)
exten => h,n,AGI(presence_2.php)

I have also included the following in the PHP script in an effort to prevent it being killed off (it didn't seem to make a difference):

/* Evil Process Block Fixing Code */
declare(ticks = 1);
pcntl_signal(SIGHUP, SIG_IGN);
pcntl_signal(SIGPIPE, SIG_IGN);
pcntl_signal(SIGILL, SIG_IGN);
pcntl_signal(SIGQUIT, SIG_IGN);
pcntl_signal(SIGABRT, SIG_IGN);
pcntl_signal(SIGSEGV, SIG_IGN);
pcntl_signal(SIGTERM, SIG_IGN);

What advice can someone give me to prevent this from happening? (Adding something to the PHP script, check x, rewrite the extensions.conf, log some extra information, etc). I'm fairly stumped, I've googled around and found a few people experiencing almost the exact same thing as me, but no solutions except for "deal with it".....

This is what a "regular" AGI execution looks like:

 -- Executing [h@sub-queue-sales:1] Set("SIP/CL-00029e74", "CALLWHEN=END") in new stack
 -- Executing [h@sub-queue-sales:2] AGI("SIP/CL-00029e74", "presence_2.php") in new stack
 -- Launched AGI Script /var/lib/asterisk/agi-bin/presence_2.php
<SIP/CL-00029e74>AGI Tx >> agi_request: presence_2.php
<SIP/CL-00029e74>AGI Tx >> agi_channel: SIP/CL-00029e74
<SIP/CL-00029e74>AGI Tx >> agi_language: en_AU
<SIP/CL-00029e74>AGI Tx >> agi_type: SIP
<SIP/CL-00029e74>AGI Tx >> agi_uniqueid: 1405134386.171952
<SIP/CL-00029e74>AGI Tx >> agi_version: 1.8.5.0
<SIP/CL-00029e74>AGI Tx >> agi_callerid: 000000000
<SIP/CL-00029e74>AGI Tx >> agi_calleridname: 000000000
<SIP/CL-00029e74>AGI Tx >> agi_callingpres: 0
<SIP/CL-00029e74>AGI Tx >> agi_callingani2: 0
<SIP/CL-00029e74>AGI Tx >> agi_callington: 0
<SIP/CL-00029e74>AGI Tx >> agi_callingtns: 0
<SIP/CL-00029e74>AGI Tx >> agi_dnid: 000000000
<SIP/CL-00029e74>AGI Tx >> agi_rdnis: unknown
<SIP/CL-00029e74>AGI Tx >> agi_context: sub-queue-sales
<SIP/CL-00029e74>AGI Tx >> agi_extension: h
<SIP/CL-00029e74>AGI Tx >> agi_priority: 2
<SIP/CL-00029e74>AGI Tx >> agi_enhanced: 0.0
<SIP/CL-00029e74>AGI Tx >> agi_accountcode: 
<SIP/CL-00029e74>AGI Tx >> agi_threadid: 139987080693520
<SIP/CL-00029e74>AGI Tx >> 
<SIP/CL-00029e74>AGI Rx << GET VARIABLE UNIQUEID
<SIP/CL-00029e74>AGI Tx >> 200 result=1 (1405134386.171952)
<SIP/CL-00029e74>AGI Rx << GET VARIABLE UNIQUEID
<SIP/CL-00029e74>AGI Tx >> 200 result=1 (1405134386.171952)
<SIP/CL-00029e74>AGI Rx << VERBOSE "Started: 1405134386.171952" 1
 presence_2.php: Started: 1405134386.171952
........ lots of events and communcation with AGI ........
<SIP/CL-00029e74>AGI Tx >> 200 result=1
 -- <SIP/CL-00029e74>AGI Script presence_2.php completed, returning 0

NOTE: I stripped out all identifying information from these logs NOTE2: Running Asterisk 1.8.5

did you ever find a solution to this? I experience the same problem... — grandnasty, Mar 03 '16 at 18:58
It's funny, you include a lot of data, but not the contents of the script. Possibly the most important piece of information... and second, no script output/errors? It's hard to tell what going on without more information. — Ryan Babchishin, Aug 22 '16 at 02:39

arheops · Answer 1 · 2014-07-16T07:18:40.040

2

Return code of AGI = return code of script used.

So check in your script presence_2.php if/when it have exit(4) command.

For more info do

1) stop asterisk

2) start asterisk via

asterisk -vvvvc

If so, you will see script error on your console.

edited Jul 16 '14 at 07:18

answered Jul 16 '14 at 00:15

arheops

708
1
5
13

I enabled dumpcore in asterisk.conf (which is what effectively you've asked for), I'll report back once it crashes again. Thanks – Mattisdada Jul 16 '14 at 00:36
Didn't change the output at all :( – Mattisdada Jul 16 '14 at 04:00
dumpcore is not same as running asterisk in console, realy. dumpcore store dump of ASTERISK,not script. – arheops Jul 16 '14 at 04:46
Sure? "dumpcore = yes; Dump core on crash (same as -g at startup)". I'm also logging all output of Asterisk into logs – Mattisdada Jul 16 '14 at 06:33
Try exactly like i described. Main goal here - got stderr of your script. No other way got that for asterisk. – arheops Jul 16 '14 at 07:17
I'll try it, I only have a production server, so shutting down / restarting is not easy. But I'll try, thanks – Mattisdada Jul 16 '14 at 23:12
You have not do test agi on production server. Setup equal test server using amazon ec2 or vps. – arheops Jul 16 '14 at 23:46
Probably won't be able to replicate the issue then, the AGI works fine 99.999% of the time, and it might be an issue particular to the current configuration, modules and asterisk version. I could try it, but I don't think I'll be able to replicate the issue (I can't replicate it on my normal server, I just have to wait for it to happen) – Mattisdada Jul 16 '14 at 23:53
No. AGi have no any relation to asterisk modules. More likly you have not enought mysql concurrent channels or errors in script. You can run asterisk in screen utility or via nohup and forward stderr to file. Or you can hire real expert. – arheops Jul 17 '14 at 18:47

Asterisk AGI randomly returning 4 and failing to execute PHP AGI

1 Answers1