Summary:ASTERISK-12847: chan_iax2 isn't using HANGUP anymore?
Reporter:Igor Zamocky (dzajro)Labels:
Date Opened:2008-10-07 17:27:07Date Closed:2008-12-10 12:49:35.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 1-ASTERISK_1-to-
( 1) 20081106_144828.pcap
( 2) 20081111__bug13645__3.diff.txt
( 3) 20081111__bug13645.diff.txt
( 4) 2-ASTERISK_1-to-1.4.22.txt
( 5) 3-ASTERISK_2.txt
( 6) 4-ASTERISK_3.txt
( 7) 5-ASTERISK_1-to-existing-number.txt
( 8) iax2-1.6.x-11-11-2008.diff
( 9) iax2-nocausecode.diff
Description:After upgrading to 1.4.22 problem with call disconnection appeared.


IP_PHONE <---sip---> ASTERISK_1 <----iax2----> ASTERISK_2 <---zap---> PSTN

Call from IP_PHONE to PSTN to non_existing number (unassigned/unallocated number, release cause 1) is no longer cleared immediately, but only after approx. 10s.
iax2 debug shows, that there is no HANGUP message sent by ASTERISK_2.
Side effect - there is impossible to discover HANGUPCAUSE on ASTERISK_1, cause HANGUPCAUSE is transmitted in HANGUP message :-(.

In fact, it looks, that there is HANGUP missing in case call was answered, too.

I'm pretty sure, in it worked. But I have no chance to rolback to right now :(


I'm attaching "set verbose 5" + "iax2 debug" for several calls.

1. From ASTERISK_1 calling via pretty old (let's call him ASTERISK_3)
2. From ASTERISK_1 calling via 1.4.22
3. From ASTERISK_2 (1.4.22)
4. From ASTERISK_3 (
5. From ASTERISK_1 to existing number. Call was answered, then called party disconnected.

First 4 calls are made to non-existent number, PSTN disconnects call immediately.
Comments:By: Igor Zamocky (dzajro) 2008-10-10 01:37:35

Nobody encountered the same issue? It starts to be pretty annoying :-(

By: Phoebe Anderson (phoebe) 2008-10-10 07:19:34

Confirmed.  I'm seeing the same issue.  And it is indeed annoying.

By: Tristram Graham (callingtris) 2008-10-13 03:02:13

I'm also seeing the same issue and has been the single issue that stopped me from upgrading. I added a note to issue ASTERISK-1337468 though this is the right bug - just hadn't spotted it at the weekend.

By: Morten Tryfoss (mtryfoss) 2008-10-24 14:28:51

This also seems to be an issue with

By: Anton Vazir (vazir) 2008-10-30 05:24:33

The same for me, I've lost 2 days switching contexts and so on, trying to find out what's happening with my dialplan, then finally switched from 1.4.22 to - which got me normal behaviour. And than found this bug file...

More, it inserts extra delay and uncertainty in the calling * so it's impossible to correctly distinguish the cause code. Since I relay on HANGUPCAUSE for passing codes to PSTN - 1.4.22 is unusable for me.

By: Igor Zamocky (dzajro) 2008-10-30 05:56:55

HANGUPCAUSE is transmitted in HANGUP, no HANGUP = no HANGUPCAUSE ;-)

By: Anton Vazir (vazir) 2008-10-30 06:20:22

I ALWAYS terminate my contexts with Hangup(my_cause_of_hangup)
And in my tests I even did DUMB tests, called the context

exten => _123,1,Hangup(21)

and if the called * is - I'm getting my HANGUPCAUSE=21 back. If it's 1.4.22 - I get HANGUPCAUSE=0

test a dumb simple. changes in a simple "make install" in the different * version directories.

But i might be getting you wrong, you did find a workarround? Any example?

By: Igor Zamocky (dzajro) 2008-10-30 07:11:37

When one side doesn't transfer HANGUPCAUSE (in IAX2 HANGUP) other end interprets this as HANGUPCAUSE=0.

Unfortunately I didn't find any workaround to all this. Except this bug I found 1.4.22 far better then Many issues I have had were solved after upgrading do 1.4.22. If someone will fix this issue (without any new issue) it will be almost perfect ;-)

By: Anton Vazir (vazir) 2008-10-30 07:20:56

Could you please mention what issues in do you mean? I'll try to apply patches for this issues from 1.4.22 and see if this is the way for us both have HANGUPCAUSE and less bugs

I suspect that IAX2 in 1.4.22 does not properly transfer HANGUP at all, since I always have a delay in ~ 5secs before I hangup the phone and calling box receive this hangup. Again this is only in 1.4.22

By: Anton Vazir (vazir) 2008-10-30 07:54:19

Ok, I've found a buggy place, and patch is below. Actually just a few checks are reverted back, which allowes to send a causecode again...

The causeing place is here, the rest is reverted since variables are required. I thnk this tiny part does not require a license submission...

if (alreadygone && iaxs[callno]) {

the fill patch would be

<code removed - please place all code changes via the upload facility provided within mantis>

By: snuffy (snuffy) 2008-10-30 08:14:11

vazir - with any patch or 'suggested' patch you need to upload it as a code submission this way we know your license is on file with digium etc.

By: Anton Vazir (vazir) 2008-10-30 09:12:14

So I don't have a license agreement and system not letting me to post the diff.  Now I do not have time to deal with licensing. And what I don't understand is what is our goal - is it to have me sign an agreement or to fix the regression, which I pointed out exactly and what could be fixed by any of the developers, since there is a few lines of the code,reverted from

By: Mark Michelson (mmichelson) 2008-10-30 16:57:07

vazir: If you have a fix, that's great, but all code submissions have to be properly licensed, otherwise there could be potential legal issues for us. I can assume that by posting code at all you are implicitly giving license to use it in Asterisk, but without explicitly signing the license agreement, we cannot use it or even view it. I'm sorry about the inconvenience it may cause, but it's a one-time agreement to sign and it does not take long.

By: Anton Vazir (vazir) 2008-10-31 00:03:28

The license signing is broken
to see it - try logging in as a new user, and try sending the code.

what it gives:


Sorry, you don't have a license agreement on file.<br />You must sign an agreement before being allowed to make code or documentation submissions.<br /><br>license_agreement.php?redirect=http://bugs.digium.com/view.php?id=13645<br />

ind if I go to the mentioned URL manually - it gives more errors upon filling all necessary fields, and anyway not letting to submit the code.

By: Joshua C. Colp (jcolp) 2008-10-31 08:44:45

vazir: Your license is in the queue to be accepted, it is not an instant process.

By: Anton Vazir (vazir) 2008-11-01 00:14:30

Issue seems to be more complicated, seems with reverted changes channel may not be destroyed, but if it's destroed, CAUSECODE is not sent. Input of someone knowing the proper IAX2 channel logic is required

By: Igor Zamocky (dzajro) 2008-11-01 03:24:59

To revert changes in chan_iax2.c I tried as first thing. After debugging it seems to me, that problem is somewhere in scheduler. But it's beyond my programming skills :-(

By: Anton Vazir (vazir) 2008-11-06 02:11:04.000-0600

Seems this IAX2 issues totally uninteresting to digium or developers, no one looked here.

By: Steve Henke (shenke) 2008-11-06 15:46:36.000-0600

I confirm this and it is problem here. I upgraded my office server to 1.4.21-2 w/chan_iax2.c rev 147389 with FreePBX generating the extensions. I have an IAX2 GlobeTelx IAD 2 line FXS device. You call the device, it starts ringing. You don't answer. You hang up the calling phone. The called phone keeps ringing. I'll upload the Wireshark capture.

By: Anton Vazir (vazir) 2008-11-11 11:38:50.000-0600

The same stuff with - just tested.

By: Anton Vazir (vazir) 2008-11-12 02:35:12.000-0600

The last patch is the v3 adopted for 1.6.x

By: Igor Zamocky (dzajro) 2008-11-12 03:53:21.000-0600

Vazir, patch You uploaded is patch to fix this issue on 1.6.x.

Or is it the patch, You assume, responsible for this issue?
If this is the case, did You try to revert changes in chan_iax2.c? Did it help?

By: Anton Vazir (vazir) 2008-11-12 03:59:03.000-0600

dzajro, the last uploaded patch is the adoption for 1.6.x of the Corydon76 patch (which was originally made for 1.4.22), In brief, patch is is a (partly) reversion of the changes from 1.4.21, plus fix for a memory leak (added scheduled call destruction)

By: Anton Vazir (vazir) 2008-11-12 04:00:20.000-0600

And yes, corresponding patches tested and work for me for both 1.4.22 and

By: Digium Subversion (svnbot) 2008-11-12 12:39:16.000-0600

Repository: asterisk
Revision: 156229

U   branches/1.4/channels/chan_iax2.c

r156229 | tilghman | 2008-11-12 12:39:16 -0600 (Wed, 12 Nov 2008) | 11 lines

Revert revision 132506, since it occasionally caused IAX2 HANGUP packets not
to be sent, and instead, schedule a task to destroy the iax2 pvt structure
10 seconds later.  This allows the IAX2 HANGUP packet to be queued,
transmitted, and ACKed before the pvt is destroyed.
(closes issue ASTERISK-12847)
Reported by: dzajro
      20081111__bug13645__3.diff.txt uploaded by Corydon76 (license 14)
Tested by: vazir
Reviewed: http://reviewboard.digium.com/r/51/