7.5. Command-line SBC Process Management

Occasionaly it may be useful to review or change the low-level status of daemons that implement the SBC functionality. ABC SBC is running several daemons for processing and controlling signalling and media traffic, management services like a web interface, a high availability system, configuration management, and others.

To control all these processes, two daemons are running:

There are two actual work-horses: the signaling and database daemons:

7.5.1. Process Management using Systemd

Systemd main system process management daemon manages processes that are started on both nodes independently and are not part of the HA pair management.

The following SBC SBC processes are managed by Systemd:

  • redis_events - all events generated by ABC SBC and are sent to the redis local in-memory database, see Sec. Diagnostics Dashboard for more details.
  • redis_cs - the redis local in-memory database for storing call state.
  • chroust-ec, chroust-ec2 - this daemon connects to the redis event database and transferres the events to remote ABC Monitor.
  • sbc-repl-pcaprec, sbc-repl-pcaprec2 - traffic logs and recordings files replication to remote ABC Monitor.
  • stunnel-redis, stunnel-rsync - provide TLS tunnel for events transfer and traffic logs and recordings files replication to remote ABC Monitor, if connection via TLS is enabled.
  • sbc-tcpdump  - this is a continuously running tcpdump process that listens on all configured and enabled SBC signalling interfaces and captures the SIP packets as PCAP files.
  • syslog-ng  - standard Syslog-NG daemon used for filtering and storing log messages.
  • mariadb  - SQL server instance used as a storage for SBC configuration
  • sshd  - standard OpenSSH daemon used for remote console login
  • nginx  - standard nginx web server, which works as front end for ABC SBC gui, xmlrpc access, tryit demo page (if enabled) and websocket redirect (if enabled).
  • monit  - checks for high system load or cpu or memory usage or low disk space and creates alert events and sends email notifications.
  • snmpd  - SNMP daemon providing interface for communication with remote SNMP monitoring systems. For instance, SBC measurements and counters can be queried by external monitoring tools.
  • collectd  -  collects system and SBC statistics
  • webmin  - framework used by ABC SBC web interface
  • sbc-pullconf - service to check and pull new configuration from configuration master.
  • sbc-pushprov - service to propagete chnages to provisioned tabled db from from configuration master to ABC SBC nodes.
  • sbc-checknet - service to check for network buffer overflows and add alert events if errors found.
  • sbc-checkcore - service that checks for any coredumps and creates diagnostic data tarball and adds alert events if found.

Every service is monitored by systemd and automatically started in case of any failure. A particular daemon can be manually stopped and started by:

% systemctl stop collectd
% systemctl start collectd

7.5.2. HA using Pacemaker

The Pacemaker manages those services needed for a High Availability cluster, and those running on a currently active machine, namely:

  • Virtual IP addresses
  • SIP and media processing (“sems”)
  • replication of signalling data between active and standby machine (“redis-server”)

The Pacemaker and the status of managed services can be checked from the ABC SBC interface “HA ‣ Status“.

The  “HA ‣ Status“, see Fig. Status of SBC cluster, screen shows the cluster (or single) node status with respect to cluster communication and services (resources) state. If everything is correct, then the cluster contains two nodes, that are both online. Resources (VIPs, sems, ms-redis-server) run on the active node.

_images/10000000000001D9000002C0A8F931CA.png

Figure 1: Status of SBC cluster

The status of the cluster can also be retrieved from the node command line, see Output of „pcs Status“.

_images/10000201000002570000018FD027CF5E.png

Figure 2: Output of „pcs Status“

From Fig. Status of SBC cluster one can identify that all pacemaker managed services up and running, namely:

  • both nodes in the cluster sbct1 and sbct2 are “Online”
  • all services are running on the same node (redis-server in “Masters” mode on sbct2)

Service can be manually stopped and started using the “pcs resource” command:

% pcs resource disable sems
% pcs resource enable sems

7.5.3. SEMS – the SIP and RTP processing Daemon

SEMS is the most important daemon as it processes the signalling and media traffic. It loads the settings from the configuration files and the SBC rules from the Mariadb database.

  • configuration files: “/etc/sems“ directory
  • log file: “/var/log/frafos/sems.log“

To check whether SEMS is correctly listening on all configured SBC interfaces, see the output of netstat as shown in Fig. Checking SEMS with netstat.

_images/10000201000003890000007C381BDB27.png

Figure 3: Checking SEMS with netstat

7.5.4. REDIS – the Real-time Database

Redis is used for data replication between active and standby machines. On an active machine, it is running as “Masters,” and on the standby machine as “Slaves”.

  • configuration file: “/etc/redis.conf“
  • log file: “/var/log/frafos/redis.log“

The administrator can check the status of redis and which rule the process is having (and role) with:

% redis-cli |  grep role

The content of the redis database (the description of its records is out of the scope of this document) can be displayed using:

% redis-cli keys "*"

This command can be useful for checking whether data replication is correctly working by comparing redis content on active and stadby machine.