[asterisk-bugs] [Asterisk 0017521]: [patch] Brief lagginess on IAX2 channels is fatal
Asterisk Bug Tracker
noreply at bugs.digium.com
Sun Feb 20 23:50:11 CST 2011
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: 2011-02-20 23:50 CST
======================================================================
Summary: [patch] 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...
related to 0018511 [patch] Asterisk hangs with no calls be...
======================================================================
----------------------------------------------------------------------
(0132215) jcovert (reporter) - 2011-02-20 23:50
https://issues.asterisk.org/view.php?id=17521#c132215
----------------------------------------------------------------------
I'm now on 1.8.3-rc3. Was still having trouble with IAX.
Did this:
; Establishes the number of iax helper threads to handle I/O.
; iaxthreadcount = 10
iaxthreadcount = 2 ; jrc
iaxmaxthreadcount = 2 ; jrc
; Establishes the number of extra dynamic threads that may be spawned to
handle I/O
; iaxmaxthreadcount = 100
This seems to improve things, though audio is still sometimes quite
choppy. Don't have a lot of experience with this yet; just did it a few
minutes ago, but the originate sip/x28 application dial
iax2/iax.covert.org/ringnoanswer test, which used to instantly produce the
long queues, no longer does so.
This continues to validate my belief that something very inefficient is
going on somewhere. Queue handling; thread handling; both?
Issue History
Date Modified Username Field Change
======================================================================
2011-02-20 23:50 jcovert Note Added: 0132215
======================================================================
More information about the asterisk-bugs
mailing list