Oracle SBC: prevent OPTIONS forwarding

May 6th, 2021

A quick howto with illustrations of what you need to do to prevent OPTIONS requests from being forwarded by your OracleSBC/AcmePacket from outside to the core of your VoIP network.


Just specify correct SIP methods in the policy-attributes of local-policy and add one more policy-attribute for OPTIONS.


Specifying ‘next-hop’ as ‘0.0.0.0’ will make SBC to reply 404.

Specifying ‘next-hop’ as ‘*’ will make SBC to reply 403.


Without these settings your SBC will forward OPTIONS sent by session-agents in the Internet (e.g. VoIP providers with which you configured SIP trunking) to your next-hops, usually this is your core network. Finally, such OPTIONS requests are answered not by SBC, but by your inner VoIP servers. These replies are not just undesirable, they also contain User-Agent header of your core equipment and the Contact header indicates their IP address.


You may also skip the creation of a separate policy-attribute for OPTIONS method, just leaving the one for every other methods you need (e.g. INVITE, PRACK, REFER, UPDATE). In this case your SBC will reply “480 No Routes Found”:

New VPS

February 3rd, 2021

The blog moved to a new VPS.

OpenSIPS: INVITE filtering

October 27th, 2020

A small snippet for passing only valid INVITEs from the Internet to your OpenSIPS server: allowing calls from VoIP ISPs and registered users only.

# antiflood
if(!is_myself("$si") && $Rp == 5060)
{
  if(!is_registered("location", "$fu") && !check_source_address("1")) 
  {
    exit;
  }
}

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:

[root@voip-srv ~]# opensipsctl fifo address_dump
part:: default
dest:: grp=1 ip=193.201.229.35 mask=32 port=0 proto=any pattern= context_info=VoIP ISP Multifon
dest:: grp=1 ip=81.211.59.102 mask=32 port=0 proto=any pattern= context_info=VoIP ISP ekt.ip.Beeline
dest:: grp=1 ip=212.119.246.230 mask=32 port=0 proto=any pattern= context_info=VoIP ISP ip.Beeline

CentOS 7: bind to privileged port without root access

September 22nd, 2020

The error I faced:

ERROR:core:tcp_init_listener: bind(32, 0x7f72fe4879ac, 16) on 11.22.33.44:443 : Permission denied
ERROR:core:trans_init_all_listeners: failed to init listener [11.22.33.44], proto wss
ERROR:core:main: failed to init all SIP listeners, aborting

The service could not start neither manually (opensips -f /path/to/cfg) nor via SystemD. The checking (opensips -C -f /path/to/cfg) of config file showed no errors.

Use ‘setcap’ command.

Example for OpenSIPS running as opensips:opensips.

How I fixed:

setcap CAP_NET_BIND_SERVICE=+eip /usr/sbin/opensips

OpenSIPS 2.4: DB/script clusterer configuration

September 7th, 2020

No DB, node 1:

modparam("clusterer", "current_id", 1)
modparam("clusterer", "db_mode", 0)
modparam("clusterer", "seed_fallback_interval", 10) # Only relevant for seed node
modparam("clusterer", "current_info","cluster_id=1,url=bin:10.145.213.63:5555,flags=seed")
modparam("clusterer", "neighbor_info","cluster_id=1,node_id=2,url=bin:10.145.213.155:5555")

No DB, node 2:

modparam("clusterer", "current_id", 2)
modparam("clusterer", "db_mode", 0)
modparam("clusterer", "seed_fallback_interval", 10) # Only relevant for seed node
modparam("clusterer", "current_info", "cluster_id=1,url=bin:10.145.213.155:5555")
modparam("clusterer", "neighbor_info", "cluster_id=1,node_id=1,url=bin:10.145.213.63:5555")

DB configuration, node 1:

modparam("clusterer", "current_id", 1)
modparam("clusterer", "db_mode", 1)
modparam("clusterer", "db_url", "mysql://opensips:MeGaPaSs@10.145.213.200/opensips")

DB configuration, node 2:

modparam("clusterer", "current_id", 2)
modparam("clusterer", "db_mode", 1)
modparam("clusterer", "db_url", "mysql://opensips:MeGaPaSs@10.145.213.200/opensips")

Clusterer table:

MariaDB [dbsrv]> select * from clusterer\G
*************************** 1. row ***************************
             id: 1
     cluster_id: 1
        node_id: 1
            url: bin:10.145.213.63:5555
          state: 1
no_ping_retries: 3
       priority: 50
       sip_addr: 
          flags: seed
    description: USRLOC_Cluster_node_1
