Here it comes the last posting of the “Billing calls from meshed potatoes” sequel.

Coding is an interesting exercise of long term investment. In fact, “for every minute spent in organizing, an hour is earned”. In October 2009, Areski (A2Billing) visited IT46 in Stockholm. There were two main answers to our “easy billing” challenge: a quick hack that will never be reusable or to add an API to A2Billing so other applications could be build in the future.

The “quick hack” consisted in collecting the information from the user (the Installation Wizard GUI) to later alter the SQL database (dump a bunch of nasty INSERTS!). The other alternative (the nice one) was to build an abstract layer at the top of A2Billing that could perform several “primitives” on behalf of the wizard.

We spent a couple of days with pen and paper, starting with the technical requirements of the Village Telco. Finally, we concluded that an “ugly hack” was going to give us more problems in the long round… so we took the decision to build something that we should not be embarrassed of in the future. After all, open source is the result of peer pressure. .

We decided (1) to build the Installation Wizard using a MVC framework (Cake PHP), (2) to use SOAP as a transport mechanism between the Wizard and A2Billing, (3) extend A2Billing to support our general API.

This was a very nice arrangement, Areski could concentrate in building the internal logic. There are so many tables in A2Billing that I still wonder how Areski could figure out what everyone is doing!. In our side we decided to concentrate in building the Wizard (full of round corners!). The Installation Wizard should be based in the well known user-friendly principle of (Next, Next, Next, Accept).

Louise has been programing intensively with Cake PHP for the last 6 months, and she did not want to write the code in anything else. It has been a very nice programming project, the new API glued all together… and every day we were figuring out a way to reduce the number of clicks that the user need to put the scenario up and running.

Our main finding was that there is still plenty of work to do in the provisioning of VoIP upstream providers and the potatoes themselves, when it comes to upstream providers our goal is to make sure that the user does no need to type any SIP parameters at all into the system (account, password, codec, etc). The wizard will present to the user a set of VoIP carriers and by means of an activation code the system will auto-provision! (One click!) There is plenty of things that can go wrong… when hooking our local telephony mesh to an external gateway… and that means lots of code inside.

For the curious this is the last step of the Installation Wizard before launching the final installation against A2Billing.

Today, we can bill local calls with a few clicks and it is time to start thinking in the overall provisioning!. Provisioning, it is definitely a Village Telco component that it is going to need more than our brains! We are getting there, it is easy to forget that one year ago we were just imagining something like this!

Related posts:

1. Billing calls from the potatoes (Part I) It has been a year now since we started...
2. Billing calls from potatoes (Part II) In November 2008, Steve, Louise and myself sat down...

Related posts brought to you by Yet Another Related Posts Plugin.

In November 2008, Steve, Louise and myself sat down in Irene (a small “township” south of Pretoria) and started to draft what we considered a billing scenario for the Village Telco. A few nice ideas came up from that meeting: the relevance of local calls, voicemail, the possibility to switch your potato from pay phone to personal phone, focusing on pre-paid models, etc.

Can we take a VoIP billing software and make it simple enough for our expected Village Telco scenario? This is not a trivial question to answer, what is “simple enough” and what is relevant to our target group? I like to explain usability and business models taking the asterisk GUI and linksys wireless AP as an example. What is better, to have a software that can do almost everything you want but only a few can configure correctly or a solution that does something very concrete out-of-the-box?

I call this the “asterisk vs linksys”. Steve prefers to call it “drupal vs wordpress”. Someone will accuse me of opening a topic that can lead to a DNFTT situation (Yes!, look for the term DNFTT and you will see what I mean). In any case, our gut feeling is that we needed the “wordpress of billing”, something that is simple enough, with default values to fit our scenario. It won’t do everything, it will do a few things very well. What I did not know at that time is how much time and energy can take to make things simple for others to use! It remind me those times when you needed to know the horizontal input frequency of your screen to get your graphical interface running. Can we make billing simple? Can we make it to work out of the box without imposing users to understand the meaning of codec, trunk, SIP, challenge-response or MD5 hashes? Can we survive the flame-wars of the geek community insisting that users needs to know advance cryptography to run a secure VoIP call?

In September 2009, we had a clear understanding of what simple billing could look like and what two big pieces of code were needed for A2billing: (1) an installation wizard, (2) a simplified management interface.

So we put together a document including the seven technical requirements of the installation wizard:

R1 Billing

• The main billing system will be pay-as-you-go

• The system should provide mechanisms to avoid fraud

R2 Connectivity

• The VT and billing platform does not depend on an Internet connection

• No Mesh Potatoes or Upstream Providers need to be active to configure the VT billing platform

• The wizard will assume that the upstream provider is reachable via IP/SIP

• Other trunk technologies as GSM, PSTN, will provide a SIP interface to the a2billing system

R3 Client Hardware

• The Mesh Potato will be the main hardware and can operate in two main modes home/business phone or pay phone mode

• A client device should have the ability to operate in one or two modes

R4 Client Types

• Three types of accounts need to be supported in the system

