[asterisk-bugs] [JIRA] (ASTERISK-29909) Add support for withdrawing a call

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258021#comment-258021 ] 

Asterisk Team commented on ASTERISK-29909:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

> Add support for withdrawing a call
> ----------------------------------
>
>                 Key: ASTERISK-29909
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29909
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 16.23.0, 18.9.0, 19.1.0
>         Environment: All
>            Reporter: Kfir Itzhak
>
> Hi,
> We use app_queue extensively and it works well.
> But often, managers would like to retrieve a call, to dispatch it to a specific agent. 
> This requires to have a way to withdraw a call from the queue, in a clean manner. Such functionality didn't exist, and for years we used the Redirect() AMI command, however it caused a lot of grief.
> With the Redirect() command, these happened often:
> 1) An already answered call (by an agent) was redirected.
> 2) A call that is no longer in the queue (e.g. exceeded max wait time), was redirected.
> 3) It is possible to send more than one Redirect() request, and all of them will be processed, leading to multiple redirects.
> These happen due to timing issues. We check that the call is really in the queue first and not answered, but by the time the Redirect() command is sent, it is possible that the call is already answered, or is no longer in the queue.
> Therefore, i developed a more native, generic solution for withdrawing a call from the queue.
> The new AMI command "QueueWithdrawCaller" works by signaling the caller's channel to exit the queue whenever it can. This is a best effort request (it may happen and it may not), this keeps it fairly simple and bug-free, while being suitable for 95% of the cases.
> Due to the best effort design, if the caller is listening to an announcement or is in a breakout menu, it will wait until these are over.
> Because this is likely to be used for retrieving a caller from a queue and dispatching to a specific agent, an optional parameter exists, that later can be retrieved using the QUEUE_WITHDRAW_INFO dialplan variable. In our system, we store the target extension number in this field, and later read it in the dialplan and dispatch the caller to that extension.
> For the queue log, A WITHDRAW verb was added.
> For AMI, QueueCallerAbandon is generated as usual, but QueueCallerAbandon lacks information why a call was abandoned from a queue, but this will be resolved in a separate issue that adds a Reason field to this AMI event. I am creating a separate issue & pull request for it, to prevent conflicts.



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