[asterisk-bugs] [Asterisk 0012825]: [patch] Always make chan_local report In Use when ringing another channel

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12825 
====================================================================== 
Reported By:                blitzrage
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12825
Category:                   Channels/chan_local
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-09-2008 12:19 CDT
Last Modified:              06-10-2008 05:52 CDT
====================================================================== 
Summary:                    [patch] Always make chan_local report In Use when
ringing another channel
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.
====================================================================== 

---------------------------------------------------------------------- 
 davidw - 06-10-08 05:52  
---------------------------------------------------------------------- 
Our local channel is on the other side of the queue.  The
http://bugs.digium.com/view.php?id=12771 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? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-10-08 05:52  davidw         Note Added: 0088511                          
======================================================================