[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:              10-05-2007 14:09 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 - 10-05-07 14:09  
---------------------------------------------------------------------- 
Concerning your note on remove_from_queue: not duplicating code is really
good idea, but remove_from_queue locks queue from which interface is being
removed. And, as this queue is always locked in check_queue_members,
deadlock condition occurs :( Or have I misunderstood something ? 
What do you think I should do better: add additional parameter meaning
'do not lock queue while remove interface' to remove_queue_member, or
leave
that part intact ? 

Note on 'misplacement' of calls to check_queue_members: Intended
behaviour
of those options is that last logged in member is always 'winner'. If I
move
call to add_queue_member - that will add this call to 'reload persistent
members from database' cycle, and there is a possibility that last logged

in becomes loser and some phantom located in database after him wins.
(Well, that can happen only when one of options changed in runtime, but,
anyway, better safe than sorry..)

Note on !=NULL vs. ast_strlen_zero: fixed. 

Note on ao2_find: fixed. However, to prevent the same member to be logged
from 
different interfaces (when denyparallellogin set to on), I still need to 
iterate queue members. 

Note on queues.conf: agents renamed to members, option onlyagentperline 
renamed to onlymemberperline

Patch is to be uploaded...

PS: also, eliel note on interface case insensitiveness fixed, 
added logging to queue_log and placement of calls to dump_queue_members()
optimized.. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-05-07 14:09  snar           Note Added: 0071551                          
======================================================================