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

[David Brillert (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235780#comment-235780 ] 

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

[~seanbright] Yes, we still have a channel Up which IMHO should not be.
Afer the agent extension transfers the channel is not torn down on a redirect.
Because the redirect fails on function due to different uniqueid and bridge
{noformat}
 /* Correct channel, correct bridge? */
        if (strcmp(left_blob->channel->uniqueid, queue_data->caller_uniqueid)
                || strcmp(left_blob->bridge->uniqueid, queue_data->bridge_uniqueid)) {
                ao2_unlock(queue_data);
                return;
        } 
{noformat}

Without patches and if wrapuptime=0
The agent transfers the caller but can still receive a new call after the transfer and before the transferred channels are hung up.
But the 'in_call' flag is true
And the core show channels still shows the agent extension in a channel
{noformat}
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 25s talktime), W:0, C:9, A:0, SL:100.0% within 60s
   Members:
      Local/214 at debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 9 calls (last was 177 secs ago)
   No Callers

master88*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/debcomainbtn213- (None)               Up      AppDial((Outgoing Line))
Local/214 at debcomainb s at macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
Local/214 at debcomainb s at debcomainbtn-agent Up      AppQueue((Outgoing Line))
SIP/debcomainbtn216- s at debcomainbtn-appli Up      Queue(debcomainbtn-reception,t
4 active channels
2 of 512 max active calls ( 0.39% of capacity)

master88*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer
192.168.192.78   (None)           6e0d1264723bc95  (nothing)        No       Rx: OPTIONS                <guest>
172.31.240.111   debcomainbtn216  0_1966151905 at 17  (ulaw)           No       Tx: UPDATE                 debcomainb
172.31.240.110   debcomainbtn213  0715e9a879d7be6  (ulaw)           No       Tx: UPDATE                 debcomainb
3 active SIP dialogs
{noformat}

As a workaround we set wraptime=0 on all queues so that agents continue to receive calls after transferring callers to other extensions.  So we cannot use any wrapuptime
Another downside is we check channel status to create ACD reports and Agent in use status and these reports are broken because the agent appears to be on a channel.



> app_queue: Member will not receive any new calls after doing a transfer if wrapuptime = greater than 0 and using Local channel
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 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
>         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)