In this example, we will show how to install QueueMetrics on the same server using MySQL storage and configure everything to have a working system. Setting things up should require about 30 minutes.
QueueMetrics is a full-fledged call center monitoring solution - see http://queuemetrics.com . It is an industry-proven, commercial product that is available free of charge to smaller call centers, home users and SOHO’s and is used in a large number of call center worldwide, including installations with hundreds of agents online.
If you have a SSH client or can access the system console (i.e. the attached keyboard and monitor, if any), log in as user root with password password (you entered the password during system installation).
If not, you should install the Java SSH client - see Common problems and solutions at the end of this tutorial.
After logging in as root, type the follwing commands:
wget -P /etc/yum.repos.d http://yum.loway.ch/loway.repo yum install queuemetrics
The yum command will download QueueMetrics and all of its dependences and install it on your system. This may take a while, depending on your internet connection speed. When asked to confirm the installation, type "y" to proceed.
After the installation is done, you have to install the sample MySQL database that will be used to initialize the system by executing the following commands:
cd /usr/local/queuemetrics/webapps/queuemetrics-1.6.1/WEB-INF/README ./installDb.sh
Note that the exact directory to use will depend on the QueueMetrics version being installed and is displayed on the last page of output that yum produces. Follow the on-screen instructions (it is a matter of typing in a couple of passwords as detailed by the installDb utility itself) and the database will be created.
![[Tip]](../images/icons/tip.png){kind=icon} | Tip |
|---|---|
For your convenience, remember that the default MySQL password for TB is "passw0rd" (yes that’s a zero) and the suggested default DB password for QueueMetrics is "javadude". |
| Tip |
|---|---|
For your convenience, remember that the default AsteriskNOW installation has empty default MySQL password and the suggested default DB password for QueueMetrics is "javadude". |
QueueMetrics comes with an user-modifiable Asterisk context that should be included in the main Asterisk context to provide additional functionalities, like e.g. automated agent log-ons and many more.
Run the following commands:
cd /usr/local/queuemetrics/webapps/queuemetrics-1.6.1/WEB-INF/ cp mysql-utils/extensions-examples/extensions_queuemetrics.conf /etc/asterisk
Then you should edit the file /etc/asterisk/extensions_custom.conf as shown in the picture by issuing the command:
nano /etc/asterisk/extensions_custom.conf
Basically you should add a line that says:
#include extensions_queuemetrics.conf
that will be picked up by Asterisk on the next reload.
Edit the configuration.properties file of QueueMetrics:
cd /usr/local/queuemetrics/webapps/queuemetrics-1.6.1/WEB-INF/ nano configuration.properties
Look for the following properties across the file and change them accordingly:
default.queue_log_file=sql:P001 callfile.dir=tcp:admin:amp111@127.0.0.1 default.rewriteLocalChannels=true callfile.agentlogin.enabled=false callfile.agentlogoff.enabled=false default.hotdesking=86400
These changes mean:
- use the SQL storage model (see below)
- use the correct credentials to access the Asterisk manager
- rewrite dynamic channel names to the Agent/XXX format
- turn off the buttons for old-style agent log-on and log-off.
- use Hotdesking
To test that everything is okay, you’ll have to point your browser to the address http://myserver:8080/queuemetrics and you should see a screen like the following one.
If you see this screen, you know that QueueMetrics is working fine. As you’ll be curious to check it out, you can login as uder demoadmin password demo.
If you run on Asterisk 1.6, you need to also give the "originate" permission to QueueMetrics:
nano /etc/asterisk/manager.conf
Add the "originate" permission in both "read" and "write" lines:
[admin] secret = amp111 deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 read = system,call,log,verbose,command,agent,user,originate write = system,call,log,verbose,command,agent,user,originate
Save and exit.
In this example, we’ll keep a copy of the statistics provided by Asterisk on a database table, this offers a number of advantages:
- Makes general operations faster
- It’s lightweight
- Lets you keep a double copy of raw queue data
- Lets you install QueueMetrics on a separate server
- Allows for Hotdesking capabilities
This can be obtained very easily by entering
yum install qloaderd
![[Note]](../images/icons/note.png){kind=icon} | Note |
|---|---|
When installing on AsteriskNOW, a warning message will be shown as reported below. Confirm the message with y to continue. |
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID e8562897 Importing GPG key 0xE8562897 "CentOS-5 Key (CentOS 5 Official Signing Key) <centos-5-key@centos.org>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 Is this ok [y/N]: y
After it’s done, you can test that the resident loaderd is working by issuing the following command:
tail /var/log/asterisk/qloaderd.log
If you see a log file that shows no errors, you’re done.
After this, do not forget to tun off the log rotation for the /var/log/asterisk/queue_log file, or the logs enclosing your precious queue data will be deleted periodically.
See Common problems and solutions at the end of this tutorial to turn off log rotation.
Installing on a different server can be a good idea if your call center has over 20 or 30 agents and you don’t want to slow down the main Asterisk box when running statistics.
It’s very easy to do:
- Install QueueMetrics on the new server and install a local copy of the database
- Create a rule on the new QueueMetrics database that allows for connection to MySQL from a client that is located on the Asterisk server.
- Install qloaderd on the TrixBox server
When you’re done, go to the TrixBox server and edit the file /etc/sysconfig/qloaderd.
It should look like:
PARTITION=P001 QUEUELOG=/var/log/asterisk/queue_log LOGFILE=/var/log/asterisk/qloaderd.log LOCKFILE=/var/lock/subsys/qloaderd PIDFILE=/var/run/qloaderd.pid MYSQLHOST=localhost MYSQLDB=queuemetrics MYSQLUSER=queuemetrics MYSQLPASS=javadude
Edit the variables MYSQLHOST, MYSQLDB, MYSQLUSER, MYSQLPASS to point to the new QueueMetrics server.
Then isssue the command:
/etc/init.d/qloaderd restart
And check the log file to make sure that there are no errors and data is being uploaded correctly to the QM server.
You should also change the callfile.dir property in order to point to the Asterisk server and, on the Asterisk server itself, allow for Asterisk Manager (AMI) access from the QueueMetrics server.
As a last warning, you should make sure that the Asterisk server and the QueueMetrics server have clocks aligned to a sub-second difference; otherwise the real-time page may act funny, e.g. by specifying negative wait times. In order to avoid this, you should install ntpd on both servers.
Point your browser to your TrixBox or AsteriskNOW server; you should see a welcome screen.
When using TrixBox:
- Click on User mode [ switch ]
- Enter user maint and password password as credentials
- Click on PBX → PBX settings
You should see the FreePBX welcome screen.
When using AsteriskNOW:
- Select FreePBX Administration
- Enter admin and admin as credentials
You should see the FreePBX system tatus screen.
Click on Queues and create a new one with the following parameters:
- Queue number: 300
- Queue name: Support EN
- Ring strategy: rrmemory
- Call recording: wav49
Leave all other settings blank.
Click on "Apply configuration changes" → "Continue with reload".
You should see a result like the following one.
Likewise, create queues 301 and 302 in turn.
If you have not already done so, for the purpouse of this tutorial you should create three SIP extensions and associate them to three physical or software phones.
They should be named 400, 401 and 402.
When you’re done, apply configuration changes and try placing some test calls, to make sure that all phones are working.
We now have to configure QueueMetrics to use the newly-defined queues and agents.
Go to http://10.10.3.123:8080/queuemetrics and login as demoadmin with password demo.
From the home page, click on Edit QueueMetrics settings → Setup wizard.
| Note |
|---|---|
The Setup wizard is present only if you’re logged with a user holding the CONFIG key. If you are migrating from a QueueMetrics version older than 1.5.2 you need to add this key to your account. |
Follow the wizard until complete.
At this point, queues 300, 301 and 302 have been created.
We now have to tell QueueMetrics on which queues our agents will be working.
Edit QueueMetrics settings → Edit agents.
Create a new agent, setting the following parameters:
- Asterisk agent code: Agent/200
- Agent description: My Agent 200
- Current terminal: ---
Leave all other parameters blank. Note that the agent code must be the prefix Agent/ plus the extension number, without spaces or other characters.
At the end, the agent configuration screen should look like the following one:
Now you should edit the queue-agent association, that is, select which agents can work on which queues.
Just click on Cfg Queues → choose queue 300 → Agents
Make sure that the following settings are implemented:
- Queue 300: Agent/200 and Agent/201
- Queue 301: Agent/200
- Queue 302: Agent/201
While you are at it, you should also edit the "00 All" queue so that you can see all your inbound activity at a glance.
Set:
- Queue(s) to "300|301|302" - this means all of those queues at once
- Main agents as Agent/200 and Agent/201
If all OK, the queue configuration page should look like this:
See that Agents column shows the number of agents defined as "2-0-0", that is to say 2 agents as Main Level, 0 as Wrap, 0 as Spill.
The configuration so far is enough for running reports.
This gets to be a problem if the number of queues and agents is higher than it is in this example - you never can tell if all agents are logged on to their correct queues, and your agents often cannot either.
QueueMetrics helps you in this by offering the so-called Agent’s page, that is, a specialized page from which agents can log on, log off, go to pause, see calls processed and do other activities as well.
In order to enable this, you have to create a log-on for each agent that matches exactly the agent code you used in the agent definition, so e.g. for extension 200 you would use Agent/ plus 200.
Go to Home page → Edit QueueMetrics settings → Administer users.
Create a new user:
- Login: Agent/200
- Password: (You choose)
- Real name: (The person’s name)
- Enabled: Yes
- Class: AGENTS
![[Warning]](../images/icons/warning.png){kind=icon} | Warning |
|---|---|
Make sure that the class is set to AGENTS and not e.g. ADMIN, or they will log-on as administrators! |
When you are done, create entries for extensions 201 and 202 as well. In the end, the user list should look like the following picture:
| Tip |
|---|---|
While you are in the user configuration screen, take a second to change the password for user demoadmin and the other default users; using default passwords in a production environment is unwise. |
To check if your changes have been successful, try logging off and logging in again with the credentials for Agent/200; you should see a screen that looks like the following:
From this page:
- To log in to a queue, click on the "Add Member" button, select your queue, enter your local extension and confirm.
- To log off of all queues, click on "Remove Member" and select "All selected" again; you will be logged off in a few seconds.
- An agent can go to pause and mark its pause status as one of the predefined pause codes (e.g. Lunch, Optional break, etc.)
- When taking a call, the agent will be able to mark a "Call status code" for that call (e.g. to mark the call as a Sale)
You can also associate the four bottom buttons to a set of functions that can either be URLs to open or pieces of the Asterisk dialplan to launch.
You can run QueueMetrics in many different modes:
- As an analytical package, it lets you see who did what in your call-center: how many calls were processed, the response times, agent sessions, etc. It produces over 150 different stats, and it’s fully documented in its user manual that can be downloaded from http://queuemetrics.com/manual_list.jsp (you can also browse it online from the same location)
- As a Quality Assessment package, QueueMetrics lets you gather and analyze statistics on the behaviour of your agents over time.
- As a real-time monitor, QueueMetrics lets you see what is going on in real-time - just select an entry from the queues list and click on "Real-time monitoring"
- As a wallboard, it runs a special screen meant to be used with a large screen or video projector; it can be set up so that it’s usable from a stand-alone Linux box.
- As an Agent’s interface, it will provide your agents with a set of functions that will help them integrate with external CRM apps and perform their tasks more efficiently. It also includes a specialized Firefox app called AGAW that acts as a real-time awareness of the general situation for agents.
- As a data source, QueueMetrics will interact with external programs using a standard XML-RPC interface and provide them with high-quality data for further processing.
We suggest that you have a look into the QueueMetrics User Manual to make the most of the wealth of information that QM can provide.
We configured the system to record all calls in format WAV49 (a derivative of GSM that is natively playable on Windows machines).
Therefore, from QueueMetrics, you simply run a report and then click on "Answered" → navigate to the bottom of the page → "All calls" → see list of all calls found → click on magnifying glass icon → click on the audio file.
Though there is usually one, there can be zero or more audio files linked to a given call.
By listening to the audio recording of a call, you can easily implement a Quality Assessment process to review the quality of each agent’s work. Though this topic is not a part of the scope of this giude, it is not to be overlooked and it discussed in detail in the User Manual.
It is sometimes nice to be able to listen to live inbound calls as they happen, while the agent is still on line with the caller. QueueMetrics makes such a task trivial.
In order to implement this, you must edit the /etc/asterisk/extensions_queuemetrics.conf and change the following lines as shown here:
...
exten => 11,7,ChanSpy(${QM_AGENT_EXT})
...
...
exten => 14,6,ChanSpy(${QM_AGENT_EXT})
...This is needed because we use dynamic agents and not standard agents, so we have to attach to their SIP channels to the actual listening.
After the change, force a reload of the dialplan by making a minor change in FreePBX and applying changes.
After this, go to the Realtime page in QueueMetrics and wait for a call to be available; when it is, click on the small telephone icon and enter your local extension.
Your phone will ring and you will be able to listen to the call in progress right as it’s happening.