I have been working with VoIP systems for over a decade. My original experience was with wholesale exchange platforms, focused on high volume LCR. I designed and implemented numerous bespoke applications that provided convenient, web-based controls to a variety of underlying SIP servers.

Back in the days, commercial large-scale VoIP was dominated by closed-source products – brands like Mera, MVTS and VoipSwitch. What they all had in common was a monolithic structure, pretty reasonable performance, and horrible GUIs:

Luckily, all of these systems relied on SQL databases to store their configuration, which opened the doors to custom built web-based interfaces. Initially, most of my projects were focused on making these soft-switches usable by providing more user friendly controls. The next step was adding an accounting layer, followed up by a turbocharged reconciliation and fraud detection. Being able to control multiple switches from different manufacturers, easily deal with pesky interconnections and generate invoices with a single click was a major improvement for the traders using our product.

It wasn’t until Freeswitch came by with their LUA and CURL support when I was finally able to control the traffic directly using my own platform. At this point our LCR (very original name indeed) system was mature enough to deal with tens of thousands of calls without having to rely on a 3^rd party SBC.

One thing all these stages of integration had in common was that they were hacks. None of these solutions were natively supported and most had drawbacks, the most common being a delay between a trader submitting an instruction and the switches picking it up.

Fast forward a couple of years, Asterisk unveils its two distinct APIs designed to manipulate the call flow and receive update events. AMI/AGI were definitely a step in the right direction, but the implementation was far from perfect. Due to opposite nature of the two (sync vs async), it was very challenging to achieve a uniform and easy to read code that would control both ends of the call (instructions and events).

And then came ARI. Rather than reinventing the wheel again by designing its own bespoke protocols, Asterisk folks decided to use well established technologies to facilitate communications between external code and the PBX. REST and Websockets made it trivial for anyone to connect and take advantage of this new uniformed approach. And for those too lazy to bother with HTTP (including myself), it came with official Python API.

For the first time in a decade I was able to seamlessly integrate call control into my business code. There was no need for dirty tricks anymore – they were replaced with this fuzzy feeling of native support.

To my surprise, ARI has yet to become widely adopted. Some still consider it immature, others have never heard about it. I personally find it revolutionary, and while I respect the conservative choices of dialplan proponents, I cannot imagine stepping back and replacing the modern ARI code with GoTos and macros.

It is by all means far from perfect. I feel like the manual should be rewritten and focused a little bit more on use cases rather than being based mostly on API reference. There are still bugs in Asterisk (13.9.1 at the time of writing) that may present a challenge to wide commercial implementations. Some features, like bridge channels separation in recordings, are yet to be implemented.

The greatest obstacle for aspiring developers, which I feel deserves way more attention from the manual authors, is the asynchronous nature of ARI. Despite growing popularity of client-side frameworks like Angular, it is not what most server-side apps developers are used to in their everyday work.

Production stage implementations should be preceded by stress tests. One issue in particular has to be closely monitored – resource usage and deallocation. I will describe it in greater details in a follow up article on ARI application structure.

All in all, I feel like the benefits of ARI greatly exceed any costs associated with these few shortcomings. Despite being fairly new technology, the attention it gets from Asterisk developers makes it a sound investment for new applications.