philologist's techblog

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:

[opensips]
type=peer
context=office
host=10.145.213.63
port=5060

And a dialplan for CDR/MixMonitor/etc:

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.

UPD: 2019-november-5. An official tutorial is available now! And some discussion on the mail list.

Draft/some notes…

2 OpenSIPS nodes without MongoDB

• clusterer.so module – one node is configured as seed (in case of using MongoDB for usrloc, both nodes were seed)
  • if a non-seed node restarts, it gets usrloc from seed one via bin interface
  • if a seed node is restarted, we have to get all usrloc records from non-seed one using ‘opensipsctl fifo ul_cluster_sync’ command

Key settings:

loadmodule “usrloc.so”
modparam(“usrloc”, “db_url”, “mysql://opensips:pass@10.145.213.63/opensips”)
modparam(“usrloc”, “nat_bflag”, “NAT”)
modparam(“usrloc”, “working_mode_preset”, “full-sharing-cluster”)
modparam(“usrloc”, “location_cluster”, 1)
modparam(“usrloc”, “use_domain”, 1)

loadmodule “clusterer.so” # requires proto_bin.so
modparam(“clusterer”, “current_id”, 1)
modparam(“clusterer”, “db_mode”, 1)
modparam(“clusterer”, “db_url”, “mysql://opensips:pass@10.145.213.63/opensips”)

    # initial INVITE
    if(is_method("INVITE")) {
	t_on_failure("1");
	$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

UPD: some useful notes from Liviu Chircu: http://lists.opensips.org/pipermail/users/2019-October/041819.html

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.

Situation: VoIP ISP server suddenly became unavailable and you have some thousands of dialogs like this:

dialog::  ID=17580696317398
	state:: 3
	user_flags:: 0
	timestart:: 1556697836
	datestart:: 2019-05-01 13:03:56
	timeout:: 1556701436
	dateout:: 2019-05-01 14:03:56
	callid:: 7EB7F3F9-6B1E11E9-90F3C2ED-81742C80@XX.YY.168.28
	from_uri:: sip:ZZZXXX7146@XX.YY.168.28
	to_uri:: sip:NNNN902290@XX.YY.169.130
	caller_tag:: 8999291C-450
	caller_contact:: sip:ZZZXXX7146@XX.YY.168.28:5060
	callee_cseq:: 0
	caller_route_set:: <sip:XX.YY.169.130;lr=on;ftag=8999291C-450;did=dff3.a92b;nat=yes>
	caller_bind_addr:: udp:EE.FF.116.74:5060
	caller_sdp:: 
	CALLEES:: 
		callee:: 
			callee_tag:: as3d7dee61
			callee_contact:: sip:abc@EE.FF.116.62:5060;transport=udp
			caller_cseq:: 101
			callee_route_set:: 
			callee_bind_addr:: udp:EE.FF.116.74:5060
			callee_sdp:: 

To kill them in some seconds (not to wait when OpenSIPS will terminate them according to SIP timers), do:

for i in `opensipsctl fifo dlg_list | grep callid | grep \@XX.YY.168.28 | awk '{print $2}'` ; do opensipsctl fifo dlg_end_dlg $i ; done

In fact, the situation was as follows: VoIP software on the ISP side (we have a DID from it connected to our OpenSIPS cluster) had some problems and they suddenly started sending us a bunch of unique INVITES (with different Call-IDs) for any certain inbound call.

Very soon the total number of dialogs dramatically increased up to enormous values. And this is a theme of my next article!