IMHO, OpenSER should act on the UPDATE from mediaproxy and kill the dialog by initiating a BYE. But, it is just a proxy and cannot initiate requests, so, the accounting software should watchout for those events and consider only the first "Stop Billing" event and ignore the rest.
Sri.
On Feb 8, 2008 11:28 AM, Norman Brandinger norm@goes.com wrote:
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help. Using the alternate update query you could log malicious update attempts.
Norm
Dan-Cristian Bogos wrote:
Hi Iñaki,
I would blame the ua sending the false BYE. Usually the BYE packets must be authenticated, therefore coming from a trusted source.
DanB
On Feb 8, 2008 5:17 PM, Iñaki Baz Castillo <ibc@in.ilimit.es mailto:ibc@in.ilimit.es> wrote:
Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE). Imagine this scenario: - A calls B. This produces a "Start" acc action, so a SQL INSERT. - After 1 minute A crashes (no BYE sent and RTP stop). - After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK). - But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!! How to avoid it? how to avoid anyone sending a malicious BYE with From&To tags and Call-ID from any other already ended call? -- Iñaki Baz Castillo ibc@in.ilimit.es <mailto:ibc@in.ilimit.es> _______________________________________________ Users mailing list Users@lists.openser.org <mailto:Users@lists.openser.org> http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users