Summary:	ASTERISK-12164: [patch] Always make chan_local report In Use when ringing another channel
Reporter:	Leif Madsen (lmadsen)	Labels:
Date Opened:	2008-06-09 12:19:22	Date Closed:	2011-06-07 14:08:06
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) queue-unknowon-not-in-use1.diff
Description:	This patch makes it so the Unknown state acts just like In Use in chan_local so that when you use the Local channel to distribute calls to agents from the Queue() that you don't end up with multiple calls to the same agent before answer.
Comments:	By: David Woolley (davidw) 2008-06-09 12:48:19 Currently there is no patch file attached, so I'm not clear exactly what the scenario is here.  However I'm worried that queues use the busy status on the "device" not the channel instance, and anything that caused either chan_local as a whole, or Local/xxxxxx to appear busy because Local/xxxxxx-iiiiiii was ringing would be a big problem for us. ... Looks like I collided with the re-addition of the patch.  Unfortunately its the end of the working day for me, so I can't work out the exact implications just now. By: Mark Michelson (mmichelson) 2008-06-09 13:18:17 davidw: The patch is a result of discussing issue ASTERISK-12125 on IRC. I mentioned that the big problem that you and aragon experience is due to the base fact that Local channels do not report a ringing state (or any other similar change when they are ringing). The result for you is that the agent appears to still not be in use when the agent has been "in use" in some way since his phone began ringing. For aragon, it's even worse since his problem is that multiple calls make it to his agents all at once. blitzrage mentioned that he had used a patch to report the 'unknown' status for local channel's as a ringing state to app_queue. I still haven't looked over the patch or tested it yet. By: Mark Michelson (mmichelson) 2008-06-09 13:25:04 After giving the patch a look and a test, I'm not sure I see how this is supposed to work. The patch makes sense. Treat the "unknown" state similar to "in use." The problem is that Local channels do not appear to change to "unknown" when I ring them as the report would indicate. Even if this patch did work for me, I would be extremely hesitant to add it to 1.4 because of the change in behavior for the "unknown" state for devices. By: David Woolley (davidw) 2008-06-10 05:52:21 Our local channel is on the other side of the queue.  The ASTERISK-12125 problem seems to be because the status change of the Agent channel gets queued to another thread, and doesn't produce a synchronous change in the queue member status. The situation we have is that we have a Local channel between the incoming call and the queue.  We did this as a workround before I was fully involved in our Asterisk based project.  Nowadays I would probably have tried to undertand the mechanics of our problem, but then adding the local channel seemed to work, and we now have a lot of code that would need to be re-worked if the behaviour changed, because other decisions are dependent on that decision. For policy reasons, we use AgentLogin with auto-answering.  We were finding that AMI Redirect of the party on the queue caused the agent to get logged out.  Introducing the extra level of redirection with the Local channel seemed to decouple things enough that the Agent no longer got logged out. We currently use the "r" option on the queue, because we don't expect the queue to be very long normally and because it has the potential for avoiding a start of charging on an incoming PSTN call, although we do not take advantage of that at the moment.  Even if we didn't, I would be concerned that there might be a transient condition that triggered the proposed behaviour change. What can thus go wrong is that some callers arriving at the wrong time get rejected with busy, rather than being put in the queue, and even to achieve this, we would be forced to make the Queue application answer the call on queueing. I would argue that, in general, the proposal confuses extensions with terminals.  Even with many non-VoIP exchanges, it is quite possible to make multiple calls to the same number and have them all answered.  Only in the simple case you get with a single line PSTN connection would you normally expect a collision with a ringing call to give busy. Incidentally, I seem to be missing a step in the logic in that I don't know why one would want to interpose a Local channel between a queue and an Agent.  Wouldn't that prevent app_queue from recognizing the Agent and using its special knowledge of Agents? By: Leif Madsen (lmadsen) 2008-06-10 08:41:05 Davidw: In my case, there is no use of the Agent channel at all -- the Local channel that the Queue() is delivering to *is* the "Agent", and performs logic necessary to distribute the call to a person acting as an agent in the queue. The Local channel performs various checks, such as deciding which box in the cluster the send the call to. This sounds a bit different than what you're doing, but I wanted to clarify that I'm not sticking a Local channel between the Queue() and the Agent channel. By: Mark Michelson (mmichelson) 2008-06-10 10:53:36 I'm going to close this because adding this patch to 1.4 (or any similar patch which changes the way queues treat the "unknown" state) is going to ruffle a lot of feathers. For some reason, I was under the impression that davidw was using callback agents and not the "always on" style agents, even though he clearly specified that information in his bug report. What I thought would solve both his problem and aragon's in one fell swoop would be if local channels reported a ringing state. However, since davidw is not using callback agents, this means that there is not a local channel (indirectly) answering the queue calls so reporting such a state would have no effect on his issue. Anyway, blitzrage, thanks for working to get this patch submitted. Sorry it's not going to be merged.