22 Dec
2008
22 Dec
'08
4:10 p.m.
On 12/21/08 15:50, Iñaki Baz Castillo wrote:
El Domingo, 21 de Diciembre de 2008, Daniel-Constantin
Mierla escribió:
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.
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.
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