[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.

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}


  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}
2016-04-21 15:35 +0000 [79d7284b8b]  Kevin Harwell <kharwell at digium.com>

	* app_queue: queue members can receive multiple calls

	  It was possible for a queue member that is a member of at least 2 or more
	  queues to receive mulitiple calls at the same time. This happened because
	  of a race between when a member was being rung and when the device state
	  notified the other queue(s) member object of the state change.

	  This patch makes it so when a queue member is being rung it gets added to
	  a global pool of queue members. If that same member is tried again, e.g.
	  from another queue, and it is found to already exist in the pending member
	  container then it will not ring that member.

	  ASTERISK-16115 #close

	  Change-Id: Ice45a1c95b9f6f15d8a9fa709c5e5c84ffd29780
{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.
> 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}



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