Use case 1: convert the username consisting of letters in incoming INVITE from your VoIP provider to digits (e.g. INVITE: rt_user1@192.168.1.203 -> INVITE: 13511654321@192.168.1.203, where country-city-subscriber is 1-3511-654321):
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.
