AstRecipes logo

Convert Monitor Recordings to mp3

Tags: , , , , , , , ,

We run a small office with our Asterisk PBX but we record all phone traffic, in and out. Needless to say, this can exact a large toll on our disk resources. I’m submitting this script and related Cron entry for those who need to compress their monitor recordings to mp3 format and need a program that will only run when the PBX is idle. Assumptions: Continue Reading...



Installing Queuemetrics on PBX-in-a-Flash

Tags: , , , ,

PBX-in-a-Flash is Nerd Vittles ultra-cool version of a preconfigured Asterisk PBX based on CentOS 5. This makes installing QueueMetrics very easy, though the fact that the standard access port is already used by a different, preinstalled package makes a bit of hand-tweaking necessary. Basic installation 

wget https://yum.loway.ch/loway.repo -O /etc/yum.repos.d/loway.repo
yum install queuemetrics
This should manually download and install most of what you will need. When the intallation terminates, remember to follow the procedure to install the database as written on the last screen that you see; this will be something like: 
cd /usr/local/queuemetrics/webapps/queuemetrics-1.4.3/WEB-INF/
./installDb.sh
The exact path will depend on the exact version of QM being installed. When asked for the system password type passw0rd (that’s a zero, not a capital O) and when asked for the default password type javadude . Now we have to change the port that QM will use for its connection: run the following command: vi /usr/local/queuemetrics/tomcat/conf/server.xml and look for a place that looks like the following: 
<!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -->
<Connector port="8080"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           debug="0" connectionTimeout="20000"
           disableUploadTimeout="true" />
Change the part that says Connector port=”8080” to Connector port=”8099”. Save and exit. Restart QueueMetrics by typing: /etc/init.d/queuemetrics restart Now we’re almost ready but for one thing: the preconfigured firewall will block external access to port 8099. You can do two things: Continue Reading...



Rebuilding Fonality queue_log

Tags: ,

On a number of Fonality boxes, you’ll find that the queue_log file, which content is critical to the correct running of QueueMetrics, is deleted almost immediately and moved to varius files under the /var/log/asterisk/real filesystem. In order to make this work with QueueMetrics, we prepared a small script that will rebuild the queue_log out of the snippets in real. In order not to overload the system, we take only s pecified period pof time (eg 30 days) into consideration for the rebuilding. Here is the script called rebuildqlog.sh 

# uso:  ./rebuildqlog.sh /var/log/qm_qlog
# --------------------------------------------------

LOGF=$1
LOGT=$LOGF.temp
LOGS=$LOGT.sorted

MAXDAYS=30

rm -f $LOGT $LOGS
nice find /var/log/asterisk/real -name queue_log.\* -mtime -$MAXDAYS | xargs cat >> $LOGT
cat /var/log/asterisk/queue_log >> $LOGT
nice sort --buffer-size=10M $LOGT | uniq > $LOGS

rm -f $LOGT $LOGF
mv $LOGS $LOGF
Then we need to call this script every 15 seconds or so in order to have a reasonably up-to-date version of the queue_log file ready for use by QueueMetrics. So we create the file run_rebuild.sh : 
#! /bin/bash

while [ true ]
do
        nice /root/rebuildqlog.sh /var/log/qm_qlog
        sleep 15
done
And we run everything by typing: 
nohup /root/run_rebuild.sh &
As we build the “new” queue_log in a different location, we’ll have to modify the file configiration.properties in QueueMetrics in order to tell it where the queue_log to use actually is: 
# This is the default queue log file.
default.queue_log_file=/var/log/qm_qlog
This should do the trick. Note: Continue Reading...



Optimizing QueueMetrics data access

Tags: , , ,

If you run a very large call center and your queue_log table starts to get big (>1M lines), you can apply the following techniques to improve database performance. 1. Create a complete index The default index used for access, called “partizione_b”, is not very efficient for huge datasets because its granularity is aimed only at partition and time period. To make an idex such that all queries can be “solved” completely through the index, you should drop other indices and create this one: 

ALTER TABLE `queue_log` ADD INDEX (   
	partition(9), time_id, unique_row_count, queue(15) 
)
Please note how we give a maximum size to each text field - make that as long as your largest entry on that field (see below). 2. Use short partition and queue names The shorter names you use for your partitions and your queues, the more compact the index will be, so the faster will be the access. In no case make the queue index smaller than an used queue, or it wil have to go check on all rows if they match or not! You can get information on how long are your fields by running the following queries: 
SELECT DISTINCT partition, length( partition ) AS L FROM queue_log
and 
SELECT DISTINCT queue, length( queue ) AS L FROM queue_log
Once you get this, I suggest using one or two characters for the partition (P1 or S3 or even A, B C…) and short names for the queues (withing 5-6 characters). Then you create the index as described in #1 using the new field lengths. 3. Make a log of slow queries If your performace is suboptimal, you should make a log of slow queries. This is easily done in MySQL: see the article MySQL’s Over-looked and Under-worked Slow Query Log. I suggest setting a limit of 5 seconds to tell a long query from a normal one. You should then look for entries like: 
Query_time: 6  Lock_time: 0  Rows_sent: 12999  Rows_examined: 988483
This means that the query took 6 seconds to run, 12999 rows were sent to the client but 988943 were examined. Better indexing will make those divergences be smaller. You can also run 
mysqldumpslow name-of-slow-query-log
To see a clearer report. 4. Optimize the table and its indices The table should be optimized by partition and access time. You can do that by running: 
ALTER TABLE queue_log 
ORDER BY partition, time_id, unique_row_count
This operation will take quite a while to perform and will lock the table while it’s running, so do it only when the CC is not working. 5. Use a large key buffer size On modern, multi-gigabyte servers there is no need to have a key_buffer_size of 8 megs! Make it at least twice of the key size for the queue_log table, like 128M or 256M See: Tuning Server Parameters Continue Reading...



