[Kamailio-Users] prepaid system

[Alex Balashov]

Agreed; my experience has been that it is easiest and wisest to keep  
the B2BUA as dumb as possible.

On Dec 31, 2008, at 9:18 AM, Daniel-Constantin Mierla  
<miconda at gmail.com> wrote:

> On 12/31/08 16:09, Luciano Afranllie wrote:
>> On Wed, Dec 31, 2008 at 7:44 AM, Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> On 12/30/08 14:23, Luciano Afranllie wrote:
>>>
>>>> [...]
>>>>
>>>> I don't know if this has been discussed earlier but it would be  
>>>> nice
>>>> to point some key requirements for a system supporting prepaid  
>>>> users
>>>> and possible solutions to those requirements.
>>>> I think several of us is doing the same things so, we can benefit  
>>>> from
>>>> other experience and may be we can find a pattern (of course not
>>>> perfect and "fit all") for this problem using open source
>>>> alternatives.
>>>>
>>>> I am talking about something like this:
>>>>
>>>> - How to store and retrieve user category (postpaid, prepaid, etc).
>>>> LDAP, Radius, SER groups?
>>>>
>>>>
>>> this is usually up to what you are more familiar to. If you go for  
>>> sql-db
>>> system, then you should have in consideration the load_credentials  
>>> feature
>>> provided by auth_db module. With that you can load attributes per  
>>> user at
>>> authentication, saving one extra db query.
>>>
>>> As I am designed now my systems, I have dropped a lot of modules  
>>> that were
>>> hiding behind sql queries, by using config file operations (via
>>> avp_db_query() and now, with trunk, via the new sqlops module). In  
>>> this way
>>> I am not stuck to a predefined db structure and can use tricks  
>>> that make the
>>> sql operation faster based on server side features. sqlops module  
>>> makes
>>> possible to load caller and callee profiles in one query for each  
>>> and keep
>>> them for entire route processing in memory, therefore, very fast  
>>> access.
>>>
>>>> - Callflows
>>>>
>>>>
>>> Usually there are two scenarios
>>> 1) caller ----- proxy ----- b2bua ----- proxy ----- callee
>>> 2) caller ----- proxy ----- b2bua ----- pstn ----- callee
>>>
>>> First is when you do prepaid for voip-to-voip and you deal with  
>>> NAT, also
>>> when you have kind of sbc for the second proxy. The second is the  
>>> typical
>>> case for calls terminated to pstn.
>>>
>>>
>>>> - What IVR to use for user notifications (no credit, etc) and user
>>>> balance check?
>>>> Asterisk, SEMS, etc?
>>>>
>>>>
>>> I use most of them. I go by default to Asterisk or FreeSWITCH,  
>>> depending if
>>> it a more PBX-like service or carrier. SEMS is something I used a  
>>> lot in the
>>> past.
>>>
>>>> - How to enforce call tear down when credit is exhausted?
>>>> What B2BUA to use?
>>>>
>>>>
>>> B2BUA, all listed above are good options in certain conditions.  
>>> The most
>>> important aspect is to understand scaling vs features requirements.
>>>
>>>
>>>> - How to manage recharges?
>>>>
>>>>
>>> Voucher cards + IVR is an option. Payment gateways (for credit  
>>> cards) +
>>> their API.
>>>
>>>
>>
>> Thanks Daniel for your ideas.
>>
>> I just have a doubt about call flows (I made this question in another
>> thread but still it is not clear to me).
>>
>> My understanding is the call comes into the proxy and it decides to
>> send the call to the b2bua if the caller is a prepaid user.
>> My question is, should the b2bua or the proxy make the final routing
>> decision? How does the b2bua know where to forward the call next? If
>> we use routing capabilities of the b2bua then we loose the ability to
>> use routing capabilities of the proxy.
>>
> use the routing capabilities of the proxy. B2BUA can use the R-URI or
> certain headers added by proxy to decide where to send.
>
> Daniel
>
>> Another approach I am thinking is one b2bua per destination so, if I
>> want to fw the call to gw01 then in the proxy I fw the call to
>> b2bua01, if I want to fw the call to gw02, then I fw the call to
>> b2bua02 and so on.
>>
>> Regards and Happy new yer for everybody!
>> Luciano
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> -- 
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users