1. WombatDialer 0.7.5: bug fixes and more

    What is Erwin the Wombat doing sitting on a large cup of coffee? well, he’s been working quite a bit lately.

    We have just released version 0.7.5, that is meant mostly as a bug fix release but also adds some architectural improvements.

    • First, we fixed a number of issues to improve the accuracy of call and queue tracking. The bottom line is that the dialer is more efficient when tracking queues and will try to keep them fully saturated at all times. We also fixed a number of error conditions that were reported by our partners.
    • Secondarily, we changed the log storage model. This means that logs will no longer make entities impossible to delete. Logs will also be scanned more efficiently for large systems (over 1M records).
    • The third important item is that the dialer will now start up immediately as the web application is loaded, unless you just performed an update. This means that you will not have to log in to restart the dialer after a system reboot.
    • The fourth important item is that from the Reports page you can now export to CSV the details of all the calls that were placed in a set of runs. This was a popular demand.
    • Last but not least, the dialer view is way more clear when tracking queues - you can now see who is logged on, how many calls are being placed, and how many channels are used by that queue.

    The downside is that the upgrade may take a while to run - as logs have to be converted, the updater processes about 30,000 calls per minute - so if you have a log database of one million calls, the upgrade may take about 45 minutes to complete. We suggest making a complete backup of the database beforehand, just in case.

    What remains to be done for 0.8? a public regression test. We are working on a suite of tests that will let you run a stress test of WombatDialer on your own systems, to assess system capacity and gettiong familiar with the different dialing modes Wombat offers. This will be a simplified and cleaned-up version of the one we use internally to test the capacities of a release. We are also working on a tutorial of how to run a blended inbound/outbound call-center using WombatDialer and QueueMetrics.

    So - it’s time to update WombatDialer to 0.7.5 now.

    We welcome your feedback about what you would like to see in new releases - we have a public suggestion jar at http://wombatdialer.userecho.com/

    Happy dialing!

  2. WombatDialer 0.6.5 released

    Today we released version 0.6.5 of WombatDialer - this version contains a few minor fixes for the UI, most noticeably a complete reworking of the security system with locks and keys.

    Together with version 0.6.5, we release a new version of the User Manual that is now complete and covers all topics, including full documentation for the APIs, system administration and a Cookbook section that presents some real-life scenarios, plus a Getting Started section that shows a basic installation on Elastix.

    We have a new video tutorial displaying WombatDialer installation and how to set up a simple telecasting campaign to run on an existing Elastix system in less than 10 minutes. It also shows how to set up basic rescheduling rules and how to analyze what went on during the campaign.

  3. Tutorial: A social media dialer

    As we are getting started with WombatDialer, we present an initial fictional scenario that shows a number of interesting features.

    Let’s imagine that we work for ACME Social, a company that specializes in tracking the success of its clients on social networks like Facebook or Google+. So, every time someone befriends one of their clients, we want WombatDialer to call the client telling them their current number of friends. The call would say something like "Hello ! Customer 1234 has 127 friends. Goodbye!"

    This example shows a couple of features that are not trivial to implement on most dialers, notably:

    • The message will be customized with a number of parameters, so that each client receives a personalized version and not just a pre-recorded note
    • The dialer starts calling on-demand when something happens and handles reschedules internally

    In order to implement this, we start by editing the Asterisk dialplan and create a couple of new contexts. The first one is called “telecast” and is used to generate the message being played:

    exten => 100,1,Wait(1)
    exten => 100,2,Answer
    exten => 100,n,Playback(hello-world)
    exten => 100,n,Playback(agent-loginok)
    exten => 100,n,SayDigits(${user})
    exten => 100,n,Playback(vm-youhave)
    exten => 100,n,SayDigits(${friends})
    exten => 100,n,Playback(vm-Friends)
    exten => 100,n,Playback(vm-goodbye)
    exten => 100,n,Hangup

    As you can see, the context above introduces two channel variables ${user} and ${friends} that are placeholders for the user-id of our client and the number of friends they currently have.

    As a convenience when testing, we want all numbers dialled during the test phase to actually dial our own SIP phone; to do this we create a new context called dialout that routes any number to our extension:

    exten => _X.,1,Dial(SIP/500)
    exten => _X.,n,Hangup

    We reload Asterisk to pick up the dial-plan changes. Then we log-in in WombatDialer and configure it, so that:

    • AS is our Asterisk server
    • We create a trunk called “Out” on server AS that points to our telephone. We enter Local/${num}@dialout as its dial string and set its capacity to 1 (so we never receive more than one call)
    • We create an end-point called “Msg” on our server AS with extension 100@telecast and a capacity that is enough for the campaign – let’s say 10 lines.

    Your configuration will look like the following screenshot:

    At this point, we create a new List called “Test” and add only one number to it; you may enter the number as:


    This uploads the number and associates the variables “user” with value 10 and “friends” with value 100.

    Then we create a new campaign - this is where all the pieces are tied together:

    • We set its name as “Runme” – avoid long names or spaces if you plan to control it externally
    • We set its priority to 10 – the priority is the order in which campaigns are queued when trying to assign free lines. A campaign with a lower number will run first, while campaigns with the same priority will have a fair share each.
    • We set “Idle on termination?” to Yes – this way this campaign will not just stop when it is out of numbers but will wait for more.
    • We set “Additional logging” to “QM compatible” so that you can use a famously reliable call-center monitoring tool to keep track of it.

    After saving the campaign, we select it and then add:

    • Trunks: Out
    • Endpoints: Msg
    • Lists:Test

    As you can see, a campaign can have multiple trunks, multiple end-points and multiple call lists, and they may be shared between multiple campaigns.

    It would be fair to add some rescheduling rules as well – for example, if we do not get an answer within 30 seconds, we want the system to retry placing the call exactly once after two minutes.

    In the end, you would get a situation similar to the one here:

    At this point we’re ready to go:

    • make sure that the WombatDialer engine is turned on (from the Home Page, click on the “Play” icon)
    • go to the “View Live” page and select our campaign “Runme” under “Available campaigns”
    • click on “Start”

    If all goes well, within a few seconds you shoul receive a call to your SIP phone telling you that user 10 has 100 friends.Hooray!

    After this, you should see your campaign being shown on the Live page in gold, with status IDLE; now, when our internal tracking system detects new friends for one of our valued customers, all it needs to do is to send a HTTP request to the WombatDialer, like we would manually from the command line:

    curl "http://server:8080/wombat/api/calls/index.jsp?

    If you do, in a few seconds the dialer will send this new call. You can send all the calls it needs to place, one at a time, and it will try scheduling them as soon as possible given the current system conditions - running campaigns and available outbound lines.

    Now, if you want it to actually dial out and not just call our SIP phone, edit your Trunk “Out”: set the dial string to something like SIP/myprovider/${num} and set its capacity as the total number of parallel calls you want to place. Then go to the Live page and reload the campaign.

    When you want to stop the campaign, you have two choices:

    • You can temporarily pause it
    • You can remove it from running campaigns when it is paused

    Of course, you can have this campaign run on multiple trunks and multiple endpoints, using multiple separate Asterisk servers, just by creating the relevant items and telling the campaign to use them. This way, handling hundreds of channels is just as easy as testing with your SIP phone!

    Further evolution:

    • You could create your own audio recordings - the example here was created with sounds present in a standard Asterisk distribution, but of course you should record your own messages.
    • You can do even better and embed a Text-to-Speech engine script, so you are not limited to inserting numbers but can play back nearly anything
    • You can add an IVR option to the “telecast” context, so that if the callee wants to talk to a live person, they are sent to a queue. By monitoring the number of lines that you are using on your trunk and the number of available agents, the WombatDialer acts as a simple progressive dialer.
    • As all the configuration is GUI-agnostic, you can use your favourite Asterisk configuration GUI to create End-points – play messages, read IVRs, add time-dependent rules like you would for incoming calls. All you need to know is the point in the dial-plan that they start from - e.g. internal number 123 in FreePBX is always available as 123@from-internal.
    • You can optionally add an Active Period to the running campaign, so that calls on it are placed only – say – between 9 AM and 6 PM no matter when the messages are queued.


    A number of Asterisk Text-to-Speech solutions are available, see e.g.