[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)]

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

David Brillert updated ASTERISK-26715:
--------------------------------------

    Description: 
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.

{noformat}
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:
Local/214 at queue-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 2 calls (last was 578 secs ago)

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

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
{noformat}


  was:
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.

This commit has caused the regression.
{noformat}
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:
Local/214 at queue-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 2 calls (last was 578 secs ago)

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

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
{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
>            Reporter: David Brillert
>
> 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.
> {noformat}
> 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:
> Local/214 at queue-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 2 calls (last was 578 secs ago)
> 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
> 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
> {noformat}



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