Summary: | ASTERISK-16287: Cancelling a connection does not clear retransmissions | ||
Reporter: | Stanislaw Pitucha (viraptor) | Labels: | |
Date Opened: | 2010-06-24 09:12:32 | Date Closed: | 2011-07-26 15:32:44 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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! |