SIP-DECT Knowledge Base SIP-DECT System Update

(1)

SIP-DECT Knowledge Base

SIP-DECT System Update

MAI 2015

DEPL-2046 VERSION 1.6

KNOWLEDGE BASE

(2)

TABLE OF CONTENT

1) Introduction ... 2

2) Update (New Service Pack in the same Release) ... 3

2.1 OMM HOSTED ON A BASE STATION (WITH AND WITHOUT STANDBY OMM) ... 4

2.2 OMM HOSTED ON A LINUX SERVER (WITHOUT STANDBY OMM) ... 5

2.3 OMM HOSTED ON A LINUX SERVER (WITH STANDBY OMM)... 6

3) Upgrade (Switch to a new release) ... 7

3.1 INTRODUCTION ... 7

3.2 OMM HOSTED ON A BASE STATION (WITH AND WITHOUT STANDBY OMM) ... 8

3.3 OMM HOSTED ON A LINUX SERVER (WITHOUT STANDBY OMM) ... 9

3.4 OMM HOSTED ON A LINUX SERVER (WITH STANDBY OMM)... 10

4) Further advise ...12

4.1 GENERAL... 12

4.2 LICENSES ... 12

4.3 DECTPHONES (HANDSETS/PORTABLE PARTS) ... 13

4.4 BASE STATIONS ... 14

4.5 STANDBY OMM CONFIGURATION ... 15

4.6 OMMLINUX SERVER ... 15

4.7 DECTPHONE SHARING AND USER DATA PROVISIONING ... 15

4.8 OMLOCATING APPLICATION (OML) ... 15

4.9 MIVOICE5000IP-DECTUPDATE ... 16

4.10 VIRTUALIZED ENVIRONMENTS ... 16

The information conveyed in this document is confidential and proprietary to Mitel® and is intended solely for Mitel employees and members of Mitel’s reseller channel who specifically have a need to know this information. If you are not a Mitel employee or a Mitel authorizedPARTNER, you are not the intended recipient of this information. Please delete or return any related material. Mitel will enforce its right to protect its confidential and proprietary informationand failure to comply with the foregoing may result in legal action against you or your company.

(3)

1 | © MITEL 2015 | SIP-DECT KNOWLEDGE BASE

This document describes required actions, pre requirements and procedures to update

a SIP-DECT system to a new software release.

In addition recommendations and details for different update scenarios are described.

REVISION CONTROL INFORMATION

DATE AUTHOR VERSION CHANGES

08.2013 Julian Zelina 1.0 Initial Version

10.2013 Julian Zelina 1.2 Updates for SIP-DECT 5.0 01.2014 Julian Zelina 1.3 Update Aastra 5000 migration

03.2014 Julian Zelina 1.4 Update OML, trigger by ipdect.cfg, Fix: update modes 02.2015 Julian Zelina 1.5 Update for SIP-DECT 6.0

(4)

1) INTRODUCTION

Depending on your system setup an upgrade to a new release requires configuration changes on single or various services. The following points need to be considered when upgrading a SIP-DECT system.

- DECT Base station firmware - DECT Phone (Handset) firmware - Interoperability with PBX / Call server - Licenses

- OMM Application (e.g. when running a OMM Linux server) - Connected OM AXI applications as OML, OMP, Alarm server, … - Base station startup parameter via DHCP server(s) or configuration files. - Changes between the original release and the new one with update path

After the upgrade of the SIP-DECT firmware configuration changes to use new features and to improve / restore interoperability with connected services may be required. The following chapters describe required steps for an update within the same release and an upgrade to a new release.

Also if the descriptions are independent of the SIP-DECT release, this document assumes that an update to the latest available release is performed. This is SIP-DECT 6.0 at this time. In the last chapter detailed advice for specific topics is given.

(5)

2) UPDATE (NEW SERVICE PACK IN THE SAME RELEASE)

The update procedure depends on the following conditions:

- Single or standby OMM configuration - OMM running on an RFP or Linux server

- Do the release you use support different update modes (Release => 4.0) - Is the update initiated by an external service e.g. PBX

- Acceptable downtime of services

Preparation

- Backup your OMM configuration. (manual backup, not via automatic DB export) - Have the new firmware ready (and place it to your servers when possible)

- Check if updates of connected applications and DECT phones are required as well. - Read the release notes of the new and intermediate releases for advise

(6)

2.1 OMM HOSTED ON A BASE STATION (WITH AND WITHOUT STANDBY OMM) 1) Place the new RFP firmware images on the configured firmware download server(s).

This step might be automatically performed during a PBX update if the PBX software includes the SIP-DECT firmware.

2) Connect to the OMM using a Web browser or OMP. Browse to “System” > “System Settings”. In Release = 2.1 – 3.1: Click on the “Update” button to initiate the update (RFP by RFP) In Release => 4.0: Configure a concurrently (all at once) or successively (RFP by RFP) update mode and if required set an update time. Then click on the “Update” button. In Release 1.x: An OMM controlled update is not possible, restart the OMM.

Update Modes:

Concurrently (all at once): in this mode the OMM allow all RFPs to update immediately. This is the fastest update, but causes service downtime as all RFPs need to sync again. Successively (RFP by RFP): in this mode the OMM allow one RFP (per cluster) to update and monitor that this RFP is up and synchronized again before the next RFP update.

This mode is slow, but keeps the system operative. This mode is usually used for bigger systems where the availability of services e.g. messaging and calls is more important than short update duration. As soon the OMM initiates the update, the standby OMM (if present) will update and restart.

When the standby OMM is up again the primary OMM will restart and the RFPs failover to the new active OMM. RFPs will then perform the selected update mode controlled by the OMM. In case no Standby OMM is available the primary OMM initiates a software update and restart. Connected RFPs will lose the connection to the OMM and initiate an immediate update after some seconds without OMM connection.

3) When the OMM is up connect via Web browser or OMP to check the system state and RFP update progress.

(7)

2.2 OMM HOSTED ON A LINUX SERVER (WITHOUT STANDBY OMM)

1) Connect to the Linux server hosting the OMM and open a terminal (e.g. via SSH). 2) Place the new RFP firmware images on the configured firmware download server(s).

This step might be automatically performed during a PBX update if the PBX software includes the SIP-DECT firmware. (Postpone this step if the RFP update should be done in a second step at a later time.)

3) Install the new OMM application: sh SIP-DECT_version.bin (to update from a build versions run sh SIP-DECT_version.bin –f) 4) Start the OMM application. /etc/init.d/sip-dect-omm start

As soon the OMM is out of service, RFPs will start to frequently check for configuration changes by DHCP and for new firmware e.g. by TFTP. At this point the base stations will detect that a firmware update is available.

Depending on the RFP type, firmware and state, a firmware download may be initiated immediately. This may take some time depending on the system size and number of servers for the file transfer. It is possible to update the OMM application and later in a second step the RFPs,

as long the major protocol version between the releases did not change.

In this case place the new RFP firmware on the servers after the OMM update is completed. This can reduce the downtime and provide options to control the RFP update at a later time.

5) When the OMM is up connect via Web browser or OMP to check the system state and RFP update progress.

(8)

2.3 OMM HOSTED ON A LINUX SERVER (WITH STANDBY OMM)

1) Connect to the Linux server hosting the standby OMM and open a terminal (e.g. via SSH). 2) Stop the OMM application: /etc/init.d/sip-dect-omm stop

Wait at least 30 seconds before you stop the active OMM in the next step.

5) Place the new RFP firmware images on the configured firmware download server(s). This step might be automatically performed during a PBX update if the PBX software includes the SIP-DECT firmware.

(Postpone this step if the RFP update should be done in a second step at a later time.) As soon the (old) standby OMM is out of service, RFPs will start to frequently check for configuration changes by DHCP and for new firmware e.g. by TFTP.

At this point the base stations will detect that a firmware update is available.

Depending on the RFP type, firmware and state, a firmware download may be initiated immediately. This may take some time depending on the system size and number of servers for the file transfer. It is possible to update the OMM application and later in a second step the RFPs,

as long the major protocol version between the releases did not change.

In this case place the new RFP firmware on the servers after the OMM update is completed. This can reduce the downtime and provide options to control the RFP update at a later time. 6) Connect to the Linux server hosting the active (old) OMM and open a terminal (e.g. via SSH). 7) Stop the OMM application: /etc/init.d/sip-dect-omm stop

