WombatDialer Blog

WombatDialer Security Update: Addressing Two Vulnerabilities

Tue, 18 Feb 2025 00:00:00 +0100

Today, February 18th 2025, there is a public disclosure of two security vulnerabilities that were recently identified. We believe in transparency and want to share the details with our users.

Vulnerability Details

CVE-2024-57055 - Server-Side Access Control Bypass

WombatDialer uses a client-server model where the client requests services from the server. Access to these services is restricted based on user grants (security keys). While access controls were in place on the client-side, a vulnerability existed on the server-side that could allow unauthorized users to potentially call certain services without the necessary access level. This issue was limited to services used by the client (not the general-use JSON services) and requires reverse engineering of the proprietary serialization protocol, making it difficult to exploit.

See CVE-2024-57055

In the affected services, the full session identity was being written to system logs. This information was meant to be used to correlate activities in the WombatDialer logs with logs from other systems, such as an HTTP frontend. Unfoirtunately, it could also be used by a maicious attacker to impersonate an existing user session. To mitigate this, we will now only provide the initial and terminal parts of the cookie in logs.

See CVE-2024-57056

Mitigation

Both vulnerabilities are addressed in WombatDialer version 25.02, that was released on Jan 30, 2025. We strongly recommend that all users upgrade to this version immediately to ensure their systems are secure.

Important Note: We have no evidence to suggest that these vulnerabilities have been exploited in the wild.

Acknowledgement

We would like to thank Mr. Aleksandr Rudkovskii “exe_cute” for identifying and responsibly reporting these vulnerabilities during a security audit. Their diligence has helped us to improve the security of WombatDialer.

How to Upgrade

To upgrade to the latest version of WombatDialer, see Upgrading WombatDialer.

We are committed to the security of our products and appreciate your continued support. If you have any questions or concerns, please do not hesitate to contact our support services.

What now?

All details for this release are available on our What’s New in WombatDialer 25.02.

To update from a previous version, see Updating.

If you’d like a test-drive, visit https://www.wombatdialer.com/ for a full featured trial.

WombatDialer 25.02: Dialing into a Better Experience!

Wed, 29 Jan 2025 00:00:00 +0100

WombatDialer, the go-to tool for outbound dialing on the Asterisk/FreePBX platform, just got a major update.

Security Update

WombatDialer version 25.02 includes a critical security update addressing a session handling vulnerability that could potentially allow unauthorized access to the configuration interface. Users are strongly advised to update immediately, even though there is no indication of exploitation in the wild. CVE identifiers for this vulnerability will be published soon.

Call reporting

This release also introduces improvements to call reporting, including a “Called Counts” feature in the Reports section. This allows users to analyze call outcomes based on the number of recall attempts, aiding in recall policy optimization. A user interface issue on the Realtime page’s “Active Lists on Run” panel has been resolved.

Documentation and installation

Documentation has been expanded with a new section on “Automatic Lists” to clarify their purpose and proper usage. API enhancements include preventing additions to campaigns without active runs and correcting the setting of the CPS parameter for trunks.

Installation and upgrade processes are streamlined with native support for MySQL 8.0.36 (in yum installations) and a fixed symlink for web-app access. The DbTest transaction during installation and upgrades has been improved.

What now?

All details for this release are available on our What’s New in WombatDialer 25.02.

To update from a previous version, see Updating.

If you’d like a test-drive, visit https://www.wombatdialer.com/ for a full featured trial.

Understanding blacklists in WombatDialer

Mon, 04 Dec 2023 00:00:00 +0100

One of the most important features of a dialer, paradoxical as it sounds, is to avoid calling numbers that are not supposed to be contacted. But why should you, in the first place, try to call numbers that you are not supposed to call?

In practice, this is a common scenario - for example, let’s say we work for a car dealership, and you prepare a list of customers to contact because their car is ready for pick up after its service ticket. While you are running this campaign, some especially eager customers decide to contact us first to inquire about the status of their vehicle, and you tell them that it’s ready. At this point, calling them again would be a waste. It would also give the impression that we do not know about their previous interaction.

But how to do it? Once WombatDialer schedules a number, the right thing to do is to cancel the call on the campaign, if the campaign hasn’t placed the call already. So, we say, let’s delete it from the relevant list, but we may want to re-use the same list of numbers more than once, and we do not want to strike some numbers out of it “just because”.

Also, if there callee ever asks “Why didn’t anybody call me? I was waiting for your call!”, it is important to understand that it was an explicit decision and not a failure. As you have no way of knowing about the cancellation when preparing the list of contacts to reach, it must be an “add-on” while the system is running. That’s what blacklists do: we can keep a separate list of numbers we don’t want to call and check it dynamically as we progress through our lists.

A second common reason why you could use a blacklist is because the customer directly asks us not to be recalled. By adding them to a blacklist we can keep this information in a separate place from the lists we manage, and WombatDialer makes sure we never forget to remove those numbers from the ones we are supposed to dial.

