[Home]

Summary:ASTERISK-00689: AGI: User hangup causes asterisk crash
Reporter:scaredycat (scaredycat)Labels:
Date Opened:2003-12-21 14:48:47.000-0600Date Closed:2011-06-07 14:00:30
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When running AGI scripts if * hangs up there is no problem, however if the user hangs up * dies immediately...

Comments:By: mochouinard (mochouinard) 2003-12-30 22:55:08.000-0600

Ok I was going to submit a post about something similar, but I dont want bkw telling me again I should have looked at others bugs report... SO here I am.

I tryed agi-test.agi yesterday, and the first call it work, but if I call it a second time, Asterisk crash.  It always does this here.  Even if there is something wrong in agi-test.agi, I guess it should never crash the whole * system.  Nothing should. No I havent done BackTrace on it.  I'll try to do it tonight.
By: Brian West (bkw918) 2003-12-31 01:53:14.000-0600

what distro are you using?
By: zoa (zoa) 2003-12-31 05:54:13.000-0600

what cvs are you using ?

Is that a perl agi script ?
By: mochouinard (mochouinard) 2003-12-31 13:28:15.000-0600

Im running redhat 9
Asterisk CVS-12/29/03-04:30:58, Copyright (C) 1999-2001 Linux Support Services, Inc.

Like I said it the agi-test.agi that come with Asterisk (so yes it a perl script)

And if you were asking me then sorry ...
By: Jared Smith (jsmith) 2003-12-31 18:14:37.000-0600

AGI is very obviously b0rked in CVS... whenever I call an AGI, Asterisk does all kinds of weird things, like refusing to playback .gsm files, and crashing remote Asterisk consoles...

And before you start thinking I'm crazy, you should know that I got bkw_ to log in and check it out... He too agrees that it's AGI that is causing the problem.

Please, somebody, get this fixed soon!
By: philipp2 (philipp2) 2004-01-01 10:43:27.000-0600

Below a posting of mine on Dec 10, 2003 on asterisk-users. WipeOut has reported the same problem (also on the list, a bit earier than me), so I am certainly not alone with that problem; this is not crash problem, still it appears that something is majorly wrong about AGI. My impression is that it works fine with PERL, but gives problems with PHP on RedHat (and maybe other distros):

AGI is partially not working for me with SAY DIGITS, SAY NUMBER, WAIT FOR
DIGITS etc. It appears that result is always one for any function that
looks for user input, regardless of which key was pressed. Playing sound
is only possible using EXEC. This applies to two * servers with RH 7.2
and RH 7.3 and very recent CVS. Any suggestion or tips about where I
goofed?

Thanks, Philipp


-- [CLI output] --
 demo.agi: write: ANSWER
 demo.agi: read: 200 result=1
 demo.agi: write: SAY DIGITS 68 7
   -- Playing 'digits/6' (language 'en')     <-- no sound & 6 only
 demo.agi: read: 200 result=1
 (null): write: EXEC SayNumber 34   <-- but this works fine
   -- AGI Script Executing Application: (SayNumber) Options: (34)
   -- Playing 'digits/30' (language 'en')
   -- Playing 'digits/4' (language 'en')
 (null): read: 200 result=1
 (null): write: WAIT FOR DIGIT 5000
 (null): read: 200 result=1     <-- user pressed 4, but we get result=1


-- [extensions.conf] --
exten => _104[013-9],1,Answer
exten => _104[013-9],2,Playback(beep)
exten => _104[013-9],3,AGI(demo.agi)
exten => _104[013-9],4,Playback(beep)
exten => _104[013-9],5,Hangup


-- [demo.agi] --
#!/usr/bin/php -q
<?php
ob_implicit_flush(true);
set_time_limit(0);
$in = fopen("php://stdin","r");
...
function __read__() {
  global $in, $debug;
  $input = str_replace("\n", "", fgets($in, 4096));
  return $input;
}
function __write__($line) {
  print $line."\n";
}
...
__write__("ANSWER");
__read__();
__write__("SAY DIGITS 68 \"7\"");
__read__();
__write__("EXEC SayNumber 34");
__read__();
__write__("WAIT FOR DIGIT 5000");
__read__();
By: Jared Smith (jsmith) 2004-01-02 10:50:26.000-0600

Appears to have been fixed in CVS on Jan 1, 2004 by Mark Spencer... at least it's working much better for me now.

Please try it and report back if that works for you.
By: iain (iain) 2004-01-02 14:26:54.000-0600

Nope - the problem is still there - and for me with a version of app_agi dating back to November.  So maybe the problem isn't entirely in that piece of code.

 Iain
By: Brian West (bkw918) 2004-01-06 23:45:56.000-0600

