Platform: PBX Actions

Each action driver allows a distinct set of features to be switched on, so not all actions are supported by all drivers.

Even when an action is supported an allowed by adriver, it is possible to disable it by setting the relevant property to false, like in:

platform.allows.addmember=false

If no property is set, or it is set to true, then the property will be shown if the underlying driver supports it.

A complete list of allowed actions that can be switched off on-demand can be found at Configuration properties for Platforms.

DirectAMI actions

In DirectAMI mode, actions performed on the PBX do not require a piece of dial-plan to be included; QueueMetrics will connect directly to the AMI port of your Asterisk system (as determined by callfile.dir and its cluster.*.manager equivalents in cluster mode) and will perform the actions you require.

This mode is slightly less flexible than the dialplan-based Classic mode, but:

  • It is way easier to set up, as you just need to specify once the channel formats for your PBX

  • It is more efficient when you need to join or leave multiple queues, as actions are batched into a single transaction

Tracking outbound

As it is not currently possible to originate outbound calls tracked by QueueMetrics without using the dialplan, if you need to do manual outbound you still need to include the custom ''extensions_queuemetrics.conf'' dialplan; QueueMetrics will then dial extension '28@queuemetrics' for manual outbound dialing.

Since Uniloader 0.4, it is possible to track outbound calls made by QueueMetrics without using the dialplan if you have outbound tracking enabled. This feature is not turned on by default and has to be set manually. This feature is at the moment experimental.

Outbound dialing is turned off by default and must be turned on manually if needed.

Configuration

To turn it on you need to set:

  • platform.pbx to DIRECTAMI

The following configuration options are available:

  • platform.directami.verbose whether to dump all AMI interactions to the system log (default: false)

  • platform.directami.agent the way an agent channel is supposed to be (default: "Agent/${num}")

  • platform.directami.extension the way an agent extension channel is supposed to be (default: "SIP/${num}")

  • platform.directami.localext the channel used for chanspy (default: "Local/${num}@from-internal")

  • platform.directami.transfer the transfer destination, in the form 'ext@context' (default: "${num}@from-internal")

  • platform.directami.outbound.enabled whether outbound dialing, though dialplan or Uniloader, is enabled (Default: false)

  • platform.directami.outbound.stanza the point in the dialplan that should be called when doing outbound (Default: "28@queuemetrics")

  • platform.directami.outbound.usetracker will use the Uniloader to track outbound call. (Deafult: false)

  • platform.directami.outbound.trackerdialout the point in the dial-plan that will be used to generate outbound calls with the Uniloader (Default: "${num}@from-internal")

  • platform.directami.spyoptions the additional options you want to use for the Asterisk application ChanSpy when listening to calls (Default: ""). By changing these options, you can have extra parameters added. The main "kind" of option ('b' for spy, 'w' for whisper or 'B' for barge) is added automatically depending on the kind of spying required.

  • platform.directami.cmdseparator the separator used for parameters in your Asterisk version. Defaults to comma (",") and should be changed to pipe ("|") only for very old Asterisk systems (pre-1.8)

  • platform.directami.optimizedagentchannel is the format of the agent channel when it is live and you want to spy on it. If blank, uses the same physical agent channel, based on the agent code or the extension code depending on whether you are in hotdesking mode or not. Defaults to blank. Please note that the ${num} variable may contain the full agent name including its technology (e.g. "SIP/1234"), so you may want to use ${num:s} to include only the numeric part.

  • platform.directami.stateinterface is the interface to get the agent state from. This is useful when adding Local channels, where Asterisk is not aware whether they are in conversation or not. By specifying a SIP device, Asterisk can always know its correct state and act accordingly. If not specified, it is simply not sent to the queue.

In all channel configuration, the string ${num} is replaced with the local agent code or extension, as appropriate. When adding or removing members from a queue, the string ${queue} is expanded to the identifier of the current queue. Both placeholders accept a suffix syntax like ${num:3} to include the string without the first three characters, ${num:s} to capture what comes after the slash (if present) and ${num:p} to capture what comes before the slash.