This way, our employees tasked with extracting call lists need not worry about making sure that all canceled numbers are manually removed, and why. In many countries, you have a legal obligation to adhere to a customer’s will never to be called again, so you need to be 100% sure you are doing this process right.

So there are two related but different scenarios: in one case you want to “edit” the current run of your campaign only; in the other, you want to create a long-term database of numbers that are not to be recalled. And, in practice, you likely want to do both things on actual campaigns you are running.

How do blacklists work?

WombatDialer checks a number against blacklists every time it has to dial it. If a number is present on any blacklist, then it is not dialed at all and it goes straight to a special state BLACKLIST.

As WombatDialer will try dialing an unsuccessful number multiple times and with different rules, a number might then live for a while in a state when it has already been called, but Wombat still wants to dial it in the future. At any time you add that number to a blacklist, all further redials are automatically blocked. This is handy because sometimes recalls may happen after hours or days from the first trial, so it makes sense that we can pull the handbrake on them at any time.

We can even blacklist a number for a specified period only; by setting the attribute BLACKLISTED_UNTIL on a call to a specific date, we make sure that the given number is blacklisted only up to that point in time. Similarly, as with plain call lists, the same number can be present multiple times on a blacklist; and WombatDialer makes sure that if it has a time limit, it is enforced. A number with no time limit is considered blacklisted forever.

As you do for lists, you can have multiple blacklists linked to the same campaign - the difference here is that while calls from plain lists are loaded in sequence, one at a time, every number to dial is checked at once against all blacklists linked to that campaign. Having multiple blacklists is handy because you can use them as different “rules” - for example, you could have a temporary blacklist that you use to avoid recalling people that just called in, and at the same time, a general blacklist (maybe shared between all of your campaigns) where you keep customers that are never to be recalled. This gives you a lot of flexibility in how you organize your work.

Plain lists vs blacklists

So, what is the difference between a normal call list and a blacklist? The answer, surprisingly, is “none”. Being a blacklist or a normal list depends on the role that the list plays in the campaign. This means that all functions meant to update lists work the same way in both cases.

For example, you can ask WombatDialer to add the current number to a list as a disposition rule at the end of the call cycle. It will simply oblige, and then it is up to you to decide if you want to use that list to place or to avoid further recalls.

Blacklists and multiple numbers

WombatDialer can use a set of numbers to reach out to customers (see “Using multiple numbers per call” in its User Manual). For example, when calling a person, it can first try their home number, then their mobile, then their office…. as you see fit. In WombatDialer lingo, this is called a MULTINUM - and while we use it as the “main” number in the identity, on every attempt the number dialed is rotated in a round-robin fashion.

When blacklisting, you want to stop all calls going to a specific person - so you add the main number to a blacklist, and it will automatically block all further recalls. On the other hand, additional numbers cannot be blocked directly.

This is not usually an issue, because the main number, the one that must be blocked, will be tied to the person’s identity on your database.

APIs and integrations

We have so far seen that blacklists, by their nature, tend to be very dynamic. Sometimes you decide which customers to call based on a fixed, given list of numbers, in other cases, you will use the API to “drip-feed” numbers to Wombat when there is a need to call them - for example, a visitor leaving their number on your website might be added to a current campaign. If all goes well, they will be recalled in a few seconds.

Note: all examples below are issued as HTTP GET calls. To maintain readability, we break them into multiple lines and may not quote all characters properly. You should.

This is how you would do it using Wombat APIs:

    http://127.0.0.1:8080/wombat/api/calls/
        ?op=addcall
        &campaign=WEBSITE
        &number=1234
        &attrs=NAME:John,SURN:Doe
        &schedule=2024-03-18.14:00:00

This says “Call number 1234 on campaign WEBSITE, where we know that the person’s name is John and their surname is Doe, after 2 PM today”. Behind the scenes, their number is added to a list called WEBSITE/AUTO that Wombat manages for you, and will then do the recalls.

But what happens if they call us in the meantime, and we want to cancel the call? in this case, we have to know which blacklist to use - that is, one that is currently linked to the campaign WEBSITE. Let’s say it was called DNC.

    http://127.0.0.1:8080/wombat/api/lists/
        ?op=addToList
        &list=DNC
        &numbers=1234,REASON:recalled

This says “Add number 1234 to list DNC”. As you know that list DNC is a blacklist that is set for the campaign WEBSITE, once you add the number, every number to be called on that campaign will be checked and skipped if necessary. While it’s not mandatory, we suggest adding a REASON attribute to that number, so we know WHY this number was blacklisted and, possibly, by whom.

You could also do the opposite - what if there is a new case open for the same customer, and you need to remove this number from the list DNC? you could use the following API call:

    http://127.0.0.1:8080/wombat/api/calls/
        ?op=cancelBlacklist
        &list=DNC
        &numbers=1234
        &reason=NEWCASE

This says “If there is number 1234 on the list DNC, mark it so that it is not used for blacklisting, and write the reason for de-blacklisting as NEWCASE”. This is because it is important to keep track of why a number was added to a blacklist or removed from it.

When adding a new number to a blacklist, you could use any attribute to keep track of the reason - WombatDialer does not care, but it will make your life easier when auditing what went on. When removing, WombatDialer writes a special attribute BLACKLISTED_CANCELLED that contains the reason you gave it and the time the de-blacklisting happened.

Note that, to cancel a blacklisting, it must be canceled on all the blacklists linked to that campaign where the number might be present. If the number is present multiple times on the same list, all the instances where it is currently blacklisting (that is, where it was not already canceled or where its blacklisting period has already expired) will be changed to earmark them as canceled.

At this point, of course, you are free to add the number again if you need to cancel it again.

Wrapping up

We expect that, at this time, you will have a solid understanding of what to use blacklists for, and how you should use them.

With them, you can set up flexible, effective, and eco-friendly campaigns that will help your business succeed and help make life easier for your customers.

Happy dialing!

What now?

If you’d like a test-drive, visit https://www.wombatdialer.com/ for a full featured trial.

WombatDialer 23.12: Dialing into a Better Experience!

Mon, 04 Dec 2023 00:00:00 +0100

WombatDialer, the go-to tool for outbound dialing on the Asterisk/FreePBX platform, just dropped a game-changing update - version 23.12. Buckle up, because it’s got some nifty improvements that’ll make your dialing experience smoother than ever.

Blacklists Got an Upgrade

The big ask from the Wombat community is here - the power to cancel a number from blacklists. No more workarounds; it’s a direct hit. You’re not deleting records; you’re updating them with reasons for cancellatiion. Wombat’s got your back, preserving information for future analysis.

Seamless Integration

Wombat’s all about teamwork. Now, HTTP notifications and Asterisk dial-plans get all the details they need for your call. Making Wombat part of complex data dances? Easier than ever.

Documentation Makeover

Blacklists got a revamp, and so did the User Manual. A brand new section, “Understanding Blacklists,” takes you on a journey through lists, blacklists, multinumbers, and API calls. Real-life examples? They’ve got those too. Check it out on GitHub and contribute your own wisdom.

Embracing the Modern Era

With CentOS 7 waving goodbye, WombatDialer ensures a smooth transition to CentOS 8/9 and Rocky Linux 8/9. Not a fan of RHEL derivatives? Fear not, the Debian installation tutorial got a facelift for flawless execution on current systems.

Wombat’s staying hip by fully supporting the latest MySQL and MariaDB versions. Choose your database adventure. Still clinging to Java 8? It’s cool, but Java 11 is here for better performance and future-proofing. WombatDialer - where tradition meets the future.

Upgrade now and dive into a dialing experience that’s flexible, integrated, and well-documented. WombatDialer 23.12: it’s not just an update; it’s a game-changer.

What now?

All details for this release are available on our What’s New in WombatDialer 23.12.

To update from a previous version, see Updating.

If you’d like a test-drive, visit https://www.wombatdialer.com/ for a full featured trial.

Creating a campaign from scratch using the JSON Configuration API

Thu, 16 Nov 2023 00:00:00 +0100

The JSON Configuration APIs that come with WombatDialer lets you perform anything that you can do through the GUI right from any piece of software you write, in any programming language you like. But how?

A lot of customers asked for real-life examples to get started - so we developed a set of scripts, built for ease of reading and understanding, that complement the User manual and show some real-life examples that:

Display the current configuration of your WombatDialer system
Display an existing campaign in JSON format - to be used as a template to create your own
Create a call list, upload some numbers to it (with their own attributes) and then read them back
Create a campaign from scratch - associate it with a trunk and an EP, add a lists and a blacklist, and create some sample reschedule rules and disposition rules on it.

This should be enough to make you productive in no time if you want to develop an API integration to WombatDialer, and complements the The JSON configuration API as it appears on the User Manual.

The full set if scripts is available on GitHub - if you create something out of it and want to share it, that’s a good starting point.

On GitHub, we also have a number of other scripts and examples in our repo Open WombatDialer Add-Ons.

WombatDialer References

For more technical information about WombatDialer please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a full featured trial.

Power Dialing at its Best

Wed, 10 Nov 2021 00:00:00 +0100

Your WombatDialer is quite a powerful tool: it is able to scale up significantly in order to manage thousands of calls at once. Whether you have 100 or 10,000 channels, you do not want to hit a wall the day you roll-out in production.

First, let’s define what we mean by high-volume dialing.

For the purpose of this article, we define “high-volume” as an amount of calls that will saturate a stock Asterisk system.
It is hard to put a specific value here - it depends on the kind of hardware you use and what your PBX is actually doing when processing your calls. If you really want to put a number here, say it might be around 250 calls, plus or minus 150.

Optimizing Asterisk

As Wombat relies on Asterisk for dialing, it is important to understand what are the challenges to high-volume call processing on your Asterisk system:

First, what you do really matters. The number of calls that your PBX will handle successfully depends on what you are doing on it and how expensive each call is. There are three usual suspects here: transcoding, call recording and AGI scripts.

Transcoding will use a lot of CPU to translate audio from some format to another. This happens silently every time you play a recording in a format and your channel uses a different format. Your music on hold is an MP3 and your channels speaks G729 - that’s transcoding. While this is a very convenient feature Asterisk offers, it is a no-no for high volume dialing.

Call recording may get very expensive pretty soon, as it will use precious disk IOPS to write hundreds of audio files to disk and precious CPU cycles to convert audio into your favourite storage format.
If you really need call recording, you should make sure it is turned on only when needed (for example, a callee is in conversation with an agent), that your disks are as fast as you can get them (and a ramdisk is a good choice here) and that the storage format requires as little CPU as possible.
For large scale recording, using a separate passive (network) recorder might be a good option.

AGI scripts require a process to be run on each invocation. They are often used in Asterisk as they provide a simple way to “glue” some logic and access to external services (webservices or databases) to the Asterisk dialplan.
They are typically written in slow, interpreted scripting languages and will definitely not scale. When running Wombat, it is usually a better option to pre-fetch any value of interest coming from external systems and having Wombat pass it to Asterisk as a channel variable.
For example, instead of running an AGI script that launches an interpreter that opens a database connection over which you run an SQL query to decide whether you should play a message in English or in Spanish, this could be a channel variable set by Wombat that already contains the name of a custom audio file to play back.

The second big thing you should consider is whether a GUI-based system is right for you.
Though having a GUI makes your life easier when administering the system, the kind of dial plan generated is often extremely byzantine and therefore slow. While this is done in order to offer you a ton of interesting features for your office PBX, you may find that you do not really need them all when you do large scale outbound dialing.
The best of both worlds is using some hand-coded dialplan for dialing out (the part that is called by Wombat), and using your favourite GUI for all other functions.

A third area of concern is caused by the AMI interface that Wombat uses to drive Asterisk.
The AMI protocol may get extremely chatty, as the system generates a lot of events, and this may lead to significant latency before all events are processed.
This can be addressed by filtering the set of events that Asterisk sends (for example: Wombat does not need dialplan execution events), but even in this case at some point the problem will manifest itself. Plus, Asterisk can only process so many requests per second, and at some point you will be wanting to generate too many calls for your Asterisk system to handle.

One last and general issue with Asterisk is that Asterisk processes voice channels; if the system is overloaded and voice is not processed in real-time, you will encounter voice quality issues.
Calling people and offering them a broken or unintelligible audio message is a big no-no. So you should make sure you have enough “capacity buffers” on your systems so that voice quality stays crystal-clear in every circumstance.

The real solution to high-volume dialing is therefore scaling out. This means running multiple Asterisk servers in parallel, each of which is processing only a limited set of channels that is well within its limits. Luckily, Wombat was designed from the start to handle a pool of Asterisk servers as if they were one single, larger machine. For Wombat there is almost no difference in processing 500 channels on one large Asterisk instance or 100 channels each on five different instances. This makes it possible to build real-world solutions that scale to the size of your problems.

Running large WombatDialer instances

Of course, WombatDialer has to work hard to drive a lot of calls at once.
It has to retrieve numbers and attributes from multiple lists, clear them against blacklists, keep track of recalls, and track live calls and live queues as each of them sends their own events. Plus, Wombat syncs the current state to a database quite often, so that in case something goes severely wrong and it crashes, it can restart exactly from where it left without losing any calls.
This is a lot of hard work, and happens in real-time.

When running Wombat, there are a few item that have to be tuned to make sure that everything runs smoothly; namely:

System I/O and database load
Dial latency and command queues
Network latency
JVM memory and GC policies
Humans!

System load

A running WombatDialer system can only be as fast as the database it syncs to. Though WombatDialer uses batching to send the database an efficient set of updates, at some point you are going to notice that there is significant I/O wait on the system.
You do not want I/O wait to go over 5-10%, because this makes Wombat less reactive; it takes more to fetch data and more to respond to changes on Asterisk, namely placing new calls.
This can be mitigated by tuning the amount of memory that is available for MySQL to be used as a cache; the default settings that MySQL ships with are inadequate to run thousands of parallel calls.
A faster disk layer (using SSDs and separate data disks) also helps a lot and can make all the difference.

Plus, Wombat has to fetch data from disk in order to know which calls are to be placed next. It does so by processing batches of calls, as this is way quicker than requesting each call separately, This means that when a channel is freed, Wombat already has a cached call ready to be placed. This value is controlled by the Batch size parameter on each campaign. A smaller batch size will cause Wombat to do more database work, but will cause less latency to be added. We suggest using a value that is about 2x the number of possible channels for a given campaign.

Dial latency

Dial latency is the amount it takes for Asterisk to “confirm” a call after it has been requested.
On a smoothly running system, very few calls should be appearing on the Live page in state REQUESTED. Those are calls that have been requested to Asterisk but have not yet been acknowledged.
Dial latency can be split into two parts:

