Platform: PMs to match Live Calls
These PMs are used to listen to live calls.
Live calls through QueueMetrics: ClassicQMListenerRT
| Module name: | ClassicQMListenerRT |
|---|---|
Full Java Path: |
it.loway.app.queuemetrics.callListen.RTlisteners.ClassicQMListenerRT |
Properties used: |
For listening to inbound calls: callfile.monitoring.channel, callfile.monitoring.extension, callfile.monitoring.context; For listening to outbound calls: callfile.outmonitoring.channel, callfile.outmonitoring.extension, callfile.outmonitoring.context; In a single-server environment: callfile.dir (points to a local call-file directory or a manager interface port); In a clustered environment: cluster.SERVER.manager (points to each Asterisk server’s manager interface port) |
Available since: |
1.4.7 |
This is the standard QM behaviour: when listening to inbound or outbound calls, a popup appears and asks for a local extension. That local extension is connected to the live channel so that the local user can listen to the ongoing call.
In order for this to work, the dial-plan on each Asterisk server must implement the correct logic - an example is given in the [queuemetrics] context that comes with QueueMetrics.
This PM is used by default if no other server is specified in the configuration.properties file.
(Obsolete) Live calls through an external module: ClassicXmlRpcListenerRT
| Module name: | ClassicXmlRpcListenerRT |
|---|---|
Full Java Path: |
it.loway.app.queuemetrics.callListen.RTlisteners.ClassicXmlRpcListenerRT |
Properties used: |
default.audioRpcServer (non-clustered) or cluster.SERVER.audioRpcServer: The address of the XML-RPC server implementing the QMAudio.listenOngoingCalls interface. |
Available since: |
1.4.7 |
This is the standard XML-RPC implementation and makes it easy to create a completely custom scheme to handle live monitoring. The output of this function must be a single URL that will launch a player to stream that call. This is completely user-configurable.
The details of how to write an XML-RPC server for the QMAudio. listenOngoingCalls interface can be found on the XML-RPC guide for QueueMetrics. We ship a sample implementation of such a server in the xmlrpc_audio_server.php server that comes with QueueMetrics.
See also section Enabling XML-RPC call listening and streaming
(Obsolete) Live calls through Oreka: OrekaWebRT
| Module name: | OrekaWebRT |
|---|---|
Full Java Path: |
it.loway.app.queuemetrics.callListen.RTlisteners.OrekaWebRT |
Properties used: |
oreka.rtserver is the master property that tells QM if Oreka is clustered or not oreka.web is the URL of an OrekaWeb application - QM uses Oreka’s applets for playback. oreka.rtserver.xxx is used for clustered configurations. |
Available since: |
1.5.2 |
This PM lets your supervisors monitor agents using a web-based interface provided by Oreka. The supervisors will simply click on a live call and it will be streamed to them through their browser (note: a window will open and will close immediately before the popup opens. This is expected behaviour).
In order for this PM to work, your system configuration must matche these criteria:
-
You should be using Callback agents, where the agent extension is correctly filled in at logon time
-
Pop-up windows should be openable by QM - this feature is disabled by default in most modern browsers.
-
You should also select a way for this PM to choose on which Oreka server the call must be listened on.
Do not forget to set the oreka.web property in any case in order to download the playback applet.
Using only one Oreka server
If you are deploying only one Oreka server, you should set the address of the live listening port by setting oreka.rtserver to fixed and then entering the live streaming port as follows:
oreka.rtserver=fixed oreka.rtserver.address=http://hostname:59120/?type=stream&localparty=#AGENTEXT#
This will work even on a clustered system, as long as there is only one Oreka server. Note how the agent extension is expanded in the string (see below for the full list of expansion tokens).
Using a cluster of Oreka servers
If you have a set of Oreka servers (likely because you have a cluster of Asterisk servers), you can associate a separate Oreka server to each box in the cluster. You do so by setting oreka.rtserver to cluster and then entering the live streaming port for each member of the cluster, as follows:
oreka.rtserver=cluster oreka.rtserver.aleph=http://ork_aleph:59120/?type=stream&localparty=#AGENTEXT# oreka.rtserver.beth=http://ork_beth:59120/?type=stream&localparty=#AGENTEXT#
In this example, all calls processed on server "aleph" will be searched on server "ork_aleph", while all calls processed on server "beth" will be processed on server "ork_beth".
Using multiple Oreka servers with UniqueID
If you have a set of Oreka servers that are not linked one-by-one to a set of Asterisk boxes, you can associate a separate Oreka server to each call in the cluster, by prepending a digit to the call’s UniqueID that will be used to know on which server each call is being handled. You do so by setting oreka.rtserver to chandigit and then entering the live streaming port for each member of the cluster, as follows:
oreka.rtserver=chandigit oreka.rtserver.1=http://ork_aleph:59120/?type=stream&localparty=#AGENTEXT# oreka.rtserver.2=http://ork_beth:59120/?type=stream&localparty=#AGENTEXT#
In this example, all calls which UniqueID starts wilth "1" will be handled by the "ork_aleph" server, and all calls which UniqueID start with "2" will be queries on the "ork_beth" server.