a2billing – How do we compare?

January 14th, 2010

We are often asked how we compare to a2billing. This question usually comes from customers who are using a2billing but are looking for a more comprehensive alternative, or customers who are starting a new business and are evaluating the different telecom billing systems available.

In this article, we will attempt to highlight the primary differences. 

Architecture

At the architectural level, a2billing is what we would refer to as a bundled system. i.e. the switch and the billing software are on the same server and share resources. This configuration is low-cost but it introduces performance, scalability and security concerns.

Running both your switch and your billing operations on the same server will also introduce performance issues as both systems are competing for the same resources.

As a bundled system, it is limited to the scalability that can be acheived using a single server only.

Having to open billing-related ports (HTTP, HTTPS, etc) on your switch will encourage malicious individuals to attempt to compromise your server.

Our system is what we would refer to as stand-alone. i.e. it is independent of the switch (or switches) and makes use of APIs to integrate with whatever switch or PBX is being used. It runs on its own server(s) and has dedicated resources. Although this scenario has higher start-up cost, it offers greater performance, security, scalability and integration opportunities. 

Codebase

A2billing is an open-source project lead by a single individual with code contributed from various programmers.

Our system is a commercial application designed and built by a team of development and support staff. As such, we provide scheduled releases and dedicated support via email, phone, remote desktop and live chat. 

Interoperability

Interoperability is another key difference between our systems. A2billing was built specifically for use on Asterisk® and currently does not operate with any other switches/PBX systems.

Our system, on the other hand, uses standardized APIs to interface with whatever switch/PBX is required for the deployment in question. This approach affords you the flexibility to use whichever switch (or switches) best suits your needs at given time in your business’ life cycle; giving you more control over your future growth. 

Summary

A2billing may be suitable for sites who intend to use Asterisk and only expect limited growth.

Our solution can work for you at the start of your business and stay with you as you grow to support thousands of concurrent calls per server.

Our system is geared towards deployments that may need to interface with multiple switches and require a higher level of scalability, integration, interoperability and customization.

Additional information about bundled vs. stand-alone deployments is available at http://dthvoipbilling.com/wordpress/?p=3

To find out more about our system, please contact us. 

Asterisk is a registered trademark of Digium, Inc.

Choosing a VoIP Billing Solution - Bundled or Stand-alone

December 16th, 2009

If you are planning on launching VoIP services, you will inedvitably be faced with the question ‘How will I bill for the services we provide?’ 

Billing for VoIP services can be a daunting task as there are a wide variety of additional features (included minutes, call forwarding, voicemail, IVR, ring groups, callback, etc) that must be accounted for on top of the standard origination/termination services.

Assuming you don’t have Development staff in-house to build a custom system, you will have to evaluate a variety of systems on the market. A simple search for ‘voip billing software’ will return many pages of options.

There are two main models when it comes to selecting your billing system; Bundled or Stand-alone.

Bundled refers to a billing system produced by the same company as your switch/PBX. The billing component is typically sold as an add-on module to your switch and runs on the same server.

Stand-alone refers to a software package that is produced by a third party development house and is not tied to any specific switch or PBX. These packages make use of generic APIs (Application Programming Interface) to integrate with your switch and other systems.

Both models have their strengths and weaknesses. In this article, we will attempt to highlight the important ones.

Cost - In most cases, the bundled model is more cost-effective as the billing component is simply sold as an additional module on top switch licensing. In the stand-alone model, your billing system would be a separate software license from a different company.

Performance - In the bundled scenario, the billing component is likely installed on the same server as your switch software. Although this would provide improved performance during authentication and authorization, it will severely limit scalability as your switching and billing tasks are now being performed by the same server. VoIP billing has many resource-intensive operations (call rating, reporting, etc) which would negatively impact your switch performance while they are running. You may notice decreased call quality while you perform simple billing operations or run reports.

Integration - In the bundled scenario, the switch and billing system are produced by the same company and often are part of the same codebase. This makes deployment of a bundled solution considerably easier as the switch and billing were ‘made for each other’. In a stand-alone scenario, the billing software manufacturer must write integration routines for each switch they work with.

Customization - It is very common in this industry to require customizations to your billing system. This is often done to facilitate data transfer to/from external systems or simply to enforce business rules that might be specific to your company. Manufacturers of stand-alone billing applications deal with customization on a regular basis. Every switch or PBX they must integrate with is effectively a new customization. Customization is just a part of daily life.

Manufacturers of bundled systems are less likely to engage in customization as it is not part of their daily requirement. Their billing code was written to operate with one switch (theirs) and there is little requirement to integrate with external systems.

Maintenance - Each configuration has its own strengths and weaknesses when dealing with system maintenance and upgrades. In the bundled scenario, you may only have to perform a single set of maintenance and upgrade routines in order to keep your entire system up to date and running smoothly. The downside is that you can’t perform maintenance indepedantly should the need arise. Suppose you needed to take your billing system offline temporarily to apply a fix to it. This might also require taking your switch offline since both components reside on the same server and are likely part of the same codebase being upgraded.

In a stand-alone scenario, the opposite is true. You would have different maintenance and upgraded tasks for each component. This leads to additional work but is also provides the ability to perform maintenance on one component without affecting the other. Which one is right for you would depend on the skill set available and the level of service you need to provide to your customers.

Security - Each scenario also has its own security pros and cons. Most billing systems require opening additional ports in order to allow customs to log in, view invoices, make payments and perform self-service. In a bundled scenario, this would mean having to run additional services (web server, etc) as well as open additional ports to the same server running your switch/PBX software.

In a stand-alone scenario, each component runs on their own server and can be secured differently. Although this means you need to perform the additional work of securing two servers, it also gives you the ability to expose only the services required by each component. i.e., you would not have to expose a web service on the same server as your switch.

Summary - For deployments requiring more scalability, customization and abstraction of components (billing, switching) , purchasing independant stand-alone system would be the better of the two options.

 If we can offer one piece of advice, it would be to sit down and document your billing requirements beforehand and share those requirements with any vendors you speak to. This will help you to evaluate the available billing vendors more affectively. It will also allow the prospective vendors to address your specific concerns and guide their demo and communications accordingly.

 DTH Software, Inc is a provider of independant (stand-alone) telecom billing solutions. Information about our VoIP Billing software is available at http://www.dthvoipbilling.com/