[SR-Users] Prepaid billing solution for a service provider

[Stefan Sayer]

Hello,

o Carlo Dimaggio on 01/05/2012 12:08 PM:
> Hi all,
>
> I'm working in a project for a service provider in which prepaid is an
> essential requirement. They have about 12000 subscribers.
> The core infrastructure will be Kamailio+RTPProxy while I have some
> doubts about the prepaid feature. I'm thinking about a B2BUA (SEMS or
> Freeswitch) that is called if the user belong to a "prepaid group" and
> perform authorization and accounting; in this case the SIP flow could
> be: Kamailio -> B2BUA(Prepaid) -> Kamailio. Is a good choice?
>
> At the moment I cannot estimate the effort needed to develop this
> section (base prepaid feature) of the project... Do you have some hints?
>
> What are the prepaid solution implemented by you? Do you use your own
> developed solution or do you think that is better to choose a
> commercial solution (that provide also calling-card and other features)?
> I have seen some commercial products (Portabilling, Jerasoft/Bilberry,
> ...); what do you think about?

we (FRAFOS) have implemented prepaid on top of SEMS SBC (and are 
offering that commercially, complete with replication and all, contact 
me if you are interested; I won't go into details here as it's not 
open source).

Some thoughts, experiences and things to consider:
- if you want to do prepaid properly, you need to be call stateful, be 
it proxy or b2bua; using a b2bua simplifies things IMO
- if you want to permit parallel calls, you can either make a time 
slice based system, or you need to have a central active calls registry
- a time slice based system may put heavy load on your accounting 
server/DB, which may be prohibitively high for high concurrent call 
numbers
- for high availability, you need replication not only for the call 
control (if you use B2BUA), but also for the registry of running 
calls, if any
- calculating timers for parallel calls with things like free minutes, 
on-/off-peak etc. is not trivial (but possible)

The subscriber base in question doesn't sound so big (12k), so a 
simple solution may be working well.

Regards
Stefan