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

[Dan Pascu]

On Wednesday 07 January 2009, Victor Pascual Ávila wrote:
> On Wed, Jan 7, 2009 at 12:44 PM, Dan Pascu <dan at ag-projects.com> wrote:
> > On second thought, I think there is a simple way to avoid any fraud
> > attempt, without checking anything in the BYE message. If the system
> > can be instructed that for every BYE that is received to also
> > generate itself a pair of BYEs from the dialog module, then even if
> > the sender did send an invalid BYE that attempts to fraud the system,
> > the BYEs generated by the dialog module will be correct and end the
> > session or in the worst case they will receive a "session does not
> > exist" reply that is ignored anyway.
>
> It sounds good but I'm not sure about the scalability of this.

Let's see. 

If I count the REGISTER requests processed by a proxy, I get an average of 
70-100 requests/second

If I count the BYE requests I get 1.5-2 requests/second (that's almost 2 
orders of magnitude less).

So the INVITE+BYE combination generates 3-4 requests/second. Now 2 more 
BYEs would make 5-6 requests/second. If you compare that with 70-100 from 
REGISTER you will find out that simply keeping trace of where your users 
are loads your proxy 20 times as much. Now what do you think? Does it 
make a difference? What if you also consider all the keepalive messages 
that both the phones and the proxy send to 20k+ devices every 60-90 
seconds? That's another 250+ requests/second from the proxy alone, not 
counting client keepalive messages.

So how does 356 instead of 354 req/sec sound to you, scalability wise?

> Naive question- Is it better (wrt performance metrics) generating a
> couple of BYEs for every single dialog rather than checking the original 
> BYE request?

I have no idea which is more efficient, but considering the numbers above 
I hardly think it matters. What I know is that one works, while the other 
is only good until a new workaround is found. What elements of the BYE do 
you propose to check to be certain that no fraud attempt is possible, 
ever?

P.S. It would be much more helpful if scalability and performance concerns 
would be raised based on measurements or at least some preliminary 
analysis like above. There seem to be some paranoid attitude towards 
anything related to performance matters in this community, but so far 
almost never backed by any relevant data. I have never seen anyone raise 
the real issues that opensips has to deal with when faced with hundreds 
of thousands or millions of users and they are not related to processing 
some extra 2 messages per second or using sprintf instead of memcpy.

-- 
Dan