[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 12:19 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..
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 10-05-07 12:19  
---------------------------------------------------------------------- 
I just took a look at the patch, and it made me feel a lot better about
this option. I had misunderstood the concept at first, but after looking
through the patch, it really does seem to make the queue application
"smarter" in detecting possible problems.

That being said, I can think of several things that could make this patch
better. 

First and foremost, there is some unnecessary code duplication. For
instance, a call to remove_from_queue could be used instead of manually
doing the same thing in the check_queue_members function. Also, the calls
to check_queue_members could be moved to add_to_queue, so that that check
is done all in one place as well.

Second, at the beginning of check_queue_members, instead of checking for
the possibility of the strings being NULL, it's better to use the
ast_strlen_zero function, which checks both for a NULL string, or a
zero-length string. Also, it's not necessary to check if interface is NULL,
since that is checked previously in all cases.

Third, because you don't have to worry about interface being NULL, you can
save some computation by using ao2_find to find a specific member. Since
astobj2 uses a hash table for storing members, it is quicker to do a find
than to iterate through the whole table. If you search for ao2_find in
app_queue, you can see how to use it.

There are a couple of nitpicks, too, but I feel I should point them out
anyway. First, it's not necessary to put semicolons after curly braces.
Second, regarding your additions to the queues.conf.sample file, I would
recommend replacing all instances of the word "agent" with "member" to
prevent confusion, since conceivably, this does not have to be used with
only agent channels.

Thanks for the patch, and I look forward to seeing an update. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-05-07 12:19  putnopvut      Note Added: 0071546                          
======================================================================