[asterisk-bugs] [Asterisk 0010845]: [patch] preventing parallel logins from the same line or by the same agent

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10845 
====================================================================== 
Reported By:                snar
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10845
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 84109 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-28-2007 11:44 CDT
Last Modified:              09-28-2007 17:50 CDT
====================================================================== 
Summary:                    [patch] preventing parallel logins from the same
line or by the same agent
Description: 

This feature allows asterisk to deal with next scenarios: 

Assume, agent A logs in (with AddQueueMember) from line SIP/NNN to queue
queueA. 
Then his/her shift ends, and he/she leaves call-center without logging
off.
On the next day, agent B logs in from the same SIP/NNN line to queueB, 
but he start receiving calls to queueA too, because asterisk supposes
that's there is still agent A (subscribed to queueA) on this line. 

Another scenario: Assume, agent A logged in from SIP/NNA. 
Then, does not matter why, he decides to log on from SIP/NNB. 
Current queue logic does not notices that, so, calls from queue gets 
ringing both SIP/NNA and SIP/NNB, and when strategy is not ringall one
this can introduce unnecessary delays in call processing.
 
Well, both scenarios can be dealt with enforcing local policy, but 
in our non-ideal world with non-ideal agents I suppose that adding some 
smart behaviour to asterisk is just better idea..
====================================================================== 

---------------------------------------------------------------------- 
 kwakwaversal - 09-28-07 17:50  
---------------------------------------------------------------------- 
Maybe it's just me but if agents are logging in with AddQueueMember I
assume something is manipulating the AMI interface to add them to a queue? 
Some kind of script or daemon?  There are a number of ways to find out if
an interface is logged into a queue but wouldn't it be just as easy to run
`RemoveQueueMember` for each queue before you AddQueueMember to make sure
that it's logged out of every queue?

I'm probably being biased towards using AMI to handle dynamic member
subscriptions, this may be a very useful feature.  I just can't help but
think there are a million and one different scenario's that might crop up
with regards to dynamic members so there may need to be a different
approach? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-28-07 17:50  kwakwaversal   Note Added: 0071191                          
======================================================================