Asterisk Call Transfer does not release channels

cpaguio · February 17, 2015, 10:26pm

FreePBX version: 12.0.37
Asterisk version: 11.15.1

Call flow:
a) Caller (PSTN) --> Cisco CUCM --> Asterisk --> Queue1 --> Cisco CUCM --> Agent1
b) Agent1 --> atxfer (#) --> Asterisk --> Queue2 --> Cisco CUCM --> Agent2

In call flow (a), customer call from PSTN arrives in queue1 and answered by agent1 correctly. Agent1 initiates an attended transfer by pressing # key shown in call flow (b). The transfer goes to queue2 and answered by Agent2. Agent1 hangs-up to complete call transfer. At this point, caller should be connected directly to Agent2, but “show channels” command displays Agent1 as still in the call path. This makes Agent1 show up as in-use even if it was transferred already. Only when the call between Caller and Agent2 ends will Agent1’s status be free.

Agents have Cisco 79XX phones, which are registered to Cisco CUCM. Agents login to queues as Local/XXXXX/n (with no release modifier).

This same scenario works with our old Asterisk setup.
FreePBX version: 2.8.0
Asterisk version: 1.6.2.12

Tried adding the /bn to the local channel, but that did not release Agent1 out of the call path after the transfer.

Appreciate if anyone can help clarify this issue.

cpaguio · February 18, 2015, 4:20pm

Other observations that I have found so far.

(1) Compared the transfer (atxfer) behavior between the new Asterisk 11.15.1 and the old Asterisk 1.6.2.12. Both versions have 2 call legs. The first leg is the call from the Caller to Agent1. The second leg is the transfer between Agent1 (92059) and Agent2 (93608).

When the transfer is initiated via atxfer in the new Asterisk setup, a separate channel is created on Agent1 side of leg 2, which keeps Agent1 (92059) in call path.

Leg1: Caller (SIP/cucm-00000060 -> Local/92059@from-queue) —> (Local/92059@from-queue -> Local/400@from-internal)

Leg2: (Local/92059@from-queue -> Local/400@from-internal) —> (Local/400@from-internal -> Local/93608@from-queue -> SIP/cucm-00000062)

When the transfer is initiated via atxfer in the old Asterisk setup, a separate channel is created on Caller side of leg 1, which keeps agent1 out of the call path.

Leg1: Caller (SIP/cucm-00000060 -> Local/400@from-internal) —> (Local/400@from-internal -> Local/93608@from-queue)

Leg2: (Local/400@from-internal -> Local/93608@from-queue) —> (Local/93608@from-queue -> SIP/cucm-00000062)

(2) Tried removing /n when adding agents to queues. So from Local/92059@from-queue/n to Local92059@from-queue. This removed the Local/92059@from-queue channels in between the call legs and allowed the transfer (atxfer) to work, but now we do not have state information for call barge, agent use state, or other queue functions.

(3) Tried adding /b when adding agents, which should make the local channel return the actual channel behind during transfers. So from Local/92059@from-queue/n to Local92059@from-queue/bn. Agent state exists, but transfers (atxfer) still does not work as expected.

(4) Aside from Attended Transfer (atxfer), tried doing a Blind Transfer (blindxfer) with the same behavior. The initiating transfer agent remains in call path.

penguinpbx · February 18, 2015, 11:06pm

It sounds like this might (also) be a bug in the FreePBX generated dialplan ie. not Asterisk. Although your setup is quite complicated.

You might want to consider additional dialplan configuration to intercept the transfer, possibly with the ChannelRedirect() application and some DumpChan() statements so you know what variables to grab and what channels to send somewhere else.

cpaguio · February 20, 2015, 5:09pm

It looks like it is an issue of Asterisk. Tried it on a vanilla 11.16.0 asterisk version (without FreePBX) and the same issue still occurs. It must be something with the native transfers (atxfer, blindxfer) that has changed since 1.6.2.12. Checked also with Asterisk 1.8.32 and it also happens with this version. Multiple transfer bug fixes are seen in the changelog after 1.6.2.12, so not sure which one changed the behavior.

In the meantime, I have been tinkering with a custom transfer via features applicationmap. Can anyone help with a dialplan for a standard attended transfer?

cpaguio · February 20, 2015, 11:34pm

Noticed a difference between the asterisk versions when using (atxfer).

Call flow description:

Caller is connected to Agent1 (Local/92059) without optimization. Four channels and two active calls for this first connection.

Caller (SIP/cucm-0000005b) <—> Local/92059@from-queue-00000056;1 <—> Local/92059@from-queue-00000056;2 <—> Agent1 (SIP/cucm-0000005c)

Agent1 initiates attended transfer (atxfer) by pressing # key.

In version 11.16.0, code level debugs when initiating atxfer are shown below.

[ul][2015-02-20 16:23:50] DEBUG[4585][C-00000050] channel.c: Got DTMF begin on channel (SIP/hqcm02-0000005c)
[2015-02-20 16:23:50] DEBUG[4585][C-00000050] channel.c: Bridge stops bridging channels Local/92059@from-queue-00000056;2 and SIP/hqcm02-0000005c
[2015-02-20 16:23:50] DEBUG[4585][C-00000050] features.c: Feature detected: fname=Attended Transfer sname=atxfer exten=#
[2015-02-20 16:23:50] DEBUG[4585][C-00000050] features.c: Executing Attended Transfer Local/92059@from-queue-00000056;2, SIP/hqcm02-0000005c (sense=2)[/ul]

The transfer is executed on Agent1’s side.

In version 1.6.2.12, code level debugs when initiating atxfer are shown below.

[ul][Feb 20 17:26:47] DEBUG[22710] channel.c: Got DTMF begin on channel (Local/92059@from-queue-00000056;1)
[Feb 20 17:26:47] DEBUG[22710] features.c: Feature detected: fname=Attended Transfer sname=atxfer exten=#
[Feb 20 17:26:47] DEBUG[22710] features.c: Executing Attended Transfer SIP/hqcm02-0000005b, Local/92059@from-queue-00000056;1 (sense=2)[/ul]

The transfer is executed on Caller’s side.

Does anyone know what could cause this difference in behavior?

drequena · April 15, 2015, 8:12am

I’m having exactly this very same issue.
Did you ever get a solution or workaround for this?

TIA

cpaguio · April 15, 2015, 2:05pm

[quote=“drequena”]I’m having exactly this very same issue.
Did you ever get a solution or workaround for this?

TIA[/quote]

No resolution or workaround on this for now. Not even support from FreePBX was helpful. We stopped this upgrade project as a result. Looking into other alternatives instead.

drequena · April 22, 2015, 7:53pm

Well, I got a little bit further and found that that’s what state_interface is for. Please check http://bahjons.com/stuff/solvingtransferring-calls-from-queues-agents-stay-busy

Unfortunately this only seems to work for ‘locally’ registered agents. Both you and my scenario have agents registered at a remote peer and as soon as you set state_interface to SIP/ext@peerip on agent registering said agent gets flagged as in invalid status.

There’re a couple venues I’m researching with low expectations at the moment. Any ideas would be greatly welcome at this point.

drequena · June 15, 2015, 10:40am

This seems to be caused by CUCME itself optimizing the transfer and not sending proper SIP messages to Asterisk. Certainly nothing is received at Asterisk’s end from transfer beginning up until original call hangup.

Next best solution: we’ve been able to somewhat solve this issue by using Asterisk’s own built-in transfer mechanism (features.conf).

Only issue is you have to fiddle with callerid on some TRANSFER CONTEXT as Asterisk seems to be transferring the original channel. In our case we were getting the one from an IVR entry point.

Hope that helps.