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
- account only: customer has an account with credit into the system
- phone number# only: customer has a phone number but not a physical phone
- 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)