2008/12/22 Daniel-Constantin Mierla miconda@gmail.com:
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.
Well, except in the case of BYE sent by the gateway (since the attacker could reply non-200 to the BYE and mantain the session open). But anyway, I imagine this exotica case:
- alice (attacker) speaking with the PSTN gateway.
- alice sends this BYE:
BYE sip:PSTN_NUMBER@PSTN_GATEWAY SIP/2.0 Route: sip:PROXY_IP Route: sip:alice@ALICE_PHONE_IP
The proxy could check the RURI to know that the destination in the gateway, so to account a BYE the gateway must reply 200 OK to the BYE. The first route is the proxy, so there is loose routing (as expected and required). But there is other Route pointing to alice again, so the BYE would be sent to alice who will reply 200 OK to this spoofed BYE. The proxy would trigger STOP action but the call session remains.
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).
Well, now I'm designing it, not a real implementation now.
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.
I think (but not 100% sure) that a B2BUA could check all the requests in both legs to ensure that no spoofed accounting action is performed, so the accounting would be in realtime (without the need of an external application re-checking it). But this is just theory XD
Thanks a lot for your comments.