[asterisk-bugs] [Asterisk 0017552]: Cancelling a connection does not clear retransmissions

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17552 
====================================================================== 
Reported By:                viraptor
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17552
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.9 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-06-24 09:12 CDT
Last Modified:              2010-06-29 14:21 CDT
====================================================================== 
Summary:                    Cancelling a connection does not clear
retransmissions
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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-29 14:21 lmadsen        Description Updated                          
2010-06-29 14:21 lmadsen        Additional Information Updated                  
 
======================================================================