The time it takes for a requested call to reach Asterisk.
Asterisk cannot process an infinite set of requests per second, and will likely crash when overloaded. Wombat tries to mitigate this by dividing a command queue into “time units”, where only so-many items can be processed in each unit. For example, the default is to avoid sending more than 5 commands every 50 milliseconds. This is a conservative estimate, and depending on your Asterisk hardware a limit of 10 or event 20 messages every 50 milliseconds might be working for you. Having multiple Asterisk servers means that there are separate messages queues connecting to each PBX instance and so each queue only holds a fraction of all outgoing calls.
The time it takes for Asterisk to confirm that a requested call is being processed.
If this time starts being in the order of magnitude of seconds, the system is likely overloaded. It is okay for confirmation times to spike up when starting a campaign with a lot of channels to fill at once; it is not okay to have them consistently high all of the time.

You can keep track of the combined time by looking at the value named Wait Pre in the reports, and by observing the percentage of calls in state REQUESTED on the Live page.
Watch out for maximum and average “Wait pre” times on your campaigns.

Additional network latency may be added by the network layer; WombatDialer is designed to work best with a local database and local Asterisk servers.
Turn-around time to the database and to the Asterisk servers should be ideally zero milliseconds; values higher than 100 milliseconds (e.g. running WombatDialer in the US with Asterisk servers in Europe and a database in Singapore) will not work for high-load scenarios.
Also, the bandwidth between all machines should be data-center or LAN class; consider that each large Asterisk instance might generate 4-5 megabit of events per second.

Memory and GC

As per memory, WombatDialer does not really need a lot of memory to run into - you can have the engine process thousands of parallel calls in as little as 256M of heap.
This said, if you run reports, have multiple users accessing the system, keep the Live page open and upload new call lists at the same time, the amount or RAM needed might be significantly higher. Plus, as with all Java applications, having less available memory means that the JVM has to be more aggressive in garbage collections.
This leads to very uneven latency and it may even cause “stop the world” garbage collection events. This is something you want to avoid at all costs; memory is very cheap, so you should give Wombat a good amount or RAM to run into, and use a throughput-oriented generational garbage collector that is optimized to avoid major collection events at the price of using more working memory.

Usage patterns

The last item on our list are human usage patterns; the less activity you will have on a system at peak dialing time, the better.
Don’t leave the Live page open “just in case”. Try to avoid running major reports or uploading very large lists when your system is fully loaded - most likely you can do it at a later time. WombatDialer includes a very extensive API that allows for complete remote control of Wombat instances.

Wrapping up

This said, it is reasonable to run thousands of parallel calls on a WombatDialer system with modern, high-end hardware.
During the years, we did some significant tuning and optimization on Wombat that means WombatDialer is about 2x as efficient as previous versions were.

In any case, remember to do a significant load test before going into production. Whether you have 100 or 10,000 channels, you do not want to hit a wall the day you roll-out in production.

Dialing thousands of channels may not be your piece of cake, but it’s nice to know that you can do it at the touch of a button. We believe that a good tool should give you margins for growth and preserve your existing investment and expertise. We work hard to make sure you will not have to worry about it.

WombatDialer References

For more technical information about WombatDialer call center solution please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a full featured trial.

Attend our Free Webinars for a live demonstration of WombatDialer.

Hey! There’s a Wombat in my Docker!

Tue, 21 Sep 2021 00:00:00 +0200

When Erwin started talking about ships and sailing, we considered it quite normal. But what is Erwin doing on an (apparently pirate) container ship?

Yes - WombatDialer is now available as a working Docker image.

Why is this cool?

Docker containers are a new standard for infrastructure management. Docker containers let you install and upgrade software without worrying about dependencies and software versions - each of them behaves as - if it was a separate virtual machine, but it is lightweight as the actual running processes and has very low latency.

This plays very well with WombatDialer, that is an extremely flexible and scalable outbound dialer for the Asterisk PBX. It follows our philosophy that you should tell the system what you want done, not how, and that WombatDialer will take care of all the low-level details (errors, reschedules, call handling, server clustering, logging) while you focus on the high-value-added business application; be it call reminders, queue recalls, telephony surveys… you name it.

What does this means for WombatDialer?

You can run the Dockerized version of WombatDialer in a single command on any Linux OS that supports Docker. So to test-drive WombatDialer on a new system running Docker v1.0+, you just enter:

docker run -p 8080:8080 -P -d loway/wombatdialer

This downloads an image containing Wombat and its database, and starts it by binding it to port 8080 of the local server. So you can connect it as http://[serverip]:8080/wombat and it will run immediately. Docker runs on CentOS 7 and Debian systems. Just make sure that you are running version 1 or newer. Want to test-drive it fully? Get a free WombatDialer demo key and start serious dialing immediately.

To make sure it’s running and find out the id, enter:

docker ps

And to stop it:

docker stop {id}

Each container is run as a separate instance; so you could have multiple distinct WombatDialers on the same box, just by binding them to a separate public port.

