It’s time for a Halloween-edition tutorial 🎃 - and what’s spookier 👻 than understanding Asterisk call transfers and how they impact QueueMetrics’ call tracking? 🦇 Scary stuff indeed!

Q: How does QueueMetrics handle transferred calls?

QueueMetrics tracks calls that are within the queue system. If a call leaves the queue system (e.g., transferred directly to an extension), QueueMetrics considers the call as “ended by transfer.” In some cases, QueueMetrics can indicate the extension to which the call was transferred (e.g., extension 500 or “bridged”), but usually, it just marks the call as terminated.

If you want to see what QM is “seeing”, try looking at the queue_log file and initiate a transfer. What you see there, is the data QM receives from you. What is not there, QM cannot display. 👻

Q: What happens when agents transfer calls to other callers or queues?

If agents on a queue transfer calls to other extensions or other queues, QueueMetrics may not report this correctly - that is, the call may appear as ongoing, or the destination call may not be visible. Additionally, an agent might still appear as busy (while they are actually idle) after the transfer, until the transferred call is over. This behavior is by design (in Asterisk) due to limitations in how the Attended transfer button works, as the PBX is not notified that the call has been “handed-over.” Consequently, QueueMetrics still considers the original agent to be connected to the call. You want to avoid at all costs that an agent is seen by Asterisk as “busy” while they are sitting idle, and there are unanswered calls in the queue they are serving.

What you can actually do about it:

  • use a different transfer method (see below)
  • use a different kind of channel for the agent - using a native PJSIP or SIP device is usually the best option.

Q: How does the use of local channels affect transferred calls?

If agents use non-optimizing local channels ending in /n (e.g., when they have multiple phones such as a desk phone and a softphone like Zulu, so you cannot simply point to a specific device), Asterisk may also not correctly track the agent’s state after a blind transfer. This is because local channels create additional complexity in determining whether an agent is in use or not.

In such cases, removing the /n at the end of the local channel - that is, turning it into an optimizable local channel - might help. If it does, you may then find out that the queue won’t find out correctly when an agent is busy and try ringing him at all times. This can be fixed by specifying the state interface as hint:${num}@ext-local, Asterisk can correctly track the agent state, ensuring that QueueMetrics is properly updated when an agent becomes available.

Setting the state interface

In cases where local channels are involved, if the QueueMetrics system is set with the system parameter platform.pbx=DIRECTAMI, adding the state interface as hint:${num}@ext-local can be effective in helping QueueMetrics track the agent status correctly.

For example, a complete setting might be like the following one:

platform.directami.stateinterface=hint:${num}@ext-local

Q: What is the difference between Attended and Unattended transfers?

  • Attended Transfer from a phone: When an agent uses the Attended transfer button to transfer a call, the PBX is not notified that the call has been “handed-over.” Therefore, QueueMetrics might still see the agent as connected to the call. The system’s design limits QueueMetrics from accurately tracking these events when an agent initiates an Attended transfer using the phone’s built-in function. The official Asterisk documentation notes that “transfers performed by SIP UA’s by way of a reinvite may not always be caught by Asterisk […] The only way to be 100% sure that you will get this event when a transfer is performed by a queue member is to use the built-in transfer functionality of Asterisk.” . This applies to all phones - physical phones, softphones, and even QueueMetrics’s own WebRTC phone - and to all kinds of transfer.
  • Transfers initiated with a Feature code: it is possible to set up specific features codes to initiate and handle attended and unattended transfers. You can usually program those as a “hot button” on your phone so that the agent does not need to remember them. These will generally - but not always - be seen by the Queue app.
  • Unattended Transfers by the Queue app: The only reliable way to ensure that the PBX properly notifies QueueMetrics of a transfer is to use an Unattended transfer. This involves setting the lowercase t option in the queue and having the agent press # to start a transfer to a different extension. Unfortunately, this does not allow the agent to speak to the receiver before transferring the call, which is a feature available in Attended transfers. See

What is a practical workaround for this limitation?

A real-life workaround involves using Asterisk’s “#” unattended transfer as performed by the Queue app. Agents initiate this only after having opened a parallel conversation to negotiate with the receiver. Although this approach is sub-optimal and lacks the ability to provide a true attended transfer, it has been shown to work effectively in practice.

Q: I am able to see transfers, but I want to keep seeing the call after a transfer, even if it’s not on a queue

Glad to see that you made it so far! You have two approaches here:

  • the first is enabling Outbound Tracking, either through the Uniloader or by the dial-plan. The idea here is that complete call records are written to the queue_log file as-if the call was a call on a queue.
  • the second is to create what we call Personal queues. A personal queue is a queue that only contains one agent, and for which the agent is always a member. For example, you could have your queue 9101 that only contains agent 101, 9102 for agent 102 and so on. When you need to transfer a call personally to them (say to agent 101), you do an unattended transfer to #9101 - and the call is queued until it reaches him. This way, the call is an actual call on a queue, so there are full logs, and you can run normal QM reports, see it on the wallboards, etc.

References

Happy Halloween! 🎃

About QueueMetrics

QueueMetrics is a highly scalable monitoring software that lets you track agent productivity, payrolls, measure targets, conversion rates, queues/ACDs, IVRs, music-on-hold, generate outbound campaign statistics and monitor realtime processes with customizable wallboards.

You can measure all activities in your contact center with more than 200 different metrics and manage realtime processes with live alarms and full control on calls and extensions, including whisper, spy and barge modes.

QueueMetrics is available on premise or as a cloud hosted service, and it is compatible with FreePBX, Grandstream, Issabel, MiRTA, Enswitch, Yeastar S PBX, VitalPBX, FusionPBX and many other Asterisk- and Freeswitch-based systems. It also supports Microsoft Teams telephony.

For more technical information please refer to the User Manual.

Visit www.queuemetrics.com for a free 15-day full-featured trial.

keyboard_arrow_left Back