Queue member stays "In Use" after parking a call

amiedzow · June 26, 2017, 10:00am

Hello everyone,

I’ve configured call parking in Asterisk 13 (using PJSIP) using the default settings in res_parking.conf and features.conf and noticed that when a call enters a queue and the agent that picked up the call parks it, the status of that agent stays “In Use” until the call ends even though the agent is no longer involved in the call at all.

For example, a call from Alice gets into a queue and gets answered by Bob. Bob parks the call and gets removed from the bridge. After that, Charlie picks up the parked call and talks to Alice normally. During this call, the status of Bob is “In Use” which doesn’t allow him to get new calls. Only when the call between Alice and Charlie ends does Bob become available again.

Would anyone know if this is something that can be changed so that Bob’s status in the queue after parking a call can be set back to “Not in use”?

Thanks in advance,

Andres

jcolp · June 26, 2017, 10:03am

You’ll need to provide your configuration and the actual output of “queue show”. I’d also suggest trying the 13 branch as a fix went in[1] for problems where members could be considered in call during certain scenarios.

[1] http://blogs.asterisk.org/2017/06/07/app_queue-case-call-agent/

david551 · June 26, 2017, 10:05am

For reasons that are lost in history, but might be related to this, we interposed a local channel between the caller an the queue and parked the incoming side of the local channel. This is with Asterisk 1.4 and 1.6, and it was a work around applied during early prototyping, before I got involved, so I never got to really understand why it was needed, or even whether it was still needed in 1.6 onwards.

amiedzow · June 27, 2017, 8:45am

Thank you for the response jcolp and david551.

My configuration is the following:

extenensions.conf

include => parkedcalls

[myqueue]
exten => s,1,Verbose(“Entering the Queue”)
same => n,Queue(myqueue,k,30)
same => n, Hangup()

queues.conf

[myqueue]
member => PJSIP/111,Agent Name

features.conf

[featuremap]
parkcall => #7

res_parking.conf

[default]
parkext => 700
parkpos => 701-705
context => parkedcalls
parkingtime => 120

In regards to the fix mentioned, I looked for the ASTERISK-26975 patch in the recent change logs and it’s not showing up. Is it already available? If so, in which version?

Regards,

Andres

jcolp · June 27, 2017, 9:01am

It will be available in the next release. You also did not provide the output of “queue show” as I mentioned.

amiedzow · June 27, 2017, 9:22am

sorry about that. Here’s the queue status before getting a call:

myqueue has 0 calls (max unlimited) in ‘rrmemory’ strategy (8s holdtime, 483s talktime), W:0, C:56, A:1, SL:0.0% within 0s
Members:
Agent Name (PJSIP/111 from PJSIP/111) with penalty 20 (ringinuse disabled) (dynamic) (Not in use) has taken no calls yet

This is how it looks during the call:

myqueue has 0 calls (max unlimited) in ‘rrmemory’ strategy (6s holdtime, 483s talktime), W:0, C:56, A:1, SL:0.0% within 0s
Members:
gent Name (PJSIP/111 from PJSIP/111) with penalty 20 (ringinuse disabled) (dynamic) (in call) (In use) has taken no calls yet

This is how it looks like after the call is parked and picked up by another extension:

myqueue has 0 calls (max unlimited) in ‘rrmemory’ strategy (6s holdtime, 483s talktime), W:0, C:56, A:1, SL:0.0% within 0s
Members:
Agent Name (PJSIP/111 from PJSIP/111) with penalty 20 (ringinuse disabled) (dynamic) (in call) (In use) has taken no calls yet

jcolp · June 27, 2017, 9:26am

I would also suggest providing console output showing that… as even the device state itself is in use, which means the core thinks the device really is in use. Not just app_queue does.

amiedzow · June 27, 2017, 9:44am

Here’s the log. I’m not sure if I need to increase the verbosity level:

[Jun 27 19:17:35] VERBOSE[8822][C-000000f0] pbx.c: Executing [s@myqueue:1] Verbose(“PJSIP/112-000001a7”, ““Entering the Queue””) in new stack
[Jun 27 19:17:35] VERBOSE[8822][C-000000f0] app_verbose.c: Entering the Queue
[Jun 27 19:17:39] VERBOSE[8822][C-000000f0] pbx.c: Executing [s@support_queue:2] Queue(“PJSIP/112-000001a7”, “myqueue,k,30”) in new stack
[Jun 27 19:17:39] VERBOSE[8822][C-000000f0] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘PJSIP/112-000001a7’
[Jun 27 19:17:39] VERBOSE[8822][C-000000f0] app_queue.c: Called PJSIP/111
[Jun 27 19:17:39] VERBOSE[8822][C-000000f0] app_queue.c: PJSIP/111-000001a8 is ringing
[Jun 27 19:17:40] VERBOSE[8822][C-000000f0] app_queue.c: PJSIP/111-000001a8 answered PJSIP/112-000001a7
[Jun 27 19:17:40] VERBOSE[8822][C-000000f0] res_musiconhold.c: Stopped music on hold on PJSIP/686-000001a7
[Jun 27 19:17:40] VERBOSE[8824][C-000000f0] bridge_channel.c: Channel PJSIP/111-000001a8 joined ‘simple_bridge’ basic-bridge <9f61f4e3-2a6b-45d0-a60a-cb0d410431dd>
[Jun 27 19:17:40] VERBOSE[8822][C-000000f0] bridge_channel.c: Channel PJSIP/112-000001a7 joined ‘simple_bridge’ basic-bridge <9f61f4e3-2a6b-45d0-a60a-cb0d410431dd>
[Jun 27 19:17:41] VERBOSE[8824][C-000000f0] res_rtp_asterisk.c: 0x7ffa08044870 – Probation passed - setting RTP source address to 192.168.0.111:16502
[Jun 27 19:17:57] VERBOSE[8822][C-000000f0] bridge_channel.c: Channel PJSIP/112-000001a7 left ‘simple_bridge’ basic-bridge <9f61f4e3-2a6b-45d0-a60a-cb0d410431dd>
[Jun 27 19:17:57] VERBOSE[8822][C-000000f0] parking/parking_bridge.c: Parking ‘PJSIP/112-000001a7’ in ‘default’ at space 701
[Jun 27 19:17:57] VERBOSE[8822][C-000000f0] bridge_channel.c: Channel PJSIP/112-000001a7 joined ‘holding_bridge’ parking-bridge <5c870e2e-3ff6-420b-9f1b-cd2f73d708b1>
[Jun 27 19:17:57] VERBOSE[8822][C-000000f0] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘PJSIP/112-000001a7’
[Jun 27 19:17:57] VERBOSE[8824][C-000000f0] file.c: <PJSIP/112-000001a8> Playing ‘digits/7.g722’ (language ‘en’)
[Jun 27 19:17:58] VERBOSE[8824][C-000000f0] file.c: <PJSIP/112-000001a8> Playing ‘digits/0.g722’ (language ‘en’)
[Jun 27 19:17:58] VERBOSE[8824][C-000000f0] file.c: <PJSIP/112-000001a8> Playing ‘digits/1.g722’ (language ‘en’)
[Jun 27 19:17:59] VERBOSE[8824][C-000000f0] bridge_channel.c: Channel PJSIP/111-000001a8 left ‘simple_bridge’ basic-bridge <9f61f4e3-2a6b-45d0-a60a-cb0d410431dd>
[Jun 27 19:18:53] VERBOSE[8840][C-000000f1] pbx.c: Executing [701@support:1] ParkedCall(“PJSIP/113-000001a9”, “default,701”) in new stack
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] res_rtp_asterisk.c: 0x7ffa80013ee0 – Probation passed - setting RTP source address to 192.168.0.113:16494
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge_channel.c: Channel PJSIP/112-000001a7 left ‘holding_bridge’ parking-bridge <5c870e2e-3ff6-420b-9f1b-cd2f73d708b1>
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] res_musiconhold.c: Stopped music on hold on PJSIP/112-000001a7
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge_channel.c: Channel PJSIP/112-000001a7 joined ‘simple_bridge’ basic-bridge <99014bea-6430-4b95-81a9-2833024c0379>
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge_channel.c: Channel PJSIP/113-000001a9 joined ‘simple_bridge’ basic-bridge <99014bea-6430-4b95-81a9-2833024c0379>
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge.c: Bridge 99014bea-6430-4b95-81a9-2833024c0379: switching from simple_bridge technology to native_rtp
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge_native_rtp.c: Locally RTP bridged ‘PJSIP/113-000001a9’ and ‘PJSIP/112-000001a7’ in stack
[Jun 27 19:18:54] VERBOSE[8840][C-000000f1] bridge_native_rtp.c: Locally RTP bridged ‘PJSIP/113-000001a9’ and ‘PJSIP/112-000001a7’ in stack
[Jun 27 19:19:35] VERBOSE[8840][C-000000f1] bridge_channel.c: Channel PJSIP/113-000001a9 left ‘native_rtp’ basic-bridge <99014bea-6430-4b95-81a9-2833024c0379>
[Jun 27 19:19:35] VERBOSE[8840][C-000000f1] pbx.c: Spawn extension (support, 701, 1) exited non-zero on ‘PJSIP/113-000001a9’
[Jun 27 19:19:35] VERBOSE[8822][C-000000f0] bridge_channel.c: Channel PJSIP/112-000001a7 left ‘native_rtp’ basic-bridge <99014bea-6430-4b95-81a9-2833024c0379>
[Jun 27 19:19:35] VERBOSE[8822][C-000000f0] pbx.c: Spawn extension (support_queue, s, 7) exited non-zero on ‘PJSIP/112-000001a7’

