[Home]

Summary:ASTERISK-19794: IAX channel won't hangup after musconhold stopped
Reporter:dadjul (djul)Labels:
Date Opened:2012-04-25 09:43:17Date Closed:2015-03-14 10:44:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_iax2 Resources/res_musiconhold
Versions:1.8.11.1 Frequency of
Occurrence
Related
Issues:
Environment:Debian Squeeze Intel XeonAttachments:( 0) issue.txt
Description:I have an IAX trunk between asterisk 1.4.22 and 1.8.11.1
Doing a basic dialplan on 1.8.11.1:
exten => 111,1,Answer
exten => 111,2,MusicOnHold()
exten => 111,3,Hangup()

When I hangup on 1.4.22

Asterisk 1.8.11.1 behave badly:

I get the following:
   -- Stopped music on hold on IAX2/dediax-4317

And then this message goes forever:
WARNING[300]: chan_iax2.c:3510 __attempt_transmit: Max retries exceeded to host XXXXXXX on IAX2/dediax-4317 (type = 6, subclass = 11, ts=40006, seqno=9)

As well as core show channels shows:
Channel              Location             State   Application(Data)
IAX2/dediax-4317      111@xxxxx:2        Up      MusicOnHold()
1 active channel
1 active call

The only way is to kill asterisk


Thank you,
Comments:By: dadjul (djul) 2012-04-30 03:48:12.606-0500

Any help on this ticket?

Thank you
By: Matt Jordan (mjordan) 2012-04-30 08:30:08.449-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please set 'iax2 set debug on' as well.
By: dadjul (djul) 2012-04-30 09:32:23.096-0500

Here is the required input.

The log file contains 2 calls, the first one hangup properly the second one did not.
Looks random.

Thank you,
By: dadjul (djul) 2012-04-30 09:37:22.216-0500

Please see attached file.
By: dadjul (djul) 2012-05-09 06:07:01.304-0500

Up

Any news on that? real bug, should I wait to go on production?
By: Matt Jordan (mjordan) 2015-03-14 10:43:15.668-0500

I'm fairly sure this was fixed by r407727:

{quote}
{noformat}
r407727 | rmudgett | 2014-02-07 11:56:57 -0600 (Fri, 07 Feb 2014) | 41 lines

chan_iax2: Block unnecessary control frames to/from the wire.

Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect.  The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.

For example:
1) v1.4 calls v1.8 (or later) using IAX2

2) v1.8 answers and sends a connected line update control frame.  (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)

3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)

4) v1.4 disconnects the call once the receive queue becomes empty.

Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:

* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.

* Made block sending and receiving control frames that have no reason to
go over the wire.

* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.

* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.

(closes issue AST-1302)

Review: https://reviewboard.asterisk.org/r/3174/
{noformat}
{quote}
By: Matt Jordan (mjordan) 2015-03-14 10:43:48.254-0500

Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended. For continued maintenance support please move to a supported branch of Asterisk. After testing with a supported branch, if you find this problem has not been resolved, please open a new issue against the latest version of that Asterisk branch.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions