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:
4 Responses to «Billing calls from potatoes (Part III)»
December 06, 2009 at 10:38 pm, David Rowe said:
I like the quote about 1 minute planning and how that reflects on coding Alberto. Re system integration what code do you need to place on the Mesh Potatoes to make them work with your billing system? Thanks, David
December 07, 2009 at 1:06 am, aep said:
Once the mesh potatoes discover the gateway and are "SIP provisioned" (user/pass) we need to be able to place authenticated calls and unauthenticated calls. Authenticated calls will match a A2Billing account/credit Unauthenticated calls will enter another Asterisk context in A2billing prompting for the account number (pay phone mode) So in a nutshell we need a way to commute a potato from one mode to another. One way is to create an IVR to set a PIN number in the mesh potato, if the number is pre-pended by the PIN the call is authenticated. Something to talk in March in Europe or to ask in the list! I wonder if running Asterisk in the MP is really the way to go, or is better to run something lighter... a basic SIP client.
December 09, 2009 at 1:22 am, David Rowe said:
Thanks Alberto, some questions/comments: 1/ So for Auth-mode the username/pass is stored on the MP? That means we need to ensure no one can access the MP e.g. via ssh or via physical access. Guess the latter is similar to a cell phone but without a SIM it's easier for another SIP device on the network to mimic the MP. 2/ Several people have asked about the choice of Asterisk on the MP - an entry in the Village Telco FAQ summarises the reasons. Curiously, no one has given a really good answer to the question "why not Asterisk?" yet :-) 3/ By default the MPs are pre-confiured to be able to dial the IP of other MPs on the same mesh. Basically you power them up, get dial tone, and dial an IP. No configuration is required. It would be good to ensure authentication is only required for off-mesh calls via a gateway. That way the MP will keep it's ease-of-use/zero-conf feel. Cheers, David
December 10, 2009 at 1:17 pm, aep said:
I think we need to sit down and discuss this in detail. In principle we do not want calls (at least the signalling) to route directly between nodes as we need to bill local calls too in some scenarios. So Dialing directly is only of the possible scenarios