[Home]

Summary:ASTERISK-16649: [patch] Peer does not hang up when caller hangup while app_dial is executing - Deadagi
Reporter:mn3250 (mn3250)Labels:
Date Opened:2010-09-05 13:36:40Date Closed:2011-04-13 11:37:09
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) issue17954_v1.4.patch
( 1) issue17954_v1.6.2.patch
( 2) issue17954_v1.8.patch
Description:I am trying to execute a dead agi application:

exten => 1111,1,DeadAgi,calling.pl
exten => 1111,n,Hangup()

in calling.pl I have:
$result=$AGI->exec("Background", "connecting");
$dialstr = $type."/$callednumber@".$providerip."|90|rHL(" . ($calltime * 60 * 1000) . ")";
$result=$AGI->exec("DIAL $dialstr");

everything works fine if the caller does not hangup and the progress tone is played to the caller but if the caller disconnect the call while connecting.gsm is played, the peer does not disconnect even after the originating channel is hung up.
Should * not disconnect the briged channel when originating channel dissconnects?
Asterisk reports the caller disconnect and DIALSTATUS is CANCEL but the bridged call stays in progress and connects unless a restart is issued. If this is normal (I do not think so), is there a workaround to disconnect the bridged leg after caller hangs up in my agi script?


****** ADDITIONAL INFORMATION ******

It happens in all asterisk verions 1.4 , 1.6 , 1.8 .
Also tried to use $SIG{HUP} to trap the error but there is no way to find the outgoing channel.
Comments:By: Stefan Schmidt (schmidts) 2010-09-05 15:45:46

the problem might be using Deadagi itself.

core show application DeadAGI

 -= Info about application 'DeadAGI' =-

[Synopsis]
Executes AGI on a hungup channel
...
A locally executed AGI script will receive SIGHUP on hangup from the channel
except when using DeadAGI.

a deadagi does not check for an outgoing channel cause normally it is allready hung up.

try using a normal Agi instead.



By: mn3250 (mn3250) 2010-09-06 02:11:12

Thank you for your answer. The same is happening using AGI.

By: Stefan Schmidt (schmidts) 2010-09-07 04:21:28

have you tried it with agi and the sig(hup) handler too?

By: mn3250 (mn3250) 2010-09-16 10:47:11

The same is happening.

By: anest (anest) 2010-12-06 04:24:12.000-0600

any news? how exactly to debug that thing?
ps: as i know this bug exists and well known about ~5 years already. i heard in first time about that on A2Billing forum long time ago, people complaining about this all the time there. And in some reasons Areski recommend to use DeadAGI to resolve that problem, not AGI. weird, huh? dejavu. i hope the solution will be found soon.



By: anest (anest) 2010-12-06 04:28:21.000-0600

[off] weird. "tilde plus five" was replaced to hyperlink. another bug (now in mantis) or this is hidden feature? ;) [/off]

By: Vadim Sherbakov (vinsik) 2011-01-26 22:04:00.000-0600

Hi,

I don't know if my issue is related, but it sure sounds like a similar problem.
Only difference is that i use AGI as command.
On asterisk-1.6.2.11 everything worked fine for me.

First i upgraded to asterisk-1.6.2.14 and things got weird.
After peer (originator) disconnects the call, asterisk does not SIGHUP
AGI script right away. Delays for 1-2 sek.

After upgrade to asterisk-1.6.2.15, AGI process is not killed at all.
Even though peer (originator) is already disconnected.

I checked SIP logs and peer sends BYE and asterisk replies ACK.
But AGI process is still running and preforming post-call tasks.
From console 'core show channels' shows me that channel is Up.

Either im missing something in configuration. Some old feature that
was fixed to work properly or a new feature that was introduced between
1.6.2.14 - 1.6.2.15 versions. Or this is a AGI related bug.

This happens every call for me, and im running this on test server, so
i can provide logs if needed.

Cheers.

By: dovid (dovid) 2011-01-27 03:19:45.000-0600

I think it is not related to AGI but maybe an Asterisk bridging issue in general.

I have the issue with the following scenario:

