Summary:ASTERISK-13155: bad Hangup Event on channel
Reporter:Didier LEBEGUE (dlebegue)Labels:
Date Opened:2008-12-02 07:16:14.000-0600Date Closed:2011-06-07 14:00:18
Versions:Frequency of
Environment:Attachments:( 0) backtrace.txt
( 1) extensions.conf
( 2) managerevents.txt
Description:after annulation of supervised transfer with #3 (features.conf) and

parked operation on the initial ZAP channel , the manager send me a "Hangup
Event" but the initial ZAP channel is really parked with moh.

The "Hangup Event" destroy the call in my interface because Hangup -> stop of call!!!


linux MANDRIVA 6.0
Comments:By: Brandon Kruse (bkruse) 2008-12-05 12:05:01.000-0600

Can you attach a backtrace?


By: Leif Madsen (lmadsen) 2008-12-05 15:16:11.000-0600

In addition, you've marked this as 1.2. Can you reproduce this on 1.4? Asterisk 1.2 is end of life and only accepting security fixes; not bug fixes.

By: Brandon Kruse (bkruse) 2008-12-05 16:01:52.000-0600


It's definitely a bug in 1.4/1.6.x/trunk, but I think it's a good idea he tests it, and reproduces his steps! :)


By: Joshua C. Colp (jcolp) 2008-12-08 14:40:39.000-0600

mISDN is actually involved here it looks like, and it may be because of a masquerade going on... as I see Local channels involved as well. Can you provide the dialplan involved, step by step, plus the manager event that gets sent?

By: Didier LEBEGUE (dlebegue) 2008-12-09 10:00:08.000-0600

this extensions.conf example is a reproduction of incident with my mISDN configuration.

the events manager are collected with asterik-java-0.2 interface !!!

By: Brandon Kruse (bkruse) 2008-12-09 15:17:26.000-0600

Could you try this with the 1.4/1.6.x/trunk branches?


By: Didier LEBEGUE (dlebegue) 2009-01-06 02:26:14.000-0600

test with asterisk 1.4 SVN--r167179

exactly same incident with core dumped

Parked mISDN/1-u0 on 71@parkedcalls. Will timeout back to extension [parkedcalls] s, 1 in 45 seconds
   -- Added extension '71' priority 1 to parkedcalls
   -- <mISDN/1-u0> Playing 'digits/7' (language 'en')
   -- <mISDN/1-u0> Playing 'digits/1' (language 'en')
   -- Started music on hold, class 'default', on mISDN/1-u0
 == Spawn extension (parkedcalls, s, 1) exited non-zero on 'mISDN/1-u0'
   -- Stopped music on hold on mISDN/1-u0
 == mISDN/1-u0 got tired of being parked
Erreur de segmentation (core dumped)

By: Didier LEBEGUE (dlebegue) 2009-01-06 07:58:29.000-0600

test with Asterisk 1.4.22

exactly same hangup event and moh for caller !!!

Thanks for help for 1.4 !!!

By: Leif Madsen (lmadsen) 2009-01-14 12:54:25.000-0600

dlebegue: sorry, can you clarify your last note re: 1.4.22? I'm confused if you're excited it is working, or excited it's not working :)

By: Didier LEBEGUE (dlebegue) 2009-01-15 01:34:32.000-0600

Sorry for confusion !!!

It's the same problem in 1.4.22

I'm excited it's not working !!!

By: Leif Madsen (lmadsen) 2009-02-09 13:18:53.000-0600

I'm removing bkruse as the assignee on this issue as he is not really available for Asterisk issues anymore (school!)

By: Mark Michelson (mmichelson) 2009-04-02 17:52:39

This issue has been idle for quite a while and needs a resolution, so I am taking over. The problem is that I am having a lot of trouble understanding exactly what the problem is here and how to reproduce it.

Let's try to break this down into steps instead of using prose to describe the situation. Based on the log you provided, I think this is what you have done.

mISDN/1-1 calls SIP/905.
SIP/905 answers the call.
SIP/905 initiates a supervised transfer to mISDN/1-u0.
While mISDN/1-u0 is ringing, SIP/905 presses #3 to disconnect the call.
...(This is where things get confusing. I may have details wrong here)...
mISDN/1-1 and SIP/905 are connected again.
It appears that SIP/905 attempts to park mISDN/1-1. It is unclear exactly how this is being accomplished.
mISDN/1-1 gets tired of being parked and hangs up.

In the log you uploaded, you then stopped Asterisk using the "stop now" command. In ~97069, you show that Asterisk crashed. The initial report did not mention a crash at all (except in the "severity" field). Did the crash occur when you first reported this against Asterisk 1.2, or is that something that started happening when using 1.4?

I'm going to need to know exactly the steps to follow to make this problem happen. It is really difficult trying to figure this out just based on the description you have provided and the files you have uploaded.


By: Leif Madsen (lmadsen) 2009-04-20 10:27:19

I'm closing this issue due to no response from the reporter. Please reopen this issue and provide the information required when you have it. Thanks!