Once the sip:provider CE is in production, security and maintenance becomes really important. In this chapter, we’ll go through a set of best practices for any production system.
The sip:provider CE runs a wide range of services. Some of them need to interact with the user, while some others need to interact with the administrator or with nobody at all. Assuming that we trust the sip:provider CE server for outgoing connections, we’ll focus only on incoming traffic to define the services that need to be open for interaction.
Table 7. Subscribers
Service | Default port | Config option |
---|---|---|
Customer self care interface | 443 TCP | www_admin→http_csc→port |
SIP | 5060 UDP, TCP | kamailio→lb→port |
SIP over TLS | 5061 TCP | kamailio→lb→tls→port + kamailio→lb→tls→enable |
RTP | 30000-40000 UDP | rtpproxy→minport + rtpproxy→maxport |
XCAP | 1080 TCP | kamailio→proxy→presence→enable + nginx→xcap_port |
XMPP | 5222 and 5269 TCP | None, standard XMPP ports for clients (5222) and federation (5269) |
Table 8. Administrators
Service | Default port | Config option |
---|---|---|
SSH/SFTP | 22 TCP | NA |
Administrator interface | 1443 TCP | www_admin→http_admin→port |
Provisioning interfaces | 2443 TCP | ossbss→apache→port |
To function correctly, the rtpengine requires an additional iptables rule installed. This rule (with a target of |
The sip:provider CE comes with some default passwords the user should change during the deployment of the system. They have been explained in the previous chapters of this document.
The Vagrant/VirtualBox/VMWare sip:provider CE images come with more default credentials which should be changed immediately:
Many NGCP services use MySQL backend. Users and passwords for these services are created during the installation. These passwords are unique for each installation, and the connections are restricted to localhost. You should not change these users and passwords. |
The sip:provider CE provides default, self-signed SSL certificates for SSL connections. These certificates are common for every installation. Before going to production state, the system administrator should provide SSL certificates for the web services. These certificates can either be shared by all web interfaces (provisioning, administrator interface and customer self care interface), or separate ones for each them can be used.
Set the path to the new certificates in /etc/ngcp-config/config.yml:
The sip:provider CE also provides the self-signed SSL certificates for SIP over TLS services. The system administrator should replace them with certificates signed by a trusted certificate authority if he is going to enable it for the production usage (kamailio→lb→tls→enable (disabled by default)).
Set the path to the new certificates in /etc/ngcp-config/config.yml:
The sip:provider CE can be integrated with most of the existing backup solutions. While it does not provide any backup system by default, any Debian compatible system can be installed. It’s not the scope of this chapter to go through backup system configuration. We’ll focus on which information needs to be saved.
The minimum set of information to be backed up is:
This is the most important data in the system. All subscriber information, billing, CDRs, user preferences etc. are stored in the MySQL server. A periodical dump of all the databases should be performed.
/etc/ngcp-config/config.yml, /etc/ngcp-config/constants.yml, /etc/ngcp-config/network.yml, /etc/mysql/debian.cnf and /etc/mysql/sipwise.cnf files, where your specific system configurations are stored, should be included in the backup as well. Saving the entire /etc/ngcp-config__ folder is a good idea in general.
The directory /home/jail/home/cdrexport contains the exported CDRs the system has generated so far. It depends on your local call data retention policy whether or not to remove these files after exporting them to an external system.
Any custom configurations, like modified templates or additionally implemented services which are not provided by the sip:provider CE
In the worst case scenario, when the system needs to be recovered from a total loss, you only need 4 steps to get back online:
To reset database to its original state you can use the script provided by CE: * Execute ngcp-reset-db. It will assign new unique password for the NGCP services and restart all services. IMPORTANT: All existing data will be wiped out without possibility of restoring.
The sip:provider CE is a very flexible system, capable of serving from hundreds to several tens of thousands of subscribers in a single node. The system comes with a default configuration, capable of serving up to 50.000 subscribers in a normal environment. But there is no such thing as a normal environment. And the sip:provider CE has sometimes to be tunned for special environments, special hardware requirements or just growing traffic.
If you have performance issues with regards to disk I/O please consider enabling the noatime mount option for the root filesystem. Sipwise recommends the usage of noatime, though remove it if you use software which conflicts with its presence. |
In this section some parameters will be explained to allow the sip:provider CE administrator tune the system requirements for optimum performance.
Table 9. Requirement_options
Option | Default value | Requirement impact |
---|---|---|
cleanuptools→binlog_days | 15 | Heavy impact on the harddisk storage needed for mysql logs. It can help to restore the database from backups or restore broken replication. |
database→bufferpoolsize | 64MB | For test systems or low RAM systems, lowering this setting is one of the most effective ways of releasing RAM. The administrator can check the innodb buffer hit rate on production systems; a hit rate over 99% is desired to avoid bottlenecks. |
kamailio→lb→pkg_mem | 16 | This setting affects the amount of RAM the system will use. Each kamailio-lb worker will have this amount of RAM reserved. Lowering this setting up to 8 will help to release some memory depending on the number of kamailio-lb workers running. This can be a dangerous setting as the lb process could run out of memory. Use with caution. |
kamailio→lb→shm_mem | 1/16 * Total System RAM | The installer will set this value to 1/16 of the total system RAM. This setting does not change even if the system RAM does so it’s up to the administrator to tune it. It has been calculated that 1024 (1GB) is a good value for 50K subscriber environment. For a test environment, setting the value to 64 should be enough. "Out of memory" messages in the kamailio log can indicate that this value needs to be raised. |
kamailio→lb→tcp_children | 8 | Number of TCP workers kamailio-lb will spawn per listening socket. The value should be fine for a mixed UDP-TCP 50K subscriber system. Lowering this setting can free some RAM as the number of kamailio processess would decrease. For a test system or a pure UDP subscriber system 2 is a good value. 1 or 2 TCP workers are always needed. |
kamailio→lb→tls→enable | yes | Enable or not TLS signaling on the system. Setting this value to "no" will prevent kamailio to spawn TLS listening workers and free some RAM. |
kamailio→lb→udp_children | 8 | See kamailio→lb→tcp_children explanation |
kamailio→proxy→children | 8 | See kamailio→lb→tcp_children explanation. In this case the proxy only listens udp so these children should be enough to handle all the traffic. It could be set to 2 for test systems to lower the requirements. |
kamailio→proxy→*_expires | Set the default and the max and min registration interval. The lower it is more REGISTER requests will be handled by the lb and the proxy. It can impact in the network traffic, RAM and CPU usage. | |
kamailio→proxy→natping_interval | 30 | Interval for the proxy to send a NAT keepalive OPTIONS message to the nated subscriber. If decreased, this setting will increase the number of OPTIONS requests the proxy needs to send and can impact in the network traffic and the number of natping processes the system needs to run. See kamailio→proxy→natping_processes explanation. |
kamailio→proxy→natping_processes | 7 | Kamailio-proxy will spawn this number of processes to send keepalive OPTIONS to the nated subscribers. Each worker can handle about 250 messages/second (depends on the hardware). Depending the number of nated subscribers and the kamailio→proxy→natping_interval parameter the number of workers may need to be adjusted. The number can be calculated like nated_subscribers/natping_interval/pings_per_second_per_process. For the default options, asuming 50K nated subscribers in the system the parameter value would be 50.000/30/250 = (6,66) 7 workers. 7 is the maximum number of processes kamailio will accept. Raising this value will cause kamailio not to start. |
kamailio→proxy→shm_mem | 1/16 * Total System RAM | See kamailio→lb→shm_mem explanation. |
rateomat→enable | yes | Set this to no if the system shouldn’t perform rating on the CDRs. This will save CPU usage. |
rsyslog→external_log | 0 | If enabled, the system will send the log messages to an external server. Depending on the rsyslog→external_loglevel parameter this can increase dramatically the network traffic. |
rsyslog→ngcp_logs_preserve_days | 93 | This setting will set the number of days ngcp logs under /var/log/ngcp will be kept in disk. Lowering this setting will free a high amount of disk space. |