Summary:	ASTERISK-17275: Problems with queue when there is no answer app before queue app
Reporter:	Sebastian Gutierrez (sum)	Labels:
Date Opened:	2011-01-24 05:57:13.000-0600	Date Closed:	2011-06-07 14:05:03
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Version: 1.6.2.14 DAHDI: 2.4.0 OS: CentOS 5.5 Queues and Agents: Realtime Queue strategy: rrmemory If I make a queue that is not answered before queue app I get this warning while the callers are waiting. [Jan 24 08:47:23] WARNING[23230]: channel.c:2556 ast_waitfordigit_full: Unexpected control subclass '2' this also has a side effect that I could not detect the reason, callerid is FSK, sometimes when I use this way without answer before the queue some callerids are mistaken and an old one (let say 2 calls before for example) is shown as the callerid for the call but asking the caller is not the one is calling from. I attached a callerid captor connected parallel and the callerid that sends the PSTN is fine and doesn't match the one is on asterisk, always is a real callerid from a previous call, if I answer the call first I have no errors. any ideas?
Comments:	By: David Woolley (davidw) 2011-01-24 07:15:02.000-0600 You haven't told the full story.  You need to provide the dial plan, queue and device configurations.  Incidentally, note that "any ideas" suggests a support question, which isn't appropriate here. Control sub-class 2 means it saw ringing current.  The real problem though is what is it doing in waitfordigit_full?  I suspect this means you have some non-standard option on your queues, and the real problem is that it is waiting for DTMF on a call that hasn't been answered.  Note, however, that producing the warning is not a bug in itself, and is almost certainly the side effect, not the cause. By: Leif Madsen (lmadsen) 2011-01-24 09:10:24.000-0600 I agree with what davidw has asked for. This is likely more appropriate for the asterisk-users mailing list. However I will leave this open for a couple of days so you can provide the information requested. By: Sebastian Gutierrez (sum) 2011-01-24 13:23:17.000-0600 1) exten=> _s,1,Queue(COLA,tTr,,,300,,CTI,,) CTI is just a macro that executes a UserEvent to provide some info to the agent. If Answer is before Queue The warning is not there anymore and I have never the callerid problem. 2) Configuration queue table (I provide de INSERT that I think is the best way to show the data): INSERT INTO `queues` VALUES ('COLA','default',NULL,'incoming',15,'MixMonitor','gsm',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'0',0,0,'no',1,1,50,15,'rrmemory','yes','no',0,1,0,0,100,1,0,1); 3) Device Configuration is on queue_members table with the format: SIP/1001 for example. By: Leif Madsen (lmadsen) 2011-01-24 15:01:03.000-0600 Try using Progress() before Queue() instead of Answer(). By: Sebastian Gutierrez (sum) 2011-01-24 15:12:55.000-0600 I will try that as soon as I can, btw the lineas are analog FXO By: Sebastian Gutierrez (sum) 2011-02-01 06:31:09.000-0600 usin Progress has the same effect By: Sebastian Gutierrez (sum) 2011-02-08 11:56:33.000-0600 any update on this? I have a production server with this issue, the problem is always when you have many people waiting in the queue, we have many of these warnings. WARNING[10847]: channel.c:2556 ast_waitfordigit_full: Unexpected control subclass '2' By: David Woolley (davidw) 2011-02-08 12:14:07.000-0600 You are still not clear what the problem is.  Having looked at the code, the warning message is totally harmless, and simply reflects that you are using hardware that detect the incoming ring cadence, and you are in a queue but haven't answered the call.  It's just a side effect of how the queue application implements its polling timer. I'd actually look towards dahdi or the device driver. In general, though progress will be logged against the issue, when it happens; however there is no commitment to deal with any issue in any particular time frame.  This is the not the right place to get quick answers. As this is likely related to the hardware, if you are using Digium hardware, you can probably get (free, I believe) commercial support from support@digium.com. You don't actually identify the hardware, but I assume it is some sort of FXO analogue interface. By: Sebastian Gutierrez (sum) 2011-02-08 12:29:20.000-0600 The problem is hard to detect, the callerid issue I'm having is when I don't have answer app before the queue I have that issue, even if I put progress, but If I answer then the callerid problem disapears, I know the warning is harmless, but is the only thing that indicates something that is not normal. I know this is not the right place for quick answers, but is the right place for bugs, and this is one of them, I just want to help to fix it, so I'm trying to follow this issue, I can test patchs, and help coding if someone point me on the right direction because I can't see where the problem could be. Hardware:  Digium, Inc. Wildcard TDM800P 8-port analog card dahdi driver is 2.4.0 By: Leif Madsen (lmadsen) 2011-03-08 14:41:45.000-0600 This sounds like something you may be able to bring up with Digium support as you are using Digium hardware. This could simply be an issue with using analog lines in that the callerID is sent in the earliest part of the call? By: Sebastian Gutierrez (sum) 2011-03-09 06:08:24.000-0600 the callerid is sent after the first ring is FSK, and is not all the time that I have the problem. Other test was to put in parrallel a callerid detector to check if the telco is sending the callerid right, and it does, the callerid is ok on the detector and is wrong in asterisk, this always happens when I don't answer the call, if I answer the call I never have that problem. By: Sebastian Gutierrez (sum) 2011-03-31 09:45:29 I now have a way to reproduce this: 1. incoming call from A (the call is not answered but is ringing) 2. A hangs up and there is a call from B before the busydetect 3. call B is now on the previous call, it doesn't start again as an incoming call is like a hijack of the line, so the callerid is never updated. any idea where can i start looking? By: Sebastian Gutierrez (sum) 2011-04-05 11:32:26 I'm following this issue on digium support, the card never signals the second call, [00223214] AEX800 - Calls Hijack other unanswered Calls    [ref:00D36mPe.5008F9Wh1:ref ] By: Leif Madsen (lmadsen) 2011-04-19 10:03:46 OK thanks for reporting to Digium support. I'm going to close this issue as all the appropriate actions will happen in the Digium ticket. Thanks! By: Sebastian Gutierrez (sum) 2012-07-11 19:46:51.130-0500 Digium issue has been close for a while, they say was an architectural problem of asterisk, what do you think?