Unable to receive new calls after internal or external transfer


(Angie Angie) #1

Hi,

Since a couple of months we have an issue regarding incoming calls after a transfer. When we receive a call and transfer it to an internal or external number, the original line goes to ‘busy’ and the agent that transferred the call cannot receive any new call, even though it is free and waiting. That is only possible when the transferred call is hung up.

I have found a similar issue on this platform “unable-to-dial-out-after-transferring-a-call” but it does not have a solution.

Could you help? Thank you in advance.


(David55) #2

This is a long standing feature of the Asterisk queue implementation.

My company got round it by putting a local channel ahead of the queue, and transferring that. However we never used FreePBX and I don’t know how easy that is to adapt for FreePBX.

I believe this is true for native SIP transfers, native DAHDI transfers and features transfers, however that is not generally true of all transfer related behaviour, so you really need to say how you are transferring, when asking questions about transfers.


(Angie Angie) #3

Thank you David. Could you tell me which information is needed to find a solution to our problem?
In other words: How can I describe how the transferring is being done in a way so it is clear what we work with?


(David55) #4

I don’t think the transfer method actually affects the way Queue behaves, which, I believe, is due to how it manipulates in use flags, and that it is not aware that the outgoing side channel has been transferred.

However the ways I know of doing an attended transfer are:

Sending the transfer feature code as DTMF.

I’ll leave it to others to say whether the local channel solution can be adapted to FreePBX, or whether there are other soluitions.
Native SIP transfer: start a new call and then doing INVITE with replaces, to one or other of the original or the new party - this will be the built in attended transfer option on SIP phones.

Native DAHDI analogue transfer: send recall signal. As I have never used DAHDI with Asterisk I’m not sure which of earth recall, hook flash, and the, shorter, timed break, recall are supported, followed by the new destination.

In addition, SIP unattended transfers can be done by using the SIP REFER method, or by running the SIP attended transfer process and completing it automatically.


(Angie Angie) #5

Okay, that could be.

I am curious to hear from others that have the same issue and have a solution for the same setup we have.
Regarding the software, we are not using DAHDI, we use PSTN cards, we have one trunk setup.

We would like to know how to close the channel after the transfer has been made.


#6

If you are using PSTN cards but not DAHDI, how are the calls arriving in your PBX?

Of what nature are the PSTN lines attached to your cards?


(David55) #7

You need to close down the queue application. With native transfers, that will disconnect the caller. The only way I know of avoiding it is to do the transfer, upstream of the queue application, using a local channel. That should be possible with clever use of features, although I don’t know how to do this in FreePBX with a minimal impact.

When I was involved with this, we used AMI to initiate the transfers.


(Lorne Gaetz) #8

What version of Asterisk? From what I recall, the issue with queue agents remaining inuse after transferring calls was resolved a long time ago.


(Angie Angie) #9

@dicko Sorry, I was wrong. We use SIP, not PSTN.
@Igaetz: The “funny” thing is that is used to work, but there were no changed made.

PBX Version: 15.0.17.43
PBX Distro: 12.7.8-2107-3.sng7
Asterisk Version: 16.15.1

I hope this helps!


(Communication Technologies) #10

FreePBX 15.0.17.4
Asterisk 16.13.0
Queues 15.0.33

Transfer (attended/blind) work (agent can take next call) as long as call confirmation is off.


(Itzik) #11

AFAIK, the issue was resolved when using agents that the queue can monitor their device state. You are using external phone numbers.


(Angie Angie) #12

Thanks for both for the input. It might be my knowledge about the subject, but I cannot see what the solution for this problem is at the moment.

What I read from both last answers, is that it is a setting only? Is that correct?


(David55) #13

What I understood from those answers is that the problem has been resolved where the agent is on a (local) extension, but not when they are remote, and that your situation falls into the latter category. In that case you need rather more than a simple setting to work round it.


(Communication Technologies) #14

If you are using external numbers for the agent, you can receive, transfer (using the feature codes) and get the next call by using a custom extension for each agent and changing the dial string to:

local/[CellPhoneNumber]@from-internal

This creates a local extension that is tied to a remote number.

There is a big caveat here in that you cannot turn on call confirm. If you turn on call confirm, when you transfer the call, the transfer to party will also receive the call confirm prompt, but no matter how fast you confirm, they will receive the message that the call is no longer available, thus breaking transfers (blind or attended).

We have spent months trying all sorts of combinations to attempt to get remote agents (via PSTN) the ability to have transfer and call confirm to no avail. I have opened a feature request (View Ticket: #984743), but the likelihood of any action being taken here is extremely low (there are many competing priorities).

A better option, if possible, is to use a softphone on the cell phones/remote computers. This can add overhead to provisioning, but, to my knowledge, is the only way to get everything to work as intended.

A final hailmary might be to look at FusionPBX. I asked a similar question on the forum over there and there seems to be consensus that you can do what your looking for without compromise on that platform. I did try this myself.


(Angie Angie) #15

Thank you so much for thinking with me. The suggestions could be very helpful, so we will try.
Maybe it is good to know that we are (already) using Bria (softphone version 5.7.1. Build 100929). Does that affect any of your suggestions? In other words, do we need to look at other options?


(Communication Technologies) #16

If you are using Bria and the extensions are registered to the same FreePBX box, you shouldn’t need to do anything, it should just work.

What is Skip Busy Agents set to on the queue settings?


(Angie Angie) #17

We hoped it would work, but it does not. It did work before, but we have no idea why and when it changed exactly.

The Skip Busy Agents is set to: Yes + (ringinuse=no)
Is this the right setting for this issue?


(Communication Technologies) #18

When set to ‘Yes’ agents who are on an occupied phone will be skipped as if the line were returning busy. This means that Call Waiting or multi-line phones will not be presented with the call and in the various hunt style ring strategies, the next agent will be attempted.

When set to ‘Yes + (ringinuse=no)’ the queue configuration flag ‘ringinuse=no’ is set for this queue in addition to the phone’s device status being monitored. This results in the queue tracking remote agents (agents who are a remote PSTN phone, called through Follow-Me, and other means) as well as PBX connected agents, so the queue will not attempt to send another call if they are already on a call from any queue.

I would think you would just need Yes if the extensions are all local (meaning you are taking the call for a registered endpoint), but I would think either would work.

What version of the queues module are you using?


(Angie Angie) #19

The queues is 15.0.33


(Communication Technologies) #20

That is the same as me. I am not sure what the issue is as I can confirm it is working for me.