Want to run a quick test? Just start a new instance, do your testing and throw it away. Each instance starts as a clean-slate, with a clean database and configuration ready to be customized.

That’s nice but… how do I keep the data between different runs?

WombatDialer uses a pattern called “data-only containers”. This means that you can have special containers that only contain the data (databases and custom configuration) where everything else is in a code image. You do this by creating a data-only container, giving it a name, in our case it’s “MYWBT”, and mounting it to your WombatDialer instance.

docker run --name=MYWBT loway/data true
docker run --volumes-from MYWBT -p 8080:8080 -P -d loway/wombatdialer

So if you run a WombatDialer instance without a special data container, everything will be put in the code image. If you do, all data that is supposed to be present on an update will be stored in the data-only container.

You want to upgrade WombatDialer because a new version is out?

Stop your existing Wombat instances, and run them again on the same data containers. Docker will download the latest version and when you connect to it, the database will be automatically updated.

Want to make backups?

Connect to the data-only container using a tool like “nsenter” and run a backup job.

What is coming next?

We expect Docker to play a significant role in infrastructure management. We believe that it makes it so simple to run WombatDialer instances that end up being just “fire and forget”. Plus, having higher performance, lower memory consumption and lower latency compared to a separate VM, it plays especially well for telephony applications.

WombatDialer References

For more technical information about WombatDialer call center solution please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a full featured trial.

Attend our Free Webinars for a live demonstration of WombatDialer.

Introducing WombatDialer 21.06

Mon, 31 May 2021 00:00:00 +0200

WombatDialer 21.06 released today

Loway is proud to announce the release of WombatDialer 21.06; this release is mostly centered around the API side of WombatDialer and makes its integration with external systems easier and safer to run.

WombatDialer boosts agents productivity and improves your contact center’s outbound flow. You can easily implement automatic dialing, Text-to-Speech integration and call-back options on unanswered calls. You can configure your outbound campaigns with different dialing modes including direct, reverse, preview, manual and predictive.

What are the main improvements for this release?

Improved API security
Backpressure on number uploads
AUTO calls start from attempt 0
Externally-fed API Queue end-points
GUI Improvements

On top of this, about 25 bugs and minor issues were fixed.

It is immediately available as an RPM archive, a TGZ archive or a Docker image.

Improved API security

When WombatDialer was created about almost 10 years ago, it was meant to be deployed on a local network. Things have changed quite a bit, and now we see a lot of deployments that go straight to the cloud.

As it was meant to be run internally, and to be easy to interact with out of the Asterisk dial plan that is rather limited in its API interactions, while human users enjoyed full security access control, APIs were simpler and we suggested using an external HTTP server as a chokepoint whenever it was appropriate.

Now, as an evolution, we offer token-based authentication so that you can enforce a token to be present on all API calls. You can have multiple tokens enabled at once.

This option must be enabled manually, but should allow for a safer deployment on networked systems.

See: The WombatDialer User manual, section: 8.3.1

Back-pressure on number uploads

If you have implemented a busy WombatDialer system, most likely you are aware of the fact that you can upload numbers one by one and have them added to a list that is running by calling a very simple HTTP API. This happens very fast, because Wombat will only make sure that the number is queued for being consumed before replying that it’s okay.

This process was designed to upload numbers - for example for recalling customers who are finding a long busy queue - so you have just a few per second as the worst case,and we didn’t want to block the PBX for a longer time than strictly necessary.

This works fine if you drip numbers in a small lots, but if you upload thousands of numbers at once, they end up being too many to be processed and Wombat may stall trying to process them all at once.

In this version of Wombat we added back pressure control to the call upload API, so that the call will not return unless the number has been added correctly to the campaign. This makes it way slower, but it also make sure that adding numbers will blend in correctly with a busy Wombat system. This behavior can be overridden by adding the parameter fireforget, that effectively restores the old behavior.

We also fixed a possible issue with starvation that could happen if too many numbers were being added at the same time when campaigns were running. Now, any running campaigns have a higher priority and may delay numbers being added, but not the other way around.

See: The WombatDialer User manual, section: 8.3.2

AUTO calls start from attempt 0

This is again a change in behavior: on earlier Wombat versions, when you add a number to an AUTO list, it is considered a reschedule and not a “cold” number. You would notice it because its attempt number was 1 and not zero, and was not much of an issue in itself.

The problem happens when you use this feature together with multi-numbers, because it being attempt #1 it will first attempt the second number and not the main one.

This was confusing, and is now fixed.

See: The WombatDialer User manual, section: 8.3.2

Experimental feature: Externally-fed API Queue end-points

WombatDialer was designed to work as a controller of one or more clustered PBX systems, so it’s expected that all the information about the state of agents it may be interested in will be immediately available from the PBX’s own update mechanisms when Wombat needs it to make a decision.

Still, we are seeing a number of people interested in tracking the state of an external queue, one that is not available on the PBX that Wombat is monitoring, and one that may be for example on a third-party’s premises, e.g. when you do call pre-qualification and have multiple clusters stacked hierarchically.

