[asterisk-bugs] [Asterisk 0018028]: [patch] Exceptionally long queue length queuing to XXXXX
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu May 26 16:51:32 CDT 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18028
======================================================================
Reported By: alecdavis
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18028
Category: Core/PBX
Reproducibility: always
Severity: minor
Priority: normal
Status: confirmed
Asterisk Version: SVN
JIRA: SWP-2292
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!): 288195
Request Review:
======================================================================
Date Submitted: 2010-09-22 06:18 CDT
Last Modified: 2011-05-26 16:51 CDT
======================================================================
Summary: [patch] Exceptionally long queue length queuing to
XXXXX
Description:
Although this is under test conditions, this can go on for ever - seems
like 100's per second.
But the state of code at the moment, allows you to hangup, and it clears.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0017521 [patch] Brief lagginess on IAX2 channel...
related to 0014249 One way voice after attended transfer
related to 0018008 deadlock in local_bridgedchannel during...
related to 0018637 [patch] No MOH on Call Park and Excepti...
======================================================================
----------------------------------------------------------------------
(0135459) jhmichelle (reporter) - 2011-05-26 16:51
https://issues.asterisk.org/view.php?id=18028#c135459
----------------------------------------------------------------------
when this problem occurs in iax it happens when calls are transatlantic so
network delay is what causes the frames to be queued for more than 96
which
causes the frame head to be removed which leads to voice degradation. when
that happen while channel.c is still printing the error. the callee tries
to hangup
And acquire a lock. this is where the deadlock happens between
ast_queue_frame
and ast_write. network delay is a major factor and i don't know how
reproduce that.
Issue History
Date Modified Username Field Change
======================================================================
2011-05-26 16:51 jhmichelle Note Added: 0135459
======================================================================
More information about the asterisk-bugs
mailing list