Is this still a problem or did the recent fix take care of it?
By: philipp2 (philipp2) 2004-01-07 04:44:09.000-0600

If I run agi-test.agi with a CVS as of now (Asterisk CVS-01/07/04-11:05:52) I call (from .9.7 with a Grandstream behind NAT with nat=yes) and see a failure in test 4 and can hear only the digits spoken until 7. By the way, the GS setup has been working fine since ages...

print STDERR "4.  Testing 'saynumber'...";
print "SAY NUMBER 192837465 \"\"\n";
$result = <STDIN>;
checkresult($result);


   -- Executing Answer("SIP/philipp-8201", "") in new stack
   -- Executing Playback("SIP/philipp-8201", "beep") in new stack
   -- Playing 'beep' (language 'en')
   -- Executing AGI("SIP/philipp-8201", "agi-test.agi") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-test.agi
AGI Environment Dump:
-- accountcode =
-- callerid = "Philipp" <1234>
-- channel = SIP/philipp-8201
-- context = sippyhippy
-- dnid = unknown
-- enhanced = 0.0
-- extension = 874
-- language = en
-- priority = 3
-- rdnis = unknown
-- request = agi-test.agi
-- type = sip
-- uniqueid = 1073470356.0
1.  Testing 'sendfile'...PASS (0)
2.  Testing 'sendtext'...PASS (0)
3.  Testing 'sendimage'...PASS (0)
   -- Playing 'digits/1' (language 'en')
   -- Playing 'digits/hundred' (language 'en')
   -- Playing 'digits/90' (language 'en')
   -- Playing 'digits/2' (language 'en')
   -- Playing 'digits/million' (language 'en')
   -- Playing 'digits/8' (language 'en')
   -- Playing 'digits/hundred' (language 'en')
   -- Playing 'digits/30' (language 'en')
   -- Playing 'digits/7' (language 'en')
   -- Playing 'digits/thousand' (language 'en')
WARNING[10251]: File chan_sip.c, Line 464 (retrans_pkt): Maximum retries exceeded on call 945ba0d9-973b-3ce9-e853-264c47c25290@192.168.9.7 for seqno 102 (Request)
 == Spawn extension (sippyhippy, 874, 3) exited non-zero on 'SIP/philipp-8201'
PASS (-1)
5.  Testing 'waitdtmf'...FAIL (unexpected result '')
6.  Testing 'record'...FAIL (unexpected result '')
6a.  Testing 'record' playback...FAIL (unexpected result '')
================== Complete ======================
7 tests completed, 4 passed, 3 failed
==================================================



Now, if I remove test #4 (replaced it with test 3) then I don't hear anything, but all tests seem to pass???

-- uniqueid = 1073471225.6
1.  Testing 'sendfile'...PASS (0)
2.  Testing 'sendtext'...PASS (0)
3.  Testing 'sendimage'...PASS (0)
4.  Testing 'saynumber'...PASS (0)
5.  Testing 'waitdtmf'...PASS (0)
6.  Testing 'record'...PASS (0)
6a.  Testing 'record' playback...WARNING[10251]: File chan_sip.c, Line 464 (retrans_pkt): Maximum retries exceeded on call 685fdaac-1fc2-6b68-264c-973b5290e853@192.168.9.7 for seqno 102 (Request)
 == Spawn extension (sippyhippy, 874, 1) exited non-zero on 'SIP/philipp-8d59'
PASS (-1)
================== Complete ======================
7 tests completed, 7 passed,  failed
==================================================
WARNING[10251]: File chan_sip.c, Line 464 (retrans_pkt): Maximum retries exceeded on call 685fdaac-1fc2-6b68-264c-973b5290e853@192.168.9.7 for seqno 2300 (Response)
By: iain (iain) 2004-01-09 15:35:21.000-0600

I think I know what's going on here.  The error is caused by the print "SEND TEXT \"hello world\"\n";  in agi-test.agi.  It causes a SIP "MESSAGE" packet to be sent and returns assuming all is OK if the packet is scheduled for transmission.

The Grandstream phones do not support MESSAGE and basically ignore it.  This causes * to retransmit the packet.  When * runs out of retries some time later it hange up the channel and subsequent AGI commands fil.  This usually happens for me towards the end of the test as * is reading out a number.  

If you try the agi with an ATA186 it will run through OK.  This is because the ATA will return a "Not implemented" response to a MESSAGE.  Hence * will simply stop sending the message and assume all is well.  

So, ideally * shouldn't hang up the channel because it leaves the AGI unaware of the channel state.  Equally, Grandstream needs to update its firmware to provide the "Not implemented" response.

 Iain
By: Brian West (bkw918) 2004-01-10 14:12:48.000-0600

This is a grandstream related issue.