[asterisk-bugs] [JIRA] (ASTERISK-26400) app_queue: Queue member stops being called after AMI "Redirect" action for queues with wrapuptime

Etienne Lessard (JIRA) noreply at issues.asterisk.org
Thu Sep 22 14:22:01 CDT 2016


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

Etienne Lessard updated ASTERISK-26400:
---------------------------------------

    Description: 
Hello,

Given I have a queue with a *nonzero wrapuptime* and one queue member
And Alice calls this queue
And the queue member answers
When an AMI "Redirect" redirects Alice's channel to a different extension
Then the queue member won't receive any new call from the queue until Alice's channel is hung up

Note that after the AMI Redirect, the queue member is available / not in use, but won't receive any new call because the queue still think it's "in call", as shown by the "queue show" command.

This is especially noticeable if your queue member is member of many queues (all with wrapup) and you have "shared_lastcall = yes" in your queues.conf.

Also, if you find yourself in a scenario similar to the one described in ASTERISK-25844, this gets worse, i.e. your queue member won't receive any new calls even after Alice's channel is hung up.

This bug (which happens to be a regression) has been introduced by commit 338a8ffed673e4c3a828c7c216575f8e3e712350 and this commit references ASTERISK-19820.

Thanks

  was:
Hello,

Given I have a queue with a *nonzero wrapuptime* and one queue member
And Alice calls this queue
And the queue member answers
When an AMI "Redirect" redirects Alice's channel to a different extension
Then the queue member won't receive any new call from the queue until Alice's channel is hung up

Note that after the AMI Redirect, the queue member is available / not in use, but won't receive any new call because the queue still think it's "in call", as shown by the "queue show" command.

This is especially noticeable if your queue member is member of many queues (all with wrapup) and you have "shared_lastcall = yes" in your queues.conf.

Also, if you find yourself in a scenario similar to the one described in ASTERISK-25844, this gets worse, i.e. your queue member won't receive any new calls even after Alice's channel is hung up.

This bug (which happens to be a regression) has been introduced by commit 338a8ffed673e4c3a828c7c216575f8e3e712350.

Thanks


> app_queue: Queue member stops being called after AMI "Redirect" action for queues with wrapuptime
> -------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26400
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26400
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 13.11.2
>            Reporter: Etienne Lessard
>            Severity: Minor
>
> Hello,
> Given I have a queue with a *nonzero wrapuptime* and one queue member
> And Alice calls this queue
> And the queue member answers
> When an AMI "Redirect" redirects Alice's channel to a different extension
> Then the queue member won't receive any new call from the queue until Alice's channel is hung up
> Note that after the AMI Redirect, the queue member is available / not in use, but won't receive any new call because the queue still think it's "in call", as shown by the "queue show" command.
> This is especially noticeable if your queue member is member of many queues (all with wrapup) and you have "shared_lastcall = yes" in your queues.conf.
> Also, if you find yourself in a scenario similar to the one described in ASTERISK-25844, this gets worse, i.e. your queue member won't receive any new calls even after Alice's channel is hung up.
> This bug (which happens to be a regression) has been introduced by commit 338a8ffed673e4c3a828c7c216575f8e3e712350 and this commit references ASTERISK-19820.
> Thanks



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



More information about the asterisk-bugs mailing list