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.

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

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

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

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

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