*************************** 2. row ***************************
             id: 2
     cluster_id: 1
        node_id: 2
            url: bin:10.145.213.155:5555
          state: 1
no_ping_retries: 3
       priority: 50
       sip_addr: 
          flags: 
    description: USRLOC_Cluster_node_2

linux: cgroups

July 27th, 2020

Just a link to a useful article about managing system resources according to a user/process:

https://www.digitalocean.com/community/tutorials/how-to-limit-resources-using-cgroups-on-centos-6

Viber on Ubuntu 18.04

May 14th, 2020

alexey@dell:~$ /opt/viber/Viber qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb. Aborted (core dumped)

alexey@dell:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.4 LTS
Release:	18.04
Codename:	bionic
alexey@dell:~$ sudo apt install qt5dxcb-plugin

Forwarded/diverted calls in Asterisk log

November 26th, 2019
VERBOSE[90578][C-0027e6ee]: app_dial.c:935 in do_forward: \
[2019-11-25 09:54:06] \
-- Now forwarding SIP/2765-00559bac \
to 'Local/3135@office' (thanks to SIP/2559-00559bad)

NOTICE[90578][C-0027e6ee]: app_dial.c:958 in do_forward: \
Not accepting call completion offers from call-forward \
recipient Local/3135@office-0014b4ca;1


VERBOSE[109197][C-0027f144]: app_dial.c:935 in do_forward: \
[2019-11-25 12:20:26] \
-- Now forwarding SIP/1888-0055b018 \
to 'Local/7xxx3063600@office' (thanks to SIP/2813-0055b019)

NOTICE[109197][C-0027f144]: app_dial.c:958 in do_forward: \
Not accepting call completion offers from call-forward \
recipient Local/7xxx3063600@office-0014b7e3;1

“thanks to SIP/2559-00559bad” – this is a name of the channel who forwarded the call, either manually or by settings configured in the UAC.

sudo without pass

November 26th, 2019

Executing apt as an example. Add to /etc/sudoers

lexus ALL=(root) NOPASSWD:/usr/bin/apt

OpenSIPS: Adding CALLERID (display-name) to calls from registered users

November 21st, 2019

This is about adding a display name to the calls from registered users. An analogue of Asterisk’s Set(CALLERID(name)=John Doe).

The idea was to move SIP accounts from Asterisk to OpenSIPS.

In case of using Asterisk we would configure something like:

[user222]
context=o.local
secret=4EwIWikV
callerid=Alexey Kazantsev <222>

How to achieve the same with OpenSIPS? This is the solution:

  • add desired display-names to ‘rpid’ columns of the ‘subscriber‘ table:
Adding desired callerid to ‘rpid’ column of the SIP-account.
modparam("auth_db", "load_credentials", "$avp(display)=rpid")
  • add ‘attr_avp‘ parameter to ‘registrar’ module settings:
modparam("registrar", "attr_avp", "$avp(display)")
  • 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);
}

How it looks like?

This is the INVITE coming to OpenSIPS:

2019/11/21 14:16:55.247856 10.145.213.64:5061 -> 10.145.213.63:5060
INVITE sip:111@taxsee.com SIP/2.0
Via: SIP/2.0/UDP 10.145.213.64:5061;branch=z9hG4bK-3822b894
From: <sip:222@taxsee.com>;tag=48b014547f398294o1

And this is the same INVITE leaving OpenSIPS, being modified:

2019/11/21 14:16:55.252518 10.145.213.63:5060 -> 10.145.213.63:5067
INVITE sip:111@10.145.213.63:5067 SIP/2.0
Record-Route: <sip:10.145.213.63;lr;ftag=48b014547f398294o1>
Via: SIP/2.0/UDP 10.145.213.63:5060;branch=z9hG4bK77e6.9bb3aa72.0
Via: SIP/2.0/UDP 10.145.213.64:5061;branch=z9hG4bK-3822b894
From: "Alexey Kazantsev" <sip:222@taxsee.com>;tag=48b014547f398294o1

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:

	AOR:: 222@taxsee.com
		Contact:: sip:222@10.145.213.64:5061 Q=
			ContactID:: 3039507536010050217
			Expires:: 42
			Callid:: 9fdd26c2-6de37105@10.145.213.64
			Cseq:: 35746
			User-agent:: Cisco/SPA303-7.6.2c
			State:: CS_NEW
			Flags:: 0
			Cflags:: 
			Socket:: udp:10.145.213.63:5060
			Methods:: 5247
			Attr:: Alexey Kazantsev