Administering QueueMetrics using Tomcat

If you run QueueMetrics, it’s often useful to know how many people are using the webapp at once. This recipe shows how to use the Tomcat manager interface that comes shipped with the standard Tomcat webapps to perform this task. You have to perform the following steps: Continue Reading...



Script to convert music-on-hold to native formats

This script converts a directory full of MP3s to another directory with the same files in native formats (WAV, GSM and U-Law) - see recipe Music-on-hold without MPG123 for an overview of how this works.

FROMDIR="/root/mp3s"
TODIR="/root/transcodes"

for i in $FROMDIR/*.mp3
do
BASEFILE=$(basename $i .mp3)
echo Converting $BASEFILE

mpg123 -s --rate 44100 --mono $FROMDIR/$BASEFILE.mp3 > $TODIR/$BASEFILE.raw
sox -r 44100 -w -s -c 1 $TODIR/$BASEFILE.raw -r 8000 -c 1 $TODIR/$BASEFILE.wav
sox $TODIR/$BASEFILE.wav -t gsm -r 8000 -b -c 1 $TODIR/$BASEFILE.gsm
sox $TODIR/$BASEFILE.wav -t ul -r 8000 -b -c 1 $TODIR/$BASEFILE.pcm
rm -f $TODIR/$BASEFILE.raw

done
Please set FROMDIR and TODIR as you best see fit (they can also be the same directory). Continue Reading...



Music-on-hold without MPG123

When playing the music on hold, Asterisk will usually decode MP3 files using the external utility MPG123. This setup is less than perfect, as: Continue Reading...



Recording queue transfers to disk

Recording a call being handled by a queue is trivial - you just set the file name and the monitor format, and there you are. The problem starts when you want the transfers from the queue system to be recorded as well. If you use the “Transfer” button on your telephone the agent won’t be disconnected from the call as long as Asterisk is concerned, so he won’t be offered any more calls while the original call lasts. This is a general issue with Asterisk queues, and the solution is to start an unattended transfer by pressing the “#” key followed by the extension of the person to be sent the call. If you behave like this, the call will be recorded as long as you enter the DTMF digits, and will then be dropped. This is not okay for us, as we would like to keep monitoring the call even after the transfer is complete. We would also like to record the second part of the call with a meaningful file name, one that might make it very easy to match the first to the second part of the call. Solution First set up a standard queue in extensions.conf, like this:

[coda-dps]
exten => s,1,Wait(3)
exten => s,n,Answer
exten => s,n,Set(__MONITOR_FILENAME=DPS-${UNIQUEID})
exten => s,n,Set(__TRANSFER_CONTEXT=queuetransfer)
exten => s,n,Queue(queue-dps|t|||150)
exten => s,n,VoiceMail,90
This is a very basic queue setup. I imagine you already know how to create a queue in queues.conf (if you don’t, see the node Configuring a queue here on AstRecipes). What matters is that:
  1. we define the file name MONITOR_FILENAME as an inheritable variable
  2. we decide in which context shall the extension typed in be searched
  3. we tell the queue app to allow agents’ transfers (the ‘t’ option).
We will then create a new context queuetransfer to allow for the transfer to take place:
[queuetransfer]
exten => _XX,1,Answer
exten => _XX,2,Monitor(wav,${MONITOR_FILENAME}_TR,m)
exten => _XX,3,Dial(SIP/${EXTEN})
This way we inherit the name of the original file we were monitoring to, and we create another one with the same name followed by “_TR”. Continue Reading...



Understanding queue logic

When a call enters the queue application, there are many possible scenarios, that are controlled by the queue’s own timeout and the ringing timeout. If a timeout is specified on the queue command itself, that is the maximum queue wait length (we call this queue timeout). It is the maximum time that a caller can wait on hold on the queue. If that time is expired, then the caller is moved on to the next step in the dialplan. If no timeout is specified, we assume it to be the default value, i.e. 300 seconds (5 minutes). There is then another timeout specified in the queue definition itself, that is the ringing timeout. This is the queue “loop time”, i.e. the timeout over which events in the queue are rotated. If the queue finds a free member, it tries to ring it for the given period of time. If it finds no free members, it retries finding a new member when this time period expires. In any case, the global queue timeout is triggered only when this timer expires, so if this timeout is very long, your queue timeouts may be longer than expected. If a member is busy or unavailable (e.g. an extension that is not working) it is skipped as soon as the condition is detected and the next available agent is rung. If the option “n” is passed to the queue command, there are no retries, i.e. when the retry period expires, the queue is terminated no matter what. It is possible to add a wait time after an extension is ringed unsuccessfully and the next one is ringed; this parameter id the retry parameter in the queue definition. When the ringing timeout expires, all queue events are processed, not only the global queue timeout; if an announce is set and the time from the last announce has elapsed, then the announce is played. While the announce is being played, no new agent is being called; this might be a minor problem if your queue-thankyou message is very short, but if it is quite long and quite frequent, you may find an undue slowdown on your agents being searched. As a summary, we can say that: Continue Reading...



asterisk

..to be done… Continue Reading...



Installing QueueMetrics from scratch

This recipe shows how to install QueueMetrics on a clean machine. Installing QueueMetrics comes in a number of steps: Continue Reading...



Monitoring Zaptel Hardware

When installing Zaptel hardware (or other Asterisk-related hardware) in Linux, it is often worth checking its status from the command line. The following commands are useful to make sure that everything is working fine. lsmod This command lists loaded modules in the kernel. You should expect to find the generic zaptel module and then one hardware-driver for it, like wct4xxp. lspci -s This command lists the boards attached to the PCI bus of the local machine. Its output may get quite long. It is possible that your PCI adaptor is not decoded perfectly in its name, but it will surely be shown with its IRQ and its associated flags. cat /proc/interrupts This shows interrupt (i.e., requests for service) that your board has asked to the CPU. Make sure your boards are on an interrupt by themselves. cat /proc/zaptel/1 By issuing this command, you’ll see the status of all defined channels for span 1 of your cards. If you have more than one span (or more than one card) you can use cat /proc/zaptel/2, cat /proc/zaptel/3, etc. Continue Reading...