[Home]

Summary:ASTERISK-04798: Calls dropped on blind transfer using IAX2
Reporter:Vincent Luba (colombus)Labels:
Date Opened:2005-08-09 08:18:20Date Closed:2011-06-07 14:10:00
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) amd.txt
( 1) console_output.txt
( 2) dell.txt
Description:I have 2 asterisk boxes, let's call them 'dell' (extensions matchs prefix 63XX) and 'amd', they are connected via IAX2 (matches prefix 62XX).

I'm in a situation where a single call may be transfered several times (operator, customers, agents, ...)

When I execute the following scenario, on one end the call is dropped, the other end stays in "communication".

Here's the scenario :
1) Bob (ext. 6202 on 'dell') calls the operator (ext. 6302 on 'amd')

2) The operator transfers the call to Brad (ext 6203 on 'dell') 'dell' performs a native bridge and releases IAX channels. On 'amd' calls between 6203 and 6202 are still stated as bridged to IAX2 channels

3) Brad transfers the call to Bert (ext. 6303 back on 'amd')
'amd' attempts a native bridge and releases two IAX2 channels, after half a second, including the one said to be bridged to SIP/6202.

Results : channel SIP/6202 is hung up.
On 'dell' the call stays active. Bert has just heard 'allo' from Brad before then '...' (silence) Whithout any 'hung up' notification.



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

- I've set up the boxes such as they use the same codec end-to-end, it did not changed anything.
- Using 'notransfer=yes' option prevent from call drops, is not suitable in our configuration (after few transfer, call quality is affected).
- All sip peers have the 'canreinvite' option set to 'yes'.
Comments:By: Michael Jerris (mikej) 2005-08-09 13:04:17

we need configuration example and debug for this as well.
By: Vincent Luba (colombus) 2005-08-10 05:19:21

I've uploaded two files : amd.txt and dell.txt. Those two files contains asterisk's console trace (with args extra debugging enabled and 'iax2 debug' command issued)

That trace illustrate the following situation (extensions are different from the example provided in the bug description)

First step
==========
6203 (registered on amd) calls 6012 (registered on dell).

an alaw sip channel links 6203 and amd, on one hand, and 6012 and dell on the other hand.
a gsm iax2 channel is set between amd and dell.

Second step
===========
6012 transfers call (blind transfer) to 6200 (registered on amd)

Releasing 'IAX2/<amd_ip_address>:4569/2' and 'IAX2/<iax2_username>@<amd_ip_address>:4569/1' on dell

!!! There's no traffic anymore between dell and amd!!!

Third step
==========
6200 transfers to 6012
Releasing 'IAX2/<dell_ip_address>:4569/3' and 'IAX2/<iax2_username>@<dell_ip_address>:4569/2' on amd

Last release drops the call.
By: Vincent Luba (colombus) 2005-08-10 05:41:15

I think I've narrowed down to the problem :
from the console output, just before the call is dropped, I read :


Tx-Frame Retry[-01] -- OSeqno: 003 ISeqno: 005 Type: IAX     Subclass: ACK
  Timestamp: 54490ms  SCall: 00001  DCall: 00002 [<amd_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 005 Type: IAX     Subclass: ACK
  Timestamp: 54490ms  SCall: 00001  DCall: 00002 [<amd_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 006 ISeqno: 005 Type: IAX     Subclass: ACK
  Timestamp: 04334ms  SCall: 00003  DCall: 00003 [<dell_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: VOICE   Subclass: 2
  Timestamp: 00000ms  SCall: 00003  DCall: 00001 [<dell_ip_address>:4569]
Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: ACK
  Timestamp: 00003ms  SCall: 00001  DCall: 00003 [<dell_ip_address>:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: VOICE   Subclass: 2
  Timestamp: 4294967018ms  SCall: 00001  DCall: 00003 [<dell_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
  Timestamp: 4294967018ms  SCall: 00003  DCall: 00001 [<dell_ip_address>:4569]
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 001 Type: VOICE   Subclass: 2
  Timestamp: 00002ms  SCall: 00001  DCall: 00003 [<dell_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: ACK
  Timestamp: 00002ms  SCall: 00003  DCall: 00001 [<dell_ip_address>:4569]
Tx-Frame Retry[001] -- OSeqno: 004 ISeqno: 006 Type: IAX     Subclass: TXREL
  Timestamp: 04334ms  SCall: 00003  DCall: 00003 [<dell_ip_address>:4569]
  CALL NUMBER     : 1

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
  Timestamp: 00000ms  SCall: 00003  DCall: 00003 [<dell_ip_address>:4569]
   -- Hungup 'IAX2/<dell_ip_address>:4569/1'
   -- Executing Macro("SIP/6203-c9a8", "hangup") in new stack
   -- Executing Hangup("SIP/6203-c9a8", "SIP//012") in new stack
Aug 10 13:20:13 WARNING[4668]: chan_iax2.c:6026 socket_read: Received mini frame before first full voice frame
Tx-Frame Retry[000] -- OSeqno: 006 ISeqno: 006 Type: IAX     Subclass: VNAK
  Timestamp: 06338ms  SCall: 00003  DCall: 00003 [<dell_ip_address>:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
  Timestamp: 00000ms  SCall: 00003  DCall: 00003 [<dell_ip_address>:4569]
   -- Hungup 'IAX2/<dell_ip_address>:4569/3'
   -- Executing Macro("IAX2/<iax2_username>@<dell_ip_address>:4569/2", "hangup") in new stack
   -- Executing Hangup("IAX2/<iax2_username>@<dell_ip_address>:4569/2", "SIP//012") in new stack
   -- Hungup 'IAX2/<iax2_username>@<dell_ip_address>:4569/2'

It seems that the "Subclass: INVAL" packet is the problem. What's its cause? I've seen the "chan_iax2.c:6026 socket_read: Received mini frame before first full voice frame" warning in other situation, but it never triggered an hang up.

Here are further details on my configuration

iax.conf
========
[general]
;bindaddr=<IP>
amaflags=billing
accountcode=IAX
bandwidth=low
disallow=all
allow=gsm
jitterbuffer=yes
dropcount=3
tos=lowdelay

language = en

;#### Configuration for remote host 1
[<username>]
type = friend
auth = plaintext
context = from-remote-hosts
qualify = yes
trunk = no
secret = <password>
username = <username>
defaultip = <IP>
By: Michael Jerris (mikej) 2005-08-27 01:32:28

Can you please also test on current cvs head, or the 1.2 beta1 and confirm if this also exists there.
By: Clod Patry (junky) 2005-09-08 23:25:15

colombus: we need feedback here.
Thanks
By: Vincent Luba (colombus) 2005-09-09 03:19:18

Hi, I've been very busy last days and couldn't test it.
I'll try to perform them next week.
Thanks
By: Olle Johansson (oej) 2005-09-09 03:55:12

Since we are quickly moving towards a release of 1.2, I would kindly ask you to test as soon as possible in order to help us moving forward. Thank you.
By: Vincent Luba (colombus) 2005-09-14 04:34:32

I just tested the CVS HEAD.
Nothing has changed, the exact same behaviour with the same warning :
"chan_iax2.c:7400 socket_read: Received mini frame before first full voice frame"
By: Matt O'Gorman (mogorman) 2005-09-29 10:05:04

Hi, after setting this up locally we were unable to generate the same bug here locally.  Can you provide me with access and when a good time for me to test would be.  You can reach me at mogorman@digium.com
By: Matt O'Gorman (mogorman) 2005-09-29 10:06:42

waiting for access
By: Olle Johansson (oej) 2005-10-11 23:53:55

Lack of response from reporter.