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