On Wed, 9 Jul 2008, Steve Totaro wrote: > On Wed, Jul 9, 2008 at 5:00 PM, Tilghman Lesher < > [EMAIL PROTECTED]> wrote:
>> On Wednesday 09 July 2008 14:06:56 Thameem Ansari wrote: >>> There is no performance impact if you use AGI or DeadAGI. There is no significant difference (in Asterisk 1.2) in the performance between agi() and deadagi(). The difference (aside from an insignificant channel state check in agi()) is whether ast_waitfor_nanfds() is called with a 0 or a 1 for the second parameter. Unfortunately, the second parameter is named "n" and I have a short attention span :) >> There is a performance impact, in terms of the time it takes for the >> process to start up. It may be measured in fractions of a second, but >> there certainly is a performance penalty. It is not zero. A wimpy 1GHz Celeron can invoke more than 1xx AGIs per second. > Do you mean they both have the same penalty or is one worse than the > other? Aside from the impact of passing a 0 or a 1 to ast_waitfor_nanfds() they are virtually the same. >>> The only difference is, if you use AGI it will not continue executing >>> the dialplan if the calling party hangsup the call. Not quite. When the channel is hung up, the AGI receives a HUP signal. If the AGI does not trap the signal it will exit. A DEADAGI receives no notification that the channel has hung up -- presumably since it's intended application is to run after a channel is hung up. >>> DeadAgi, will continue executing the dialplan and its upto the >>> applications responsibility to hangup the channel. So, the application >>> should be aggressive enough to hangup the channel to avoid wrong cdr >>> durations. >> DeadAGI is not recommended and is not supported for channels which are >> not already hungup (and invoked from the "h" extension in the >> dialplan). The "h" extension "requirement" seems a bit strict. If I "catch" the hangup in an "h" and goto(example, s, 1), wouldn't that still be a valid environment for the deadagi()? (It would be a "better practice" to goto(example, h, 1), however) > Not recommended and not supported would imply it doesn't work. I think > it works so who doesn't support it and why not? Since you can trap the HUP and continue, I thought there was no need to run deadagi(). After a bit of testing, it appears there may be a legitimate use for deadagi() on a "live" channel. When the channel associated with an AGI is hung up, the AGI receives a HUP. The AGI can trap the signal and continue executing. However, if you observe the console and issue "show channels" you will see that the channel is "gone" even though the AGI is still executing (since it is a process separate from Asterisk). My guess (I haven't tested it) is that this means that the "post hangup" AGI could not look up or set channel variables, fiddle with the context, extension, priority or otherwise interact with the dialplan. If you need such interaction, deadagi() would appear to be the correct "application." Thanks in advance, ------------------------------------------------------------------------ Steve Edwards [EMAIL PROTECTED] Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
