[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?
miconda at gmail.com
Mon Dec 22 15:10:33 CET 2008
On 12/21/08 15:50, Iñaki Baz Castillo wrote:
> El Domingo, 21 de Diciembre de 2008, Daniel-Constantin Mierla escribió:
>> Then it comes the billing application that implements the logic to deal
>> with different cases. Easiest one is when you have one STOP event, but
>> if you have more, then you have to check for reply code, cseq, etc...
> Well, as I said I don't need dealing with it if I use radius ACC since only
> one BYE matching the dialog can trigger a SQL STOP action (other BYE's
> matching this dialog will trigger radius STOP action, but not SQL action due
> to "WHERE" clausules the SQL query).
> So the only I need is the proxy ensures that the BYE is not fraudulent, for
> example, it's not a spoofed BYE from the user with RURI=same_user.
accounting only 200ok-ed BYEs will ensure that.
By the way, are you accounting all session updates, e.g., re-INVITE, or
just first INVITE and the BYE. There are billing systems that use the
re-INVITEs due to session timers to estimate the duration when BYE is
> Anyway, it seems really complex and a post-accounting process should be needed
> as you say. I will try to avoid needing it doing the billing in a B2BUA.
Don't you have a rating engine to compute the costs? Also, I assume you
have a tool to aggregate the cdrs from your providers with what you get
on proxy. Indeed, accounting/billing is quite complex, depending also on
what type of charging you have (e.g., time of the day based charging).
Would be interesting to see what would be more efficient, a b2bua that
may give better CDRs or a stand alone application that digest the
accounting events. It is clear that a b2bua introduces delays, therefore
reduces the processing capacity -- probably difference is not that big.
More information about the Users