[asterisk-bugs] [Asterisk 0017521]: Brief lagginess on IAX2 channels is fatal

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17521 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17521
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.8 
JIRA:                       SWP-1718 
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-17 10:32 CDT
Last Modified:              2010-12-20 06:05 CST
====================================================================== 
Summary:                    Brief lagginess on IAX2 channels is fatal
Description: 
The problem reported in issue https://issues.asterisk.org/view.php?id=15609 and
https://issues.asterisk.org/view.php?id=15900 continues:

[Jun 17 09:55:14] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
[Jun 17 09:57:54] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
[Jun 17 09:57:54] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
[Jun 17 09:58:07] NOTICE[15579]: chan_iax2.c:11447 __iax2_poke_noanswer:
Peer 'x29' is now UNREACHABLE! Time: 2
[Jun 17 09:58:07] NOTICE[15579]: chan_iax2.c:11447 __iax2_poke_noanswer:
Peer 'jrclaptop' is now UNREACHABLE! Time: 4
[Jun 17 09:58:07] NOTICE[15579]: chan_iax2.c:11447 __iax2_poke_noanswer:
Peer 'x38' is now UNREACHABLE! Time: 136
[Jun 17 09:58:10] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
[Jun 17 09:58:10] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
[Jun 17 09:58:10] WARNING[15579]: channel.c:1044 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/x38-9660
    -- Hungup 'IAX2/x38-9660'
  == Spawn extension (dialstation, 38, 1) exited non-zero on
'SIP/x28-0000048b'
[Jun 17 09:58:12] NOTICE[15579]: chan_iax2.c:10418 socket_process: Peer
'x29' is now REACHABLE! Time: 2
[Jun 17 09:58:12] NOTICE[15579]: chan_iax2.c:10418 socket_process: Peer
'jrclaptop' is now REACHABLE! Time: 4
[Jun 17 09:58:12] NOTICE[15579]: chan_iax2.c:10418 socket_process: Peer
'x38' is now REACHABLE! Time: 137

This tends to reproduce for me only on transatlantic calls.

/john

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015609 [patch] WARNING[23025]: channel.c:952 _...
related to          0015900 Console flood & CPU load 100% when ...
related to          0017625 "I should never be called!" m...
====================================================================== 

---------------------------------------------------------------------- 
 (0129786) jcovert (reporter) - 2010-12-20 06:05
 https://issues.asterisk.org/view.php?id=17521#c129786 
---------------------------------------------------------------------- 
This past week I had some more experience with this problem:

Call was placed from the asterisk instance in Germany to my instance in
the U.S., and the codec choice the whole way ended up being G.711, because
it was
answered in the U.S. on a Cisco ATA186.  We talked at length with no
problems.

I then did a blind xfer to a Snom 300, which had the G.722 codec
available, and chose to use it and transcode.  Due to the slight extra
overhead of transcoding, the lagginess occurred and conversation became
difficult.  A blind xfer back to a 2500 set on an ATA186 restored the call
quality to normal.

and now I see that this is not new information, but rather the same as
reported in (0124236).

I was reading the code some months ago, and noticed that the code which
handles the queue and checks the queue length has a scaling problem: since
the queue is singly-linked and there is no count of entries maintained, the
queue length is checked by traversing the queue.  As more entries are
placed on the queue, this traversal time gets longer, exacerbating the
problem.  Removel from the queue also requires traversal.  Since this is a
FIFO queue, for efficiency it should be doubly linked, with both a head and
tail pointer, in order to allow insertion at one end and removal at the
other without requiring traversal.

/john 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-20 06:05 jcovert        Note Added: 0129786                          
======================================================================