[asterisk-bugs] [JIRA] (ASTERISK-26715) app_queue: Member will not receive any new calls after doing a transfer if wrapuptime = greater than 0

[Joshua Colp (JIRA)]

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

Joshua Colp updated ASTERISK-26715:
-----------------------------------

    Assignee: David Brillert  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Are you absolutely sure you are using a state interface? As [~seanbright] stated if you are not then you would see the exact behavior you are seeing - as you are transferring the Local channel, and not the caller directly, so the Local channel will remain in use after the transfer.

How are you adding queue agents and what are the arguments?

> 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: David Brillert
>         Attachments: fulldebug.txt
>
>
> 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)