| Summary: | ASTERISK-12295: Agent Status and outgoing calls | ||
| Reporter: | Eduardo Gomes Santos (edugs15) | Labels: | |
| Date Opened: | 2008-07-01 09:46:21 | Date Closed: | 2009-03-30 10:27:03 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 20090125__bug12970.diff.txt ( 1) Core_locks.txt | |
| Description: | Hello, I'm using Asterisk 1.4.21 e bellow I describe my problem : I've got a Call Center, with 30 agents running X-lite (I use AgentCallbackLogin). These agentes make outgoing calls and receive incoming calls as well (incoming calls from queues). When they are making calls, queues don't recognize agent status (still remains Not in use), and then Asterisk tries to send calls from queues to these agents. I've configured ringinuse = no, call-limit in sip.conf (=1, type = friend), and this is enough to avoid that these agents receive a call ringing in the softphone's second line. This is ok. But call-limit is not enough to stop Asterisk from trying to send calls to an agent, when this agent is making an outgoing call, or talking to another agent, and so on. So Asterisk tries to send a call, then notes call-limit, and only then tries another agent, after timeout. I have tried hints and subscriptions, but queues don't recognize hints. Asterisk doesn't try to send a call to an agent, only it this agent is paused, or already talking to a caller from queues. Asterisk tries to send calls to agents even if they are : - Making outgoing calls - Talking to another agent - Using Chanspy to monitor another agent - Talking to a caller from a DID call (Direct Inward Dialing) Is there a way by which I can get app_queue to set busy in these conditions, so that I can stop Asterisk from trying to send a call to agents ? Thanks. | ||
| Comments: | By: Mark Michelson (mmichelson) 2008-07-01 09:48:19 There are two potential ways to fix this. 1. Set limitonpeers=yes in sip.conf. This is *supposed* to work for the situation you have described, but I find that it sometimes does not. 2. Instead of using type=friend, use type=peer in sip.conf. This has worked so that calls originating from the queue member will cause the member to appear "in use" to app_queue. See if either of those suggestions fixes the problem. By: David Woolley (davidw) 2008-07-01 09:57:20 This is being addressed for AgentLogin in ASTERISK-12127. However, a problem that arises with AgentCallbackLogin is that the system doesn't have a technology/address combination for the agent, but actually has an extension number and context. As well as the question of multiple calls on a single (SIP) channel, extensions can offer calls to multiple technology/address combinations. Even if one read the hints, you can only hint an extension for one device. Also, AgentCallbackLogin is deprecated, and one is actually expected to add a local channel as the queue member, and have that local channel actually try to call the agent. That makes the problem one of passing the device state back across the local channel, rather than across an Agent. It has the added complication that a local channel can have arbitrary logic for deciding who to actually call. By: Eduardo Gomes Santos (edugs15) 2008-07-01 09:59:22 Hello, limitonpeers=yes is already configured in sip.conf. So I will try type=peer and report results. Thanks. By: Mark Michelson (mmichelson) 2008-07-01 10:02:31 Ah, I glanced over the fact that you are using AgentCallbackLogin before. As davidw pointed out, this is being looked at in issue ASTERISK-12127. Changing to type=peer in sip.conf will not help. By: David Woolley (davidw) 2008-07-01 10:04:37 Getting accurate presence for the SIP device doesn't help, because the presence information doesn't propagate back across the Agent, or, if using the current approved method, the Local channel. The patch associated with ASTERISK-12127 only helps when the Agent is actually connected to a channel on the device. Whilst that is always true for an agent logged in with AgentLogin, it is only true for AgentCallbackLogin, when there is an outgoing call, which is the least interesting case. By: Eduardo Gomes Santos (edugs15) 2008-07-01 10:05:36 So, there is nothing to do by now ? Thanks By: Eduardo Gomes Santos (edugs15) 2008-07-01 13:42:52 Really, type=peer can't fix this issue. By: David Woolley (davidw) 2008-07-02 06:00:00 Accurate presence information will prevent Asterisk from trying to start a SIP connection to the Agent, but it will still pick the call from the queue, assign it to the agent, and then try to start the call, i.e. it will start by assuming the agent is free, even though it will then discover they are busy. I've not used AgentCallbackLogin, so I don't know what the end result of this is. It may or may not be close enough to what would happen if the queue had known the agent was busy. By: Tilghman Lesher (tilghman) 2008-07-14 16:28:08 edugs15: in fact, ASTERISK-12127 will probably fix your problem exactly as you have described it. Please update to current SVN, as ASTERISK-12127 has been committed. By: Eduardo Gomes Santos (edugs15) 2008-07-14 17:11:11 ok, I'll follow your instructions, and report results. Thanks. By: Eduardo Gomes Santos (edugs15) 2008-07-16 09:40:46 Patch from 0012773 didn't fix this issue. Queues only knows that an agent is busy, if this agent is ringing in a incoming call from queues, or talking to a caller from queues. By: David Woolley (davidw) 2008-07-16 11:01:30 I don't think ASTERISK-12127 really deals with call back logins, which, I think, are being used here. By: Eduardo Gomes Santos (edugs15) 2008-07-16 11:13:45 Yes, I am using AgentCallbackLogin Thanks. By: Eduardo Gomes Santos (edugs15) 2008-07-17 13:59:35 The problem is that in many Call Centers we just can't use Agentlogin, due to the way agents work. Is it possible to fix it for AgentCallBacklogin as well ? By: David Woolley (davidw) 2008-07-17 16:50:38 firstly note that AgentCallBackLogin is deprecated. I believe the official line is that you should script the login and use a Local channel instead of the Agent channel (I suspect this policy is going to fail, though). As I commented earlier, the problem with call back logins is that there isn't a well defined device (technology/address) associated with an Agent that is not in a call. I believe the ASTERISK-12127 change actually tracks changes whilst in a call, but that is not normally the interesting case. Given that one needs hints to track extension states, one would need to create hints for each agent. That mechanism could only be made to work in the special, if common, case, where there was one and only one device address associated with an extension; that isn't a constraint that currently applies to agents. I haven't tried to work out what code changes would be necessary, even under those constraints, but I think the change will be comparable to, or larger than the change for AgentLogin. By: Eduardo Gomes Santos (edugs15) 2008-07-18 09:21:28 ok, Thanks. I understand it. But it's really bad, making it very hard to apply Asterisk for Call Centers where agents both receive and make calls. Maybe patch from 0012773 could at least fix, for AgentCallbacklogin, the bug I have related in issue 0012992, already closed by administrator ? " Queues do not report agent status correctly. For example : - Agent receives a call from queue, and queue do not report busy (only report busy if I make reload app_queue.so during the call). - When in busy, if agent hangs up, queue do not recognize it as not in use (only recognize if I make reload app_queue.so after hangup). If I don't make reload app_queue.so, it takes a long time for the members move back into the "not in use", from the "busy" state, or into the "busy", from the "not in use" state. " By: Tilghman Lesher (tilghman) 2008-07-31 12:51:59 I'd still recommend that you try 1.4 SVN, as there have been multiple changes to device states, any one of which might fix this issue for you. By: Thiago Garcia (thiagarcia) 2008-07-31 13:06:07 This issue occurs for me in Asterisk version 1.4.21.2 My softphone is Ekiga 2.0.12 from fedora 9 package By: Eduardo Gomes Santos (edugs15) 2008-07-31 13:23:41 Hello Corydon76, thanks for replying. If I'm not wrong, changes from issue 0012771 might fix this issue. Is it correct ? By: Tilghman Lesher (tilghman) 2008-07-31 13:59:45 edugs15: I suppose it's possible, although I don't quite know why it would. By: Tilghman Lesher (tilghman) 2008-09-11 17:50:48 edugs15: have you tried the 1.4.22 release candidate yet? By: Eduardo Gomes Santos (edugs15) 2008-09-14 07:15:54 Hello Corydon76, I haven't tried yet, but I will tomorrow. Thanks. By: Doug (doug) 2008-09-15 03:25:42 We having this problem on 1.4.21.2 and have tried to use both Dynamic SIP agents and Direct SIP both with the same result. See http://bugs.digium.com/view.php?id=13481. I have attached lock info from 1.4.22 as well (Core lock.txt) By: Doug (doug) 2008-09-15 05:38:32 I have re-tried using 1.4.22, problem still exists. These problems are always related to the error: [Sep 15 12:36:52] WARNING[31787]: app_queue.c:3183 try_calling: The device state of this queue member, SIP/1831, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings. By: David Woolley (davidw) 2008-09-15 06:33:56 My impression on ASTERISK-1269771 is that it side tracked somewhat into a problem that increases the window for the race condition (a DNS lookup delay), but never actually removed the race condition. Unfortunately, we are close to a release here, and the policy is to use 1.4.21.2, because it is released, rather than 1.4.22-rc???, which has ASTERISK-1269771 in it. By: Tilghman Lesher (tilghman) 2008-12-18 11:41:42.000-0600 Given that we're now way past the 1.4.22 release and we're about to release 1.4.23, is it safe to assume that this has been fixed now? By: Mark Michelson (mmichelson) 2008-12-18 12:48:58.000-0600 Corydon76. No, this is not fixed, and unfortunately, aside from backporting the state_interface changes from 1.6 for queues, I know of no way to actually fix this. By: Ronald Chan (loloski) 2008-12-26 20:26:53.000-0600 I can confirm this issue using local channel on recent SVN 1.4 branch. we are using AddQueueMember apps. via AddQueueMember(1,Local/${agent}@agents/n,,,,${agentname}) On the interim we are back at SIP/xxx technology member for queue. we can't jump on 1.6 for now thanks. If state_interface backport from 1.6 was really the solutions. i vouch for it :) just my 0.02 $ By: Amilcar S Silvestre (amilcar) 2008-12-28 20:06:20.000-0600 Since we have many bug reports on this, like ASTERISK-12295, ASTERISK-12285, ASTERISK-11890 and maybe others, i think backporting state_interface changes from 1.6 is very reasonable. I think it will be a bug fix and not a new feature backport. By: Tilghman Lesher (tilghman) 2009-01-25 16:55:46.000-0600 amilcar: actually, agentcallbacklogin has been deprecated for the entire 1.4 series and is, in fact, completely removed from 1.6 and later versions. So it's kind of hard to justify backporting anything. By: Tilghman Lesher (tilghman) 2009-01-25 17:06:18.000-0600 We could, however, reserve the channel name when a login is performed, and store it for later comparison by the devicestate infrastructure. Patch uploaded. By: Leif Madsen (lmadsen) 2009-02-27 16:33:32.000-0600 Changing status to Confirmed as there is a patch here ready to be tested. Thanks! By: Amilcar S Silvestre (amilcar) 2009-03-14 16:53:03 tilghman, if I understand right, your patch tries to use the underlying channel device state to propagate this status to the Agent channel? If that's the case, it doesn't work! :-) If I make a call using a sip channel with agent channel logged in, the Agent channel persists in "Not In Use" state. By: Thiago (thiagofernandes) 2009-03-17 07:23:28 I tested this patch using a sip channel and not worked too By: Leif Madsen (lmadsen) 2009-03-18 08:33:32 Changing issue back to 'Confirmed' as a reporter states that the patch does not resolve his issue. By: Leif Madsen (lmadsen) 2009-03-18 08:34:17 I'm going to assign this issue to Mark Michelson for now, however he may deem this was not the right move :) By: Digium Subversion (svnbot) 2009-03-30 10:24:00 Repository: asterisk Revision: 184980 U branches/1.4/apps/app_queue.c U branches/1.4/configs/queues.conf.sample ------------------------------------------------------------------------ r184980 | mmichelson | 2009-03-30 10:23:59 -0500 (Mon, 30 Mar 2009) | 22 lines Backport state interface changes to app_queue from trunk. After several issues raised on the Asterisk bugtracker against the 1.4 branch were determined to be fixable with the state interface change available in the 1.6.X series, it finally came time to just suck it up and backport the change. For a detailed explanation of what this change entails, the original trunk commit for this feature may be found here: http://svn.digium.com/view/asterisk?view=revision&revision=97203 In addition, the details for the use of this change to fix the problems stated in issue ASTERISK-12295 may be found in the review request I made for this change. It is linked below. (closes issue ASTERISK-12295) Reported by: edugs15 Review: http://reviewboard.digium.com/r/116 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=184980 By: Digium Subversion (svnbot) 2009-03-30 10:25:05 Repository: asterisk Revision: 184986 _U trunk/ ------------------------------------------------------------------------ r184986 | mmichelson | 2009-03-30 10:25:04 -0500 (Mon, 30 Mar 2009) | 27 lines Blocked revisions 184980 via svnmerge ........ r184980 | mmichelson | 2009-03-30 10:23:59 -0500 (Mon, 30 Mar 2009) | 22 lines Backport state interface changes to app_queue from trunk. After several issues raised on the Asterisk bugtracker against the 1.4 branch were determined to be fixable with the state interface change available in the 1.6.X series, it finally came time to just suck it up and backport the change. For a detailed explanation of what this change entails, the original trunk commit for this feature may be found here: http://svn.digium.com/view/asterisk?view=revision&revision=97203 In addition, the details for the use of this change to fix the problems stated in issue ASTERISK-12295 may be found in the review request I made for this change. It is linked below. (closes issue ASTERISK-12295) Reported by: edugs15 Review: http://reviewboard.digium.com/r/116 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=184986 By: Digium Subversion (svnbot) 2009-03-30 10:25:45 Repository: asterisk Revision: 184989 _U branches/1.6.0/ ------------------------------------------------------------------------ r184989 | mmichelson | 2009-03-30 10:25:45 -0500 (Mon, 30 Mar 2009) | 33 lines Blocked revisions 184986 via svnmerge ................ r184986 | mmichelson | 2009-03-30 10:25:04 -0500 (Mon, 30 Mar 2009) | 27 lines Blocked revisions 184980 via svnmerge ........ r184980 | mmichelson | 2009-03-30 10:23:59 -0500 (Mon, 30 Mar 2009) | 22 lines Backport state interface changes to app_queue from trunk. After several issues raised on the Asterisk bugtracker against the 1.4 branch were determined to be fixable with the state interface change available in the 1.6.X series, it finally came time to just suck it up and backport the change. For a detailed explanation of what this change entails, the original trunk commit for this feature may be found here: http://svn.digium.com/view/asterisk?view=revision&revision=97203 In addition, the details for the use of this change to fix the problems stated in issue ASTERISK-12295 may be found in the review request I made for this change. It is linked below. (closes issue ASTERISK-12295) Reported by: edugs15 Review: http://reviewboard.digium.com/r/116 ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=184989 By: Digium Subversion (svnbot) 2009-03-30 10:26:14 Repository: asterisk Revision: 184992 _U branches/1.6.1/ ------------------------------------------------------------------------ r184992 | mmichelson | 2009-03-30 10:26:14 -0500 (Mon, 30 Mar 2009) | 33 lines Blocked revisions 184986 via svnmerge ................ r184986 | mmichelson | 2009-03-30 10:25:04 -0500 (Mon, 30 Mar 2009) | 27 lines Blocked revisions 184980 via svnmerge ........ r184980 | mmichelson | 2009-03-30 10:23:59 -0500 (Mon, 30 Mar 2009) | 22 lines Backport state interface changes to app_queue from trunk. After several issues raised on the Asterisk bugtracker against the 1.4 branch were determined to be fixable with the state interface change available in the 1.6.X series, it finally came time to just suck it up and backport the change. For a detailed explanation of what this change entails, the original trunk commit for this feature may be found here: http://svn.digium.com/view/asterisk?view=revision&revision=97203 In addition, the details for the use of this change to fix the problems stated in issue ASTERISK-12295 may be found in the review request I made for this change. It is linked below. (closes issue ASTERISK-12295) Reported by: edugs15 Review: http://reviewboard.digium.com/r/116 ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=184992 By: Digium Subversion (svnbot) 2009-03-30 10:27:00 Repository: asterisk Revision: 184996 _U branches/1.6.2/ ------------------------------------------------------------------------ r184996 | mmichelson | 2009-03-30 10:26:59 -0500 (Mon, 30 Mar 2009) | 33 lines Blocked revisions 184986 via svnmerge ................ r184986 | mmichelson | 2009-03-30 10:25:04 -0500 (Mon, 30 Mar 2009) | 27 lines Blocked revisions 184980 via svnmerge ........ r184980 | mmichelson | 2009-03-30 10:23:59 -0500 (Mon, 30 Mar 2009) | 22 lines Backport state interface changes to app_queue from trunk. After several issues raised on the Asterisk bugtracker against the 1.4 branch were determined to be fixable with the state interface change available in the 1.6.X series, it finally came time to just suck it up and backport the change. For a detailed explanation of what this change entails, the original trunk commit for this feature may be found here: http://svn.digium.com/view/asterisk?view=revision&revision=97203 In addition, the details for the use of this change to fix the problems stated in issue ASTERISK-12295 may be found in the review request I made for this change. It is linked below. (closes issue ASTERISK-12295) Reported by: edugs15 Review: http://reviewboard.digium.com/r/116 ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=184996 | ||