[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) noreply at issues.asterisk.org
Fri Mar 10 15:34:10 CST 2017


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

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

There are some subtle differences between this ticket and ASTERISK-26400
There is a patch up on the reviewboard which looks to address each issue.
External redirects ASTERISK-26400

ASTERISK-26715 direct member transfers.
https://gerrit.asterisk.org/#/c/5149/
When a member transfers the call directly (without using features), the device state of the member is correctly reset, but the "in call" flag is still set to true.

exmaple:
{noformat}
master88*CLI> queue show

debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 18s talktime), W:0, C:11, A:0, SL:100.0% within 60s
   Members:
      Local/214 at debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago)
   No Callers

master88*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/debcomainbtn213- (None)               Up      AppDial((Outgoing Line))
SIP/debcomainbtn216- s at debcomainbtn-appli Up      Queue(debcomainbtn-reception,t
Local/214 at debcomainb s at debcomainbtn-agent Up      AppQueue((Outgoing Line))
Local/214 at debcomainb s at macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
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
172.31.240.111   debcomainbtn216  0_2064138430 at 17  (ulaw)           No       Tx: UPDATE                 debcomainb
192.168.192.78   (None)           3be2ae342e97dcb  (nothing)        No       Rx: OPTIONS                <guest>
172.31.240.110   debcomainbtn213  35c30b9a6a1c852  (ulaw)           No       Tx: ACK                    debcomainb
3 active SIP dialogs
{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, 13.13.1
>            Reporter: David Brillert
>            Assignee: Unassigned
>
> 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)



More information about the asterisk-bugs mailing list