Summary:ASTERISK-13884: DeadAGI at h extension
Reporter:hoaianh (hoaianh)Labels:
Date Opened:2009-04-02 07:54:51Date Closed:2009-05-12 20:01:59
Versions:Frequency of
Environment:Attachments:( 0)
( 1) 20090501__bug14811.diff.txt
( 2) A-leg-hungup-case
( 3) B-leg-hangup-case
Description:I make outgoing call with the context

exten => s,1,Anser()
exten => s,n,Playback(tt-weasels)
exten => s,n,Dial(ss7/out/123456789)
exten => s,n,Hangup()

exten => h,1,DeadAgi(agi://agi-server/script)

The problem is when leg A is hang up it works fine but if leg B is hang up I get
--> deadagi_exec: Running DeadAGI on a live channel will cause problems, please use AGI

This one seems to be very close to issue 0014624 but the major difference is that always happens.

On another box with it works just fine.


OS: Centos 5
Comments:By: Donny Kavanagh (donnyk) 2009-04-02 09:13:24

Could you attach in a file (not paste into a response) the console output w/ verbose & debug information of two calls, one where leg A hangs up and the other where leg B hangs up.  The entire extensions.conf you used to produce the error may not hurt either.

By: hoaianh (hoaianh) 2009-04-03 08:19:25

Core debug level set to 6. Verbosity level set to 10 ;-). Output files posted.

By: Donny Kavanagh (donnyk) 2009-04-03 15:40:29

Ok Per the debug i can see the softhangup of the SS7/siuc/13 channel does not happen until after DeadAGI has been run.  Also your Hangup() is never run because once there is a hangup Dial() exits and the call jumps to the h exten.  If i'm correct you should be able to solve this by passing the g option to your dial, this will force the dialplan to continue and Hangup() to run when the callee (as opposed to the caller) hangs up and a result the channel should be hungup when DeadAGI runs.  You could also try adding h,1,Hangup() as the first step in your h extension.  I think either should work, but the first solution would be the most appropriate.  Let us know if that works and we'll close this issue.

By: Tilghman Lesher (tilghman) 2009-04-03 16:25:38

juggie: actually, Hangup as the first application in "h" will never work.  You might be able to execute a SoftHangup(${CHANNEL}), though.

By: Donny Kavanagh (donnyk) 2009-04-06 07:22:59

Figures, i'd never tried it but i thought it might.

Thanks for letting me know tilghman.  

However the first solution should, if you can confirm it did we can close this ticket as a config issue.


By: hoaianh (hoaianh) 2009-04-06 07:39:34

Thanks very much for your response.

I post also an output file got from a box with version where every thing works fine.

As in Soft-Hangup is called on both legs before the AGI script is called. In 1.4.24 it seems to be that Soft-Hangup is called first on the leg sending REL then the AGI stuff is triggered, then Soft-Hangup on the other leg. I assume h extension is here considered relatively to the leg which has initiated call (leg A). Hence I get this WARNING if leg B is hang up.

I will try your recommendations and inform you about the result as soon as possible.

By: hoaianh (hoaianh) 2009-04-07 08:47:04

Dial() with g option and h,1,SoftHangup(${CHANNEL}) work without WARNING

By: Donny Kavanagh (donnyk) 2009-04-08 10:31:28


I dont think the behaviour of the call should of changed, only the warning in the older release of 1.4.19 (before it was added) should not show up.

If you can confirm that the actual behaviour has changed then we may have an issue, but if you are just seeing the warning in one version and not in he other that is just cosmetic, let us know.

By: hoaianh (hoaianh) 2009-04-08 10:57:18


I'm not sure of the predetermined behaviour of Asterisk in processing calls bridged together.

But studying the debug outputs (see posted files). I can make out a difference in the way Asterisk processes between and 1.4.24 namely:
- In if two channels are bridged together, Asterisk calls SoftHangup() internally on both legs BEFORE it jumps to h extension.
- In 1.4.24 if two channels are bridged together, Asterisk calls SoftHangup() first on the channel which sends HANGUP then jump to h extension and then calls SoftHangup() on the other channel.

By: Donny Kavanagh (donnyk) 2009-04-08 14:08:05

Something may be going on here, i presume all these tests have been run with the same libss7 version?

By: hoaianh (hoaianh) 2009-04-14 08:25:50

I use chan_ss7 and the tests have been run with the same version.

By: Donny Kavanagh (donnyk) 2009-04-14 23:53:30

Something is fishy for sure, however using g solves the issue.  Someone will look into this regression/change in behavior soon.

By: hoaianh (hoaianh) 2009-04-15 04:25:54

Thank you for your attention ;-)

By: Tim Ringenbach at Asteria Solutions Group (tim_ringenbach) 2009-05-01 15:21:23

I'm getting that warning running DeadAGI's from the h extension too.
I'm seeing it in 1.4.24 and did not see it in 1.4.22 or earlier.

Like was said earlier, adding a SoftHangup(${CHANNEL}) avoids the warning.

Also, as said earlier, it only happens if the callee hangs up first.

By: Donny Kavanagh (donnyk) 2009-05-04 03:26:19

This is definitively a known issue.  Using the g flag w/ a hangup() will supress the warning.

This is just waiting for some developer attention.

By: Tilghman Lesher (tilghman) 2009-05-04 14:15:59

There has already been developer attention, in the form of a patch.  It would be greatly appreciated if testing attention and feedback attention were given.

By: Tim Ringenbach at Asteria Solutions Group (tim_ringenbach) 2009-05-04 14:25:58

Sorry, somehow I didn't notice the patch.

I didn't test the patch but looking at it, I don't think it would help me.

I have a lot of places where in the h extension I call Macro(handlehangup), and it's actually the macro that calls DeadAGI, which means the extension it would see would not be h. I guess you could hack around it and find the the real extension in that case, but what if someone did a Goto or a Gosub?

By: Tilghman Lesher (tilghman) 2009-05-04 14:42:17

tim_ringenbach:  there is zero I can really do about this problem.  It's only a warning, after all, and it can be ignored easily enough.

By: Tilghman Lesher (tilghman) 2009-05-12 20:01:59

This really isn't fixable.  You can ignore the error or upgrade to 1.6.0 or higher, where AGI doesn't care whether it's run on a live or dead channel.