[Serusers] SER + Prepaid = Old discussion

Iqbal iqbal at gigo.co.uk
Mon Jun 20 20:03:29 CEST 2005


I would disagree partially with this, if you use asterisk, which I have 
done, you will have overhead, this you need to weigh in terms of cost 
and minutes lost in a pseudo billing system

Even "proper" telcos these days have aproblem in billing, which only 
come to light whena prudent user actually tracks per mins/per second usage.

If you use a B2Bua, u are handling all the streams (which you may be 
doing for NAt issues anyhow..but thats  diff story), however if you are 
not, u need to see what that adds up in terms of cost. One asterisk box 
could handle 100/1000 calls, see how much bandwidth you have to use for 
this, and then cost of server and manpower to admin it. Lets say cost is 
£2000 (give or take ), now call termination to places like USA can b 
bought for around £0.01 which means that for that £2000 you have 200000 
mins in a pool to negate any effects you may have to poor billing, which 
will occur (see posts below), however in terms of headache it will be 
far less, and its far more expandable.

I am not saying its without issues, man I have my fair share, but you 
will always get these with asterisk also, see threads on astcc etc.

SIp itself is not really good with billing, see multiple invites, BYE 
you name it, hence even with a B2BUA you will have those problems just 
because no one is really following standards to a 't'.

Session-timers can lead to overhead, as Klaus said, especially if for 
each users you need to have diff session-timers per call (i.e based upon 
destination). You could have a "layered approach" where users drop into 
bands, as they get closer to there cut off point, each band of user then 
being monitored separately,and more often than the other band, again not 
nice, I havent tried it, but its a thought process as yet, and would 
negate alot of overhead.

Dial plans in asterisk are much easier as I have come to learn the hard 
way, however I think lcr module could be expanded to include this 
mapping of user-->grp--prefixes-->gateways

Also you mentioned flat rate, I believe thats where it is going hence 
its best to invest time in the future than prepaid solutions of the 
past, just my $0.02

Iqbal



Klaus Darilion wrote:

> You can not set the maximum call duration with Session-Timer. 
> Session-Timer is a keep-alive mechanism, not a session-termination 
> mechanism.
>
> Quick answer: go with Asterisk. There are dozens of existing, well 
> working calling card functions.
>
> regards,
> klaus
>
>
> Ricardo Poppi wrote:
>
>>
>> Hi all.
>>
>> This list had a long discussion for the last two months about how to 
>> use SER with prepaid applications, since it does not participate into 
>> the media path. I´ll try to put things together in a easy way - at 
>> least for me... - for trying to solve some doubts about how this 
>> feature can work with SIP without creating new problems. And, of 
>> course, I´m assuming that we WILL NOT use b2bua, but try to make this 
>> work in a proxied environment.
>>
>> As mentioned before, one way to do so, is using the session timer 
>> (RFC-4028)  definitions.
>> The main reason those definitions were created, is for using when a 
>> BYE message don´t reach one of the UAs involved into a SIP dialog, 
>> that without those definitions would be virtualy connected "forever" 
>> since it did not receive any SIP signaling to disconect. With session 
>> timer working, even if a BYE message never reaches the other point, 
>> the maximun time that the "not-reached" UA would stay connected is 
>> the time setted into the session-timer parameter.
>>
>> Ok. But let´s use it to work with the prepaid environment. We 
>> implement a logic into our sip proxy (SER), that record-route all 
>> signaling messages between all UAs of our SIP network. Then we put 
>> our proxy to analize all re-invite messages that goes into our  SIP 
>> dialogs and, if the customer credit (in seconds) is below that the 
>> time into the session-timer parameter, it rewrites the 
>> "seconds-credit" into the message session-timer position, decrements 
>> the last session time into the customer seconds credits table, and 
>> counts on the UAs to disconecting the call, since it - the proxy - 
>> will drop/block the next re-invite(s) to this especific dialog.
>>
>> In this aproach, we need to check the first invite as well, because 
>> if the customer credit is below that the value of the first/default 
>> session-timer, the SIP message needs to be rewriten too.
>>
>> Problems on this aproach:
>>
>>  - If a re-invite from the caling user - the one that will be billed 
>> - never reachs the proxy, the UA will disconect the call sending a 
>> BYE, and, if the BYE never reachs the proxy either,  the seconds of 
>> the last session won´t be billed, correct?
>>
>>  - Thinking about security issues into a environment that just one UA 
>> support session-timers, It would be very easy for a malicious UA - 
>> the one that supports session-timers - when it runs out of credit, to 
>> send its last re-invite - the never answered one -  withouting 
>> disconecting the media path. In this case, the proxy will "think" 
>> that the call is off, but it would be not true.
>>
>>
>> Does anyone work with a true proxied prepaid environment using 
>> session timers?
>>
>> There is any aproach, other than using RFC-4028 - session timers,  
>> for doing this?
>>
>>
>> Any clue will be welcome.
>>
>> Thanks in advance for the list.
>>
>> Regards,
>>
>> Ricardo Poppi
>>
>>
>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> .
>




More information about the sr-users mailing list