At this time the (new) standby OMM will failover and become active to allow RFPs to connect. 8) When the OMM is up connect via Web browser or OMP to check the system state

and RFP update progress.

9) Update connected components and applications if required. In the last step update and start the former active OMM (old).

This step can be delayed until full operation after the upgrade is verified. In case of problems a failover to the old OMM may be possible.

(9)

3) UPGRADE (SWITCH TO A NEW RELEASE)

3.1 INTRODUCTION

The upgrade procedure depends on the following conditions:

- Single or standby OMM configuration - OMM running on an RFP or Linux server

- Is the update initiated by an external service e.g. PBX - Connected applications

- DHCP server configuration - Software releases (old and new)

Preparation

- Backup your OMM configuration. (manual backup, not via automatic DB export) - Have the new firmware ready (and place it to your servers when possible) - If required generate a license for the new release and download the license file. - Check if updates of connected applications and DECT phones are required as well. - Read the release notes of the new and intermediate releases for advise

- Check if the hardware you use is still compatible and able to perform its function.

- Check if the operating systems hosting your applications are compatible to the new release. If you update an OMM PC or OML server keep in mind to update (or reinstall)

the hosting operating system to the supported version. Instructions to remove applications do not apply in case of a new server installation during the upgrade.

- When upgrading to Release 5.0 and 6.0 changes in Firewall rules may be required to add new required ports. (e.g. SIP-TLS, Multi Ports)

(10)

3.2 OMM HOSTED ON A BASE STATION (WITH AND WITHOUT STANDBY OMM) 1) Place the new RFP firmware images on the configured firmware download server(s).

When upgrade from Release 2.1 or lower the file name for the RFP 32/34/42 did change from omm_ffsip.tftp to iprfp2G.tftp in the software delivery.

In case of using a local RFP startup configuration or the firmware file name need to be configured on multiple services, we recommend to overwrite the existing image (or to set

a symbolic link) and to place a copy with the new file names into the server directory. This avoids a reconfiguration of many RFPs or multiple services in this stage.

In case of using a common DHCP server setting, change the filename to iprfp2G.tftp

2) When upgrade from Release 2.1 or lower only an RFP (L) 35,36,37 or 43 can now host the OMM (+ standby OMM) function. As this hardware was not supported before add or replace the OMM RFP(s) or migrate to a PC OMM.

In this case prepare the new RFP to replace the current OMM and apply the (old) OMM database to the new OMM. To avoid the reconfiguration of all connected RFPs the new

OMM(s) can use the same IP-address as the old OMM, when the old is out of service. Do not connect the new OMM hardware with customer database into the productive LAN until the old OMM is disconnected or set to be unconfigured!

(When the customer database is active this OMM try to connect with the SIP server(s).) 3) When upgrade from Release 2.1 or lower using a DHCP Server to startup RFPs,

consider updating the DHCP Server configuration to support the RFP 35, 36, 37, 43 units. 4) Connect to the OMM using a Web browser or OMP. Browse to System > System Settings.

In Release = 3.0 – 3.1: Click on the “Update” button to initiate the update In Release => 4.0: Configure the concurrent (all at once) update mode and if required set an update time. Then click on the “Update” button.

In Release 2.1 or lower: An OMM controlled update is not possible in this case.

Replace the OMM RFP(s) as described above, this downtime causes all RFPs to update. 5) When the OMM is up connect via Web browser or OMP. Apply the new license file if required

and check that all regulatory domains in the OMM system settings are valid and configured. When upgrading from Release 5.0 or lower, review the NTP Settings in the OMM System Settings. 6) Perform additional configuration to enable new features and restore interoperability with the call server. 7) Update connected components and applications if required.

(11)

3.3 OMM HOSTED ON A LINUX SERVER (WITHOUT STANDBY OMM)

1) Connect to the Linux server hosting the OMM and open a terminal (e.g. via SSH). 2) Place the new RFP firmware images on the configured firmware download server(s).

When upgrade from Release 2.1 the file name for the RFP 32/34/42

did change from omm_ffsip.tftp to iprfp2G.tftp in the software delivery.

3) When upgrade from Release 2.1 using a DHCP Server to startup RFPs,

consider updating the DHCP server configuration to support the RFP 35, 36, 37, 43 units. 4) If you update from Release 2.1 uninstall the installed OMM application:

use: /etc/init.d/omm_ffsip stop

then: rpm –e omm_ffsip-OMM omm_ffsip-HANDSET 5) Install the new OMM application: sh SIP-DECT_version.bin

(to update from a build versions run sh SIP-DECT_version.bin –f) 6) Configure the OMM startup parameter (when upgrade from Release 2.1)

Open the file /etc/sysconfig/SIP-DECT with a text editor and edit required parameters e.g. OMM_IF="eth0" (to define the network interface the OMM listens to)

7) Start the OMM application. /etc/init.d/sip-dect-omm start As soon the OMM is out of service, RFPs will start to frequently check for configuration changes by DHCP and for new firmware e.g. by TFTP. At this point the base stations will detect that a firmware update is available.

Depending on the RFP type, firmware and state, a firmware download will be initiated immediately. This may take some time depending on the system size and number of servers for the file transfer. The base stations cannot connect to the (new) OMM with a different protocol version,

they will stay disconnected until they proceed a software update or the OMM is on the same version. 8) Connect to the OMM via Web browser or OMP. Apply the new license file if required

and check that all regulatory domains in the OMM system settings are valid and configured. When upgrading from Release 5.0 or lower, review the NTP Settings in the OMM System Settings. 9) Perform additional configuration to enable new features and restore interoperability with the call server. 10) Update connected components and applications if required.

(12)

3.4 OMM HOSTED ON A LINUX SERVER (WITH STANDBY OMM)

1) Connect to the Linux server hosting the standby OMM and open a terminal (e.g. via SSH). 2) Stop the OMM application: /etc/init.d/sip-dect-omm stop

If you run Release 2.1 use: /etc/init.d/omm_ffsip stop 3) If you update from Release 2.1 uninstall the installed OMM application:

rpm –e omm_ffsip-OMM omm_ffsip-HANDSET

4) Install the new OMM application: sh SIP-DECT_version.bin (to update from a build versions run sh SIP-DECT_version.bin –f) 5) Configure the OMM startup parameter (when upgrade from Release 2.1)

When upgrade from Release 2.1, OMM startup parameter are not migrated.

Open the file /etc/sysconfig/SIP-DECT with a text editor and edit required parameters e.g.

OMM_IF="eth0" (to define the network interface the OMM listen to) OMM_RESILIENCY="OMM_IP1:OMM_IP2" (define OMM + Standby OMM)

6) Start the OMM application. /etc/init.d/sip-dect-omm start Wait at least 30 seconds before you stop the active OMM in the next step.

7) Place the new RFP firmware images on the configured firmware download server(s). This step might be automatically performed during a PBX update if the PBX software includes the SIP-DECT firmware.

When upgrade from Release 2.1 the file name for the RFP 32/34/42

did change from omm_ffsip.tftp to iprfp2G.tftp in the software delivery.

8) When upgrade from Release 2.1 using a DHCP server to startup RFPs,

consider updating the DHCP server configuration to support the RFP 35, 36, 37, 43 units. As soon the (old) standby OMM is out of service, RFPs will start to frequently check for configuration changes by DHCP and for new firmware e.g. by TFTP.

At this point the base stations will detect that a firmware update is available.

Depending on the RFP type, firmware and state a firmware download will be initiated immediately or controlled by the OMM. This may take some time depending on the system size and number of servers for the file transfer.

The base stations cannot connect to the (new) OMM with a different protocol version,

(13)

9) Connect to the Linux server hosting the active (old) OMM and open a terminal (e.g. via SSH). 10) Stop the OMM application: /etc/init.d/sip-dect-omm stop

If you run Release 2.1 use: /etc/init.d/omm_ffsip stop

At this time the (new) standby OMM will failover and become active to allow RFPs to connect.

11) Connect to the (new) active OMM via Web browser or OMP. Apply the new license file if required and check that all regulatory domains in the OMM system settings are valid and configured. When upgrading from Release 5.0 or lower, review the NTP Settings in the OMM System Settings. 12) Perform additional configuration to enable new features and restore interoperability with the call server. 13) Update connected components and applications if required.

In the last step update and start the former active OMM (old).

This step can be delayed until full operation after the upgrade is verified. In case of problems a failover to the old OMM may be possible.

14) Install the new firmware on the former active OMM (old)

If you update from Release 2.1 uninstall the installed OMM application: rpm –e omm_ffsip-OMM omm_ffsip-HANDSET

15) Install the new OMM application: sh SIP-DECT_version.bin (to update from a build versions run sh SIP-DECT_version.bin –f) 16) Configure the OMM startup parameter (when upgrade from Release 2.1)

When upgrade from Release 2.1, OMM startup parameter are not migrated.

Open the file /etc/sysconfig/SIP-DECT with a text editor and edit required parameters e.g.

OMM_IF="eth0" (to define the network interface the OMM listen to) OMM_RESILIENCY="OMM_IP1:OMM_IP2" (define OMM + Standby OMM) 17) Start the OMM application. /etc/init.d/sip-dect-omm start

(14)

4) FURTHER ADVISE

4.1 GENERAL

SIP-DECT can be updated direct from older releases to a new version, an update with intermediate releases is not required in a standard scenario. Mitel do only validate that an update from the last two major releases is working.

Upgrades from Release 3.0 or lower to 6.0 require an intermediate upgrade step e.g. to 5.0. In some upgrade scenarios the update mode all at once must be used to secure that the OMM

is not waiting for the updated standby OMM to reconnect. This is usually mentioned in the release notes. In case of updating a critical installation, we recommend to test the update scenario

with a customer database in the lab to verify operation and to be aware of required actions.

4.2 LICENSES Up to Release 5.0:

For each new minor or major Release a new license was required, when the system does not

run a build in license (1-2 RFPs). Licenses from former releases can be upgraded on the license server within the free update period (1 year) or after an OM Upgrade License was applied.

(An upgrade is also required for activated systems which use an OM System Activation for L-RFP installations e.g. 1or 2 L-RFPs with G.729 and 3-20 L-RFP installations.)

Licenses for a new release can be applied to the OMM before and

after the upgrade to a new release. If the new release includes new license types we recommend applying the new license after the OMM update to the new firmware. Since release 5.0 the license file now includes an installation id.

It is not possible to apply license files for release 5.0 and higher before the OMM upgrade to Release 5.0 or higher.

When upgrading from release 2.1 please notice that an additional license may now be required to use the codec G.729. (For all systems without OM System Activation for L-RFP installations) Release => 6.0:

When upgrading from Release 5.0 or lower the license will be maintained for standard RFP installations. All Installations with 1-2 RFPs will be migrated to the new build in licenses for up to 5 RFPs.

Licenses for G.729, Sending Messages from DECT Phones, Upgrade Licenses are removed as the features are included and don’t require a license anymore.

When upgrading a system with 3-20 RFP-L units from Release 5.0 or lower a new license files is required. Go to the license server to upgrade your system for free and install the new license file after upgrade. Since Release 6.0 RFPs with a branding e.g. RFP L are treated as standard RFPs.

When upgrading from release 1.x create a new license. (Licensing was introduced with 2.1)

When upgrading from release 2.1 RFP OMM we recommend keeping the license RFPs of your installations in service when possible e.g. in case that the license RFPs did host the OMM function before and are not longer required use them in exchange with other standard RFPs.

(15)

4.3 DECT PHONES (HANDSETS / PORTABLE PARTS)

With a new SIP-DECT software, the 600 DECT Phones start to download

software updates from the OMM in the background. Depending on the system size it can take several hours to update all DECT phones to the new release.

During this time the phone stays operational.

Depending on the changes between the phone firmware versions, new features are not available and cannot be configured on the phone until the update is completed. Please be aware that with new phone firmware, changes in the GUI may require

the end user to adjust his known handling. Introduce the users to changes when possible e.g. by sending a text message, provide a new user guide.

Here a list of some important changes to be considered: Since SIP-DECT 3.0 (Aastra 600d 4.00 / Aastra 6x2d/c 1.01)

- Introduction of en-bloc dialing, e.g. no simulated “line free” tones anymore. GAP phones with overlap sending have to use the dial terminator (#) - Support of XML applications e.g. to use remote call list and redial list - Introduction of UTF-8 signaling

- Local ringtone setting to differentiate external from internal calls

- Introduction of alphanumeric dial editor! The usage of * in the dial editor e.g. to dial procedures did change. (Long press key to insert *)

- SD Card support

Since SIP-DECT 4.0 (Aastra 600d/c 5.00)

- Introduction of enhanced alarm handling (display color, set audio parameter, …) - Bluetooth capability enhancement (Locating) (discontinued with SIP-DECT 6.0)

Since SIP-DECT 6.0 (602 DECT Phones 6.00, 6x0 DECT Phones 5.0) - Introduction of Configuration over Air and Branding

- New default Colour Scheme

Be aware that the 600 DECT Phone firmware download may be disabled in the phone or OMM. Check the phone update progress in the OMM to validate the status and update progress. The phone download settings can be configured in the 600 service menu.

For the 142 DECT Phone software updates need to be initiated by USB.

(16)

Since SIP-DECT 2.1 the base station software update is controlled by the OMM. As long the RFP is connected to the OMM, they announce available software updates detected by local checks to the OMM and wait for the OMM to allow the update.

When the RFP is not connected to the OMM anymore, an update will be initiated immediately e.g. in case of a release upgrade when RFPs cannot connect to the new OMM anymore.

To force the update of all base stations it can be useful to initiate a restart of the OMM base station(s). It is also possible to force an RFP update by the ssh service shell if required.

The RFP (L) 32, 34 and 42 download firmware only during each startup via TFTP.

When an update is triggered or detected the RFP restart to the booter phase and load software. A reboot initiated by SSH or power-down of the RFP force the RFP to load new software. To speed up the download TFTP Server options e.g. blocksize and multicast can be configured. When update from Release 1.x the RFP (L) 32, 34 and 42 start to offer blocksizes, tsize and multicast after the first startup.

The RFP (L) 35, 36, 37 and 43 download firmware only when in operation (after the startup). The RFP can download new firmware and restart at a later time when the OMM allows the update. A reboot initiated by SSH or power-down will not speedup or initiate the update of this RFP. Use “imgchk 1” in the “rfpm_console” to force an update of this RFP.

When using scheduled firmware updates e.g. on multiple SIP-DECT systems at one customer, the ipdect.cfg can be used to trigger the RFP firmware check with each OMConfigCheckInterval. This trigger allows local configured RFPs to check for firmware updates without user action.

In case an RFP (L) 35, 36, 37 and 43 cannot update over the network infrastructure an update via USB flash drive (“USB Stick”) can be initiated. Place the iprfp3G.dnld file into the root folder of the USB Stick and then plug the device into the RFP’s USB port.

The RFP should automatically apply the new version from USB and restart after some seconds. If a server for firmware updates is configured the RFP will try to load the software from

the configured server when the USB Stick is removed.

In case RFP (L) 35, 36, 37 and 43 are introduced into an installation using an DHCP Server, which was configured only for RFP (L) 32, 34 and 42 e.g. upgrade scenario from Release 2.1. The DHCP Server configuration needs to be adapted to support the new RFPs.

configure options bases on the Vendor class identifier to provide the required individual options. Identifiers: RFP (L) 32,34,42 = "OpenMobility" and RFP (L) 35,36,37,43 = "OpenMobility3G"

In case DHCP options can only be configured for all clients, add option 233 (or option 66) to use ipdect.cfg files.

In the files configure the “OM_SwImageUrl” to provide a software update URL for the new RFPs. Keep DHCP next server and filename configured for the old RFPs.

Check that also the DHCP option 224 is adapted to “OpenMobilitySIP-DECT”.

When updating from Release 3.0 to 6.0 or higher the regular iprfp3G.dnld software file is larger than the download limits in Release 3.0. In this case a specific software file without the 600 DECT Phone software or an upgrade with intermediate step is required.

Since Release 6.0 some DHCP options and configuration file attributes was discontinued, DHCP and Configuration files should be adapted to remove unsupported parameters.

(17)

In case a standby OMM is configured, both OMMs will initiate actions to check that the SIP server and the other OMM are reachable. In such checks the OMM use the DECT Phone with the lowest phone number to register to the SIP-Server. If the registration succeeds the SIP-server is considered as up & running. The SIP server needs to make sure that SIP registrations after an OMM failover can be initiated again, also if the SIP registrations from the former OMM did not time out at this time.

In most systems new registrations will “overwrite” former registrations for this terminal or initiate parallel registrations. If this is not automatically the case additional configuration should be performed on the SIP server e.g. allows multiple SIP registrations for the first user account.

For MiVoice 5000 configure an additional DECT IP terminal with the lowest number. This terminal must not be used by an existing DECT phone.

Since SIP-DECT 5.0 the user for the SIP register check can be configured in OMP.

In Standby RFP OMM scenarios it is possible to switch off the Standby OMM before an upgrade is initiated. This allows reverting to the original state in case an unexpected issue occurs. To revert, restore the original TFTP and DHCP state and to switch off the active OMM before the (old) Standby OMM is started. (Otherwise this RFP will not startup or upgrade)

4.6 OMM LINUX SERVER

With SIP-DECT 3.0 the OMM and OML server have to run on Red Hat® Enterprise Linux® 6. Since SIP-DECT 4.0 also CentOS 6 and Virtualized environments are supported.

The installation and requirements are described in the SIP-DECT OM System manual and in the Knowledge Base article “KB OMM Linux Server Installation”.

When updating from SIP-DECT 2.1 with RHEL 5.4 we recommend updating (reinstall) the Linux OS.

4.7 DECT PHONE SHARING AND USER DATA PROVISIONING

When upgrading from Release 2.1 on RFP OMM(s) all dynamic users will be logged out as the database need to be activated to a new OMM RFP. Users need to login afterwards. With new releases additional configuration parameters for DECT phone users can be introduced. If external user configuration files are used (user_common.cfg and “extension”.cfg) consider

that the files need to be adapted on the configuration file server to apply new configuration parameters. Since Release 6.0 relations between phone and user can be maintained when importing a OMM Database. 4.8 OM LOCATING APPLICATION (OML)

The installation and requirements are described in the OM Locating Application -

Installation, Administration & User Guide. Backup the OML database and location images before you update the OML.war file.

When updating from SIP-DECT 2.1 with RHEL 5.4 we recommend updating (reinstall) the Linux OS. Check that the version of Tomcat and Java match to the OML requirements.

(18)

Since SIP-DECT 4.0SP4 the OML Database location did change to /var/lib/OML/

When updating from releases lower than 4.0SP4 it is mandatory to create this new Database folder, set the permissions for tomcat and move the Database to this folder.

See OM Locating Application - Installation, Administration & User Guide for more information. Since SIP-DECT 5.0 Java 1.7 is required to operate OML.

It is required to install the new java version using yum install java-1.7.0-openjdk and to apply this as active java version using /usr/sbin/alternatives --config java 4.9 MIVOICE 5000 IP-DECT UPDATE

Upgrade scenarios for IP-DECT 2.1 with MiVoice 5000 are similar to SIP-DECT 2.1.

Please read the MiVoice 5000 documentation for more details on how to proceed an upgrade. It is mandatory to upgrade MiVoice / Nexspan IP-DECT systems to IP-DECT 2.1 before migrating to SIP-DECT 4.0. When migrating IP-DECT to higher SIP-DECT releases it is mandatory to upgrade to SIP-DECT 4.0 first.

A specific license is not required for the intermediate release while upgrading. Known differences to this documentation:

- RFP (L) 32, 34, 42 firmware filename is omm_a5000.tftp instead of omm_ffsip.tftp - Linux Server OMM scripts and files include the name omm_a5000 instead of omm_ffsip

4.10 VIRTUALIZED ENVIRONMENTS

In general updates and upgrades should be performed as on a traditional hardware environment. With the advanced capabilities of virtualization it is recommended to create

a virtual machine snapshot of the machine before the update is initiated (if possible). This allows a fast method to revert to the original state in case issues occur.

Notice that VMware snapshots including memory freeze the OMM operations for a short time, consider to perform snapshots e.g. when the OMM service is stopped to avoid OMM failover.