Software Upgrade

Run the terminal multiplexer under the sipwise user (to reuse the Sipwise .screenrc settings that are convenient for working in multiple windows):

Become root inside your screen session:

Check the overall system status:

For the below steps, investigate and make sure you understand why the custom modifications were introduced and if they are still required after the software upgrade. If the custom modifications are not required anymore, remove them (e.g. if a bug was fixed in the target release and the existing patch becomes irrelevant).

Find the local changes to the template files:

The script will also ask you if you would like to download the templates for your target release. To download the new templates separately, execute:

In the tmp folder provided by the script, you can review the patchtt files or merge the current customtt with the new tt2 templates, creating the new customtt.tt2 files. Once you do this, archive the new patchtt/customtt files to reapply your custom modifications after the software upgrade:

Find all available script options with the "-h" parameter.

Changes made directly in tt2 templates will be lost after the software upgrade. Only custom changes made in customtt.tt2 or added by patchtt.tt2 files will be kept. Hence, check the system for locally modified tt2 files on all nodes:

Check the configuration framework status on all nodes. All checks must show the "OK" result and there must be no actions required:

Run "apt-get update" and ensure that you do not have any warnings and errors in the output.

Public Debian mirrors may not provide packages for old Debian releases anymore. Also, they might be outdated. Consider using Sipwise repositories for the time of the upgrade.

Run the following command on all the nodes to install the package responsible for upgrading Sipwise C5 to a newer release:

There is a list of checks before the actual upgrade so it’s wise to run them beforehand to detect and fix all the issues.

The following options in ngcp-upgrade can be specially useful in some instances of upgrade:

You can run 1st stage outside the maintenance window.

To do this run the upgrade script as root:

There is "stop" step in upgrade scenario, ngcp-upgrade stops there. At this time the new system in fallback partition is ready.

The maintenance mode of the Sipwise C5 will disable some background services (for instance: ngcp-mediator) during the software upgrade. It thus prevents the system from getting into an inconsistent state while the upgrade is being performed. You can activate maintenance mode by applying a simple configuration change as described later.

If you upgrade from version mr11.1.1 or lower use:

Otherwise use:

Before reboot switch boot record, run as root:

Reboot the standby node and run as root:

Once up again, double-check your config file /etc/ngcp-config/config.yml (sections will be rearranged now and will contain more parameters) and your domain/subscriber/peer configuration and test the setup.

As anticipaed in the release notes, starting from Sipwise C5 version mr11.3.1 the Soundset inheritance feature has been added. Every Sound_Set can have a parent Sound_Set: if the parent is configured, all the announcements not defined in the current Sound_Set will be inherited from the parent, if any. Additionally the Contract_Sound_Set has been extended to contain all the announcements available in the standard Sound_Set. In case both of the sound set types are assigned to a subscriber, the Contract_Sound_Set takes precedence. This change could have an impact on systems with the CloudPBX module enabled and a mix of Sound_Set and Contract_Sound_Set are used.

To proceed with the migration, please follow the steps described in the release notes.

The exposition of the ncos and ncos_set preferences to subscribers may have an impact on NGCP systems where system administrators used to setup ncos instead of adm_nos to apply barrings on subscribers/domains. That change might potentially have an unintended consequence where subscribers modify the previously assigned by administrators 'ncos' preference.

In case if the ncos levels/sets were wrongly used in past, those have to be migrated to the corresponding admin level/set. This process can be easily done and automated using API or the Web interface. Alternatively, to help customer with this migration, a dedicated script called 'ngcp-migrate-adm-ncos' has been created. The script has to be run ONLY in systems where ALL the ncos and ncos_set have to be migrated to adm_ncos and adm_ncos_set preferences. In case of a mixed environment (some preferences have to be migrated and others not) then the migration has to be done manually. The script automatically runs through all subscribers, profiles, customer and domain preferences, check for any ncos or ncos_set occurrence and migrate it to the corresponding administrative preference. The script can be called anytime after the upgrade. If no parameter is specified, the script will simply print to the standard output the list of potential conflicts in the system: in cases where both the ncos and the adm_ncos (or ncos_set and adm_ncos_set) are configured. When all the reported changes has been acknowledged by the system administrator, the script should be run again with '--apply' parameter. Further invocations of the script will not have any effect on the system.

In order to disable the maintenance mode, do the following:

When everything has finished successfully, check that replication is running. Check ngcp-status. Finally, do a basic functionality test. Check the web interface, register two test subscribers and perform a test call between them to ensure call routing works.

Merge/add the custom configuration templates if needed.

Apply the changes to configuration templates:

Execute the final checks as described in the Post-upgrade checks section.