[asterisk-bugs] [JIRA] (ASTERISK-23662) Extended Wrap terminated by AMI

Rusty Newton (JIRA) noreply at issues.asterisk.org
Mon May 19 13:10:46 CDT 2014


     [ https://issues.asterisk.org/jira/browse/ASTERISK-23662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton closed ASTERISK-23662.
-----------------------------------

    Resolution: Suspended

Please contact a bug marshal in #asterisk-bugs or #asterisk-dev on irc.freenode.net when you are ready to attach your patches to the issues and we can re-open them. Thanks!

> Extended Wrap terminated by AMI 
> --------------------------------
>
>                 Key: ASTERISK-23662
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23662
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: Feature Tracker
>            Reporter: Brett Sutton
>            Assignee: Rusty Newton
>
> When an agent completes a call they often have additional 'paper work' to complete before they are ready to take the next call.
> The current 'wrap' function only provides a fixed wrap interval which is often not appropriate given the variablity of the work required by some calls.
> The patch enables a queue to be put into 'manager wrap' mode. In manager wrap mode at the end of a call the agent is immediately placed into an 'indefinite wrap' period. When the agent completes their task they can 'via some externally defined UI' end their wrap by sending a 'end manager wrap' AMI call to the queue. 
> This patch can be somewhat dangerous in a production environment as agents can get stuck in wrap if the 'externally defined UI' crashes. This issue is some what mitigated by the fact that if the 'use manager wrap' flag is disabled on a queue all agents in wrap will be immediately released from wrap.
> The elegance of this method is that it is much cheaper to implement than methods which pause/unpausing the agent in all queues and much more reliable than the pause/unpause method as that method can allow calls to 'slip through' if the pause is not enacted before the standard fixed wrap completes.
> We also found that in an environment with 40 queues and 30 agents (each agent in every queue) the lock contention of pausing/unpausing agents in every queue was bringing asterisk to its knees.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list