jcolp · June 27, 2017, 9:45am

What does “core show channels” show afterwards and what Asterisk version are you using?

amiedzow · June 27, 2017, 10:07am

This is how it looks like before the call is parked:

Channel Location State Application(Data)
PJSIP/112-000001a7 s@myqueue:2 Up Queue(myqueue,k,30)
PJSIP/111-000001a8 s@support:1 Up AppQueue((Outgoing Line))

It looks the same after it’s parked and this is how it looks like after the call is picked up by another agent:

Channel Location State Application(Data)
PJSIP/113-000001a9 701@support:1 Up ParkedCall(default,701)
PJSIP/112-000001a7 s@myqueue:2 Up Queue(myqueue,k,30)
PJSIP/111-000001a8 s@support:1 Up AppQueue((Outgoing Line))

The Asterisk version is 13.12.2

jcolp · June 27, 2017, 10:11am

The channel still appears to be active, which is why it is doing what it is doing - that is the problem. Your version is almost 8 months old so the problem may have been fixed since then.

amiedzow · June 27, 2017, 10:13am

thanks jcolp. Do you know which version might have the fix (maybe a bug or issue number that you can provide me) or if I need to wait for the future release that solves ASTERISK-26975?

jcolp · June 27, 2017, 10:39am

I don’t know any off the top of my head. Your problem is unrelated to ASTERISK-26975.

amiedzow · August 15, 2017, 4:58am

Hi all,

I just upgraded my Asterisk lab to version 13.17 as suggested but I’m still having the same issue: the queue member that parks a call remains in the “In Use” state and stays that way until the calling party hangs up.

Any ideas will be greatly appreciated.

jcolp · August 15, 2017, 9:50am

All the cases that were previously reported that were having in use problems were resolved with the latest change. If you are still experiencing it then you need to provide updated output with the latest version, as it will help narrow things down with the latest code.

amiedzow · August 20, 2017, 1:29am

Here are the new tests using version 13.17.0. Extension 681 calls the queue and it’s picked up by extension 687. The call is then parked by 687 and picked up by extension 689.

My configuration is the following:

extenensions.conf

include => parkedcalls

[myqueue]
exten => s,1,Verbose(“Entering the Queue”)
same => n,Queue(myqueue,k,30)
same => n, Hangup()

queues.conf

[myqueue]
member => PJSIP/111,Agent Name

features.conf

[featuremap]
parkcall => #7

res_parking.conf

[default]
parkext => 700
parkpos => 701-705
context => parkedcalls
parkingtime => 120

Before placing the call:

asterisk-lab*CLI> queue show test
test has 0 calls (max unlimited) in ‘ringall’ strategy (0s holdtime, 52s talktime), W:0, C:7, A:0, SL:14.3% within 0s
Members:
PJSIP/687 (ringinuse enabled) (Not in use) has taken 5 calls (last was 121 secs ago)
No Callers

asterisk-lab*CLI> parking show

Parking General Options
Dynamic Parking : no