[asterisk-dev] [Code Review] 3595: app_queue: delayed state event can trigger leavewhenempty ringing too early

Matt Jordan reviewboard at asterisk.org
Fri Jun 6 12:00:56 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3595/#review12083
-----------------------------------------------------------



/branches/1.8/apps/app_queue.c
<https://reviewboard.asterisk.org/r/3595/#comment22097>

    I don't think we can go with this as a solution.
    
    Relying on time based solutions in Asterisk is prone to failure. On one particular system, offsetting the time by 3 seconds may be sufficient. It may be overkill. Is may not be sufficient. (Making this configurable only perpetuates the problem)
    
    The problem here is the race condition between the device state propagation and this system relying on its delivery. I don't feel like I understand the problem well enough to advocate for a solution, but there are a couple of points to consider:
    
    (1) Should CEL event delivery impact device state (and other state) delivery?
    
    (2) When a Queue member's status is checked, is there a mechanism to query the device state core for what the true, actual, non-subscription based status is?
    
    (3) Can we synchronize between a device state update and this request?


- Matt Jordan


On June 6, 2014, 11:36 a.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3595/
> -----------------------------------------------------------
> 
> (Updated June 6, 2014, 11:36 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: AST-1248
>     https://issues.asterisk.org/jira/browse/AST-1248
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> In a world where a single agent is available and doesn't answer the first call, it is possible for the caller to then be kicked out of the queue incorrectly.  Due to an uncommon mix of other event messages in transit (such as CEL), the state change for the agent's extension from ringing back to available can arrive after app_queue has already decided to kick the user.  This change saves the day by adding a slight delay before kicking the caller out of the queue, but only under the situation where that single available agent is the one that was just called and did not answer.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_queue.c 415336 
> 
> Diff: https://reviewboard.asterisk.org/r/3595/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140606/31846d28/attachment.html>


More information about the asterisk-dev mailing list