In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel

S/PBS - Phone Billing System

One of our clients does a lot of work for a large Private Equity Investor and one of the projects they were asked to manage was the provision of an integrated IP Phone/Broadband service to an up market student accommodation in Central London. We were invited to create some custom software that would integrate the functions of billing the clients, controlling the phones and providing on line access to call information.

So the modules required would be

  • Secure FTP client to pull down Call Data Records from FTP Site. Technology required - Secure FTP.
  • Pricing module to process Call Data Records and allocate to individuals - Technology required, RTP65.
  • Billing module to take money from the person's credit/debit card or cashless card - Technology required, HTTPS and SOAP/XML.
  • Web interface to permit students to maintain their accounts - Technology required, HTTPS and 256 byte encryption.
  • Desktop software to allow administration of system - Technology required, Web Services and OpenInsight.

Secure FTP Client

As this had to be a 24/7 operation, the routine that collects the call data records from the FTP site cannot run as a desktop application - it has to be a service. So utilizing Sprezzatura?s proprietary Engine Farm technology and some bought in communications libraries, we developed a Secure FTP service that communicates with the FTP site holding the call data records, pulls down the new files and subsequently calls an OpenEngine routine to process the new Call Data Records and put them into tables ready for billing.

The client is configured using a control panel applet which permits the following functionality:

OpenEngine Manager Tab

This identifies the application to launch engines in, along with the name of the various handler procedures.

The number of engines to run with and whether or not they ought to be persistent. It also allows additional configuration of how the engines should be communicated with.

And finally additional procedures to be run at initialisation and termination, when engines should be assumed to have hung and should be killed and how often the system should perform internal garbage collects.

SFTP Transfer Tab

This tab permits for the specification of how frequently updates should be looked for along with where the resultant files should be stored. Note that as this is a mission critical application we may specify multiple servers to access so that if the comms line to one location goes down for any reason we can roll over to the next server. When this happens, the service sends an email to the person specified in the Email tab to alert them to the fact that there is a problem.

Email Tab

The configuration of the Email is simplicity itself - simply say who to send mail to, who from and provide the details if the SMTP server to use. From hereon in, if there are issues we'll know about it. Using this functionality wewere able to point to specific service failings that provided the client with ammunition to ensure that the SLAs being provided to them by their supplier were enforced.


When initially testing system setup, it is useful to see exactly what is happening so there is the provision for every action taken by the service to be logged to an external file. Because of the way this is written to, it can be examined whilst the service is in use permitting easy verification that the service is performing as it is intended to.

Pricing module to process Call Data Records and allocate to individuals

This is essentially a Basic+ program that looks at the destination called and compares it to a pricing table. The call is then priced and the user?s account is debited. If this causes the account to fall below a configurable amount, the user?s chosen payment method is debited. If the debit fails, then the telephone is locked for outgoing calls and incoming calls are diverted to a voicemail system. Thus, the OpenInsight program is actually controlling a telephone switchboard. Whilst the mechanism behind the scenes for controlling the switchboard is itself complicated, the interface exposed to OpenInsight is a straightforward object exposing LOCK and UNLOCK methods.

Billing module to take money from the person's credit/debit card or cashless card

The user can choose to pay by credit or debit card OR by using the cashless card that they use in the rest of the building. This requires a mixture of secure HTTP and SOAP messaging. Both methods request a "payment" from the appropriate supplier and credit the user account if successful.

Web interface to permit students to maintain their accounts

This was an important aspect of the system as students had to be able to log in at any time to check their account balance and to "top up" their account if needs be. From the interface, they initially register and upon clicking through a registration link they are taken to the main page. Subsequent visits require login. Naturally, all dealings with the site take place through HTTPS for added security.

Topups may be made by any means the student wishes to employ and naturally statements are available at any time:

Desktop software to allow administration of system

This is a normal OpenInsight application and permits the day to day administration of the system.

Of course, in the world of mobile telecoms, things are constantly changing and new number ranges are added without supplier notification. When this happens there are tools provided to permit the operator to bill an unbillable call and add the new number range into the system automatically.

In Conclusion

We're pleased with the ease with which we were able to deliver this all singing all dancing software to our client. Our client was delighted with the value for money received. So much so, that they have now gone ahead and purchased a new Switchboard - so the cycle starts again as now we need to add a module to actually CREATE the Call Data Records from a raw feed instead of FTPing the information down. Whilst it is true that for the communications we relied upon our own internal routines, the flexibility of OpenInsight was a significant contributor to the success of this application.

Pixel Footer R1 C1 Pixel