Just some explanation of dispatcher module argorithms.
hash over callid – ensures that all requests within a dialog goes to same box hash over from uri – ensures that all requests from same user goes to same box hash over to uri – ensures that registrations of an AoR goes to same box hash over request-uri – ensures that requests to same destination are processes by same box #hash over config variable – for different needs
This guide will help you to understand how OpenSIPS can be monitored with Zabbix, sharing its statistic data via HTTP interface in JSON format. This article assumes using OpenSIPS 3.2 and Zabbix 6.
The official documentation does not have other more complicated examples, e.g. “get_statistics sl:”, that’s why I decided to write this article, maybe it’s more about JSON, JSONPath and working with all this in Zabbix.
As an example, we’ll get stateless replier module statistics, like shown by invoking a CLI command “opensips-cli -x mi get_statistics sl:” .
OpenSIPS will answer and you’ll see SL module statistics after sending this request with CURL.
But the responce is a one-liner, so we need to convert this one line to JSON format and then to create a JSONPath, to be able to extract the value we need.
Let’s monitor not all SL module statistics received from OpenSIPS, but the number of 2xx replies only.
Now it’s time to add items to your OpenSIPS host in Zabbix. Item parameters:
Type: HTTP Agent
Type of information: Numeric (unsigned)
Request type: POST
Request body type: JSON data
Request body: {"jsonrpc": "2.0", "id": "1", "method": "get_statistics", "params": {"statistics": ["sl:"]}}
Retrieve mode: Body
Convert to JSON (enabled)
Screenshots as usual:
Item Preprocessing parameters:
1st step - JSONPath
Parameters: $.body.result.["sl:2xx_replies"]
Type of information: Numeric (unsigned)
Screen – item Preprocessing and successful testing:
Now we add a graph with this item (I hope you know how to create graphs in Zabbix) and it’s time to test. I will generate thousands of OPTIONS requests to my OpenSIPS with the sipp tool (I also recommend this sipp cheatsheet).
Download OPTIONS.xml scenario file, and generate 10000 OPTIONS requests with call rate of 10 (I assume that your OpenSIPS, like mine, answers “200 OK”):
In this example we store ISPs IP addresses in the ‘address’ table of the permissions module, in group 1, which is seen from the output of the corresponding fifo command:
and finally some magic in the script, to add the display-name to the INVITE request from the registered user, going through our OpenSIPS SBC:
# call from registered user -> add callerid # and forward to mediaserver for call recording, etc. if(is_registered("location")) { # replace only display and do not touch uri uac_replace_from("$avp(display)",""); rewritehostport("10.145.213.63:5067"); route(relay); }
The information stored in the ‘rpid’ column (in our example, or some custom in your architecture) is fetched to AVP at each REGISTER/save, so you do not need to reload anything to take changes in effect.
The callerid info is seen in console output via ‘opensipsctl fifo ul_dump’ command:
Let’s imagine that we’ve upgraded our VoIP network which was formerly based on geographically distributed Asterisks.
We configured OpenSIPS servers as registrars, connected them together in a full-sharing usrloc cluster and now we need to route calls between endpoints not directly, but through Asterisks – to handle our calls in a familiar way (CDR records, call recording via MixMonitor, some AGI scripts, etc).
We have to create something like that:
This is a code snippet of OpenSIPS with IP address 10.145.213.63:
# initial INVITE
if(is_method("INVITE") && !has_totag())
{
t_on_failure("1");
# call from registered user ->
# forward to mediaserver for call recording, etc.
if(is_registered("location"))
{
$ru="sip:" + $oU + "@" + "10.145.213.63:5067";
route(relay);
}
# call from Asterisk? -> change domain part before doing lookup
if($sp=="5067")
{
$rd="taxsee.com";
}
$var(lookup_flags) = "m";
if(cluster_check_addr("1", "$si")) {
xlog("si: $si . $rm from cluster, doing local lookup only\n");
} else {
xlog("si: $si . $rm from outside, doing global lookup\n");
$var(lookup_flags) = $var(lookup_flags) + "g";
}
if(!lookup("location", "$var(lookup_flags)"))
{
t_reply("404", "Not Found");
exit;
}
if(has_body("application/sdp"))
{
rtpengine_offer("RTP/AVP replace-origin replace-session-connection ICE=remove");
}
} # initial INVITE end
route(relay);
A SIP peer to this OpenSIPS in Asterisk sip.conf looks like this:
context office
{
_XXX =>
{
NoOp(imagine this is CDR, MixMonitor, AGI);
Dial(SIP/opensips/${EXTEN});
Hangup();
};
};
UPD: assuming your SIP acoounts DB has moved from Asterisk to OpenSIPS cluster, its desirable not just processing REGISTER requests and doing authentication, but also adding caller ids to your SIP accounts.
Pay attention: according to his advice, we don’t need any data in ‘sip_addr’ columns when creating a full-sharing usrloc cluster. In case of federated cluster we have to fill them with IP addresses on which OpenSIPS nodes are listening.
if (is_method("REGISTER")) { if(!allow_register("register")) { sl_send_reply(403, "Forbidden by permissions"); exit; }
“Deny all, but …” policy – we will allow registrations of explicitly defined usernames and drop anybody else.
register.deny file:
ALL : ALL
register.allow file:
# this allows lexus, lexus2, lexus3 to register "^sip:lexus[23]?@alexeyka.zantsev.com" : ALL
# regexp seems to be CORRECT, but for some reason lexus2 and lexus3 can not register # "^sip:lexus[\d]?@alexeyka.zantsev.com" : ALL
Have a look how it’s working! A good guy is being registered successfully:
good guy
While a bad guy had been kicked:
bad guy
Another solution using regex.so module from Pavel Eremin. The pros of this method is that it allows editing a txt file with usernames defined and reload regex.so module via MI interface (no restart needed).
This note will instruct you how to protect each DID number connected to your OpenSIPS from SIP DDoS, limiting not the total amount of INVITE requests going to your OpenSIPS server, but only INVITEs to some certain RURI.
Check it out, I hope you like it!
This is useful when you have a plenty of SIP numbers (DIDs) connected to your server and each one accepts inbound calls, e.g. a call centre or a taxi ordering service, etc. And you have to check each destination and drop too much requests, without degradation of any other incoming calls.
This is a nice solution to prevent the situation seen on the graph in the previous post.
PS: clustering support is not described here.
loadmodule "ratelimit.so" # no deps
modparam("ratelimit", "window_size", 2) # ban timeout, sec
# AntiDDoS for each inbound call
if($si !~ "^10\..*") {
cache_fetch("local", "inc:rl", $var(rl));
# $var(rl) invites/sec going to each $rU.
# SBT is the most precise policy.
if (!rl_check("pipe_$rU", "$(var(rl){s.int})", "SBT")) {
sl_send_reply("503", "Service Unavailable. AntiDDoS");
xlog("L_INFO", "call $ci from $fU@$si:$sp to $oU@$Ri drp by rl");
exit;
};
};