To handle this, we thought that we could turn the problem on its head. Instead of being Wombat that goes out and tries to understand the state of a queue, and an external system will notify one but when something of interest happens, typically when one of the target agents changes its state. This happens through an API call.

This feature is at the moment experimental, because it’s still new and we want to understand how it could work in real life in a way that is simple enough to be used by the majority of our customers. Still like you can testify and benefit from it. Just remember that state updates it must be timely, otherwise Wombat cannot make the correct decisions.

See: The WombatDialer User manual, section: 3.4.2. API-driven queue end-points

GUI Improvements

We’ve had a number of smaller changes that were meant to make the GUI easier to work with.

Buttons and end-point selectors on the Live page look better and are little easier to use.
The endpoint configuration used used to display an outdated message.
The agent reverse dialing page was totally redesigned, so that so that it looks a bit better. That page was meant to be just an example of how to implement a reverse dialing page, but most people ended up using it as it is, and so we made sure it is cleaner.

WombatDialer References

For more technical information about WombatDialer call center solution please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a full featured trial.

Attend our weekly Free Webinars for a live demonstration of WombatDialer.

Handle queue peak times more effectively with WombatDialer call-backs

Tue, 02 Jun 2020 00:00:00 +0200

How can you handle your call center peak times more effectively while agents are working from home?

Due to recent COVID19 pandemic, most call centers are adopting remote working solutions. This can create a problem as agents will work from home or outside the company, staff is reduced and your service level performance suffers.

If you are running an inbound call centre it often happens, especially with reduced staff or remote workers that you experience long waiting times in specific days of the week or hours.

Wait times peak and abandon rates spike can be very frequent. Your call center managers will be very concerned of having to hire and train some temporary people in order to handle load that only happens on a few days.

With WombatDialer predictive dialer you can successfully manage this situation using Queue Call-Back feature.

WombatDialer is highly scalable software, multi-server and works with your Asterisk PBX. With its campaign management tools it boosts agents productivity and improves your outbound campaigns with automatic dialing, queue recalls functions, call forwarding options, and different dialing modes including direct, reverse, preview, manual and predictive.

You can configure your Asterisk PBX so that when people are tired of waiting, they press a digit and get to a menu where they can leave their number. Then the system queues their call and attempts to call them at a convenient time but only when some of your agents are sitting idle.

This helds your waiting times and abandon rates to go down, and by placing calls at a convenient time you can smooth out the workload of your agents during the day, just by moving agents to a dedicated inbound queue.

To do this on a plain Asterisk system you will have to create a database and write a script that reads back from it. You have to handle invalid numbers and busy numbers. You need to have a GUI of some kind for the manager to start and stop dialing and you have to adapt to the number of available agents. Additionally you have to report on this activities and to avoid flooding the trunks of your PBX with too many calls. In other words, it’s the kind of activity that gets more complex the more you think about it.

That’s what WombatDialer is for.

You can use WombatDialer as a call-back engine. It can be controlled by an external HTTP API, so you can do that from the Asterisk dial-plan. It has a definite topology and call back rules, so you get the number of calls you expect on one or more Asterisk servers. It follows opening hours so calls are never placed at the wrong time; it does not interfere with calls that are not its own and retries calls automatically. It keeps track of call completions and knows what to do in case of invalid and busy numbers.
It has reports of its own and can work with QueueMetrics for powerful and detailed reports.

If you are interested in this feature do not hesitate to contact us, our engineers will guide you towards the best solution for your call center daily management with Queue call-back.

Start your WombatDialer predictive dialer free full featured trial at https://www.wombatdialer.com/

WombatDialer References:

For more technical information about WombatDialer call center solution please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a full featured trial.

Attend our Free Webinars for a live demonstration of WombatDialer.

Introducing WombatDialer 20.02

Mon, 17 Feb 2020 00:00:00 +0100

WombatDialer Release Version 20.02

Loway is proud to announce the release of WombatDialer 20.02; it was designed to make the life of administrators easier, with many small fixes that improve the overall experience of running the dialer for both small and very large systems.

What are the main improvements for this release?

Improved handling of black lists
Tracking of attended and unattended transfers from queues
Improved GUI
Improvements to the API, with full visibility of JMX internals

On top of this, about 40 bugs and minor issues were fixed.

Improved black-lists

You asked and we listened: this is an apparently simple change that has deep implications. WombatDialer has powerful black-list where numbers can be added at any time and for any specified duration of time - one minute to a month or more. As you can imagine, black-lists are central to compliance with local regulation in many parts of the world.

So far, black-lists were checked only when starting a new call, so if the call was allowed and it needed multiple attempts to go through, all of them would be made even if the number had been black-listed in the mean time.

With WombatDialer 20.02, black-lists are checked on each and every attempt, so as soon as a number is black-listed, all subsequent attempts to dial it will be caught. This means you can use black-lists in a way that is more natural, and create new scenarios: for example, to cancel further scheduled outbound calls when a caller happens to call in first.

See: The WombatDialer User manual, section: 3.6.6. Black lists

