yum: show pkg versions, install certain version

August 31st, 2021

Show available versions of ‘ngcp-rtpengine’ package from repository:

yum --showduplicates list available ngcp-rtpengine

Show available versions from repository of packages which name starts with ‘ngcp-rtpengine’:

yum --showduplicates list available ngcp-rtpengine*

… will result:

ngcp-rtpengine.x86_64 6.5.2-1.el7 repo_name
ngcp-rtpengine.x86_64 6.5.3-1.el7 repo_name

ngcp-rtpengine-dkms.noarch 6.5.2-1.el7 repo_name
ngcp-rtpengine-dkms.noarch 6.5.3-1.el7 repo_name

Install certain version:

yum install ngcp-rtpengine-8.5.3-3.el7

CentOS: remove old/unused kernels

August 24th, 2021

Install ‘yum-utils’ package.

Before:

voip ~ # uname -sr
Linux 3.10.0-327.36.2.el7.x86_64
voip ~ # rpm -q kernel
kernel-3.10.0-327.el7.x86_64
kernel-3.10.0-327.10.1.el7.x86_64
kernel-3.10.0-327.18.2.el7.x86_64
kernel-3.10.0-327.36.2.el7.x86_64


voip ~ # df -h | grep boot
/dev/md126p1 283M 212M 52M 81% /boot

Let’s leave 2 kernels, others will be removed. Use ‘package-cleanup’ tool:

voip ~ # package-cleanup --oldkernels --count=2
...

Result:

voip ~ # uname -sr
Linux 3.10.0-327.36.2.el7.x86_64
voip ~ # rpm -q kernel
kernel-3.10.0-327.18.2.el7.x86_64
kernel-3.10.0-327.36.2.el7.x86_64


voip ~ # df -h | grep boot
/dev/md126p1 283M 127M 138M 48% /boot

RTPEngine set weight

August 23rd, 2021

Undocumented feature –
how to configure weight for a rtpengine set (default value is 1):

modparam("rtpengine", "rtpengine_sock", "udp:localhost:12222=2")

http://lists.opensips.org/pipermail/users/2021-August/045084.html

openbsdrouterguide

August 5th, 2021

Found a very nice website https://openbsdrouterguide.net/

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