[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)
noreply at issues.asterisk.org
Tue Mar 14 09:00:09 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235776#comment-235776 ]
David Brillert edited comment on ASTERISK-26715 at 3/14/17 8:58 AM:
--------------------------------------------------------------------
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 at debcomainbtn-agent-00000000;1
{noformat}
But not the transfer so we are left with channels Up which should not be.
{noformat}
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))
{noformat}
Which causes the 'in_call' flag to be true
{noformat}
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
{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 at debcomainb s at debcomainbtn-agent Up AppQueue((Outgoing Line))
Local/214 at debcomainb s at 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.
was (Author: aragon):
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 at debcomainbtn-agent-00000000;1
{noformat}
But not the transfer so we are left with channels Up which should not be.
{noformat}
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))
{noformat}
Which causes the 'in_call' flag to be true
{noformat}
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
{noformat}
We add more debug to see where the redirect fails
{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 at debcomainb s at debcomainbtn-agent Up AppQueue((Outgoing Line))
Local/214 at debcomainb s at 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.
> 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)
More information about the asterisk-bugs
mailing list