[Home]

Summary:ASTERISK-16287: Cancelling a connection does not clear retransmissions
Reporter:Stanislaw Pitucha (viraptor)Labels:
Date Opened:2010-06-24 09:12:32Date Closed:2011-07-26 15:32:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If you create a connection and cancel it (with HANGUP) before getting an answer, the IAX channel tries to retransmit some messages, even though this may cause other problems.

The scenario which is specifically affected (this all happens before the other side responds anything):

> NEW
> HANGUP
> NEW (retransmission)
> HANGUP (retransmission)

In this case, the first hangup is supposed to end the connection. Since "Upon receipt of a HANGUP message, an IAX peer MUST immediately respond with an ACK, and then destroy the call leg at its end." [RFC5456 6.2.5], the second NEW is treated like a beginning of a new call (it's a proper retransmission of the first one)

So now there are 2 ways to handle it:
- current one, where it's actually following the protocol, but may create 2 calls on the other end, where we'd expect only one
- clear retransmissions of NEW when the call is being cancelled - I think this is a more logical way to handle it, since there might be another, worse situation:

> NEW
< (ACK[NEW] gets lost)
> HANGUP
> NEW (retransmitted)
< ACK[HANGUP]
Now the channel stays in NEW state on the other side and keeps resending auth request, or something else, which results in INVAL on the other side - in other words: useless traffic.

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

iax debug of such situation:

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
  Timestamp: 00008ms  SCall: 01069  DCall: 00000 [A.B.C.D:4569]
  VERSION         : 2
  CALLED NUMBER   : 123456
  CODEC_PREFS     : ()
  CALLING NUMBER  : 234567
  CALLING PRESNTN : 0
  CALLING TYPEOFN : 0
  CALLING TRANSIT : 0
  CALLING NAME    :
  LANGUAGE        : en
  USERNAME        : devsip
  FORMAT          : 2
  CAPABILITY      : 1795
  ADSICPE         : 2
  DATE TIME       : 2010-6-24  14:46:50

Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass: HANGUP
  Timestamp: 00011ms  SCall: 01069  DCall: 00000 [A.B.C.D:4569]
  CAUSE CODE      : 0

Tx-Frame Retry[001] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
  Timestamp: 00008ms  SCall: 01069  DCall: 00000 [A.B.C.D:4569]
  VERSION         : 2
  CALLED NUMBER   : 123456
  CODEC_PREFS     : ()
  CALLING NUMBER  : 234567
  CALLING PRESNTN : 0
  CALLING TYPEOFN : 0
  CALLING TRANSIT : 0
  CALLING NAME    :
  LANGUAGE        : en
  USERNAME        : devsip
  FORMAT          : 2
  CAPABILITY      : 1795
  ADSICPE         : 2
  DATE TIME       : 2010-06-24  14:46:50

Tx-Frame Retry[001] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass: HANGUP
  Timestamp: 00011ms  SCall: 01069  DCall: 00000 [A.B.C.D:4569]
  CAUSE CODE      : 0
Comments:By: Russell Bryant (russell) 2011-07-26 15:32:38.024-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!