[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:comment-tabpanel&focusedCommentId=235706#comment-235706 ] 

David Brillert commented on ASTERISK-26715:
-------------------------------------------

[~seanbright] Something weird is going on because core show channels shows Local/214 is involved in a channel after it hangs up to complete the transfer.  I've also reproduced this using DTMF feature code transfers. I can't tell what is going on here, but I have uploaded a full CLI fulldebug.txt trace with sip debug also enabled to show when INVITES are occurring during dial plan execution.  Essentially a channel is left up after x214 transfers and I think this causes the 'in use' flag.

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