[asterisk-bugs] [JIRA] (ASTERISK-26400) app_queue: Queue member stops being called after AMI "Redirect" action for queues with wrapuptime
David Brillert (JIRA)
noreply at issues.asterisk.org
Thu Mar 9 10:49:10 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235649#comment-235649 ]
David Brillert edited comment on ASTERISK-26400 at 3/9/17 10:47 AM:
--------------------------------------------------------------------
[~seanbright]
You mentioned a SIP blind transfer should be explicitly handled so I tested that scenario as well
Same call flow as above only instead of attended SIP transfer I did a Polycom Blind transfer
{noformat}
master88*CLI> queue show
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 18s talktime), W:0, C:11, A:0, SL:100.0% within 60s
Members:
Local/214 at debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago)
No Callers
master88*CLI> core show channels
Channel Location State Application(Data)
SIP/debcomainbtn213- (None) Up AppDial((Outgoing Line))
SIP/debcomainbtn216- s at debcomainbtn-appli Up Queue(debcomainbtn-reception,t
Local/214 at debcomainb s at debcomainbtn-agent Up AppQueue((Outgoing Line))
Local/214 at debcomainb s at macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk
4 active channels
2 of 512 max active calls ( 0.39% of capacity)
master88*CLI> sip show channels
Peer User/ANR Call ID Format Hold Last Message Expiry Peer
172.31.240.111 debcomainbtn216 0_2064138430 at 17 (ulaw) No Tx: UPDATE debcomainb
192.168.192.78 (None) 3be2ae342e97dcb (nothing) No Rx: OPTIONS <guest>
172.31.240.110 debcomainbtn213 35c30b9a6a1c852 (ulaw) No Tx: ACK debcomainb
3 active SIP dialogs
{noformat}
was (Author: aragon):
[~seabbright]
You mentioned a SIP blind transfer should be explicitly handled so I tested that scenario as well
Same call flow as above only instead of attended SIP transfer I did a Polycom Blind transfer
{noformat}
master88*CLI> queue show
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 18s talktime), W:0, C:11, A:0, SL:100.0% within 60s
Members:
Local/214 at debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago)
No Callers
master88*CLI> core show channels
Channel Location State Application(Data)
SIP/debcomainbtn213- (None) Up AppDial((Outgoing Line))
SIP/debcomainbtn216- s at debcomainbtn-appli Up Queue(debcomainbtn-reception,t
Local/214 at debcomainb s at debcomainbtn-agent Up AppQueue((Outgoing Line))
Local/214 at debcomainb s at macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk
4 active channels
2 of 512 max active calls ( 0.39% of capacity)
master88*CLI> sip show channels
Peer User/ANR Call ID Format Hold Last Message Expiry Peer
172.31.240.111 debcomainbtn216 0_2064138430 at 17 (ulaw) No Tx: UPDATE debcomainb
192.168.192.78 (None) 3be2ae342e97dcb (nothing) No Rx: OPTIONS <guest>
172.31.240.110 debcomainbtn213 35c30b9a6a1c852 (ulaw) No Tx: ACK debcomainb
3 active SIP dialogs
{noformat}
> 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
> Assignee: Sean Bright
> Labels: regression
>
> 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