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

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10845 
====================================================================== 
Reported By:                snar
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   10845
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
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:              01-16-2008 16:13 CST
====================================================================== 
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..
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-16-08 16:13  file           Status                   new => assigned     
01-16-08 16:13  file           Assigned To               => putnopvut       
======================================================================