[Home]

Summary:ASTERISK-14307: busylevel does not work with realtime
Reporter:Tim King (timking)Labels:
Date Opened:2009-06-12 11:34:01Date Closed:2011-06-07 14:08:23
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The code that checks for busy_level is within a lookup for its name that excludes realtime support "because it would break rtautoclear".
Certain aspects of call limit also affected, but call limit (mostly?) works because it's done in update_call_counter.

Suspect busy_level should be checked in update_call_counter as well.

****** ADDITIONAL INFORMATION ******

in sip_devicestate

if ((p = find_peer(host, NULL, FALSE, FINDALLDEVICES, TRUE))) {
                              ^^^^^
...
else if (p->call_limit && p->busy_level && p->inUse >= p->busy_level)
/* We're forcing busy before we've reached the call limit */
res = AST_DEVICE_BUSY;
Comments:By: Tilghman Lesher (tilghman) 2009-08-24 21:45:19

I have no idea what you want here.  Could you upload a candidate patch, please?
By: Tim King (timking) 2009-08-25 03:24:19

I can't fix this myself as I don't understand the issue that is documented in sip_devicestate, which is:
/* If find_peer asks for a realtime peer, then this breaks rtautoclear.  This
* is because when a peer tries to autoexpire, the last thing it does is to
* queue up an event telling the system that the devicestate has changed
* (presumably to unavailable).  If we ask for a realtime peer here, this would
* load it BACK into memory, thus defeating the point of trying to clear dead
* hosts out of memory.
This documents the reason why busylevel does not work with realtime peers given the current implementation. The third argument to find_peer is false which means it doesn't look for realtime peers. But it would be nice if busylevel *did* work with realtime peers [or at the very least it was documented elsewhere the restriction].
By: Leif Madsen (lmadsen) 2009-09-22 08:37:29

Honestly, this issue is in such a position that it needs to be discussed on the asterisk-dev list first before moving forward here. I'm going to suspend this issue for now, and the reporter is welcomed to reopen the issue after discussing on asterisk-dev. Thanks!