Tracking of attended and unattended transfers

It is quite a common scenario for outbound contact centres to have agents contact and qualify a prospect, and then transfer them to the appropriate department. When this happens, the original agent will be free again to take another call.

Historically, call transfer support on queues with Asterisk was not that good, and only unattended transfers were supported. Luckily, this has improved significantly since Asterisk 13, and WombatDialer now supports it fully for both attended and unattended transfers, making the agent ready to take a new call as soon as a previous one is transferred.

You can use both attended and unattended transfers, and it works in direct and reverse dialing mode, with or without predictive over-dialling.

See: The WombatDialer User manual, section: 3.8.3. Call transfers

Improved GUI

Selecting multiple runs for inspection on the Reports page is easier, with a select all/unselect all checkbox for each campaign.

Users can now change their own password right from the GUI, through a new integrated password change panel:

The Copy Campaign feature requires a new, separate security key called COPY. On upgrade of an existing system, you will see that the option is disabled until the new key is granted.

The Reverse Step-wise dialer panel had a face-lift to make integration with QueueMetrics more natural and working with it more pleasant.

The Dialer State page now features a different icon for stop-and-restart, as it looked too similar to the one used to refresh current state on the home page.

Improvements to the API

The elephant in the room here is JMX counters: these are the standard mechanism a Java program uses to publish performance counters. They expose a wealth of information on what WombatDialer is doing internally - memory and CPU usage, number of operations, delays on queues, fine performance of many separate operations, number and delay of messages exchanged with the PBX, for a total of over 140 counters.

Now, WombatDialer exposes all of them as a simple JSON service, without the hassle and the complexity of setting up a JMX client. So it is very easy to push them to a graphing or monitoring back-end in order to observe and monitor performance over time.

The API now returns the correct campaign-list association as soon as it is created, saving you a second round-trip to fetch this information on campaign creation.

See: The WombatDialer User manual, section: 8.3.7. JMX statistics

Misc items

Full compatibility with Asterisk 15 and 16 (current LTS)
Extensive testing of PJSIP channel support
Fixed issue with local logging where data would not persisted to the database on some restarts
Addressed an auth bypass bug on campaign creation
Addressed security bypass on end-points through the GUI
Compact and easier-to-read representation of AMI blocks in debug logs
Pause events would not be tracked correctly on Asterisk 13+
Improved set-up wizard
Upgraded GWT version and collapsed obsolete browser versions into single build.
Clean-up of various deprecated methods
Manual preview mode enforces Reverse Dialling in the editor

Get it now!

WombatDialer 20.02 is immediately available, as a RPM package for CentOS 6+, a tar.gz archive or a pre-configured Docker image. Get it from https://www.wombatdialer.com/installation.jsp.

The updated User Manual can also be found on the Downloads page.

If you currently have a licensed WombatDialer system, you can upgrade now at no extra cost.

We welcome your comments and feedback.

Happy dialing!

WombatDialer References:

For more technical information about WombatDialer call center solution please refer to the User Manual.

Visit https://www.wombatdialer.com/ for a 30 days full featured trial.

Attend our Free Webinars for a live demonstration of WombatDialer.

WombatDialer Blog

WombatDialer Security Update: Addressing Two Vulnerabilities

Vulnerability Details

CVE-2024-57055 - Server-Side Access Control Bypass

CVE-2024-57056: Incorrect cookie session handling

Mitigation

Acknowledgement

How to Upgrade

What now?

WombatDialer 25.02: Dialing into a Better Experience!

Security Update

Call reporting

Documentation and installation

What now?

Understanding blacklists in WombatDialer

How do blacklists work?

Plain lists vs blacklists

Blacklists and multiple numbers

APIs and integrations

Wrapping up

What now?

WombatDialer 23.12: Dialing into a Better Experience!

Blacklists Got an Upgrade

Seamless Integration

Documentation Makeover

Embracing the Modern Era

What now?

Creating a campaign from scratch using the JSON Configuration API

WombatDialer References

Power Dialing at its Best

Optimizing Asterisk

Running large WombatDialer instances

System load

Dial latency

Memory and GC

Usage patterns

Wrapping up

WombatDialer References

Hey! There’s a Wombat in my Docker!

Why is this cool?

What does this means for WombatDialer?

You want to upgrade WombatDialer because a new version is out?

Want to make backups?

What is coming next?

WombatDialer References

Introducing WombatDialer 21.06

WombatDialer 21.06 released today

Improved API security

Back-pressure on number uploads

AUTO calls start from attempt 0

Experimental feature: Externally-fed API Queue end-points

GUI Improvements

WombatDialer References

Handle queue peak times more effectively with WombatDialer call-backs

How can you handle your call center peak times more effectively while agents are working from home?

WombatDialer References:

Introducing WombatDialer 20.02

WombatDialer Release Version 20.02

Improved black-lists

Tracking of attended and unattended transfers

Improved GUI

Improvements to the API

Misc items

Get it now!

WombatDialer References: