[Home]

Summary:ASTERISK-26715: app_queue: Member will not receive any new calls after doing a transfer if wrapuptime = greater than 0 and using Local channel
Reporter:David Brillert (aragon)Labels:
Date Opened:2017-01-11 15:58:15.000-0600Date Closed:2017-05-24 07:50:40
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_queue
Versions:11.25.1 13.13.1 Frequency of
Occurrence
Constant
Related
Issues:
is duplicated byASTERISK-26757 When a queue member transfers queue call, he remains marked as "in call"
is related toASTERISK-26400 app_queue: Queue member stops being called after AMI "Redirect" action for queues with wrapuptime
Environment:Attachments:( 0) bt26715onTransfer.txt
( 1) fulldebug.txt
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.

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@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@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@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}
Comments:By: Asterisk Team (asteriskteam) 2017-01-11 15:58:16.779-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Rusty Newton (rnewton) 2017-01-12 09:14:45.765-0600

Thanks for the report. In addition please provide a minimal, but complete queues.conf and extensions.conf that would reproduce the issue.

By: Etienne Lessard (hexanol) 2017-01-12 09:47:34.635-0600

Hi David,

There seems to be some similarities with the bug I've opened a while ago: ASTERISK-26400 . The only thing being really different is how the transfer is accomplished.

By: Etienne Lessard (hexanol) 2017-01-12 09:53:47.027-0600

The ticket I wanted to link to is ASTERISK-26400, I made a mistake in my last post.

By: David Brillert (aragon) 2017-01-12 10:03:08.563-0600

Hi Rusty,
Extensions.conf refers to a lot of verbose scripts and I am not sure what kind of configs you are looking for...
But the easiest way to reproduce is simple:
if wrapuptime = 0 there are no issues with member receiving any calls after transfers.
if wrapuptime = 1 the member will never receive a call until channels involved in transfer are torn down.

{noformat}
Transfers tested are:
*1
*2
One Touch DTMF PARK
SIP blind
SIP attended
SIP semi-attended
SIP PARK
{noformat}

Regardless of wrapuptime = 0 or 1
Member status during transfer always includes flag (in call) (not in use) while the transferred channels are up.
If I quote the author of the regression 'Members with "in_call" set to true are treat as unavailable.' But during testing this statement is false since the member does receive calls after a transfer if wrapuptime = 0 and queue show does display the (in call) flag.

Working queues.conf
{noformat}
strategy                       =  ringall
servicelevel                   =  60
timeout                        =  15
retry                          =  5
maxlen                         =  
weight                         =  0
reportholdtime                 =  no
reportwaitcall                 =  no
memberdelay                    =  0
timeoutrestart                 =  no
autofill                       =  yes
autopause                      =  no
ringinuse                      =  no
setinterfacevar                =  yes
wrapuptime                     =  0
joinempty                      =  penalty,invalid,unknown
leavewhenempty                 =  penalty,invalid,unknown
eventwhencalled                =  vars
eventmemberstatus              =  yes
announce-holdtime              =  no
announce                       =  
monitor-format                 =  wav49
monitor-type                   =  MixMonitor
penaltymemberslimit            =  -1
{noformat}

Affected queues.conf
{noformat}
strategy                       =  ringall
servicelevel                   =  60
timeout                        =  15
retry                          =  5
maxlen                         =  
weight                         =  0
reportholdtime                 =  no
reportwaitcall                 =  no
memberdelay                    =  0
timeoutrestart                 =  no
autofill                       =  yes
autopause                      =  no
ringinuse                      =  no
setinterfacevar                =  yes
wrapuptime                     =  10
joinempty                      =  penalty,invalid,unknown
leavewhenempty                 =  penalty,invalid,unknown
eventwhencalled                =  vars
eventmemberstatus              =  yes
announce-holdtime              =  no
announce                       =  
monitor-format                 =  wav49
monitor-type                   =  MixMonitor
penaltymemberslimit            =  -1
{noformat}

By: David Brillert (aragon) 2017-01-12 10:16:12.549-0600

Yes Etienne, there are remarkable similarities to your bug report ASTERISK-26400
I am not using AMI "Redirect".  It is simple to reproduce with any type of transfer in my case.  Not sure if you have tested other transfer methods when wrapuptime = 1 or greater
However given that the patch in ASTERISK-19820 was committed back in December 2015 I am not surprised to see others reporting this type of app_queue behavior.  This regression reminds me of the old days prior to state_interface implementation.

By: Joshua C. Colp (jcolp) 2017-01-17 10:36:25.713-0600

Looking at this it appears to be the same underlying thing as ASTERISK-26400 which you've discussed. To that end I'm marking this out as a duplicate. Any progress will be tracked on ASTERISK-26400.

By: David Brillert (aragon) 2017-03-10 15:32:14.190-0600

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@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@debcomainbtn-appli Up      Queue(debcomainbtn-reception,t
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))
Local/214@debcomainb s@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@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}

By: Asterisk Team (asteriskteam) 2017-03-10 15:32:14.561-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Sean Bright (seanbright) 2017-03-11 11:08:57.979-0600

[~aragon], are you using state interfaces with your Local queue members? I don't see it in the {{queue show}} output. If not, is the device state of the member always "Not in use" whether they are on a call or not?

By: David Brillert (aragon) 2017-03-11 12:44:18.466-0600

[~seanbright] Yes, definitely using state interface.
And GROUP_COUNT and callcounters=yes

Here is queue show when member is on a call without any transfer.
{noformat}
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 32s talktime), W:0, C:1, A:0, SL:100.0% within 60s
  Members:
     Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (In use) has taken 1 calls (last was 78865 secs ago)
  No Callers

master88*CLI> core show channels
Channel              Location             State   Application(Data)
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))
Local/214@debcomainb 214@debcomainbtn-loc Up      Dial(SIP/debcomainbtn214,,tk)
SIP/debcomainbtn216- s@debcomainbtn-appli Up      Queue(debcomainbtn-reception,t
SIP/debcomainbtn214- (None)               Up      AppDial((Outgoing Line))
4 active channels

core show hints
214@debcomainbtn-loc: SIP/debcomainbtn214   State:InUse           Presence:Not_Set         Watchers  1
{noformat}

queue show when idle
{noformat}
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 119s talktime), W:0, C:2, A:0, SL:100.0% within 60s
  Members:
     Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (Not in use) has taken 2 calls (last was 25 secs ago)
  No Callers

master88*CLI> core show channels
Channel              Location             State   Application(Data)
0 active channels
0 of 512 max active calls ( 0.00% of capacity)

core show hints
214@debcomainbtn-loc: SIP/debcomainbtn214   State:Idle            Presence:Not_Set         Watchers  1
{noformat}

By: David Brillert (aragon) 2017-03-12 17:33:14.667-0500

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

By: Joshua C. Colp (jcolp) 2017-03-12 18:22:37.845-0500

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?

By: Joel Vandal (jvandal) 2017-03-12 18:36:50.979-0500

If I check on logs :

AddQueueMember("SIP/debcomainbtn214-00000013", "debcomainbtn-reception,Local/214@debcomainbtn-agent/n,,,,SIP/debcomainbtn214,") in new stack

And if I check on AstDB :

Queue/PersistentMembers/debcomainbtn-reception   : Local/214@debcomainbtn-agent/n;0;0;Local/214@debcomainbtn-agent/n;SIP/debcomainbtn214;

So the State Interface must be set to SIP/debcomainbtn214



By: David Brillert (aragon) 2017-03-12 18:38:00.754-0500

Joel is my colleague, he replied for me.

By: Joel Vandal (jvandal) 2017-03-12 18:46:22.024-0500

And if I check AMI to confirm that StateInterface is set :

Event: QueueMember
Queue: debcomainbtn-reception
Name: Local/214@debcomainbtn-agent/n
Location: Local/214@debcomainbtn-agent/n
StateInterface: SIP/debcomainbtn214

By: Joshua C. Colp (jcolp) 2017-03-12 18:55:13.913-0500

[~jvandal] Please try removing the "," at the end of the state interface that is passed to the AddQueueMember dialplan application just for kicks.

By: David Brillert (aragon) 2017-03-12 19:01:36.165-0500

Same result removing the ","
debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 29s talktime), W:0, C:7, A:0, SL:100.0% within 60s
  Members:
     Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken no calls yet
  No Callers


By: Joshua C. Colp (jcolp) 2017-03-12 19:03:29.683-0500

Then I'm afraid someone will have to dig in deeper.

By: Joel Vandal (jvandal) 2017-03-12 19:12:03.231-0500

We removed all custom patch (ex. xivo_queue_skills), etc... and same issues. We are now using a plain Asterisk 13.14.0 and still have issues.

I also remove the , after the state interface.



By: Sean Bright (seanbright) 2017-03-13 07:41:00.162-0500

This is strange... if I run {{queue show}} I see the state interface explicitly (maybe because it's a statically defined agent?):

{noformat}
Members:
  Sean Bright (Local/Msean@ringall/n from PJSIP/sean) (ringinuse enabled) (Unavailable) has taken no calls yet
                                          ^^^^^^^^^^
{noformat}


By: Joel Vandal (jvandal) 2017-03-13 08:39:53.583-0500

Sean, you see the "from ..." because the Member Name do not match the Interface name.
In our case we arent using the "Member Name", it why this part of app_queues is not displayed :

{noformat}
ast_str_set(&out, 0, "      %s", mem->membername);
if (strcasecmp(mem->membername, mem->interface)) {
   ast_str_append(&out, 0, " (%s", mem->interface);
   if (!ast_strlen_zero(mem->state_interface)) {
       ast_str_append(&out, 0, " from %s", mem->state_interface);
   }
   ast_str_append(&out, 0, ")");
}
{noformat}

By: Sean Bright (seanbright) 2017-03-13 08:44:06.909-0500

[~jvandal], roger that.

By: Joel Vandal (jvandal) 2017-03-13 08:53:25.030-0500

But thanks, I've been curious why I've never see the "From..." and found the explaination on the code :)

To be sure that the State Interface is defined, I've check on AMI output (I see the StateInterface), I also verified on AstDB, etc. so I confirm that the State Interface is set.

By: Sean Bright (seanbright) 2017-03-13 13:48:11.674-0500