1) User makes call with u option which sends the called party to another context.
2) The context that I sent it to plays a message (using Background) in a loop till the called party enters any dtmf key.
3) If when the gosub is playing the file before entering DTMF the caller hangs up Asterisk gets the BYE and sends a 200 OK however it never hits the h extension and asterisk keeps playing the message to the called party.
4) If the called party enters in DTMF then the call gets hung up for both legs in Asterisk.

I am using Asterisk 1.8.2.2.

By: Vadim Sherbakov (vinsik) 2011-01-27 14:26:58.000-0600

Hi all,

I checked ChangeLog starting from asterisk 1.6.2.14 release.
I was searching for something that could do this.

Found this entry:
r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines  
 Don't ignore frames that have been queued when softhangup'd
 ...
(closes issue ASTERISK-15731)

Here is the diff:
 http://svnview.digium.com/svn/asterisk/branches/1.6.2/main/channel.c?r1=289339&r2=291580&pathrev=291580

Fould that this added code breaks normal AGI behavior for me anyways.
I removed it from 1.6.2.16 source, now AGI will SIGHUP when call gets Hangup.

Now im curious, is this bug a similar problem, or should i open a new bug explaining this.

By: Leif Madsen (lmadsen) 2011-01-31 12:44:54.000-0600

vinsik: please open a new issue for that and we'll get it triaged. Thanks!

By: Claudio Villalobos (devmod) 2011-02-07 09:49:43.000-0600

@vinsik I think we might have a similar issue: https://issues.asterisk.org/view.php?id=18492

By: Richard Mudgett (rmudgett) 2011-04-08 13:07:22

The issue17954_v1.8.patch file is the patch on reviewboard.

By: Digium Subversion (svnbot) 2011-04-13 11:21:27

Repository: asterisk
Revision: 313545

U   branches/1.4/main/channel.c
U   branches/1.4/res/res_agi.c

------------------------------------------------------------------------
r313545 | rmudgett | 2011-04-13 11:21:26 -0500 (Wed, 13 Apr 2011) | 41 lines

Asterisk does not hangup a channel after endpoint hangs up.

If the call that the dialplan started an AGI script for is hungup while
the AGI script is in the middle of a command then the AGI script is not
notified of the hangup.  There are many AGI Exec commands that this can
happen with.  The reported applications have been: Background, Wait, Read,
and Dial.  Also the AGI Get Data command.

* Don't wait on the Asterisk channel after it has hung up.  The channel is
likely to never need servicing again.

* Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.

(closes issue ASTERISK-16649)
Reported by: mn3250
Patches:
     issue17954_v1.8.patch uploaded by rmudgett (license 664)
     issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
     issue17954_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA SWP-2171

(closes issue ASTERISK-17124)
Reported by: devmod
Tested by: rmudgett
JIRA SWP-2761

(closes issue ASTERISK-17520)
Reported by: nvitaly
Tested by: astmiv, rmudgett
JIRA SWP-3216

(closes issue ASTERISK-16144)
Reported by: siby
Tested by: rmudgett
JIRA SWP-2727

Review: https://reviewboard.asterisk.org/r/1165/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313545

By: Digium Subversion (svnbot) 2011-04-13 11:29:52

Repository: asterisk
Revision: 313579

_U  branches/1.6.2/
U   branches/1.6.2/main/channel.c
U   branches/1.6.2/res/res_agi.c

------------------------------------------------------------------------
r313579 | rmudgett | 2011-04-13 11:29:51 -0500 (Wed, 13 Apr 2011) | 48 lines

Merged revisions 313545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
 
 Asterisk does not hangup a channel after endpoint hangs up.
 
 If the call that the dialplan started an AGI script for is hungup while
 the AGI script is in the middle of a command then the AGI script is not
 notified of the hangup.  There are many AGI Exec commands that this can
 happen with.  The reported applications have been: Background, Wait, Read,
 and Dial.  Also the AGI Get Data command.
 
 * Don't wait on the Asterisk channel after it has hung up.  The channel is
 likely to never need servicing again.
 
 * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
 in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
 AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
 
 (closes issue ASTERISK-16649)
 Reported by: mn3250
 Patches:
       issue17954_v1.8.patch uploaded by rmudgett (license 664)
       issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
       issue17954_v1.4.patch uploaded by rmudgett (license 664)
 Tested by: rmudgett
 JIRA SWP-2171
 
 (closes issue ASTERISK-17124)
 Reported by: devmod
 Tested by: rmudgett
 JIRA SWP-2761
 
 (closes issue ASTERISK-17520)
 Reported by: nvitaly
 Tested by: astmiv, rmudgett
 JIRA SWP-3216
 
 (closes issue ASTERISK-16144)
 Reported by: siby
 Tested by: rmudgett
 JIRA SWP-2727
 
 Review: https://reviewboard.asterisk.org/r/1165/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313579