When running in cluster mode, you can have configuration that is specific for one single cluster member and it will override the general one - see Defining system properties for members of a cluster.

Examples

Example for a FreePBX system running without hotdesking enabled. The agent is logged on to the queue as "Local/XXX@from-internal", that is rewritten by QueueMetrics as "Agent/XXX", and matches a SIP extension with the same code. We specify a StateInterface so the queue is always aware of the state of the agent’s phone.

default.hotdesking=0

platform.pbx=DIRECTAMI
platform.directami.agent=Local/${num}@from-internal
platform.directami.transfer=${num}@from-internal
platform.directami.outbound.enabled=true
platform.directami.localext=Local/${num}@from-internal
platform.directami.optimizedagentchannel=SIP/${num:s}
platform.directami.stateinterface=SIP/${num}
platform.directami.verbose=false

This is an example for a FreePBX system running with hotdesking enabled. The agent is logged on to the queue as "SIP/YYY" but appears in QM as "Agent/XXX" and a proper hotdesking record is written to match the two entities.

default.hotdesking=86400

platform.pbx=DIRECTAMI
platform.directami.agent=Agent/${num}
platform.directami.extension=SIP/${num}
platform.directami.transfer=${num}@from-internal
platform.directami.outbound.enabled=true
platform.directami.localext=SIP/${num:s}
platform.directami.verbose=false

This is an example for a FreePBX system running with hotdesking enabled but without dialplan. Uniloader must be running in "tracker" mode with "outbound" enabled.

default.hotdesking=86400

platform.pbx=DIRECTAMI
platform.directami.agent=Agent/${num}
platform.directami.extension=SIP/${num}
platform.directami.transfer=${num}@from-internal
platform.directami.outbound.enabled=true
platform.directami.outbound.usetracker=true
platform.directami.outbound.trackerdialout=${num}@from-internal
platform.directami.localext=SIP/${num}
platform.directami.verbose=false

Some Notes on Spying

When spying, QueueMetrics always tries to connect the supervisor to the agent’s channel. If the live agent channel appears under a different name from the one used to create it (e.g. if the agent channel was a Local/XXX@ctxt that has been optimized to SIP/XXX), then you need to supply the parameter platform.directami.optimizedagentchannel in order to let QueueMetrics find the correct agent channel to spy on.

When spying, you can try different settings of platform.directami.spyoptions to configure additional behavior. The following options are added automatically:

  • b (spy): Supervisor is able to listen to the on-going call, but cannot talk. This is the default.

  • w (whisper): Supervisor is able to listen to the on-going call and can talk to the agent; caller does not hear supervisor.

  • B (barge): Supervisor is able to listen and speak to all parties on the on-going call

DirectAMI Live actions

In DirectAMI Live, DirectAMI calls are not performed immediately but stored on the AMI queue and then performed by Uniloader on the receiving server. This means you can have the advantages of DirectAMI (no dialplan included for most use cases) on remote systems where actions are proxied by Uniloader.

To inspect the status of commands being sent to the remote system, see Checking the AMI Queue.

Configuration

To turn it on you need to set:

  • platform.pbx to DIRECTAMI_LIVE

All other configuration options are the same as DIRECTAMI.

Classic PBX Actions

This is the default platform for QueueMetrics and it is able to perform all QueueMetrics interactions to the PBX. Actions are executing by calling the 'extensions_queuemetrics.conf' dial-plan, that must be available on the target machine.

Depending on the target PBX, you may need to edit the supplied dialplan to use it.

Configuration

To turn it on you need to set:

  • platform.pbx to CLASSIC (or just leave blank).

Available actions are controlled in configuration.properties by setting:

  • default.hotdesking to a number > 0 to enable hotdesking

Each action is controlled by a stanza in configuration.properties, for example to set call outcomes:

callfile.calloutcome.enabled=true
callfile.calloutcome.channel=Local/12@queuemetrics/n
callfile.calloutcome.extension=10
callfile.calloutcome.context=queuemetrics

More details are availble in Enabling Agent’s page actions.

QMLive PBX Actions