1. account only: customer has an account with credit into the system
2. phone number# only: customer has a phone number but not a physical phone
3. phone: customer owns a phone with a # and an account associated with it

R5 DID

• The system can support 0,1 or N (many) DID numbers. When DID numbers are more than 1, we assume a pool of numbers

R6 Voicemail

• Any person with a DID (external or internal) should have a Voicemail

• Voicemail should be reachable by any phone

R7 Callplans and Rates

• The selection of the provider, implies the automatic creation of a rate plan associated with the provider

• Users should not have to deal with dialplans in asterisk, including all main contexts: call outs, recharge, did, voicemail

Time to move the specifications into an architecture model!

Extending A2Billing to support our Installation Wizard

The picture (green area) shows what A2Billing provides by default. Changes to A2Billing (as getting a basic scenario up and running) require accessing the web GUI.

The Village Telco has extended A2Billing to include (1) our Simplified Management Interface and (2) a Web service that talks with A2Billing internal logic. This new Webservice presents a API that hides the complex SQL back office logic.

The idea behind this new (abstract) layer of communication with A2Billing was to allow the design of third party applications that can perform complex tasks inside of the Billing Platform. The new API currently consists of 26 functions that are accessible via a SOAP interface.

Our Village Telco Installation wizard makes use of the newly developed API. With this approach, the Installation Wizard does not need to know anything about A2Billing’s SQL . Hopefully, any changes inside of the internal logic of A2Billing will not break our Wizard.

So how the wizard look like?

Simple… full of round corners and performs a default installation of a local Village Telco A2Billing in 12-17 clicks!

Screen shoots follows in Part III

References

[1] A2Billing Webservice API

https://docs.google.com/Doc?docid=0AX-tdmlhxGGBZGh0bmtncTZfMGN6aGh6Z2Zy&hl=en

[2] Installation Wizard Development SVN

http://svn.it46.se/svn/villagetelco/a2billing/wizard/

[3] Simplified Management Interface SVN

http://svn.it46.se/svn/villagetelco/a2billing/gui/

[4] A2Billing Village Telco Contrib Branch SVN

http://svn.a2billing.net/svn/asterisk2billing/trunk/addons/contrib/villagetelco/ (user/passwd: guest/guest)

Related posts:

1. Billing calls from the potatoes (Part I) It has been a year now since we started...

Related posts brought to you by Yet Another Related Posts Plugin.

It has been a year now since we started to look into billing for the Village Telco. It is about time to announce where we are in terms of development. We have been so busy that we forgot to write about what happened behind the scenes. A bit of it in the next few posts!

A quick reminder about where we want to go:

The Village Telco runs several functional components, the mesh potatoes (our open hardware) route wireless VoIP calls via other mesh potatoes. Mesh islands (the bunch of potatoes in the same ad-hoc channel) can be interconnected by means of “super nodes”. The super nodes are responsible of linking different mesh networks, allowing multiple wireless channels to coexist in wide wireless area network. Yes, so we can scale up!. Mesh potatoes are monitored thanks to Afrimesh and will be happily provisioned by our budding server (also a botanic term that i really like!)

Local and external calls needs to be billed and upstream technologies for telephony needs to be plugged into our mesh cloud.

Now that you got the introduction to the Village Telco architecture overview… this is how we tried to find a solution for billing the potatoes!

The past December, we (IT46) took the responsibility to look into billing and upstream technologies for the Village Telco. After some research in billing systems for VoIP, we found A2billing! A2billing is a LAMP application that sits at the top of Asterisk that bills and manages VoIP calls. A2billing takes advantage of the Asterisk Manager Interface (AMI) and Asterisk Gateway Interface (AGI) to deal with the call logic. Several thousands of lines of PHP and almost a hundred MYSQL tables glue all together!. Powerful but definitely not simple for our Village entrepreneur.

In my way to Spain in Christmas 2008, I made a stop over in Barcelona. Barcelona is a truly international city and the current base of Areski (the core technical developer of A2billing) and Joe (commercial director of Start2billing). It was a very fruitful face to face meeting between a Belgian living in Barcelona, a British living in his boat somewhere in the Mediterranean and a Castillian living in Sweden. I explained Areski and Joe what we wanted to do in the Village Telco, about the mesh potatoes (a hardware that did not exist by then!) and why I liked A2billing. I am not sure if they thought I was mad, but I had to give it a try and meet the people behind the code.

During the next three months I put some time to understand the internals of A2billing, helped to make their GUI more human friendly and wrote some documentation. In a geek world, trust is when you get write access to main trunk in SVN!. For some reason, I got access very quickly something that motivated me to keep working with the software. In early April 2009, A2billing 1.4 Beta was released… new documentation, new logo, new GUI, a tier-3 architecture (admin, agents and clients).

Before the European summer of 2009, A2billing 1.4 was “frozen” enough to start considering our next step. Making A2billing easy to deploy for the Village Telco. It was time to start thinking in our target users.

The challenge: be able to install and bill local Calls with no more than 10 mouse clicks!

Related posts:

1. About The Village Telco is an initiative to build low-cost community...

Related posts brought to you by Yet Another Related Posts Plugin.