[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-30-2007 10:24 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..
====================================================================== 

---------------------------------------------------------------------- 
 snar - 09-30-07 10:24  
---------------------------------------------------------------------- 
No, AMI is not necessarily used with AddQueueMember. In my context 
AddQueueMember is just a dialplan application which should be used 
to add dynamic member to queue from dialplan in abscence of
AgentCallbackLogin
in 1.6. (example: doc/queues-with-callback-members.txt in 1.4 sources).

Well, there is also AMI action 'QueueAdd', which is mostly identical 
to AddQueueMember, and which is also handled by proposed patch. 

And, of course, there is also a variant of writing separate daemon, 
which will handle QueueMemberAdded/QueueMemberRemoved
events and preventing any kind of parallel logins using AMI, but:
- writing/debugging such a daemon is a non-trivial task, much harder than

provide 100-line patch to asterisk. Remember, that daemon must be
non-blocking
and run at least on Linux/FreeBSD/Solaris. 
- system administrators all over the world will have to install
additional software to get those little features to work (and, for
starters, they should know that they need to install that daemon).
- this daemon (at least for the first time) will be application-oriented.
I know functions and requirements of my call-center, you know functions
and requirements of yours - but, at least I'm not sure that I will ever
know functions and requirements of "call-center in general". 
- and, for the final - there are possibilities of 'daemon conflicts', 
when, assume, your daemon issues QueueAdd, my daemon thinks that in 
result (QueueMemberAdded) we got policy violation, issues QueueRemove, 
your daemon see QueueMemberRemoved, but, as he wants agent to be logged,
issues QueueAdd and so on and on... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-30-07 10:24  snar           Note Added: 0071214                          
======================================================================