In this mode, actions are performed by queueing them and waiting for 'uniloader' to fetch and perform them. Actions are expressed as calls to the 'queuemetrics' dialplan, that needs to be available on the target PBX.

This platform is used in QueueMetrics Live to allow remote actions.

To inspect the status of commands being sent to the remote system, see Checking the AMI Queue.

Configuration

To turn it on you need to set:

  • platform.pbx to CLASSIC_LIVE

  • or set default.webloaderpbx to 'true' in Classic mode

Freeswitch actions

With the Freeswitch actions module, commands are sent to Freeswitch’s 'mod_callcenter' though the ESL API.

As in FusionPBX the id of 'mod_callcenter' agents is a UUID, it is important to configure all agents so that their UUID is set in the 'External reference' field. A list of agents with their UUIDs can be obtained by running uniloader pbxinfo fusionpbx.

The Freeswitch module will not enable any interactions if hotdesking is enabled.

Configuration

To turn it on you need to set:

  • platform.pbx to FREESWITCH

  • and make sure that:

    • your callfile.dir is set to fsw:ClueCon@127.0.0.1:8021, or whatever credentials you need for the Freeswitch ESL.

    • default.hotdesking=0

  • platform.freeswitch.addmember=true

  • platform.freeswitch.tenant is the domain name of the current tenant connected to this QM instance

  • platform.freeswitch.use_external_ref whether to use the agent’s own id or the "external reference" configured on the agent (default: true - use external reference)

  • platform.freeswitch.verbose whether to dump all interactions to the system log (default: false)

If you want to have agents perform manual outbound:

  • platform.freeswitch.agentChannel is the channel template to reach your agent, as specified in variable num. The id of the outbound queue is available as code q - for example to display it as the caller number when the agent phone rings. Make sure you set the FreeSwitch channel variable qm_queue to the ID of the outbound queue to be used for this call, otherwise it won’t work. If this attribute is left empty, manual outbund is disabled.

  • platform.freeswitch.destinationNumber is the number to be dialed, as specified in variable num. It is dialed as-if it was composed on the main dial-plan within the specified tenant.

The settings above only control manual outbound, that is the agent selecting an outbound queue and then entering a number manually (or using AMO to do the same thing). Automatic outbound, if needed, is performed automatically by Uniloader.

If you want to perform spy/whisper/barge:

  • platform.freeswitch.spychannel is the format of the channel to reach the supervisor who wants to attach to a given call. Variable num is the extension of the supervisor, q the queue on which the call being spied on currently is, and a the agent code.

  • platform.freeswitch.spycmd is the command to be executed when spychannel connects. The variable spymode stands for the correct code for application eaversdrop, while callid is the uniqueid of the call that is to be spied.

For this to work, you must make sure that you run Uniloader 24.11.3 or newer. If you run an earlier version, use the Earlier mode descibed below.

Examples

Example for a FusionPBX system running at address 192.168.7.5:

default.hotdesking=0
callfile.dir=fsw:ClueCon@192.168.7.5:8021

platform.pbx=FREESWITCH
platform.freeswitch.use_external_ref=true
platform.freeswitch.verbose=true
platform.freeswitch.addmember=true
platform.freeswitch.use_external_ref=true
platform.freeswitch.tenant=mytenant.myserver.com
platform.freeswitch.agentChannel={qm_queue=${q},origination_caller_id_number=1973,origination_caller_id_name=QM-${q},enable_early_media=true}user/${num}
platform.freeswitch.destinationNumber=${num}
platform.freeswitch.spychannel={qm_ignore=1,origination_caller_id_name=Spy_q${q}_q${a}}user/${num}
platform.freeswitch.spycmd=queue_dtmf:w${spymode}@500,eavesdrop:${callid}

  • On manual dial out, the agent’s phone will display "QM-123" if the call is being made on outbound campaign "123"

  • On chanspy, the agent’s phone will initially ring with caller-id "Spy_q123_a321", where 123 is the queue that holds the call being spied, and agent 321 the current connected agent.

  • To dial extension 1234, in both cases it will be dialled channel user/1234@mytenant.myserver.com

Configuration - earlier mode

