[asterisk-bugs] [Asterisk 0013668]: sip show inuse count is negative

Wed Oct 29 18:40:10 CDT 2008

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13668 
====================================================================== 
Reported By:                mjc
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   13668
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-10 15:02 CDT
Last Modified:              2008-10-29 18:40 CDT
====================================================================== 
Summary:                    sip show inuse count is negative
Description: 
I have a bunch of snom 360s and asterisk-1.6.0-rc6. The snom BLF LEDs
monitor hints. However, the hints are getting confused and inverting state
sometimes. That is, unused extensions are being shown as in-use, and
vice-versa.

If I run "sip show inuse" during these times, I see entries like this:

steerpike*CLI> sip show inuse
* User name               In use          Limit
mjc_server                0               10
mjc_library               0               10
mjc_lab                   0               10
mjc_office                0               10
mjc_home                  0               10
* Peer name               In use          Limit
mjc_server                0/0/0           10
mjc_library               0/0/0           10
mjc_lab                   -1/0/0          10
mjc_office                0/0/0           10
mjc_home                  0/0/0           10

Note the "-1"! This is nonsense, and results in an "in use" hint:

steerpike*CLI> core show hints
                    601 at internal            : SIP/mjc_office&SIP/m 
State:InUse           Watchers 11

where the defined hint is:

exten =>
601,hint,SIP/mjc_office&SIP/mjc_home&SIP/mjc_lab&SIP/mjc_server&SIP/mjc_library

Somehow, the call count is being decremented by 2 after a hangup (from 1
to -1). Call counts should be clamped at zero, I would suggest.

This problem did not occur on the same system when we had 1.2.x and 1.4.x
running.

- Mike
====================================================================== 

---------------------------------------------------------------------- 
 (0094382) wolfelectronic (reporter) - 2008-10-29 18:40
 http://bugs.digium.com/view.php?id=13668#c94382 
---------------------------------------------------------------------- 
I just provided a patch hintfix_trunk_rev152649.patch for the trunk
revision 152649 of chan_sip.c.
Notes for the reviewer who commits to svn:
1) please be aware that i was not able to test the patch for the trunk
revision on a live system. I just checked if it compiles. In my opinion the
changes between 1.6.0.1 and the trunk revision in the function
update_call_counter (removal of find_user) should not have any side effects
to the patch.
2) the main part of the patch expands the locks to be arround the
conditions including flag set/clear and counter increment/decrement and not
only arround the increment / decrement of the counters.
3) except one part (see 4) i kept the original logic and just modified the
locks
4) the part where i changed the original logic is between the /* continue
*/ and the if(sipdebug). As i found no reason why the flag SIP_INC_COUNT
was not checked here i added the check. (i discussed this with putnopvut in
IRC).
5) i opted to not just silently correct the counters if something wired
happens to the counters but to log a debug message. While this could be
(and was) useful for verifing the patch they could be removed when
committing to svn
6) i added some additional checks in the lines between /* remember murphy
*/  and /* end of removable code */. These lines also help in verifing the
patch. Before commiting to svn you could just remove these lines, put some
#ifdef PESSIMISITIC arround them ore check the debug level before executing
them. They should not be left unmodified because they use additional
locks.
7) somparing to the svn revision the number of locks increased just by one
(without the "murphy lines") so hopefully there should not arise a
perfomance issue from this patch. Only ast_xxx_flag functions are called
inside the locks so they should not take much time.
8) if you have any additional questions please drop a note to this bug or
try on IRC. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-29 18:40 wolfelectronic Note Added: 0094382                          
======================================================================