By: Digium Subversion (svnbot) 2011-04-13 11:31:51

Repository: asterisk
Revision: 313588

_U  branches/1.8/
U   branches/1.8/main/channel.c
U   branches/1.8/res/res_agi.c

------------------------------------------------------------------------
r313588 | rmudgett | 2011-04-13 11:31:51 -0500 (Wed, 13 Apr 2011) | 55 lines

Merged revisions 313579 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
 
 Merged revisions 313545 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
   
   Asterisk does not hangup a channel after endpoint hangs up.
   
   If the call that the dialplan started an AGI script for is hungup while
   the AGI script is in the middle of a command then the AGI script is not
   notified of the hangup.  There are many AGI Exec commands that this can
   happen with.  The reported applications have been: Background, Wait, Read,
   and Dial.  Also the AGI Get Data command.
   
   * Don't wait on the Asterisk channel after it has hung up.  The channel is
   likely to never need servicing again.
   
   * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
   in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
   AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
   
   (closes issue ASTERISK-16649)
   Reported by: mn3250
   Patches:
         issue17954_v1.8.patch uploaded by rmudgett (license 664)
         issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
         issue17954_v1.4.patch uploaded by rmudgett (license 664)
   Tested by: rmudgett
   JIRA SWP-2171
   
   (closes issue ASTERISK-17124)
   Reported by: devmod
   Tested by: rmudgett
   JIRA SWP-2761
   
   (closes issue ASTERISK-17520)
   Reported by: nvitaly
   Tested by: astmiv, rmudgett
   JIRA SWP-3216
   
   (closes issue ASTERISK-16144)
   Reported by: siby
   Tested by: rmudgett
   JIRA SWP-2727
   
   Review: https://reviewboard.asterisk.org/r/1165/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313588

By: Digium Subversion (svnbot) 2011-04-13 11:37:07

Repository: asterisk
Revision: 313606

_U  trunk/
U   trunk/main/channel.c
U   trunk/res/res_agi.c

------------------------------------------------------------------------
r313606 | rmudgett | 2011-04-13 11:37:06 -0500 (Wed, 13 Apr 2011) | 62 lines

Merged revisions 313588 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r313588 | rmudgett | 2011-04-13 11:31:50 -0500 (Wed, 13 Apr 2011) | 55 lines
 
 Merged revisions 313579 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
   
   Merged revisions 313545 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
     
     Asterisk does not hangup a channel after endpoint hangs up.
     
     If the call that the dialplan started an AGI script for is hungup while
     the AGI script is in the middle of a command then the AGI script is not
     notified of the hangup.  There are many AGI Exec commands that this can
     happen with.  The reported applications have been: Background, Wait, Read,
     and Dial.  Also the AGI Get Data command.
     
     * Don't wait on the Asterisk channel after it has hung up.  The channel is
     likely to never need servicing again.
     
     * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
     in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
     AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
     
     (closes issue ASTERISK-16649)
     Reported by: mn3250
     Patches:
           issue17954_v1.8.patch uploaded by rmudgett (license 664)
           issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
           issue17954_v1.4.patch uploaded by rmudgett (license 664)
     Tested by: rmudgett
     JIRA SWP-2171
     
     (closes issue ASTERISK-17124)
     Reported by: devmod
     Tested by: rmudgett
     JIRA SWP-2761
     
     (closes issue ASTERISK-17520)
     Reported by: nvitaly
     Tested by: astmiv, rmudgett
     JIRA SWP-3216
     
     (closes issue ASTERISK-16144)
     Reported by: siby
     Tested by: rmudgett
     JIRA SWP-2727
     
     Review: https://reviewboard.asterisk.org/r/1165/
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313606