At the moment, only actions for agent login, logoff and pause are supported. Also, as agent presence is unique and not related to specific queues, on the agent page only a "ALL" queue will be shown.

To turn it on you need to set:

  • platform.pbx to FREESWITCH

  • and make sure that your callfile.dir is set to fsw:ClueCon@127.0.0.1:8021, or whatever credentials you need for the Freeswitch ESL.

The following configuration options are available:

  • platform.freeswitch.use_external_ref whether to use the agent’s own id or the "external reference" configured on the agent (default: true - use external reference)

  • platform.freeswitch.verbose whether to dump all interactions to the system log (default: false)

The Freeswitch module will not enable any interactions if hotdesking is enabled.

Examples

Example for a FusionPBX system running at address 192.168.7.5:

default.hotdesking=0
callfile.dir=fsw:ClueCon@192.168.7.5:8021

platform.pbx=FREESWITCH
platform.freeswitch.use_external_ref=true
platform.freeswitch.verbose=true

Freeswitch Live actions

In Freeswitch Live, Freeswitch API calls are not performed immediately but stored on the AMI queue and then performed by Uniloader on the receiving server.

To inspect the status of commands being sent to the remote system, see Checking the AMI Queue.

Configuration

To turn it on you need to set:

  • platform.pbx to FREESWITCH_LIVE

All other configuration options are the same as FREESWITCH.

Examples

This example is for a system where Uniloader and Freeswitch are running on the same machine. Please note that the ESL address is relative to Uniloader.

default.hotdesking=0
callfile.dir=fsw:ClueCon@127.0.0.1:8021

platform.pbx=FREESWITCH
platform.freeswitch.use_external_ref=true
platform.freeswitch.verbose=true

JSON API Actions

This platform lets you control an arbitrary external system that implements a very simple JSON API. This way, QM can control any PBX system, and it is often used to interact with cloud providers that "abstract away" the specific PBX API.

For each interaction request, a simple JSON stanza like the one below is sent to an HTTP/s end-point you define as a parameter called cmd, using either HTTP POST or GET.

{
	"requestor": "Loway QueueMetrics 19.04.3",
	"token": "1234",
	"action": "ADDMEMBER",
	"login": "demoadmin",
	"serverId": "aleph",
	"agent": {
		"agentId": "101",
		"externalReference": null
	},
	"extension": "999",
	"targetExtension": null,
	"queues": [{
		"queueId": "111",
		"penalty": "UNKNOWN",
		"externalReference": null
	}, {
		"queueId": "112",
		"penalty": "UNKNOWN",
		"externalReference": null
	}],
	"callId": null,
	"message": null
}

QueueMetrics expects no specific answer to the call, as long as it succeeds with an HTTP status 200, as any requested action will be reflected in the queue_log data being uploaded.

For example, imagine an agent that wants to join a queue. They send a call for action ADDMEMBER with the correct details. As soon as the PBX processes the call, an ADDMEMBER event for the agent appears on the queue_log; at this point QueueMetrics updates the agent status to show that they joined the queue.

Configuration

An example configuration might be like the one below:

platform.pbx=JSONAPI
platform.jsonapi.url=https://api.your.pbx.com/yourendpoint/
platform.jsonapi.method=POST
platform.jsonapi.token=1234
platform.jsonapi.enabled=ADDMEMBER,REMOVEMEMBER,PAUSE,UNPAUSE
platform.jsonapi.verbose=true

The meaning is:

  • platform.jsonapi.url: is the URL end-point that will be called. Must be specified.

  • platform.jsonapi.method: either GET or POST (default: POST)

  • platform.jsonapi.token: a token used to identify the specific QueueMetrics instance. Default: empty.

  • platform.jsonapi.enabled: a comma-separated list of which actions are possible through the API. You do not need to implement them all, just the ones you specify. Default: none.

  • platform.jsonapi.verbose: whether the request an payload will be written on QM’s system logs. Default: false.

