[OpenSIPS-Devel] [opensips] Allow pulling statistics from script logic (#362)

brettnem notifications at github.com
Fri Oct 17 09:06:47 CEST 2014

In the following I'm specifically referencing the kinds of stats you can obtain from:
opensipsctl fifo get_statistics all

I'm not sure of the right way to do this. I think there are a number of reasons why during script processing we'd want to check on the international statistics. Normally I think it would be for resource management. 

One particular idea I had was to "preserve children to handle call tear downs during very heavy traffic". The switch will always have a melt down point. It's important that when it does melt down, that melt down is graceful and as harmless as possible. In a "typical" switch, INVITE transactions perform costly lookups that can hang children. As load increases, the likelihood of hanging children increases. Unfortunately, this blocks *all* request types being processed by OpenSIPs. Ultimately, I'd like to be able to say something like, if 75% of my children are busy then do X. For example:

if (($internal_stat(child_load)) > 75 && is_method("INVITE")) {
    send_reply("500","Server too busy");

The net effect is that when the server load on the child is > 75 we simply don't take any new calls. In this scenario, we essentially are reserving 25% of our processing capability to ensure we can process things like BYEs, ACKs, maybe even re-INVITEs for existing sessions. 

 Without this (the today scenario), if all children are blocked, we ignore BYEs, we ignore ACKs, calls get stuck in a hung state and it's a big mess. 

Of course, I'm making some pretty application specific assumptions. Specifically that INVITEs are expensive and BYEs are cheap. This is more or less why I'm looking for a scriptable way to do this so the script writer can apply the logic as it's appropriate.

In the above example `$internal_stat(child_load)` is the new thing I want, and is essentially the value of:
load:<this_calls_socket>-load = 0

I'd welcome some suggestions for alternate ways to do this as well. 


Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20141017/69455d87/attachment.htm>

More information about the Devel mailing list