[Serusers] SER + Prepaid = Old discussion

[Samuel Osorio Calvo]

I don't think that session timers have the accuracy required for a billing system. If you take a look at the specification, minimum values are 90 seconds and recommended values are 30 minutes. If you reduce these values to bill every second a user is accessing the service, you could end up in interoperability problems. Moreover, any traversed proxy may use Min-SE header to increase the minimum value to few minutes, or hours, and then your user is gonna feel really happy having minutes for free...
I really think the only reliable way is to use a b2bua because it is the only entity aware of the media path and able of dropping the call "instantaneously". I don't even think a statefull proxy will work since it is not in the media path and it is not supposed to initiate BYEs...

I would suggest to choose between b2bua or flat fares. I think the latter suits more the IP world: almost everywhere you pay X per month for internet access, doesn't it apply better to VoIP?? interconnecting with PSTN is another topic and I think something like skype would suit better to IP than the classic X minutes->Y money.

Samuel.


Unclassified.
>>> Ricardo Poppi <rpoppi77 at giro.com.br> 06/20/05 06:11PM >>>

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