Actions

  • AGENTLOGIN - Agents starts working. Queues are controlled externally.

  • AGENTLOGOUT - Agents stops working.

  • ADDMEMBER - Agents joins one or more queues.

  • REMOVEMEMBER - Agent leaves one or more queues.

  • PAUSE - Agents starts a pause. The pause code is passed as message.

  • UNPAUSE - Agent stops the pause.

  • CALLOUTCOME - Agents sets a call outcome for a specific call. The outtcome code is passed as message.

  • ADDFEATURECODE - Agent adds a feature code to a call. The feature code is passed as message.

  • REMOVEFEATURECODE - Agent removes a feature code.

  • CUSTOMDIAL - Agent dials out a specific number on a given queue.

  • SENDTEXT - Send SIP SMS to an extension.

  • SOFTHANGUP - Supervisor wants to close a call.

  • TRANSFER - Supervisor transfers a call to a new extension/queue

  • SPY_INBOUND - Supervisor wants to start a spy session on an incoming call.

  • SPY_OUTBOUND - Supervisor wants to start a spy session on an outbound call.

  • WRITE_INFO_VAR - Agent wants to write an arbitrary variable to a call.

You will usually implement either AGENTLOGIN/AGENTLOGOUT or ADDMEMBER/REMOVEMEMBER-style presence for your agents.

JSON request details

In the JSON request, fields have the following meaning:

  • requestor: the specific version of QueueMetrics sending this request

  • token: an auth/identification token you use to distinguish from which QM system the request is coming

  • action: one of the actions above

  • login: the login of the user starting this action

  • serverId: on clustered QM system, to which machine in the cluster this request belongs to. You can set up the cluster.XXX.platform.jsonapi.token property to override the default token for server XXX.

  • agent: the agent to which this action belongs. Contains fields agentId and externalReference

  • extension: the extension we are referring to

  • targetExtension: an extension that is the target of this action (e.g. spying) or a variable name for WRITE_INFO_VAR

  • queues: an array of queues this action refers to. Each queue defines a queueId, a penalty (if known to QM), and an externalReference

  • callId: the Unique-ID of the call this action refers to

  • message: a free text message, e.g. the feature code or the pause code this action needs. For features codes, if the feature code contains a text entry as well, our message field appears in the format ftrcode|message, otherwise if the text entry is blank or missing, just the feature code. For variables, the contents of the variable.

When parsing the JSON request, you can expect all the fields above to be present, and must accept any other fields that may be added to the request in the future. The JSON block has always the same shape, and unused parameters for the current action are set to null.

External reference ids are not currently returned.
When testing specific action, it is often useful to point QueueMetrics to a service like Requestbin, so you can easily track outgoing requests and see which fields are set and how.

Enswitch actions

The Enswitch actions module will connect over HTTP/HTTPS to an existing Enswitch 3.14+ system and perform actions.

The following actions are supported:

  • Setting outcomes and call features

  • Hanging up and transfering calls from the RT page

  • Spying inbound calls from the RT page

  • Logging-on and logging-off agents to queues

  • Pause and unpause agents

Configuration

To turn it on you need to set:

  • platform.pbx to ENSWITCH

  • default.hotdesking to 0 (very important - if not so all actions will be disabled and an error will be logged)

The following configuration options are available:

  • platform.enswitch.http.baseurl is the main URL for the Enswitch system

  • platform.enswitch.http.login an API user log-in

  • platform.enswitch.http.password an API user password

  • platform.enswitch.guiaddmember whether ADDMEMBER/REMOVEMEMBER actions are available (default: false - only chanspy is enabled and actions must be done through the agent’s phones)

  • platform.enswitch.verbose whether all Enswitch interactions should be logged in full to the standard log (default: false)

  • platform.enswitch.lookbackClosedCalls for how long a recently-closed call should be searched on CDRs (default: 7200 seconds)

  • platform.enswitch.spyPrefix the default prefix to use to initiate a chanspy on an inbound call (Default: *91)

  • platform.enswitch.bargePrefix the default prefix to use to initiate a barge-in on an inbound call (Default: *92)

  • platform.enswitch.qpriority.main the queue priority for an agent being logged in with priority MAIN (default: 8)

  • platform.enswitch.qpriority.wrap the queue priority for an agent being logged in with priority WRAP (default: 6)

  • platform.enswitch.qpriority.spill the queue priority for an agent being logged in with priority SPILL (default: 4)

  • platform.enswitch.openLogons whether agents have an "open" logon or must already be present on the queue. Default: false

  • platform.enswitch.dialoutPrefix the prefix used to implement dial-out. Use placeholder $Q to add a queue-id (see below)

  • platform.enswitch.dialoutSpyPrefix the default prefix to use to initiate a chanspy on an outbound call (Default: *91)

  • platform.enswitch.dialoutBargePrefix the default prefix to use to initiate a barge-in on an outbound call (Default: *92)

  • platform.enswitch.dialoutClid a caller-id to be used as presentation for outbound calls. If none is specified, the default one is used. Note that if an incorrect one is specified, all calls will fail.

