[asterisk-bugs] [Asterisk 0014399]: wrong call-limit count when counteronpeer=yes
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Feb 4 05:17:53 CST 2009
The following issue has been SUBMITTED.
======================================================================
http://bugs.digium.com/view.php?id=14399
======================================================================
Reported By: caspy
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14399
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.6.0.3-rc1
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-02-04 05:17 CST
Last Modified: 2009-02-04 05:17 CST
======================================================================
Summary: wrong call-limit count when counteronpeer=yes
Description:
If i set counteronpeer=yes in sip.conf, then inuse and inringing counters
will be dropped to zero on nearest call to device.
This is result of combined 'if':
if ((*inuse > 0) && ast_test_flag(&fup->flags[0], SIP_INC_COUNT)) {
(*inuse)--;
ast_clear_flag(&fup->flags[0], SIP_INC_COUNT);
} else {
*inuse = 0;
}
if inuse>0, but no flag SIP_INC_COUNT, - inuse will be cleared, but
should be left untouched. (and the same for inringing)
in attached patch there is a dirty hack - i simply comment out setting
zero.
in my case it works ok, but i'm not sure that it is don't break anything
else.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-02-04 05:17 caspy New Issue
2009-02-04 05:17 caspy Asterisk Version => 1.6.0.3-rc1
2009-02-04 05:17 caspy Regression => No
2009-02-04 05:17 caspy SVN Branch (only for SVN checkouts, not tarball
releases) => N/A
======================================================================
More information about the asterisk-bugs
mailing list