[Home]

Summary:ASTERISK-12718: IAX Transfer/releasing between 3 asterisk's are not working.
Reporter:Nico Giefing (nicox)Labels:
Date Opened:2008-09-12 04:42:41Date Closed:2009-02-04 15:32:35.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax-log.txt
Description:Since the Asterisk Version 1.6.0-beta9 (the first 1.6.0 i tried) i the IAX Releasing is not working on this machine.
I tried also 1.6.0-rc6 and the problem is still the same.

I have some asterisk 1.2.* and 1.4.* and SVN-trunk-r92976 running, and with all machines calls are released after the call answered.

Only the machine with asterisk 1.6.0-* can't do this.

i don't know how to test things to help debugging it.

if you need anything to solve this problem, please let me know.

thanks a lot

Nico
Comments:By: snuffy (snuffy) 2008-09-12 08:38:51

Please describe the exact steps you take to get this issue.
This way we may be able to reproduce the bug ourselves.

eg.
1.2 iax call to 1.4
1.4 iax then xfer to 1.6
etc etc
By: Nico Giefing (nicox) 2008-09-12 08:54:51

The call comes from Asterisk 1.4 or 1.2 to 1 "routing box" which handles how to route the call next, the routing box is asterisk 1.4
The routing box dials the call to "termination boxes" for this boxes we using 1.2, SVN-trunk-r92976 and 1.6.0-*.

Where the calls are terminating via a box which is running 1.2 or the svn-version the call is released and the media-path and anyting else is handled without the "routing-box".

This scenario is not working with the 1.6 version of asterisk, in this case the media patch is handled also via the "routing-boxes".


that means
A (1.2) calls to B(1.4) calls to C(1.2)
the call will be released after answering and the media path and all signalling is handled between A and C

A (1.2) calls to B(1.4) calls to D(1.6)
the call will not be released after answering, so the complete media path is handled via C.
By: snuffy (snuffy) 2008-09-12 16:21:36

could you also post a iax debug of the behaviour.
was this an issue in older 1.6 builds?
By: Nico Giefing (nicox) 2008-09-13 01:50:55

the iax debug is not so easy, but i will try and post asap.
This Issue for me started on 1.6.0-beta9. aa working Version was SVN-trunk-r92976, but i don't know if this is already a 1.6-Version.
By: Nico Giefing (nicox) 2008-09-15 02:58:46

Here is a verbose 3 output and iax2 debug

i don't know which packet is which call, so there are all things of 2 calls.


(now as attachment)


By: Nico Giefing (nicox) 2008-09-22 01:34:35

anyone who can repdroduce this problem, or is this feature not longer supported?
By: Nico Giefing (nicox) 2008-10-02 17:06:11

New Version, old bug.

In asterisk 1.6.0 i get a warning:
  -- DAHDI/1-1 answered IAX2/voice2-srv27-1511
[Oct  3 00:13:09] WARNING[3933]: chan_iax2.c:1200 __send_lagrq: I was supposed to send a LAGRQ with callno 9324, but no such call exists (and I cannot remove lagid, either).
   -- Channel 'IAX2/voice2-srv27-1511' unable to transfer
By: Nico Giefing (nicox) 2008-10-08 08:16:27

Unable to transfer is executed because of transfer timed out (line 2328 in chan_iax2.c)
Please let me know how to debug it a bit better to solve the problem.
By: Tristram Graham (callingtris) 2008-10-11 11:53:38

I've had a similar issue and IAX debug output for an IAX trunk between two Asterisk boxes. The issue seems to appear in version 1.4.22 of Asterisk but works fine with version 1.4.21. Both versions are running on Zaptel 1.4.8.

The issue is for a call hangup between two Asterisk boxes over an IAX trunk. If an Asterisk 1.4.22 box initiates the hangup, the second box leaves the channel open for a few seconds before the following IAX debug is seen (on both boxes);

   Tx-Frame Retry[000] -- OSeqno: 004 ISeqno: 008 Type: IAX     Subclass: LAGRQ
      Timestamp: 20013ms  SCall: 00001  DCall: 07750 [192.168.71.102:4569]
   Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
      Timestamp: 00000ms  SCall: 07750  DCall: 00001 [192.168.71.102:4569]

If I move the version of Asterisk back to 1.4.21, the hangup is immediate on both boxes with the following IAX debug;

   *CLI> Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 006 Type: IAX     Subclass: HANGUP
      Timestamp: 08594ms  SCall: 00001  DCall: 06356 [192.168.71.103:4569]
      CAUSE CODE      : 16
   
   Tx-Frame Retry[-01] -- OSeqno: 006 ISeqno: 003 Type: IAX     Subclass: ACK
      Timestamp: 08594ms  SCall: 06356  DCall: 00001 [192.168.71.103:4569]
     == Spawn extension (default, 21211, 1) exited non-zero on 'IAX2/swayzak-6356'
       -- Hungup 'IAX2/swayzak-6356'