Installing QueueMetrics on Fonality PBXtra

Tags: , , ,

The Fonality PBXtra boxes are based on CentOS 4.2, so the yum install is feasible with some modifications. The most important thing that is missing is that those boxes use Fonality’s RPM repository, where the mysql-server packages are missing. Luckily, it is possible to download and install the correct RPM package from the CentOS vault: 

wget http://vault.centos.org/4.2/os/i386/CentOS/RPMS/mysql-server-4.1.12-3.RHEL4.1.i386.rpm
rpm -i mysql-server-4.1.12-3.RHEL4.1.i386.rpm
/etc/init.d/mysqld restart
This fetches and installs the correct MySQL server. Then we add the Loway repository and install QueueMetrics: 
wget https://yum.loway.ch/loway.repo -O /etc/yum.repos.d/loway.repo
yum install queuemetrics
At the end of the installation, do not follow the automated procedure to create/upload the database but type: 
/etc/init.d/mysqld restart
cd /usr/local/queuemetrics/webapps/queuemetrics-1.4.3/WEB-INF/README
mysql mysql
This will enter the MySQL shell; type the following lines: 
create database queuemetrics;
grant all privileges on queuemetrics.* to 'queuemetrics'@'%' identified by 'javadude';
grant all privileges on queuemetrics.* to 'queuemetrics'@'localhost' identified by 'javadude';
grant all privileges on queuemetrics.* to 'queuemetrics'@'pbxtra9999' identified by 'javadude';
See the last line where it says pbxtra9999? change that to the actual code of the box, as shown in the command prompt. Type \q to exit the MySQL shell. Now type: 
mysql -u queuemetrics -p queuemetrics < queuemetrics_sample.sql
Enter javadude as a password when prompted. Now go to http://yourserver:8080/queuemetrics and login as demoadmin pass demo. If your server has queues and agents configured, you can import them by using the Import wizard voice in the main screen. It is very likely that you will have to run a script to build a suitabe queue_log: see Rebuilding Fonality queue_log. See Also: Continue Reading...



Managing agents that dynamically log-on

Tags: , , ,

AddQueueMember is a command that lets you add dynamic agents to a queue. Its main advantage is that you can add channels, i.e. terminals, so you’ll have most of the advantages of agents without the performance and stability problems that the agents module may cost in very large systems. Its disadvantage is that in Asterisk 1.2 it does not log the agent login/logoff to the queue_log, and so programs that analyze the queue log data like QueueMetrics will not see agents logging on and off. This is a major organizational problem in a real-world call center, where tracking agent logons and logoffs is vital to the smooth running of the operations. In Asterisk 1.4 instead this bug has been fixed, so you can use this code: Code for Asterisk 1.4 and QueueMetrics 1.4 or newer To do the adding, you dial 422XX, where XX is your local extension; the same goes to be removed from queue. 

; addqueuemember - 422 - for Asterisk 1.4
exten => _422XX,1,Answer
exten => _422XX,2,AddQueueMember(my-queue,SIP/${EXTEN:3})
exten => _422XX,3,Hangup



; removequeuemember - 423 - for Asterisk 1.4
exten => _423XX,1,Answer
exten => _423XX,2,RemoveQueueMember(my-queue,SIP/${EXTEN:3})
exten => _423XX,3,Hangup
Code for Asterisk 1.2 and QueueMetrics 1.4 or newer In case you run Asterisk 1.2, you’ll have to implement this piece of dialplan instead: 
; addqueuemember - 422
exten => _422XX,1,Answer
exten => _422XX,2,AddQueueMember(my-queue,SIP/${EXTEN:3})
exten => _422XX,3,System( echo  
"${EPOCH}|${UNIQUEID}|my-queue|SIP/${EXTEN:3}|ADDMEMBER|-" >> /var/log/asterisk/queue_log )
exten => _422XX,4,DBput(dynlogin/log_Agent-${EXTEN:3}=${EPOCH})
exten => _422XX,5,Hangup



; removequeuemember - 423
exten => _423XX,1,Answer
exten => _423XX,2,RemoveQueueMember(my-queue,SIP/${EXTEN:3})
exten => _423XX,3,DBget(ORGEPOCH=dynlogin/log_Agent-${EXTEN:3})
exten => _423XX,4,Set(RV=$[${EPOCH} - ${ORGEPOCH}])
exten => _423XX,5,GotoIf($["${RV}" = "0"]?8:6)
exten => _423XX,6,System( echo  "${EPOCH}|${UNIQUEID}|my-queue|SIP/${EXTEN:3}|REMOVEMEMBER|-|${RV}" >> /var/log/asterisk/queue_log )
exten => _423XX,7,DBdel(dynlogin/log_Agent-${EXTEN:3})
exten => _423XX,8,Hangup
This will allow logging in one queue at a time and QueueMetrics correctly tracking that agent being associated with that queue and computing correct overall agent activity statistics. See also: Continue Reading...



Resetting devices from the command line

Tags: , ,

It is sometimes handy to be able to reset network and telephony apparatus right from the command line, in order to script them in case that is needed. We use: Continue Reading...



Manually updating QueueMetrics

Tags: , ,

This recipe assumes that you have a working QueueMetrics installation and you just need to update it to a newer version. It should work with any servlet container. Continue Reading...



About AstRecipes

AstRecipes is a community effort to share tasty recipes for your Asterisk PBX.

Submit your articles on Github:
l3nz/AstRecipes