Summary:	ASTERISK-09845: The device state of this queue member, SIP/XXXXX, is still 'Not in Use' when it probably should not be!
Reporter:	Nick Barnes (bcnit)	Labels:
Date Opened:	2007-07-10 02:05:30	Date Closed:	2007-07-10 08:53:22
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	This appears to be related to bug ASTERISK-8528580. sip, queues and queue members are being driven from realtime (MySQL). I get several warnings when queueing calls:    -- Executing [s@cust-in:44] Queue("SIP/103-095182f0", "0844304|n") in new stack [Jul 10 07:49:00] WARNING[6677]: translate.c:163 framein: no samples for gsmtolin    -- Started music on hold, class 'default', on SIP/103-095182f0    -- SIP/101-09522e00 is ringing    -- SIP/101-09522e00 is ringing    -- SIP/101-09522e00 is ringing [Jul 10 07:49:02] WARNING[4029]: chan_sip.c:3140 update_call_counter: Inringing for peer '101' < 0?    -- SIP/101-09522e00 answered SIP/103-095182f0    -- Stopped music on hold on SIP/103-095182f0 [Jul 10 07:49:02] WARNING[6677]: app_queue.c:2646 try_calling: The device state of this queue member, SIP/101, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings.  == Spawn extension (cust-in, s, 44) exited non-zero on 'SIP/103-095182f0' I have followed the instructions in UPGRADE.txt (see below). The result is that calls are offered to handsets which are already on a call and this has broken a 1.2 based application when ported to 1.4. ****** ADDITIONAL INFORMATION ****** sip.conf contains both:  limitonpeer=yes and  limitonpeers=yes (as I have seen references to both of these here and on the wiki) The relevant part of the table definition for sip in MySQL is as follows:  `call-limit` varchar(10) NOT NULL default '10',  `call_limit` varchar(10) NOT NULL default '10',  `calllimit` varchar(10) NOT NULL default '10', (again, as I have seen references to all of these)
Comments:	By: Nick Barnes (bcnit) 2007-07-10 04:48:47 If 'rtcachefriends=yes' in sip.conf, this warning goes away (along with the "WARNING[4029]: chan_sip.c:3140 update_call_counter: Inringing for peer '101' < 0?" one) and everything works as it should. Unfortunately, the use of 'rtcachefriends=yes' means that we have to reload sip every time the database changed which completely defeats the point of using realtime (for us, anyway). By: Joshua C. Colp (jcolp) 2007-07-10 07:33:03 This is a known issue of realtime, just like using qualify and mailbox without caching. Call limits were not designed to work under those circumstances and without major changes can't. By: Nick Barnes (bcnit) 2007-07-10 08:34:32 OK. I take your point. In that case, the bug is that the warning messages are, at best, misleading. In addition, given that this situation is likely to occur in a high call volume environment (where realtime is being used), the warning messages are likely to swamp any other output. May I request that some thought be given to not displaying the warning messages if the device in question is defined in the realtime configuration and rtcachefriends=no? By: Joshua C. Colp (jcolp) 2007-07-10 08:35:07 Which warning message? By: Nick Barnes (bcnit) 2007-07-10 08:44:50 I was thinking both:  update_call_counter: Inringing for peer.... and  The device state of this queue member..... since they are related. I have removed the appropriate "ast_log" lines from chan_sip.c and app_queue.c, so my problem has gone away, however this isn't ideal and, unfortunately, that's the extent of my programming ability :-( By: Joshua C. Colp (jcolp) 2007-07-10 08:46:05 I can tweak the chan_sip one but not the app_queue one, it has no idea that the device it called is from realtime. By: Digium Subversion (svnbot) 2007-07-10 08:50:29 Repository: asterisk Revision: 74262 ------------------------------------------------------------------------ r74262 | file | 2007-07-10 08:50:27 -0500 (Tue, 10 Jul 2007) | 2 lines Only spit out an inringing warning message when it is applicable. Since call limits are already toast in realtime let's not scare the user if they are using it. (issue ASTERISK-9845 reported by bcnit) ------------------------------------------------------------------------ By: Nick Barnes (bcnit) 2007-07-10 08:51:27 OK. Thank you. I suspected one may be easy (relatively) and the other not! Is it possible to be able to state something in the queue definition which keeps quiet about some errors? e.g. queues.conf (assuming for the moment that queues aren't realtime driven) [test1] strategy=ringall timeout=10 retry=5 . . logwarnings=off . . Or is that taking a sledgehammer to a walnut? By: Digium Subversion (svnbot) 2007-07-10 08:52:17 Repository: asterisk Revision: 74263 ------------------------------------------------------------------------ r74263 | file | 2007-07-10 08:52:16 -0500 (Tue, 10 Jul 2007) | 9 lines Blocked revisions 74262 via svnmerge ........ r74262 | file | 2007-07-10 11:07:13 -0300 (Tue, 10 Jul 2007) | 2 lines Only spit out an inringing warning message when it is applicable. Since call limits are already toast in realtime let's not scare the user if they are using it. (issue ASTERISK-9845 reported by bcnit) ........ ------------------------------------------------------------------------ By: Joshua C. Colp (jcolp) 2007-07-10 08:53:08 That's not something we do... and there, chan_sip portion done. That's the best I can do!