The second system in the above tests is Asterisk 1.4.18 on Zaptel 1.4.8 in both cases. I've also tested Asterisk 1.6.0 and have seen the same issue.


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

Issue ASTERISK-1355645 seems to be the same issue for the missing explicit IAX trunk hangup.
By: Derek Whitten (derekwhitten) 2008-11-09 10:47:06.000-0600

I get lots of this same error w/asterisk 1.4.22, asterisk-addons-1.4.7 & zaptel-1.4.12.1


[Nov  8 23:44:58] WARNING[23141]: chan_iax2.c:1056 __send_lagrq: I was supposed to send a LAGRQ with callno 10564, but no such call exists (and I cannot remove lagid, either).
[Nov  8 23:45:18] WARNING[23140]: chan_iax2.c:1056 __send_lagrq: I was supposed to send a LAGRQ with callno 10200, but no such call exists (and I cannot remove lagid, either).
[Nov  8 23:46:38] WARNING[23136]: chan_iax2.c:1056 __send_lagrq: I was supposed to send a LAGRQ with callno 5307, but no such call exists (and I cannot remove lagid, either).
[Nov  8 23:47:18] WARNING[23144]: chan_iax2.c:1056 __send_lagrq: I was supposed to send a LAGRQ with callno 6735, but no such call exists (and I cannot remove lagid, either).


Odd part about this is there were no calls active at the time these messages were generated.
By: Nico Giefing (nicox) 2008-12-10 08:19:18.000-0600

I updated now to asterisk 1.6.0.3-rc1 and still the same problem!
By: Leif Madsen (lmadsen) 2008-12-10 10:25:34.000-0600

Assigned to Russell in the hope he may be able to look at it. If this is not the case, please re-assign as necesary. Thanks!
By: Allan Button (abutton) 2008-12-12 11:57:32.000-0600

We are experiencing the same issue between two of our asterisk machines. Both are running 1.6.x, we have tryed a couple different versions of 1.6 with no change.

We are also getting the lagid.

Basically, we have our IVR for the entire company, on Site A. So when you call to Site B, it swings you to site A for the IVR, then when you select someone from Site B, it swings back. I was hoping this would release the call, as to not have the entire call tromboned from one site to the other for the duration of the call.

We a call attempts to transfer here, we see 4 'unable to transfer' messages on Site A's console.

I can gather more information if needed, just let me know what would help.

Thanks.
By: Leif Madsen (lmadsen) 2009-01-28 14:36:45.000-0600

I have re-assigned this issue to dvossel to take a look and see if he has any ideas of how to move this forward. Please re-assign should you not be able to continue with this issue. Thanks!
By: David Vossel (dvossel) 2009-01-29 17:22:36.000-0600

ok, I've done a whole bunch of testing.  Here's whats up.

These configurations transfer correctly
A = 1.2
B = 1.2, 1.4, or 1.6
C = 1.2

These configurations do not transfer correctly

A = 1.4 or 1.6
B = 1.2, 1.4, or 1.6
C = 1.4 or 1.6

so it looks like somethings wrong in 1.4 and 1.6... And  I believe i've narrowed that down as well. both  A and C get TXREQ from B and send TXCNT messages to each other afterwards.  The wireshark capture show that A and C get the TXCNT frames from each other but do not process them at all.  They are just thrown out, not even acknowleged.   It appears some aggressive callno and calldst filters in chan_iax2.c's socket_process function are throwing out the packets before they can even be processed preventing the transfer to complete.


By: Digium Subversion (svnbot) 2009-02-03 17:35:58.000-0600

Repository: asterisk
Revision: 173248

U   branches/1.4/channels/chan_iax2.c

------------------------------------------------------------------------
r173248 | dvossel | 2009-02-03 17:35:57 -0600 (Tue, 03 Feb 2009) | 6 lines

Fixes issue with IAX2 transfer not handing off calls.

Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.

(issue ASTERISK-12718)

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

http://svn.digium.com/view/asterisk?view=rev&revision=173248
By: Digium Subversion (svnbot) 2009-02-03 17:39:14.000-0600

Repository: asterisk
Revision: 173249

_U  trunk/

------------------------------------------------------------------------
r173249 | dvossel | 2009-02-03 17:39:14 -0600 (Tue, 03 Feb 2009) | 12 lines

Blocked revisions 173248 via svnmerge

