[asterisk-bugs] [JIRA] (ASTERISK-26715) app_queue member will not receive any new calls after doing a transfer if wrapuptime = greater than 0
David Brillert (JIRA)
noreply at issues.asterisk.org
Thu Jan 12 10:05:09 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234593#comment-234593 ]
David Brillert edited comment on ASTERISK-26715 at 1/12/17 10:03 AM:
---------------------------------------------------------------------
Hi Rusty,
Extensions.conf refers to a lot of verbose scripts and I am not sure what kind of configs you are looking for...
But the easiest way to reproduce is simple:
if wrapuptime = 0 there are no issues with member receiving any calls after transfers.
if wrapuptime = 1 the member will never receive a call until channels involved in transfer are torn down.
{noformat}
Transfers tested are:
*1
*2
One Touch DTMF PARK
SIP blind
SIP attended
SIP semi-attended
SIP PARK
{noformat}
Regardless of wrapuptime = 0 or 1
Member status during transfer always includes flag (in call) (not in use) while the transferred channels are up.
If I quote the author of the regression 'Members with "in_call" set to true are treat as unavailable.' But during testing this statement is false since the member does receive calls after a transfer if wrapuptime = 0 and queue show does display the (in call) flag.
Working queues.conf
{noformat}
strategy = ringall
servicelevel = 60
timeout = 15
retry = 5
maxlen =
weight = 0
reportholdtime = no
reportwaitcall = no
memberdelay = 0
timeoutrestart = no
autofill = yes
autopause = no
ringinuse = no
setinterfacevar = yes
wrapuptime = 0
joinempty = penalty,invalid,unknown
leavewhenempty = penalty,invalid,unknown
eventwhencalled = vars
eventmemberstatus = yes
announce-holdtime = no
announce =
monitor-format = wav49
monitor-type = MixMonitor
penaltymemberslimit = -1
{noformat}
Affected queues.conf
{noformat}
strategy = ringall
servicelevel = 60
timeout = 15
retry = 5
maxlen =
weight = 0
reportholdtime = no
reportwaitcall = no
memberdelay = 0
timeoutrestart = no
autofill = yes
autopause = no
ringinuse = no
setinterfacevar = yes
wrapuptime = 10
joinempty = penalty,invalid,unknown
leavewhenempty = penalty,invalid,unknown
eventwhencalled = vars
eventmemberstatus = yes
announce-holdtime = no
announce =
monitor-format = wav49
monitor-type = MixMonitor
penaltymemberslimit = -1
{noformat}
was (Author: aragon):
Hi Rusty,
Extensions.conf refers to a lot of verbose scripts and I am not sure what kind of configs you are looking for...
But the easiest way to reproduce is simple:
if wrapuptime = 0 there are no issues with member receiving any calls after transfers.
if wrapuptime = 1 the member will never receive a call until channels involved in transfer are torn down.
Transfers tested are:
*1
*2
One Touch DTMF PARK
SIP blind
SIP attended
SIP semi-attended
SIP PARK
Regardless of wrapuptime = 0 or 1
Member status during transfer always includes flag (in call) (not in use) while the transferred channels are up.
If I quote the author of the regression 'Members with "in_call" set to true are treat as unavailable.' But during testing this statement is false since the member does receive calls after a transfer if wrapuptime = 0 and queue show does display the (in call) flag.
Working queues.conf
{noformat}
strategy = ringall
servicelevel = 60
timeout = 15
retry = 5
maxlen =
weight = 0
reportholdtime = no
reportwaitcall = no
memberdelay = 0
timeoutrestart = no
autofill = yes
autopause = no
ringinuse = no
setinterfacevar = yes
wrapuptime = 0
joinempty = penalty,invalid,unknown
leavewhenempty = penalty,invalid,unknown
eventwhencalled = vars
eventmemberstatus = yes
announce-holdtime = no
announce =
monitor-format = wav49
monitor-type = MixMonitor
penaltymemberslimit = -1
{noformat}
Affected queues.conf
{noformat}
strategy = ringall
servicelevel = 60
timeout = 15
retry = 5
maxlen =
weight = 0
reportholdtime = no
reportwaitcall = no
memberdelay = 0
timeoutrestart = no
autofill = yes
autopause = no
ringinuse = no
setinterfacevar = yes
wrapuptime = 10
joinempty = penalty,invalid,unknown
leavewhenempty = penalty,invalid,unknown
eventwhencalled = vars
eventmemberstatus = yes
announce-holdtime = no
announce =
monitor-format = wav49
monitor-type = MixMonitor
penaltymemberslimit = -1
{noformat}
> app_queue member will not receive any new calls after doing a transfer if wrapuptime = greater than 0
> -----------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-26715
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26715
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Applications/app_queue
> Affects Versions: 11.25.1, 13.13.1
> Reporter: David Brillert
> Assignee: Unassigned
>
> To reproduce edit queues.conf
> wrapuptime = 10
> Dynamic member answers a call and transfers caller to any extension.
> Member will not receive a new call from queue until all parties involved in transfer hangup.
> Testing multiple revisions tells me that the regression was introduced between 2015-02-27 and 2016-01-31. I arrived at this conclusion by testing multiple versions of Asterisk rpms I had laying around until I could reproduce the breakage.
> At some point between 2015-02-27 and 2016-01-31 something introduced (in call) state in which broke agent status when wrapuptime is defined:
> Example:
> {noformat}
> Local/214 at queue-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 2 calls (last was 578 secs ago)
> {noformat}
> The last release I am certain that wrapuptime was working properly was 11.16
> Based on this additional investigation and review of the changelog it is probably this commit which caused the regression
> Release 11
> {noformat}
> 2015-12-29 05:44 +0000 [1943cfc53c] Martin Tomec <tomec.martin at gmail.com>
> app_queue: Add member flag "in_call" to prevent reading wrong lastcall time
> Member lastcall time is updated later than member status. There was chance to
> check wrapuptime for available member with wrong (old) lastcall time.
> New boolean flag "in_call" is set to true right before connecting call, and
> reset to false after update of lastcall time. Members with "in_call" set to true
> are treat as unavailable.
> ASTERISK-19820 #close
> Change-Id: I1923230cf9859ee51563a8ed420a0628b4d2e500
> {noformat}
> Release 13
> {noformat}
> 2015-12-29 04:31 +0000 [338a8ffed6] Martin Tomec <tomec.martin at gmail.com>
> * app_queue: Add member flag "in_call" to prevent reading wrong lastcall time
> Member lastcall time is updated later than member status. There was chance to
> check wrapuptime for available member with wrong (old) lastcall time.
> New boolean flag "in_call" is set to true right before connecting call, and
> reset to false after update of lastcall time. Members with "in_call" set to true
> are treat as unavailable.
> ASTERISK-19820 #close
> Change-Id: I1923230cf9859ee51563a8ed420a0628b4d2e500
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list