The sip:provider PRO provides SSH access to the system for Sipwise operational team for debugging and final tuning. Operational team uses user sipwise which can be logged in through SSH key only (password access is disabled) from dedicated access server jump.sipwise.com only.

To completely remove Sipwise access to your system, please execute as user root:

root@myserver:~# ngcp-support-access --disable && apt-get install ngcp-support-noaccess

	you have to execute the command above on each node of your sip:provider PRO system!

	please ensure that the script complete successfully:

  * Support access successfully disabled.

If you need to restore Sipwise access to the system, please execute as user root:

root@myserver:~# apt-get install ngcp-support-access && ngcp-support-access --enable

	please ensure that the script complete successfully:

  * Support access successfully enabled.

The sip:provider PRO 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 PRO server for outgoing connections, we’ll focus only on incoming traffic to define the services that need to be open for interaction.

To function correctly, the rtpengine requires an additional iptables rule installed. This rule (with a target of RTPENGINE) is automatically installed and removed when the rtpengine starts and stops, so normally you don’t need to worry about it. However, any 3rd party firewall solution can potentially flush out all existing iptables rules before installing its own, which would leave the system without the required RTPENGINE rule and this would lead to decreased performance. It is imperative that any 3rd party firewall solution either leaves this rule untouched, or installs it back into place after flushing all rules out. The complete parameters to install this rule (which needs to go into the INPUT chain of the filter table) are: -p udp -j RTPENGINE --id 0

The sip:provider PRO 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.

	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 PRO 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.

The sip:provider PRO 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)).

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.

In case of unresolvable database replication issues or to copy mysql data between a pair of hosts (usually a pair of sp1 and sp2 nodes).

There is a script for that: ngcp-sync-db.

To synchronize databases you need to run the script on your target host.

	Your existing database on local will be completely wiped. The script provides a possibility to backup both master and local databases during the procedure.

You can run the script with -h or --help to check its options or use man ngcp-sync_db

If you run it without any options it automatically calculates master hostname (e.g. if you run it on sp2 then sp2==local and sp1==master).

The script also requires mysql credentials and if none provided it uses username=sipwise and the password is picked from /etc/mysql/sipwise.cnf. You can specify user and/or password for both master and local.

Before the actual start it produces a summary with settings used to the procedure and a confirmation prompt to prevent accidental usage. Making use of --force option" however suppresses the confirmation prompt. By default no messages are printed on STDOUT (compliant to be integrated into another tools) and with -v or --verbose options you enable debugging where all the ongoing steps will be printed to STDOUT.

There are 2 modes avaialble for synchronization, online and backup. By default online is used where the procedure does not create any backups and everything goes on the fly. That is useful for large databases where creating backups would require solid amounts of avaialble free disk space. With the backup mode master db is dumped into a backup file on local first (default directory: /var/backup/ngcp-sync-db) and imported upon the backup completion.

Mysql database connection to the master db and the local db is the essential part and by default the script tries to establish direct mysql connection however that may not be possible due to the access restrictions. To overcome that you can use --ssh-tunnel option and specifying there a local custom free port (e.g. --ssh-tunnel=33125) in this case an ssh tunnel will be created to master and used to establish the db connection on the localhost behalf (NOTE: Public key based ssh negotiation is required for the tunnel as the script does not suppot ssh credentials for security reasons).

Backups may be a subject to create during synchornization for possible rollbacks. To create the local db backup you should add --local-backup. The master db backup is automatically created only using --sync-mode=backup. Upon completion all those created backups are deleted and if you need to keep them please use --keep-backups option (NOTE: In case of errors during synchronization and when backups are created they are NOT automatically deleted. Therefore, if the script had failed with an error and afterwards completed successully you may want to manually remove the remaining backups from /var/backup/ngcp-sync-db).

Normal online mode synchronization sp1 → sp2.

sp2> ngcp-sync-db

Normal backup mode synchronization sp1 → sp2.

sp2> ngcp-sync-db --sync-mode=backup

Forced online mode synchronization sp1 → sp2. USE WITH CARE as there will be no confirmation prompts.

sp2> ngcp-sync-db --force

Direct mysql db access is not possible. SSH tunnel is initialised to local port 33125 and forwards all connections 127.0.0.1:33125 → sp1:3306.

sp2> ngcp-sync-db --ssh-tunnel=33125

Custom mysql credentials for the master db connection (by default: sipwise:/etc/mysql/sipwise.cnf)

sp2> ngcp-sync-db --master-user=frank --master-pass=dbconnect

Normal online mode synchronization sp1 → sp2 with the local db backup and retaining the backup. (no master backup in this case as it is only avaiable with --sync-mode=backup).

sp2> ngcp-sync-db --local-backup --keep-backups

Normal online mode synchronization custom-node → sp2 with ssh tunnel

sp2> ngcp-sync-db --master-host=custom-node --ssh-tunnel=45001

Forced syncrhonization custom-node → sp2 with ssh tunnel, backup sync mode, local backup, custom master and local db credentials and ports as well as a different backup dir

sp2> ngcp-sync-db --force --sync-mode=backup --master-host=custom-node --master-port=3308 --ssh-tunnel=45001 --master-user=frank --master-pass=dbconnect --local-user=john --local-pass=dblocal --local-backup --keep-backups --backup-dir=/home/barry/backups

The sip:provider PRO 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 PRO 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 PRO administrator tune the system requirements for optimum performance.

	In case of using virtualized environment with limited amount of hardware resources, you can use the script ngcp-toggle-performance-config to adjust sip:provider PRO configuration for high/low performance:

root@spce:~# /usr/sbin/ngcp-toggle-performance-config
/usr/sbin/ngcp-toggle-performance-config - tool to adjust sip:provider configuration for low/high performance

  --help                Display this usage information
  --high-performance    Adjust configuration for system with normal/high performance
  --low-performance     Adjust configuration for system with low performance (e.g. VMs)

root@spce:~#

The sip:provider PRO platform provides detailed logging and log files for each component included in the system via rsyslog. The main folder for log files is /var/log/ngcp/, it contains a list of self explanatory log files named by component name.

The sip:provider PRO is a high performance system which requires compromise between traceability (maximum amount of debug information being written to hard drive) and productivity (minimum load on IO subsystem). This is the reason why different log levels are configured for the provided components by default.

Most log files are designed for debugging sip:provider PRO by Sipwise operational team while main log files for daily routine usage are:

	it is highly NOT recommended to change default log levels as it can cause system IO overloading which will affect call processing.

	the exact size of log files depend on system type, system load, system health status and system configuration, so cannot be estimated with high precision. Additionally operational network parameters like ASR and ALOC may impact the log files' size significantly.