........
 r173248 | dvossel | 2009-02-03 17:35:55 -0600 (Tue, 03 Feb 2009) | 6 lines
 
 Fixes issue with IAX2 transfer not handing off calls.
 
 Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.
 
 (issue ASTERISK-12718)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=173249
By: Digium Subversion (svnbot) 2009-02-03 17:41:28.000-0600

Repository: asterisk
Revision: 173250

U   branches/1.6.0/channels/chan_iax2.c

------------------------------------------------------------------------
r173250 | dvossel | 2009-02-03 17:41:28 -0600 (Tue, 03 Feb 2009) | 7 lines

Fixes issue with IAX2 transfer not handing of calls.

Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.

(issue ASTERISK-12718)


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

http://svn.digium.com/view/asterisk?view=rev&revision=173250
By: David Vossel (dvossel) 2009-02-03 17:49:12.000-0600

the above patches make 1.4 and 1.6.0 work correctly. additional work must be done in 1.6.1 and trunk.
By: Digium Subversion (svnbot) 2009-02-04 09:20:27.000-0600

Repository: asterisk
Revision: 173248

U   branches/1.4/channels/chan_iax2.c

------------------------------------------------------------------------
r173248 | dvossel | 2009-02-03 17:35:55 -0600 (Tue, 03 Feb 2009) | 7 lines

Fixes issue with IAX2 transfer not handing off calls.

Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.

(issue ASTERISK-12718)
Review: http://reviewboard.digium.com/r/140/

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

http://svn.digium.com/view/asterisk?view=rev&revision=173248
By: Digium Subversion (svnbot) 2009-02-04 09:21:27.000-0600

Repository: asterisk
Revision: 173249

_U  trunk/

------------------------------------------------------------------------
r173249 | dvossel | 2009-02-03 17:39:14 -0600 (Tue, 03 Feb 2009) | 13 lines

Blocked revisions 173248 via svnmerge

........
 r173248 | dvossel | 2009-02-03 17:35:55 -0600 (Tue, 03 Feb 2009) | 6 lines
 
 Fixes issue with IAX2 transfer not handing off calls.
 
 Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.
 
 (issue ASTERISK-12718)
Review: http://reviewboard.digium.com/r/140/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=173249
By: Digium Subversion (svnbot) 2009-02-04 09:21:45.000-0600

Repository: asterisk
Revision: 173250

U   branches/1.6.0/channels/chan_iax2.c

------------------------------------------------------------------------
r173250 | dvossel | 2009-02-03 17:41:28 -0600 (Tue, 03 Feb 2009) | 7 lines

Fixes issue with IAX2 transfer not handing of calls.

Fixes issue with IAX2 transfers not taking place.  As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table.  The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required.  This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.

(issue ASTERISK-12718)
Review: http://reviewboard.digium.com/r/140/

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

http://svn.digium.com/view/asterisk?view=rev&revision=173250
By: Digium Subversion (svnbot) 2009-02-04 15:25:16.000-0600

Repository: asterisk
Revision: 173502

U   trunk/channels/chan_iax2.c
U   trunk/channels/iax2-parser.h

------------------------------------------------------------------------
r173502 | dvossel | 2009-02-04 15:25:16 -0600 (Wed, 04 Feb 2009) | 9 lines

Fixes issue with IAX2 transfer not handing off calls. Reverts changes in 116884
 
Fixes issue with IAX2 transfers not taking place. As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table. The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required. This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table. The changes reverted in 116884 caused backwards compatibility issues involving iax2 transfer with 1.6.0, 1.4, and 1.2.
 
(closes issue ASTERISK-12718)
Reported by: nicox
Tested by: dvossel


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

http://svn.digium.com/view/asterisk?view=rev&revision=173502
By: Digium Subversion (svnbot) 2009-02-04 15:32:33.000-0600

Repository: asterisk
Revision: 173506

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_iax2.c
U   branches/1.6.1/channels/iax2-parser.h

------------------------------------------------------------------------
r173506 | dvossel | 2009-02-04 15:32:33 -0600 (Wed, 04 Feb 2009) | 15 lines

Merged revisions 173502 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r173502 | dvossel | 2009-02-04 15:25:14 -0600 (Wed, 04 Feb 2009) | 9 lines
 
 Fixes issue with IAX2 transfer not handing off calls. Reverts changes in 116884
   
 Fixes issue with IAX2 transfers not taking place. As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table. The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required. This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table. The changes reverted in 116884 caused backwards compatibility issues involving iax2 transfer with 1.6.0, 1.4, and 1.2.
   
 (closes issue ASTERISK-12718)
 Reported by: nicox
 Tested by: dvossel
........

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

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