[asterisk-bugs] [Asterisk 0016010]: Call abort after wrong behaviour of VNAK transmission

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16010 
====================================================================== 
Reported By:                ffloimair
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16010
Category:                   Channels/chan_iax2
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.26.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-02 03:22 CDT
Last Modified:              2009-10-14 20:20 CDT
====================================================================== 
Summary:                    Call abort after wrong behaviour of VNAK
transmission
Description: 
Asterisk sends VNAK to signal a retransmission of a packet. After
retransmission the request is sent again and again... Abort of the call is
the result after a few retries.
Overall, asterisk very often sends VNAK after receiving LAGRQ and PING
consecutively. Why does asterisk know that packet 2 after 1 is missing if
there was no packet 3 so far (numbers referring to ascending sequence
numbers in IAX Header)? This is confusing since the RFC states the below
text requiring to retransmit all frames with a higher sequence number than
the one received with the VNAK.

Please see the attached pcap file.

There was no significant output in the asterisk console, so I do not post
this as of now. If required I can post this later.

====================================================================== 

---------------------------------------------------------------------- 
 (0112311) c0rnoTa (reporter) - 2009-10-14 20:20
 https://issues.asterisk.org/view.php?id=16010#c112311 
---------------------------------------------------------------------- 
I have the same issue. Under my control are 2 servers. There are some
queues on each server. Operator receives call from queue, that came to
station via DAHDI, and transfers it via IAX to another queue on another
server. Second operator receives the call. After a call from DAHDI by
server 1 and operator on server 2 bridged together + a few seconds, and a
call drops.

I'm digging log all night and found what: both my stations time to time
have deadlocks:
[Oct 14 13:51:23] DEBUG[11495] channel.c: Avoiding initial deadlock for
channel '0xb6605278'
But sometimes deadlocks have something like this:
[Oct 14 11:22:26] DEBUG[11495] channel.c: Avoiding initial deadlock for
channel '0xb6105fc0'
[Oct 14 11:22:26] DEBUG[11509] chan_iax2.c: Packet arrived out of order
(expecting 3, got 5) (frametype = 2, subclass = 256)
I'm using "trunk=yes" option in my configuration. Cound deadlock be by
chan_iax? while trunk channel locked, we are receiving VNAK message, and
then
[Oct 14 11:22:33] DEBUG[11505] chan_iax2.c: Immediately destroying 16096,
having received hangup
Could it be true or it's absurd? It's only my theoretical supposition.

I'm so sorry, but VNAK message does not exist permanently in my debug log
before drops. But messages about "chan_iax2.c: Packet arrived out of order"
does. And there are over 23000 messages "Received VNAK: resending
outstanding frames" having different time with call drops.

I'll try to attach my log files. Call drop was at 11:22:33 (amazing!) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-14 20:20 c0rnoTa        Note Added: 0112311                          
======================================================================