[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?

[Daniel-Constantin Mierla]

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 
missing.

> 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.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com