We see a lot of questions in support and sales (especially after the VoipNow 1.6.2 release) about VoipNow CallAPI. It looks to be some confusion around this subject. In VoipNow we have two CallAPIs:

• a very easy to use HTTP interface, you can use to send calls, list, hangup, etc using HTTP GET requests.
• an Asterisk Manager interface that technically can be used with any client that can work with Asterisk Manager

I want to discuss about the Asterisk Manager interface, as it’s more difficult to understand. As you know VoipNow is a multitenant system. This means that you can have multiple customers on the same machine. You do not want customer X to see customer Y calls or to hangup them.

Unfortunately, the Asterisk manager does not care about multi-tenancy, scales very poorly with multiple connections and the authentication mechanisms are far from great. We could have rewritten the entire manager interface, but this would have created a management issue for our Asterisk build.

The natural solution was to create a proxy. There is one Open Source proxy called Astmanproxy, which is pretty well known, so the approach is not new. New was what we wanted to achieve with this proxy:

• Integration with VoipNow. This means that the proxy should read the MySQL database
• Quality of Service. We were particularly interested in limiting the number of connections and number of commands sent by a user, to add black list and whitelist per IP. Otherwise you cannot really open such a service to the Internet.
• Filtering and isolation, this means that a user logging to Call API as customer X should receive only events that are related to customer X. The proxy should ignore any command that targets a resource not owned by customer X.
• LUA scripting for requests and answers, so the engine could translate requests and server answers before they are sent to the customer. This way the proxy could work with virtually any Asterisk Manager client, because the user can use LUA to translate requests, if these are not properly made (clients are quite different).

When we started the project we want to build these features on Astmanproxy. It was an Open Source project and we didn’t want to spend time reinventing the hot water. Unfortunately after we added most of the features to Astmanproxy, we discovered a lot of issues with it under load tests (most issues due to the threading implementation), so we started to modify it extensively. I think that today only around 20% of the original code was preserved, which is not the brightest example of software engineering.

This project was made open source and will be committed to the upcoming 4PSA Developers Network which is due this summer. I will let you know of course as soon as it will become available.