To listen to audio recordings, you also need to turn on the EnswitchPlatformListener (see Pluggable Listener for the Enswitch platform).

Selecting chanspy vs barge-in

As QueueMetrics has only one "spy" action available, the choice of whether it is a "normal" spy or a barge-in depends on the number you enter as your local extension.

If the extension is prefixed with a "!", then a barge is attempted using the default prefix defined in platform.enswitch.bargePrefix; otherwise the prefix specified in platform.enswitch.spyPrefix is used.

Prefixes are set as in the Features → Feature prefixes menu of your Enswitch system.

Open and Closed log-on modes

The default integration mode for Enswitch uses a "closed" log-on mode; this means that QueueMetrics cannot log an arbitrary agent on to Enswitch, but will basically toggle the pause status of an existing agent, albeit logging the event "as if" it was a real log-on/log-off or a pause/unpause event.

Weird as this sounds, this means that an administrator can configure with certainty which agents are supposed to work on a queue, and end-users cannot change them - they can just toggle them on and off.

If you set platform.enswitch.openLogons=true, a log-in will instead mean that an extension with the same agent code and dtype=phone will be added to the queue, with a priority as defined on the QM queue definition. A log-off will remove such extension from a queue.

Outbound mode

In order to use outbound, you need to create a special extension prefix that will take a few digits for the queue id and then the number to be dialled, for example let’s say our prefix is *787, then tree digits for our queue, then the number to be dialled - e.g. eg *787 146 123456 will dial number 123456 on queue 146.

Then queue 146 must be a real Enswitch (inbound) queue, that we will use as a placeholder to make sure that only active agents (currently logged on, not puased), can actually dial out.

Agents will then:

  • select an outbound queue from the GUI. Only outbound queues that they are currently logged on can be selected. This means that you can control the visibility of queues to agents though each queue’s visibility key

  • enter a number of at least two digits and click on the phone icon to initiate a call

When this happens, a call is sent to the agent’s phone; as soon as they pick it up, a second leg to the callee is dialled and all queue log events are to be recorded in real-time as the call progresses.

The outbound call is displayed on the agent’s panel as it happens, and also on the real-time screen. As the agent need to be logged on to an outbound queue to make an outbound call, there is no risk of misalignment between their log-in status and calls made; and the queue will be existing in Enswitch (though not actually used to process incoming calls).

Also, from the real-time page and the wallboard, it is possible to start a chanspy of such an outbound call.

A possible configuration could be:

platform.pbx=ENSWITCH
default.hotdesking=0
platform.enswitch.guiaddmember=true
platform.enswitch.verbose=true
platform.enswitch.http.baseurl=https://my.pbx....
platform.enswitch.http.login=user
platform.enswitch.http.password=password
platform.enswitch.dialoutPrefix=*787$Q
platform.enswitch.dialoutSpyPrefix=*91
platform.enswitch.dialoutBargePrefix=*92
platform.enswitch.dialoutClid=
platform.enswitch.audioSearchMargin=500

Note how the $Q placeholder allows adding the queue id within the outbound prefix. This also allows having only one default outbound queue, by not adding the placeholder in the generated number.

For example, if you are dialling number 1234 on queue 101 with platform.enswitch.dialoutPrefix set to…​

  • *787$Q would dial *787 101 1234 - normal node (spaces added for clarity)

  • *787 would dial *787 1234 - no queue id, all outbound logged on a queue you define

  • *787$Q999 would dial *787 101 999 1234

Generated queue_log

When QueueMetrics works with Agent/1234 on Enswitch:

  • It creates artificial logs for Agent/1234

  • It adds/removes/toggles presence for an Enswitch extension 1234 having dtype=phone

  • The extension itself will most likely log its calls under SIP/1234@enswitch or something similar

Therefore it is important in the agent definition that your agent be called Agent/1234 with an alias of SIP/1234@enswitch so that it will work properly.

Enswitch extensions are often long numeric codes, and agents may have a hard time remembering that their login is Agent/770102319. To work around this issue, make sure you configure their email address in the agent’s user profile - it can then be used in place of their login and it’s easier to remember.

Another difference in generated queue_log is that the PAUSEALL verb will appear not just once but for all queues, that might in turn emit a local pause event. This causes no problem to QueueMetrics, and is caused by the fact that any log entry on Enswitch must belong to an existing queue. So you may see duplicated records at the same time-stamp.

MirtaPBX actions

The MirtaPBX actions module will connect over HTTP/HTTPS to an existing MirtaPBX system and perform actions.

The following actions are supported:

  • Setting outcomes and call features

  • Hanging up and transfering calls from the RT page

  • Logging-on and logging-off agents to queues

  • Pausing and Unpausing agents on queues

  • Dialing out on specific queues

MiRTA also supports out-of-the-box outbound call tracking to QueueMetrics on a default queue.

INFO: Remember that each queue you want tracked on QM must be set up manually, and queues that are not won’t be sending data to QM.

Configuration

To turn it on you need to set:

  • platform.pbx to MIRTAPBX

  • default.hotdesking to 0

  • platform.mirtapbx.baseurl to your MirtaPBX url (e.g. https://my-mirta-pbx.com/)

  • platform.mirtapbx.key to your MirtaPBX tenant key (e.g. a234Dadf4dfsdg4)

  • platform.mirtapbx.tenant to your MirtaPBX tenant (e.g. TENANT1)

So it would look like:

platform.pbx=MIRTAPBX
default.hotdesking=0

platform.mirtapbx.baseurl=https://my.mirta-server.pbx/
platform.mirtapbx.key=a234Dadf4dfsdg4
platform.mirtapbx.tenant=TENANT1

platform.mirtapbx.verbose=true

audio.server=it.loway.app.queuemetrics.callListen.listeners.MirtaPbxListener

This same configuration is shared by the audio driver that can easily access recordings with no extra steps - see here.

Manual Outbound Calling in MirtaPBX

Agents can make manual outbound calls directly from the agent page by clicking the "Dial" button and selecting from available outbound campaigns in the dropdown menu. This also means that both AMO campaigns and recall tasks work as expected.

For QueueMetrics to properly track an outbound call, all of the following conditions must be met:

  • The outbound campaign must exist as a queue in MiRTA

  • The agent must be a logged-on member of that queue

  • The queue must be configured with type outbound in QueueMetrics' queue configuration

  • The destination number must be dialed through a trunk (not a local extension)

If conditions 1 or 2 are not met, QueueMetrics will display an error message when the agent attempts to dial.

Best Practice: Separate Inbound and Outbound Queues

While MiRTA allows queues to handle both inbound and outbound calls, we recommend keeping them separate for better reporting and management in QueueMetrics. Instead of creating a single queue like "Sales," create two separate queues: "Sales In" and "Sales Out."

This is because you get:

  • Improved Agent Visibility: Since agents must join queues, supervisors can instantly see which team members are handling inbound versus outbound calls.

  • Accurate Performance Metrics: Separate queues allow you to track statistics independently, which is critical because e.g. inbound wait time is a key performance indicator for call centers, while outbound wait time is not applicable or controllable. Combining these metrics produces meaningless averages.

You can still view combined data by creating an aggregate queue called "Sales" that merges "Sales In" and "Sales Out" for comprehensive reporting. You could also have multiple outbound campaigns related to the same inbound queue, or vice-versa.