[New patch uploaded|https://gerrit.asterisk.org/#/c/5151/] but I make no guarantees that it will actually ever be merged (it may or may not be a big hack).

By: David Brillert (aragon) 2017-03-14 08:48:16.799-0500

I have two results.
Same call flow for both tests
Call flow=
A = 216 calls queue = reception
B = queue member logged to SIP 214 answers via queue and completes an attended SIP Transfer to C = 213
C= 213 is bridged to 216
B= idle (transfer completed)

Result 1:
Using https://gerrit.asterisk.org/#/c/5151/ patch set 3 and adding debug to core
When 214 does the transfer we check to see if the "Redirect trigger" event is generated
{noformat}
ast_debug(3, "Detected redirect of queue caller channel %s\n",
+               caller_snapshot->name);
{noformat}
Is never executed
We see :
{noformat}
[2017-03-13 14:01:42] DEBUG[19505] app_queue.c: Detected entry of caller channel SIP/gateway-00000000 into bridge e0693ed3-75b0-40f2-a03f-64a5d37983e0
[2017-03-13 14:02:14] DEBUG[19525] app_queue.c: Detected hangup of queue member channel Local/214@debcomainbtn-agent-00000000;1
{noformat}
But not the transfer so we are left with channels Up which should not be.
{noformat}
Local/214@debcomainb s@macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))
{noformat}
Which causes the 'in_call' flag to be true
{noformat}
Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago)
  No Callers
{noformat}
We add more debug to see where the redirect fails and see that since it not same uniqueid, not same bridge, etc... it fail
{noformat}
[2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428881.4 - 1489428880.0 ::: 42c6bcd8-f54a-4a81-ad52-d6bdc57efffe 5b340214-af35-46ec-8b25-ff42ee41a282
[2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL left
[2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428884.18 - 1489428880.0 ::: f8bf135b-f9a5-4164-a3c3-97ccaf06f078 5b340214-af35-46ec-8b25-ff42ee41a282
[2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL left
[2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428881.8 - 1489428880.0 ::: 42c6bcd8-f54a-4a81-ad52-d6bdc57efffe 5b340214-af35-46ec-8b25-ff42ee41a282
{noformat}
And see the failure on this function
{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}

Result 2:
Is our tests using https://gerrit.asterisk.org/#/c/5151/ patch set 5
I don't have any CLI to report with patch set 5 but here is the summary of our findings:
The patch does allow the agent to receive a call after they transfer a call and after the wrapuptime=10
But it still leaves an Up channel whiich should be torn down after a transfer or feature redirect
{noformat}
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))
Local/214@debcomainb s@macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
{noformat}
So patch set 5 fixes the reported issue but does not appear to fix root cause which is a failure to execute the redirect event.





By: Sean Bright (seanbright) 2017-03-14 09:10:38.161-0500

There is a lot of noise in your most recent comment, but what I am getting from it is: Using the latest patch on the gerrit review, after a transfer there are still Local channels that you believe should not be there. Does that sum it up?

By: Sean Bright (seanbright) 2017-03-14 09:16:00.055-0500

Without the patch, what happens after a "SIP transfer" if your queue member has a wrap up time of 0?

By: David Brillert (aragon) 2017-03-14 09:24:46.587-0500

[~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@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@debcomainb s@macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))
SIP/debcomainbtn216- s@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@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.



By: Sean Bright (seanbright) 2017-03-14 09:41:03.654-0500

Again there is a lot of noise in your comment (I don't need/want code snippets or CLI output), can you just answer Yes or No to the following questions?


# *Without* the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away?
# *With* the patch from gerrit, if wrapuptime is greater than 0 and a "sip transfer" is performed, the Local channels stay?

Also, considering the code analysis you have done, could you please attach a patch that resolves the problem completely in your environment? I'd be happy to integrate your suggested changes.

By: David Brillert (aragon) 2017-03-14 09:49:41.119-0500

1.  Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away?
No
2.  With the patch from gerrit, if wrapuptime is greater than 0 and a "sip transfer" is performed, the Local channels stay?
Yes

Sorry we cannot write a patch, not enough coders with C mojo.




By: Sean Bright (seanbright) 2017-03-14 09:53:53.164-0500

{quote}
Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? No
{quote}

OK. So why is that a problem WITH the patch when wrapuptime is greater than 0?

By: David Brillert (aragon) 2017-03-14 10:11:27.765-0500

Because with the patch we still have invalid channel status due to the failed redirect.  Patch set 5 only masks the problem.
The invalid channel affects CDR reports, agent in use status, call durations etc...
For what it's worth I did testing and if I do an AMI redirect the reviewboard patch set 3 does fix and tear down the agent channel on the redirect ASTERISK-26400


By: David Brillert (aragon) 2017-03-14 10:19:15.749-0500

Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? No
This means that we still see the ghost channel.
Let me try to summarize again since I guess there is a miscommunication still:
With or without patches and regardless if wrapuptime =0 or wrapuptime = greater than 0
in_call is always true after a local transfer
Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 9 calls (last was 177 secs ago)
  No Callers

Agent still shows in a channel after the transfer (ghost channel).
Local/214@debcomainb s@macro-debcomainbtn Up      Dial(SIP/debcomainbtn213,20,tk
Local/214@debcomainb s@debcomainbtn-agent Up      AppQueue((Outgoing Line))

It just so happens that if wrapuptime = 0 that agent can still receive a call without patches (fluke)

By: Andrej (tekach) 2017-03-22 03:17:14.612-0500

Hi everybody,

is there any progress with this issue? Bug is seriously impacting our call center work processes (I originally opened ASTERISK-26757).

If this helps and is acceptable, I am offering a bounty for solving this bug (500€). Sincere apologies if this is not appropriate, I am new to this.

Thanks,
Andrej

By: Joshua C. Colp (jcolp) 2017-03-22 05:13:19.364-0500

Any updates will be posted on this issue. As there is noone assigned there is noone working on it. The process for a bounty is also documented on the wiki[1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties

By: Friendly Automation (friendly-automation) 2017-05-24 07:50:41.094-0500

Change 5640 merged by Jenkins2:
app_queue: Fix members showing as being in call when not.

[https://gerrit.asterisk.org/5640|https://gerrit.asterisk.org/5640]

By: Friendly Automation (friendly-automation) 2017-05-24 08:40:09.362-0500

Change 5639 merged by Jenkins2:
app_queue: Fix members showing as being in call when not.

[https://gerrit.asterisk.org/5639|https://gerrit.asterisk.org/5639]

By: Friendly Automation (friendly-automation) 2017-05-24 09:41:37.130-0500

Change 5641 merged by Joshua Colp:
app_queue: Fix members showing as being in call when not.

[https://gerrit.asterisk.org/5641|https://gerrit.asterisk.org/5641]

By: David Brillert (aragon) 2017-05-25 10:20:29.695-0500

After applying https://gerrit.asterisk.org/#/c/5639/ to Asterisk 13 SVN
I get a segfault each time an agent answers a call on their Polycom phone and tries a SIP attended transfer to any other extension.

By: Asterisk Team (asteriskteam) 2017-05-25 10:20:30.091-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: David Brillert (aragon) 2017-05-25 10:57:07.757-0500

Attaching back trace file bt26715onTransfer.txt

By: Joshua C. Colp (jcolp) 2017-05-25 11:15:41.393-0500

I just did this with 13 from git with no problems. You're going to need to give more details in order to reproduce it:

1. What specific git revision did you apply it to?
2. Are there other callers in the queue?
3. Are Local channels involved?
4. What is the queue configuration?

By: David Brillert (aragon) 2017-05-25 11:22:52.535-0500

Looks like I did not apply the patch correctly. After re-applying the patch there is no more crashing during a transfer and the originally reported issue is also resolved. Sorry for the noise.