T-MXONE-7-0-C2-IM v1.2

MiVoice MX-ONE
Core Part 2 Installation and Maintenance course

Software Release 7.0
Issue 1.2
MiVoice MX-ONE Core Part 2 Installation and Maintenance Course
NOTICE
The information contained in this document is believed to be accurate in all respects but is not
warranted by Mitel Networks Corporation or any of its affiliates or subsidiaries (collectively “Mitel”).
The information is subject to change without notice and should not be construed in any way as a
commitment by Mitel. Mitel assumes no responsibility for any errors or omissions in this document.
Revisions of this document or new editions of it may be issued to incorporate changes. The document
in its entirety or any part thereof may not be reproduced or transmitted in any form by any means –
electronic or mechanical – for any purpose without the express written permission from Mitel
Networks Corporation.
Trademarks
Mitel is a registered trademark of Mitel Networks Corporation.
Windows and Microsoft are trademarks of Microsoft Corporation.
VMware, vMotion, vCenter, vCloud, vSphere, ESX, and ESXi are trademarks of VMware
Incorporated.
Google and the Google logo are registered trademarks of Google Inc.
Firefox is a registered trademark of the Mozilla Foundation.
Other product names mentioned in this document may be trademarks of their respective companies
and are hereby acknowledged.
MiVoice MX-ONE
Release 7.0
January, 2019
© 2018,2019 Mitel Networks Corporation

Personal use of this material is permitted. However, permission to reprint/republish this
material for advertising or promotional purposes or for creating new collective works for
resale or redistribution to servers or lists, or to reuse any copy righted component of this
work in other works must be obtained from Mitel Networks Corporation
ii T-MXONE-7-0-C2-IM v1.2.docx
Student Code of Conduct ..................................................................................................... xiii
Course Description ............................................................................................................... xiv
Information Icons ................................................................................................................... xv
Product Documentation ........................................................................................................ xvi
Getting Help ........................................................................................................................ xvii
Technical Certification .........................................................................................................xviii
Installing MX-ONE with Redundancy........................................................................... 1

Network Redundancy ............................................................................................................. 3
Network Redundancy design .............................................................................................. 3
Network redundancy by using Ethernet bonding ................................................................. 4
Lab 1 - Installing the Server operating system and preparing it for the MiVoice MX-One
install .................................................................................................................................. 5
Lab 2 - Setting up the MiVoice MX-One system on Server 1 and 2 ..................................... 5
Home Location Register (HLR) Redundancy .......................................................................... 6
Lab 3 - Installing Provisioning Manager .............................................................................. 7
Lab 4 - Creating Extensions and Registering Phones ......................................................... 7
Lab 5 - HLR Redundancy.................................................................................................... 7
Server Redundancy ................................................................................................................ 8
Configuring and using server redundancy ........................................................................... 8
Display the cluster status ...................................................................................................17
Display the cluster configuration ........................................................................................19
Lab 6 - Creating a Cluster ..................................................................................................20
Lab 7 – Displaying the cluster status and configuration ......................................................20
Adding a LIM to a cluster ...................................................................................................21
Execute a manual fallback to a regular server ....................................................................23
Change fallback type and server priority ............................................................................25
Execute a manual ordered synch of data ...........................................................................28
Lock or unlock a LIM to a specific server............................................................................29
Lab 8 – Displaying the cluster configuration and status ......................................................31
Lab 9 – Testing a Standard MX-ONE Standby Server cluster ............................................31
Lab 10 - Change the Fallback and Priority of a Cluster ......................................................31
Lab 11 – Performing a manual ordered synch of data ........................................................31
iii
PreLoaded Cluster .............................................................................................................37
Converting a Cluster to a Pre-Loaded one .........................................................................37
Lab 11 – Performing a manual ordered synch of data ........................................................40
Lab 12 – Locking and Unlocking a LIM ..............................................................................40
Lab 13 - Removing a LIM from a Cluster ............................................................................40
Lab 14 - Removing a Cluster..............................................................................................40
Lab 15 - Creating a new PreLoaded Cluster ......................................................................40
Installing Provisioning / Service Node Manager Redundancy ................................................41
Configuration of the Master Server.....................................................................................41
Configuration of the Standby Server ..................................................................................45
Web Redundancy Utilities ..................................................................................................47
Lab 16 - Configuring Web Service Redundancy .................................................................49
VMWare High Availability and Fault Tolerance ......................................................................50
MiVoice MX-ONE Migration and Advanced Backup ................................................... 1

UPGRADE TO MIVOICE MX-ONE 7.X .................................................................................. 3
UPGRADE USING REGENERATION SCRIPT UTILITY..................................................... 4
COLLECTION REGENERATION OF DATA, VIA REGENERATION SCRIPT UTILITY....... 4
INSTALL THE MIVOICE MX-ONE 7.X ................................................................................ 4
IMPORT SAVED TELEPHONY DATA, VIA THE REGENERATION SCRIPT UTILITY ....... 4
RESTORING SAVED DATA INTO THE MIVOICE MX-ONE 7.X ........................................ 5
MIGRATING PROVISIONING MANAGER AND SERVICE NODE MANAGER ...................... 6
BACKUP SERVICE NODE MANAGER (MANAGER TELEPHONY SERVER IN MX-

ONE 5.0/6.0) ....................................................................................................................... 6
TEMPLATE DATA BACKUP ............................................................................................... 6
BACKUP PROVISIONING MANAGER (MANAGER PROVISIONING IN MX-ONE

5.0/6.0) ............................................................................................................................... 7
MANAGER PROVISIONING TEMPLATE DATA BACKUP ................................................. 8
RESTORE SERVICE NODE MANAGER ............................................................................ 8
RESTORE PROVISIONING MANAGER ............................................................................. 8
pm_snm_6.x_backup script ...............................................................................................10
Using PC-REGEN to Backup/Archive an MX-ONE System ...................................................12
Installing and Initializing PC-Regen .......................................................................................13
iv T-MXONE-7-0-C2-IM v1.2.docx
Installing the PC-Regen Utility............................................................................................13
Using PC-Regen ................................................................................................................14
Creating the Initial Capture Batch File ................................................................................15
Lab 1 - Installing and Using PC-REGEN ............................................................................21
Service Node Manager Upgrade ...........................................................................................22
OS Upgrade ..........................................................................................................................23
MiVoice MX-ONE Maintenance Utility ................................................................................23
SLES Upgrade Preparation ................................................................................................24
SLES Upgrade on a System running MiVoice MX-ONE 7.0 ...............................................25
Lab 2 - Performing a SLES OS Upgrade ............................................................................28
Service Node (Telephony System) Upgrade ......................................................................29
Verifying the Upgrade ........................................................................................................38
Lab 3 - Performing a Service Node Upgrade......................................................................40
Provisioning Manager Upgrade Preparation.......................................................................41
Provisioning Manager Upgrade ..........................................................................................42
Lab 4 - Performing a Provisioning Manager Upgrade .........................................................48
Call Information Logging ............................................................................................. 1

Reference Material ................................................................................................................. 3
Overview ................................................................................................................................ 4
Call Information Logging (CIL) Function Description ............................................................... 6
Condition Data for Call Data ................................................................................................... 7
One-Character Condition Code ........................................................................................... 7
Two-Character Condition Code ........................................................................................... 8
Three-Character Condition Code ........................................................................................ 9
Output Types and Subtypes ..................................................................................................11
Output Types .....................................................................................................................12
Output Subtypes ................................................................................................................12
Mobility Data..........................................................................................................................13
Condition codes for Mobility events ....................................................................................13
Mobility Criteria......................................................................................................................14
Output Formatting .................................................................................................................15
v
CIL Heartbeat ........................................................................................................................16
Capacity ................................................................................................................................17
Max. Capacity, Independent of Output Devices .................................................................17
System Reliability...............................................................................................................17
Alarms ...................................................................................................................................18
CIL Commands .....................................................................................................................19
CIL Output .........................................................................................................................23
Fixed Format Example .......................................................................................................26
CIL Output over TCP with Heartbeat Example ...................................................................26
Forward All CIL Data to Server 2 for Centralized CIL Example ..........................................27
To Set CIL Output to a Flexible Format Example ...............................................................27
Lab 1 - Configuring Call Logging to a Local File Lab 2 - Configuring Call Logging to a
TCP Connection.................................................................................................................29
Recorded Voice Announcements ................................................................................ 1

Initializing Recorded Voice Announcements ........................................................................... 4
Upload Sound Files ............................................................................................................. 4
Link Messages to Announcements...................................................................................... 6
Activating RVA for specific purposes................................................................................... 7
Link Announcements to Specific Components .................................................................... 9
Lab 1 - Setting up Recorded Voice Announcements ..........................................................10
Streaming Audio to SIP Extensions .......................................................................................11
Activating the Media Streaming Server ..............................................................................12
Media Server Message ......................................................................................................15
Activating on the Mitel SIP Handsets .................................................................................16
Least Cost Routing and Number Conversion / Translation..................................... 17

LCR – Least Cost Routing .....................................................................................................18
Overview ............................................................................................................................18
How does LCR work? ........................................................................................................18
External Number Table ......................................................................................................19
Number Length Table ........................................................................................................20
Destination Number Tables (DNT1 & DNT2)......................................................................20
Fictitious Destination Table ................................................................................................21
vi T-MXONE-7-0-C2-IM v1.2.docx
LCR Initiation .....................................................................................................................23
Lab 1 - Configuring Simple Least Cost Routing ..................................................................26
Number Conversion...............................................................................................................27
Using SNM to configure Number Conversion .....................................................................28
Number Conversion Bulk Upload .......................................................................................31
Lab 2 - Configuring Number Conversion ............................................................................32
Fault locating & Recovery ............................................................................................ 1

Overview ................................................................................................................................ 3
Logs ....................................................................................................................................... 4
System Logs ....................................................................................................................... 4
Log Entries.......................................................................................................................... 4
Log Configuration................................................................................................................ 5
MIVoice MX-ONE Service Node Manager Logs ..................................................................... 6
Log Settings ........................................................................................................................ 6
Fault Location Subflow ........................................................................................................... 7
Subflows................................................................................................................................10
Subflow 1: Collection of Further Information.......................................................................10
Subflow 2: Initial Fault Locating..........................................................................................12
Subflow 3: Print Alarm List or Log ......................................................................................12
Subflow 4: Individual Fault Code Flows ..............................................................................12
Subflow 5: Verify if it's a Software or Hardware Fault .........................................................12
Subflow 6: Verify that the Fault is Unambiguous ................................................................12
Subflow 7: Block HW Unit ..................................................................................................13
Subflow 8: Replace HW Unit ..............................................................................................13
Subflow 9: Restart HW Unit ...............................................................................................13
Subflow 10: Verify Functions of the Replaced HW Unit ......................................................13
Subflow 11: Deblock HW Unit ............................................................................................13
SubFlow 12: Acknowledge the Alarm .................................................................................13
Subflow 13: Reporting ........................................................................................................13
Subflow 14: Measures to take if it is not possible to communicate with the MiVoice MX-
ONE ...................................................................................................................................14
Subflow 15: Restart............................................................................................................14
vii
Subflow 16: Measures to Initiate when Irrelevant Information is Obtained ..........................14
Subflow 17: Measures when the above steps do not work .................................................14
Fault Codes ...........................................................................................................................16
Domain 0 - MiVoice MX-ONE Compatible Alarms .................................................................17
Service System, SES, Fault Codes 1 - 255 ........................................................................17
Advanced Communications System, ACS, Fault Codes 257 - 511 .....................................20
Domain 1 - SES.....................................................................................................................29
Domain 2 - ACS ....................................................................................................................31
Domain 3 - Other MiVoice MX-ONE Service Node ................................................................32
Domain 4 - WBM - Web Based Management ........................................................................33
Domain 5 - Media Gateway ...................................................................................................34
Lab 1 - Reviewing Logs and Alarms ...................................................................................35
Recovering an MX-ONE System ...........................................................................................36
Restoring using Backups / config_mirror ............................................................................36
Restoring a configuration using a safety backup ................................................................37
Replacing a failed server/LIM using the recovery process..................................................39
Optional Lab 2 - Recovering a Failed Server......................................................................45
Security ......................................................................................................................... 1
Certificate Management ......................................................................................................... 3
Certificates and Key Management ...................................................................................... 3
TLS Handshake .................................................................................................................. 3
Preparation and Work Process ........................................................................................... 4
Strategies for Certificate Handling ....................................................................................... 6
Execution ............................................................................................................................ 7
Create and Install a default certificate and activate TLS ...................................................... 7
Create a ROOT Certificate .................................................................................................. 7
Create or Renew a Certificate ............................................................................................. 7
Import of a Signed Certificate .............................................................................................. 7
Managing TLS in the MiVoice MX-ONE .............................................................................. 9
VoIP Security.........................................................................................................................10
Configuring TLS using the configuration files .....................................................................11
viii T-MXONE-7-0-C2-IM v1.2.docx

Configuring TLS using the Mitel Web UI ............................................................................11
Changing the Security Policy .............................................................................................13
Steps to install and setup VoIP security .............................................................................13
No Security Policy ..............................................................................................................13
All Secure Policy ................................................................................................................14
All Secure with Extension Exception ..................................................................................15
All Secure with Exception Type ..........................................................................................15
Media Encryption ...............................................................................................................16
Check Signaling Security ...................................................................................................16
Configuring PM & SNM to use HTTPS ..................................................................................17
Tracing ........................................................................................................................... 1
Trace Functionality ................................................................................................................. 3
Trace Types ........................................................................................................................ 3
Perform a Trace .................................................................................................................. 4
Lab 1 - Configuring an MX-ONE Signal Trace ..................................................................... 9
SNMP and DHCP ........................................................................................................... 1

Overview ................................................................................................................................ 3
MiVoice MX-ONE SNMP Implementation ............................................................................... 4
The SNMP Licensing Mechanism ........................................................................................... 8
Supported Objects in the MiVoice MX-ONE MIB (MX-ONE-TS-ALARM-MIB) ..................... 9
Supported traps in the MiVoice MX-ONE MIB (MX-ONE-TS-ALARM-MIB) ......................... 9
System Status MIB Detailed Description ............................................................................10
Interfaces MIB Detailed Description ...................................................................................10
TRAPS...............................................................................................................................17
Configuration .........................................................................................................................19
SNMP Configuration using using mxone_maintenance ......................................................19
SNMP Configuration using the command line / manual file edit .........................................22
Configuration of Alarm Notification using E-MAIL and SMS ...............................................22
Enabling Mail from SNMP Traps ........................................................................................22
Proxy Traps to the same destination ..................................................................................23
Disabling the Trap Daemon ...............................................................................................23
ix
Restarting the Trap Daemon ..............................................................................................23
Verifying the Installation ........................................................................................................24
Checking the status of the Daemons..................................................................................24
Using NET_SNMP tools to check alarms ...........................................................................24
SNMP Version 3 ................................................................................................................26
Lab 1 - Enabling SNMP on MX-ONE..................................................................................27
DHCP ....................................................................................................................................28
IP Configuration Data from DHCP ......................................................................................28
DHCP Settings for Option 66 .............................................................................................28
DHCP Settings for Option 43 and 60..................................................................................28
Appendix A - MiVoice MX-ONE Extensions using the Command Line Interface ..... 1
IP/SIP/Virtual .......................................................................................................................... 3
Commands used for generic extensions (IP, SIP, Virtual): .................................................. 3
Generic extension parameters worth mentioning for this release: ....................................... 4
Commands used for IP extensions (IP and SIP): ................................................................ 5
IP extension specific parameters worth mentioning for this release:.................................... 5
Virtual IP extension creation command ............................................................................... 5
Password creation for a SIP extension (Used for Free seating (hot desking)) ..................... 6
Common Service Profile (CSP) .............................................................................................. 7
Parameters ......................................................................................................................... 7
Main Command Line Parameters ........................................................................................ 9
Example: ............................................................................................................................10
Number Presentation Category ..........................................................................................11
Traffic Category .................................................................................................................12
Service Category ...............................................................................................................13
Call Diversion Category .....................................................................................................17
Routing Category ...............................................................................................................19
IP Phone Software Server .....................................................................................................20
Setting up the Software Server ..........................................................................................20
Install IP Phone SW Server ................................................................................................22
Microsoft IIS Web Server ...................................................................................................23
x T-MXONE-7-0-C2-IM v1.2.docx
Appendix B - MiVoice MX-ONE Telephony Features using the Command Line

Interface ....................................................................................................................... 25
Parallel Ringing (Multiple Terminal Service) ..........................................................................27
Forking (Multi Terminal Service) ............................................................................................29
Personal Number List ............................................................................................................31
Hunt Groups ..........................................................................................................................35
Pickup Group.........................................................................................................................37
Free Seating (Hot Desking) ...................................................................................................38
Capacity .............................................................................................................................38
Restrictions ........................................................................................................................39
Call Forwarding .....................................................................................................................40
Appendix C - External Survivable Gateway ............................................................. 41

External Survivable Gateway .................................................................................................42
Mitel GX .............................................................................................................................43
Mitel EX .............................................................................................................................48
EX Controller & GX Gateway Usage and Operation ..............................................................50
Using SNM to add a GX Gateway ......................................................................................52
xi
This page intentionally blank.
xii T-MXONE-7-0-C2-IM v1.2.docx

Student Code of Conduct
Mitel Training makes every effort possible to provide a safe, clean and professional
environment for students attending training classes. It has become necessary, for the benefit
of all students, to define what is expected from those attending classes at Mitel Training.
Please observe the following guidelines.
Punctuality
Classes begin promptly at the time designated by your instructor. Students are required to
return from breaks and lunch promptly, as the instructor specifies. Instructors will begin
lectures promptly at the scheduled times.
Appropriate Behavior
Students are expected to participate in class as professionals. Disruptive behavior will not be
tolerated.
Disruptive behavior is any action interfering with the instructor’s presentation or action
distracting from another student’s ability to participate in the class. If, at the instructor’s
discretion, a student is being disruptive, the following steps will be taken:
• 1st Occurrence: Verbal warning. The student will be advised that his or her behavior is
disruptive.
• 2nd Occurrence: Verbal warning. The student and the student’s manager or supervisor
will be informed that this is the final warning.
• 3rd and Final Occurrence: The student will be dismissed from the remainder of class
and the student’s manager or supervisor will be informed that the student has been
released from class. The only option available to the student is to take the course exam
at a proctored testing center, at the student’s expense, or retake the course, in its
entirety, at full tuition. No refund will be issued.
Training Equipment
Mitel Training has made every effort to provide a “state-of-the-art” training facility and
training equipment. Every effort has been made to provide the technology and equipment
necessary to provide students with a real-world environment. All training systems and
equipment (including PCs and the PC Network) are provided as tools to enhance the training
experience. Equipment is only to be accessed and utilized for the completion of class lab
exercises as the instructor indicates. Unauthorized exploring of, or experimenting with the
training equipment will be considered disruptive behavior and will not be tolerated.
Leaving Class Prior to the Final Certification Exam
Occasionally, a student may have a bona fide reason to leave class early due to a family
emergency, death in the family, etc. If a student must leave class prior to the administration
of a final written exam for any reason, the only option available to the student is to complete
the final written exam at a proctored testing center. Testing fees from the testing center are
the responsibility of the student and/or company requesting the test.
xiii
Course Description
The MiVoice MX-ONE Core Part 2 I&M course covers more advanced tasks involved in
installing, configuring, maintaining, and troubleshooting the MiVoice MX-ONE system.
Topics covered include:
• Using Server Redundancy
• Migrating data from v6 to v7
• Using PC-REGEN
• Call Logging
• Recorded Voice Announcements
• Fault locating
• Least Cost Routing and Number Conversion
• Enabling Security and Encryption
• Network services, DHCP & SNMP
• Tracing
For Technical Students needing a MiVoice MX-ONE Core Part 2 I&M certification, trainees
must successfully complete the following:
MiVoice MX-ONE Core Part 1 I&M 7.0
xiv T-MXONE-7-0-C2-IM v1.2.docx

Information Icons
Information icons are used throughout the course to identify the following:
Reference: Directs you to additional reference information in the Technical

Documentation, Online Help, or other support documents
Note: Identifies a key point of interest. The note symbol may also direct you to
helpful information in the system documentation or other supporting
documentation.
Navigation: Identifies tips on how to navigate through the course material.
Remote Training: Identifies instructions that are specific to remote training

courses.
Tools and Equipment: Identifies tools and equipment you will need to
complete a lab exercise.
Caution: Identifies a potentially dangerous situation that may result in injury to

you or damage to the equipment.
xv
Product Documentation
You can view all the product documentation required to complete this course from the Mitel
Connect on the Knowledge Base.
MiVoice MX-ONE documentation is found under Answers/Release Information.
If you do not have access to this information, contact your local Mitel representative or Mitel
Connect.
xvi T-MXONE-7-0-C2-IM v1.2.docx

Getting Help
If you have trouble with any part of this course, please contact our Technical Training
Department.
If you have trouble with any part of this course, please contact our
Technical Training Department.
Please be ready to provide the following information:
• Your name
• Your telephone number
• The course name
• A description of the problem you have or the assistance you need.
In North America, call Mitel Technical Training at 1-800-722-1301. When

the Automated Attendant answers, select menu option 6 and then
option 2. The first available operator will answer your call.
You can also email technical_training@mitel.com
.
In Australia/Asia Pacific, call Mitel Training at +61 2 9023 9500.
You can also email channelsupportanz@mitel.com
In France, call Mitel France Training at +(33) 130964230 Call Mitel France Training.
You can also email training.france@aastra.com .
In Germany, call Trainingszentrum Deutschland +49 69 430535 7331.

You can also email training_de@mitel.com
In Sweden, email education.se@aastra.com
In Switzerland, call Mitel Switzerland Ltd at +(41) 32 655 3333. When the Attendant
answers, your call will be transferred to the Mitel Switzerland Training Manager.
You can also email TrainingCH@mitel.com
In the United Kingdom and all other countries In Europe, Middle East,
Africa (EMEA), call Mitel Training at +(44) 01291 436539. After normal
working hours, your call is transferred to voice mail.
You can also email uktraining@mitel.com
xvii
Technical Certification
To gain Mitel technical certification on this product, you must complete a practical test at the
end of the course. Your final test score must be 80% or higher to attain certification.
The last day of the course will be the practical test.
xviii T-MXONE-7-0-C2-IM v1.2.docx

Installing MX-ONE with
1
Redundancy
Objectives
When you finish this module, you will:
 Understand how to implement Network Redundancy

 Understand how to implement Server redundancy
 Know how to configure a Pre-Loaded cluster
 Configuring Webserver redundancy
This page is intentionally blank.
1-2 T-MXONE-7-0-C2-IM v1.2.docx

Installing MiVoice MX-ONE with Redundnacy
Network Redundancy
To achieve network redundancy, a redundant network infrastructure must be available.

Although several redundancy methods are available, the MiVoice MX-ONE only supports
the layer 2 switched redundant network method.
Network Redundancy design

Redundant Networks can be designed in several different ways, it will depend on the
customer requirements, and normally a good network design includes a combination
of hardware and software techniques.
Network single point of failure reduction can be achieved using duplication of some
hardware and the introduction of some network protocols that can help the availability
of the network. Equipment can also be installed in different physical locations.
Techniques like Virtual Local Area Networks (VLANs), Virtual Redundant Route
Protocol (VRRP) and Layer 3 protocols can be used to create a redundant
environment that can increase the network availability. When using VRRP, different
VRID's shall be used to avoid that the same MAC address is used by two VLANs.
Also, some sort of Spanning Tree protocol is needed on the network if it contains redundant
network paths. This is required to prevent Ethernet broadcast storms. The network recovery
speed varies depending on the type of Spanning Tree protocol and network configuration
being used. Rapid Spanning Tree protocol (RSTP or MSTP) is recommended.
1-3
Network redundancy by using Ethernet bonding

By using Ethernet bonding, a switched network with a single subnet can be used for
network redundancy.
When using Ethernet bonding with the MiVoice MX-ONE, two Ethernet interfaces are
aggregated to a logical unit where one interface is active at a time, while the other
interface acts as a backup. The two interfaces share the same IP and MAC address.
If one of the interfaces fail, the other one will continue to serve the operations and the
Telephony Server will be available on the functioning interface.
Note: Ethernet bonding is the only method that the MiVoice MX-ONE
supports.
Certain features like Operator Queue and ACD backup group can achieve a
certain redundancy by being duplicated and placed in different Telephony
servers. This increases the reliability/redundancy of their respective features.

Lab 1 - Installing the Server operating system and preparing it for

the MiVoice MX-One install
Lab 2 - Setting up the MiVoice MX-One system on Server 1 and 2

Open your Lab Workbook and complete the associated lab exercises.
1-5
Home Location Register (HLR) Redundancy
Home Location Register refers to the server that hosts the registration details for an IP
extension. In the case of the MX-ONE, when an extension is created the server or LIM
number is specified. This becomes the extension’s HLR. The ULR (User Location Register)
is the server or LIM that actually receives the initial registration request (logon) from the
extension and handles future requests to make and clear calls. If an extension logs on to a
server that is not it’s HLR, then when using the default configuration, that server must
contact the HLR server to verify the extension’s credentials. If the HLR server is down or not
reachable then the extension will not be able to logon or make new calls.
HLR Redundancy is an additional way to provide redundancy for IP extensions (SIP, H.323).
This allows an extension to register to a backup HLR server if the main HLR server fails.
When HLR Redundancy is enabled, duplicate copies of the extension’s essential data are
make throughout the system. This ensures that any Service Node can authenticate an
extension and provide basic telephony facilities.
Note: HLR Redundancy does not copy every detail of an extension.

Therefore, some more advanced features may not be present if the
extension’s HLR server is unavailable e.g. group memberships, parallel
ringing.
To activate HLR redundancy, a license must be purchased and application parameter 198
must be changed from 0 to 1. This change must be done from the command line using the
ASPAC MML command.
To view the current setting issue the following command from the MDSH shell:
ASPAP:PARNUM=198;
To enable HLR Redundancy, issue the following command from the MDSH shell:
ASPAC:PARNUM=198,PARVAL=1;
Once enabled, the existing extension information will start to be replicated. After 5-10
minutes the HLR Redundancy should be fully implemented and can be tested.
When the home server of an extension fails, the extension will attempt to register to a
backup server. This server will create a temporary HLR with all the data that is available in
the system database for the registering extension.
In order for a terminal or application to take advantage of HLR, it must typically support the
configuration of a secondary or backup gatekeeper/proxy to ensure that an alternative server
can be utilised if the first choice is unavailable .
Find out more about HLR by viewing 58/1551-ANF 901 14 from the CPI documentation

Lab 3 - Installing Provisioning Manager
Lab 4 - Creating Extensions and Registering Phones
Lab 5 - HLR Redundancy

Open your Lab Workbook and complete the associated lab exercises
1-7
Server Redundancy
Server redundancy is achieved by adding one Standby Server for a cluster with up to ten
servers. The system can be divided in as many clusters as applicable, with a minimum of
one operating server and one standby server (1+1) up to ten operating servers and one
standby server (10+1) per cluster.
All servers within a cluster must be configured to use the same IP subnet and should be
connected via reliable network connections. If a system is spread across multiple subnets,
multiple clusters must be created.
Clusters can be configured with different characteristics, such as priorities to take over
servers when more than one server fails, whether a server should automatically fall back or
should be manually changed back. This configuration is done through the
mxone_maintenance tool.
Standby server and cluster configuration can be performed during normal daily service
without traffic disturbance. The main limitation when configuring server redundancy is that all
servers in a cluster MUST be on the same subnet. When failover occurs, the standby server
will take over the identity of the failing server and it will also take control of any media
server(s) that are not on the failing server itself but that are associated to the failing server.
Please keep in mind that this is a "warm standby" solution. Meaning that the Standby server
will take a few minutes before it starts working. This is due to the fact that the standby server
needs to start up the MiVoice MX-ONE processes first before loading the data of the failed
server. Only at this point does normal service resume. The delay can be anything from 3-8
minutes typically, depending on hardware and system size.
The server redundancy solution uses the ARP protocol. It sends gratuitous ARP (GARP)
messages when a server fails. ARP is used to indicate which physical hardware address is
connected to a specific IP address. This information is then stored in an ARP table. With
GARP, the heartbeat program forcibly updates these ARP tables with new hardware (MAC)
addresses when the primary server fails, thereby enabling communication with the backup
server.
In version 7, due to the new multi-master Cassandra database, telephony configuration
changes (such as extension additions, service profile changes etc.) can be now be made
even when the system is running on the standby server. When the changes are backed up,
they are stored in the system and they are copied to the original server when it comes back
online and takes over it’s original role.
Configuring and using server redundancy

Cluster configuration is performed after system installation. It can be executed in a running
system, preferably during a low traffic period.
Every regular server needs an extra IP address in the cluster. This address, which is entered
during cluster configuration, will become the new base address. The old base address will
be used as an alias address. This trick will remove the need for restarts during configuration.
The cluster configuration is performed using the MX-ONE Maintenance Utility. Log-in as user
mxone_admin, and enter the command:
sudo -H /opt/mxone_install/target/bin/mxone_maintenance
and select the option
Cluster

The following actions are available from the mxone_maintenance / Cluster Handling menu:
• List all clusters

• Show status
• Create new cluster in system
• Change fallback type or priority
• Add a lim to existing cluster
• Remove a lim from existing cluster
• Delete cluster in system
• Move lim from standby to regular server
• Lock lim to server
• Unlock lim from server
• Sync exchange data within cluster
Creating a cluster
1. Install a second server as an "Other Server" (as covered in the Core Part 1 I&M
course).
2. On LIM 1 log in using the mxone_admin user credentials.
3. Enter the command sudo -H /opt/mxone_install/target/bin/mxone_maintenance
to start the MiVoice MX-ONE Maintenance Utility.
4. Select the "Server" option to add a new server to the system.
1-9
5. Select the "Add" option and ensure you see the server you just created and then
press "c" to continue.
6. The system will prompt for the mxone_admin password.
7. The system will display a success addition message once done. Select OK.

8. You will be returned to the main menu. Now click "sby_server"
9. Select the "add" option
10. Now the system displays a message reminding you, that if the Service Nodes that
are to be part of the cluster are also running as Cassandra database Nodes then
Cassandra should be added to the standby server as well. This can be done after the
standby server has been added. Select Yes in this case.
11. Choose the server you created in step 1 in order to convert it into a standby server
1-11
12. The following message will appear once the server has been converted into a
standby server
13. Assuming that Cassandra is running on one of the Service Nodes that will be part of
the cluster, you should now add Cassandra to the Standby server. Choose the
Cassandra database option.
14. Choose to add database to server

15. Select the Server to add the Cassandra database instance to
16. Enter the Alias IP address to use for this Cassandra instance.
17. The system will install the database replica on the standby server and complete. Use
the server / list option to confirm that the standby server is now hosting Cassandra.
1-13
18. Returning to the main menu. Select the "cluster" option
19. Choose the "create" option.

20. The system will remind you about the Cassandra installation. Select yes to continue
as we have already installed it.
21. It will now prompt you to select a standby server for the cluster
22. Enter a name for the cluster. This should be a descriptive name, relating the role or
location of the cluster.
23. Select the servers to include in the cluster. This can include from one to ten servers,
provided they are on the same IP subnet.
1-15
24. Define new base address’ for the cluster members.
25. Verify and confirm your settings. (Note: Clicking No here will return you to the main
menu). Also note that any historical backups will be removed. A config_mirror and
safety backup should be taken and archived before creating the cluster.
26. Enter the mxone_admin password to continue
27. You will now receive a confirmation that the cluster has been created

Display the cluster status

to start the MiVoice MX-ONE Maintenance Utility
3. Select the "cluster" option from the main menu
4. Select the "status" option from the sub-menu
1-17
5. Select the cluster for which you want to view the status
6. The status information will display at the bottom of the screen. The first example
shows a system running normally with the standby server alive but not running as a
LIM.
The second example shows a system with the standby server having taken over from
a failed LIM (2 in this case).

Display the cluster configuration

3. Select the "cluster" option from the main menu.
4. Select the "list" option in order to see the config for all clusters in the system
5. The information will be displayed at the bottom of the screen
1-19
Lab 6 - Creating a Cluster
Lab 7 – Displaying the cluster status and configuration


Adding a LIM to a cluster

A LIM can be added to a cluster. An additional IP address has to be entered. This IP
address will be the new base address for the interface. NOTE: the LIM being added
must already exist in this example.
3. Select the "cluster" option on the main menu
4. Select the "add" option from the sub-menu
1-21
5. Select the cluster that you want to add a LIM to
6. A list of available servers will appear, select the one you wish to add
7. Select the new base IP address for this LIM
8. Confirm that you want to add this server to the cluster
9. Provide the mxone_admin password
10. You will receive a confirmation message showing if the add was successful

Execute a manual fallback to a regular server

In the event a server fails and a standby server has taken over, if fallback mode is set
to manual (which is the default), you must manually tell the system to fall back to its
regular server once it's deemed safe to do so.
4. From the next menu, you want to choose the "fallback" option
5. If no LIMs are running on the Standby server the following message is displayed.
1-23
6. If fallback is required, the cluster where a manual fallback is required must be chosen
7. Confirm that the LIM shown is the LIM you want to fallback to
8. You will receive a confirmation message stating that the fallback was succesful

Change fallback type and server priority

3. Select the "cluster" option form the main menu
4. Select the "change" sub-menu option
5. From here, you can select "fallback" or "priority" (The "priority" option is followed at
step 11)
1-25
6. By choosing the "fallback" option, you now get the cluster selection screen
7. Here you can set the fallback type to either "manual" or "automatic". By default it's
set to "manual"
8. We must now confirm the change
9. In order to complete the change, the mxone_admin password is required
10. You will now see the following message. Selecting OK will bring you back to the main
menu
11. If the "priority" option was selected instead in step 5, you will still be prompted to
select the cluster just like in step 6.

12. Enter a new priority for the LIM's displayed. Note that all cluster members have a
priority 0 by default. This means that no failed system is more important than
another. In most case LIM 1 will be given the highest priority (1), followed by LIMs
that manage traditional TDM based media gateways. The standby server will always
attempt to take over from the failed server with the highest priority i.e. 1 first then 2, 3
etc. until 10 then finally 0. If a second server fails in the cluster and it has a higher
priority than the one currently operating on the standby server. The standby will drop
that server in favour of the higher priority one.
13. You will now be asked to confirm the new priority you've configured
14. It will now show you all LIMs in the system in a list sorted by priority. You will need to
confirm that this is correct
15. Enter the mxone_admin password in order to make the change
16. Once the change is completed, you will receive the following message
1-27
Execute a manual ordered synch of data

4. Select the "data_synch" option from the sub-menu. This option is used to force the
updating of information about the Service Nodes in the cluster with the Standby
server. This normally happens during backup processes but may be performed
manually too.
5. You will now receive a confirmation request
6. Once completed, you will receive a confirmation of success message

Lock or unlock a LIM to a specific server

A LIM can be locked to a regular server or to a standby server to prevent failover.
When a LIM is unlocked from a server, failover actions can occur again.
If a LIM locked to the standby is unlocked, the clusters configured fallback type
determines what will happen. With automatic fallback, the LIM will fallback to a
regular server (if it is functional). With manual fallback the user has to manually order
the fallback.
The lock and unlock features work in the same way, we shall only demonstrate a
locking procedure. Please note that the unlocking is the same procedure with the
only difference being that you choose unlock instead of lock in step 4.

4. Select Lock/Unlock depending on the function you want to perform
1-29
5. Select the LIM within the correct cluster that you wish to lock/unlock
6. Select what server the LIM should be locked/unlocked to
7. Confirm lock, this will return you to the main menu

Lab 8 – Displaying the cluster configuration and status
Lab 9 – Testing a Standard MX-ONE Standby Server cluster
Lab 10 - Change the Fallback and Priority of a Cluster
Lab 11 – Performing a manual ordered synch of data
1-31
Removing a LIM from a cluster

A LIM can be removed from a cluster. Note: If the last LIM in the cluster is removed,
the complete cluster will be removed.
4. Select the "remove" option from the sub-menu

5. Select the cluster from which you would like to remove a LIM
6. Select the LIM you wish to remove from the cluster
7. Confirm the removal of the LIM
8. Enter the mxone_admin password in order to continue
9. You will receive a confirmation message
1-33
Removing a cluster
In the previous section covering removing a LIM from a cluster, removing the last LIM
in the cluster also deletes the cluster. However a cluster can also be removed using
the Delete option.
Select the "cluster" option from the main menu
3. Select the "remove" option from the sub-menu

4. Select the cluster you wish to remove
5. Select the last LIM in the cluster
6. Confirm the removal of the cluster
7. Enter the mxone_admin password in order to continue
8. You will receive a confirmation message stating that the cluster has been removed,
but the standby server is still configured and could be used to create a new cluster.
1-35
9. You can verify that the cluster was removed by using the "list" option from the
"cluster" sub-menu as we've done in the "display cluster configuration" section
previously.
10. The following will confirm that the cluster has been removed. This example assumes
that only one cluster existed before in the system

PreLoaded Cluster
In recent versions of MX-ONE, a new feature was added to the Server Redundancy facility.
The preloaded function speeds up the process and allows the standby server to take over
from a failed Service Node much more quickly than with the standard feature.
With standard server redundancy, the service waits to ensure that the live Service Node is
not contactable (either at the IP or service level). Once it has been deemed that the LIM is
non-functional, the standby server must load the Service Node service and associated
Program Units. Once these are loaded the backup copy of the data files for the failed
Service Node are loaded into memory and the standby server successfully takes over the
role of the LIM.
This process takes between 3-8 minutes (normally sub 5 minutes), during which time any
services or features exclusively hosted by that LIM are not available. This includes any
Media Gateways/Servers managed by the LIM and any TDM resources contained within
them.
A Preloaded cluster allows this downtime to be substantially reduced. This is achieved by
having the standby server, pre-load the Service Node services and data. This means that
the time taken for a standby server to replace a LIM is reduced, typically to under a minute
and often to 10’s of seconds.
However, the downside of a preloaded cluster is that each cluster must have only ONE
Service Node and one standby server rather than the standard maximum of 10.
A cluster can be converted to a preloaded one, provided only one Service Node is present
(other Service Nodes must be removed from the cluster before conversion).
Once converted, a preloaded cluster cannot be reverted back to a traditional cluster. It must
be removed by following the procedure mentioned previously and recreated.
Converting a Cluster to a Pre-Loaded one

3. Select the "cluster" option
1-37
4. Create the cluster (if it doesn’t already exist) following the procedure covered above,
adding the standby server and one Service Node / LIM server to the cluster. Using
the List option the current state of the cluster should show that Preload is not
enabled.
5. From the cluster menu, select the Preloaded option.
6. Choose the cluster to convert to preloaded.
7. Confirm the conversion and the change to the backups

8. Enter the mxone_admin password
9. The system confirms the change to the cluster. When List is used the preload option
is shown as enabled.
1-39
Lab 11 – Performing a manual ordered synch of data
Lab 12 – Locking and Unlocking a LIM
Lab 13 - Removing a LIM from a Cluster
Lab 14 - Removing a Cluster
Lab 15 - Creating a new PreLoaded Cluster

Installing Provisioning / Service Node Manager

Redundancy
In version 7, when a standby server takes over an MX-ONE LIM, in addition to taking over
the running of the main Service Node daemons (services), it can also now take over the
services providing the web-based tools, (Provisioning Manager and Service Node Manager)
if they are loaded on the server that has failed.
Additionally, the Media Server service running on the failed server, can also be taken over
by the standby server. As already seen, a Cassandra database instance can also be
installed on the standby server if required. Note that in the latter case, the Cassandra service
is running full time on the standby server and is used as any other DB instance would be.
To enable PM/SNM redundancy the procedure listed below must be followed after a pre-
loaded cluster has been created:
NOTE: If SNM and PM are installed on separate servers (as is generally recommended)
then TWO 1+1 clusters are needed and the process below must be carried out twice. Once
for Server 1 and SNM and once for the PM server.
Configuration of the Master Server

The first stage of the process is to configure the master server where Service Node Manager
(and potentially Provisioning Manager ) are installed
1. Ensure Server redundancy with a preloaded cluster is configured before the PM/SNM
redundancy set up process is started.
2. Login into the Master server and execute the command webserver_config (this can
also be launched from mxone_maintenance.
3. Select Redundancy from the Configure web server list (this option is available only if
Lim1 is a cluster member).
4. A warning message will be displayed stating that the web service tools will be
unavailable whilst redundancy is being setup. Select Yes
1-41
5. Once yes is selected, the system will search for the Master and Standby server
details from the cluster. Assuming these details are found, the system will prompt for
the new password for the mxone_manager account that will be used for webserver
redundancy.
6. Set the password for the mxone_manager user in the Master server. It is
recommended to use complex passwords (the system will complain if a poor
password is used, but will accept it. The it will attempt to set the mxone_manager
password on the Standby server. The system will typically prompt you for the
Standby server root user password for the sudo process that will be run.
7. After the system uses sudo to connect to the standby server, it will prompt for the
mxone_manager password for this server. This should be set the same as on the
Master server. Confirm the password and the process continues.
8. The screenshot above shows the step 7 process, note that 192.168.1.108 is IP of the
standby server in this case. Once password for mxone_manager is set in both
Master and Standby server, silent login between master and standby servers is
configured.
9. Press Enter key when it asks for a passphrase (shown as the last step on the
screenshot above).
10. The system will then setup SSH communication between the two servers. When
prompted enter the password for the mxone_manager user created on the standby
Standby server, the system them completes the silent login to the Standby from the
Master server.
11. The System checks if the SNM software is already installed on the standby server. If
it is not installed, a pop-up box is displayed to allow you to select and install the same
SNM version as on the Master server.
12. Enter 0 in the bandwidth box unless running on a live system with limited spare
network capacity.
13. Confirm the installation process.
1-43
14. After a few more confirmation messages, SNM will be installed on the Standby
server. Choose to restart the web services when prompted.
15. In the case where PM and SNM both co-exist on the same Master server, ensure
that PM is also installed on the Standby server at this stage as well.
16. Enter Virtual IP (common IP, which re-routes itself to corresponding active server at
any point of time). This should be a new, unused IP address on same subnet.
17. Enter a new username and password for creating a replication role for postgres. This
username can be called anything so long as it doesn’t conflict with any other users
on the Linux system. In this case we use the name webrepl. Ensure that the same
username and password for the replication role is provided when setting up Standby
server.
As always usernames and passwords are case sensitive. Note that the password is
only prompted for once, so ensure it is typed correctly.
18. Now proceed to the Standby server to complete the web redundancy process.

Configuration of the Standby Server

Once the configuration process has been carried out on the Master server, follow the steps
below for setting up Standby server and completing the process.
1. Execute webserver_config and select Redundancy as before. The system
automatically fetches master and standby details.
2. To setup silent login of Standby to Master server, press Enter key to leave the
passphrase blank. Then enter yes to complete the SSH connection.
3. Enter the mxone_manager password to continue.

4. Now enter the Virtual IP and Replication role details that were selected whilst
configuring the Master server.
1-45
5. Assuming the correct details and credentials are entered, the system will start to
replicate the Postgresql database. Once finished, choose Yes to restart the
webserver.
6. Once the installation has finished, go to a web browser and try to access the web
services.
Type the URL: http://<Virtual_IP>/mp or http://<Virtual_IP>/wbm to access the
current active server type (assuming here that web security has not been
implemented at this point, otherwise use https:).

Web Redundancy Utilities

7. To access other utilities related to redundancy after redundancy is set, use
mxone_maintenance and choose the webserver option or execute the command
webserver_config and then select Redundancy, the following screen is then
displayed.
The menu options shown above are described below:

a) CheckStatus
Shows the status of redundancy. This shows the current status of the servers in the
exchange with regard to webserver redundancy, as shown below:
b) Reconfigure
This option can be used for the reconfiguring of redundancy. It can be used if it is
necessary to re-configure the set-up. This is a two stage process. Ensure that the
option is executed on the Master server first, and then followed by the Standby
server. The prompts will ask for similar information to when redundancy was initially
configured.
1-47
c) Fallback
If the fallback type of the main cluster is set to the default value (Manual), then once
the master server comes up and is ready, the Service Node function is manually
configured to fallback via mxone_maintenance and falls back to the Master.
However, the webservices will still be running on the standby server.
It is then necessary to login to master server, select this option and choose that the
PM/SNM services also fall back to the master server.
d) Reconfigure Fallback
If the fallback type for the main cluster is changed, the same must be done for
webservice redundancy.
Selecting this option replicates the current state of the main cluster onto the
webservice redundancy feature. Note the message below does not remain on the
screen.
e) Remove Redundancy
To remove the webserver redundancy feature, this option is used. Again, the process
is a two step procedure. First it is removed on the Master server and then followed by
the Standby server.

Lab 16 - Configuring Web Service Redundancy
1-49
VMWare High Availability and Fault Tolerance
VMWare vSphere High Availability allows a cold standby solution, which means that in the
event that a physical server where the Telephony server guest machine is running goes
down, a short downtime will occur, due to the fact that the Telephony server guest machine
needs to be started on another physical server. The traffic impact during this process is
about the same as in a native server cluster, meaning there is a short time where no traffic
can be established, terminals will need to register again and media gateways controlled by
this server will restart.
The difference between VM High Availability and native standby server cluster is that after a
failover, using VMWare HA, the original server is now running on another physical server
which doesn't impact the telephony system at all. This means that once HA has started the
new server, there are no limitations. Data changes, data backups, maintenance, etc. are all
working since the new HA server is identical to the old server and isn't considered a backup
server.
VMWare VSphere Fault Tolerance enables a transparent failover solution. This means that
in the event that a physical server where a Telephony server guest machine is running goes
down, no calls will be dropped during the failover process and continuity will be maintained.
And of course, the higher the availability is, the more sophisticated the VMWare
infrastructure needs to be. This implies multiple network interfaces on physical VMWare
servers and multiple separate LAN's for different VM functionality.
You can read more about VM Redundancy in the CPI documentation
(ASE/MXO/GEN/0040/ED /04/ 2015-05-22)
You can read more about Redundancy in 4/1531-ANF 901 43 Chapter 7.
Note: In general, VMWare redundancy is not normally mixed with the MiVoice
MX-ONE's native redundancy as the HA & FT features of VMware replace the
need to use Server and Network redundancy.
Also, network redundancy isn’t normally used 1 when this server is a
virtualized (VMWare) server. In this case, VMWare should be handling the
Network interface redundancy.

MiVoice MX-ONE Migration
2
and Advanced Backup
Objectives
 Understand how to migrate from a previous MX-ONE system

 Using the PC-REGEN tool for advanced backups
 Know how to perform upgrades to SLES
 Understand how to upgrade the MX-ONE Service Node & web-
services
 Understand how to upgrade firmware on devices and hardware.

MiVoice MX-ONE Migration and Advanced Backup
UPGRADE TO MIVOICE MX-ONE 7.X
As the Version 7 system uses a new OS and core database, it is not possible to perform an
in-place upgrade on an existing MX-ONE 6 or earlier system.
There are two alternative ways to regenerate the system telephony data when upgrading,
one uses the Regeneration script utility, by copying the data from the old OpenLDAP
database, converting it to CQL format, and entering it in the Cassandra database, and the
other uses the legacy PC-Regeneration function.
The first option requires that the new system is unchanged from the old i.e. the server (LIM)
and media gateway configuration uses the same settings.
The second must be used if the server (LIM) or media gateway settings (IP, DNS,
hostnames etc) must be changed during the upgrade.
2-3
UPGRADE USING REGENERATION SCRIPT UTILITY
The following steps must be followed for the upgrade procedure:
1. Collect Telephony data (with config.mirror).

2. Install MX-ONE 7.x including its system database(s)
3. Import saved Telephony Data (with the regeneration script utility)
COLLECTION REGENERATION OF DATA, VIA REGENERATION

SCRIPT UTILITY
To save the telephony configuration data from the old MX-ONE Service Node, and to restore
the same data in the new MX-ONE Service Node, this upgrade procedure uses the
regeneration script regen.sh for MX-ONE.
Perform the following steps to back up the data from the old MX-ONE
• Perform a data backup (with command data_backup).

• Collect the old source data, i.e. enter the config_mirror command or take the
config.mirror files if the mirror is already OK.
• Save the config.mirror file containing all server data in a place outside the MX-ONE
system. The mirror is found in the directory /mxone/mirror/version/dateandtime/. Copy
the entire content of that directory (for all servers).
INSTALL THE MIVOICE MX-ONE 7.X

Perform a normal installation of MX-ONE v7 using the same names, ip addresses and
domain names as the original system.
IMPORT SAVED TELEPHONY DATA, VIA THE REGENERATION

SCRIPT UTILITY
After upgrading the new MX-ONE, the following steps need to be performed for successful
regeneration of the telephony data from the old MX-ONE system into the new MX-ONE
system.

RESTORING SAVED DATA INTO THE MIVOICE MX-ONE 7.X

To restore the telephony data into the new MX-ONE system, the created config.mirror files
first have to be transferred.
• Login to the server as mxone_admin.

• Transfer the mirror to the freshly installed MX-ONE system (either to a Service Node
Server if the system database is co-located, or to a separate database server). This can
be done via USB or a network copy, to the Master Server, by placing the mirror in a new
directory i.e. /tmp/upgrademirror/
• Run sudo -H (to be root) and then run the command
/opt/mxone_install/target/utilities/regen.sh regen_ldap_and_lim_data
pathToMirror
(pathToMirror points to the backup location e.g. /tmp/upgrademirror).

• The regeneration script utility will show the data restoration progress. Check the printout
and logs for errors.
• Now reload the system. Use the reload --system command. The reload data is now in
the program units.
• Test the configuration and ensure the system is stable and operating correctly.
• Run the command license_normalize to update the license configuration according to
the new license structure in MX-ONE 7.0.
• Perform a data backup of the system using the command data_backup
• Do a new config_mirror.
• The data is now in the Cassandra database and the system has been upgraded
2-5
MIGRATING PROVISIONING MANAGER AND SERVICE

NODE MANAGER
To migrate Provisioning Manager and Service Node Manager, the database backups are
required.
The procedure below describes the steps required to backup SNM and PM, however a script
has been written (pm_snm_6.x_backup ) which will perform these tasks in the correct order
for existing version 6.x systems. The script is shown at the end of the section.
BACKUP SERVICE NODE MANAGER (MANAGER TELEPHONY

SERVER IN MX-ONE 5.0/6.0)
To backup Service Node Manager database in the MX-ONE 5.0 SP7, execute the following:
1. Make sure that you are logged in as root.
2. Create a folder named as an example: /home/eri_sn_admin/TSBackup/
3. Change the permission to allow postgres to write in the folder, such as chmod 757
/home/eri_sn_admin/TSBackup.
4. Save all data of WBM database.
a. Use the command:
b. su postgres -c "pg_dump -a -d WBM -f
/home/eri_sn_admin/TSBackup/wbm_data_only.sql"
c. It may be necessary to enter the password for the database, which by default is
default in MX-ONE 5.0
5. Save all data of QoS Database and use the command:
su postgres -c "pg_dump -U postgres QoS -f

/home/eri_sn_admin/TSBackup/QoS_entire_data.sql -C --inserts"
8. Enter the password for the database, which is default in MX-ONE 5.0
9. Copy the created files to an external media, for example a USB memory, or another
safe location.
TEMPLATE DATA BACKUP

1. Ensure that you are logged in as root on the Manager Telephony System Server.
2. Use the below command for to archive the templates.
“tar -cf customer.tar --directory=/opt/jboss/server/default/conf/templates customer”

3. Copy the customer.tar file to an external media; for example, USB memory.

BACKUP PROVISIONING MANAGER (MANAGER PROVISIONING IN

MX-ONE 5.0/6.0)
If Provisioning Manager and Service Node Manager are installed on the same server or on
different servers, the data for Provisioning Manager must be saved. Because, upgrading
Service Node Manager clears the database that is used by Provisioning Manager.
In case of standalone system taking backup from mp_config and backing up of template will
suffice.
To backup Provisioning Manager database in the MX-ONE 5.0 SP7, execute the following:
1. Logon on Manager Provisioning server as root.
2. Create a Folder /home/eri_sn_admin/TSBackup/ if it does not exist. Such as, mkdir -p
/home/eri_sn_admin/TSBackup/
3. Enter the command mp_config and select database backup.
4. Backup MP database is stored in directory /var/opt/eri_mp_config/ with a file name

starting with “mpManagerPostgresDump” followed by date, rpm version and release
details.
2-7
5. Save all data of Quartz Database using the following command:
su postgres -c "pg_dump -a -d Quartz -f

/home/eri_sn_admin/TSBackup/Quartz_data_only.sql"
6. Enter the password for the database, which is default in MX-ONE 5.0 and contact
admin for password in case of 6.0.
7. Copy the created files (or the entire directory) to an external media, for example a USB
memory, or another safe location.
MANAGER PROVISIONING TEMPLATE DATA BACKUP

1. Ensure that you are logged in as root on the Manager Provisioning Server. This is
useful when the Manager Provisioning is in different server (standalone).
2. Use the following command to backup the templates.
tar -cf customer_mp.tar --directory=/opt/jboss/server/default/conf/templates customer
3. Copy the customer_mp.tar file to an external media, for example an USB memory
For 6.x execute the 6.3_backup script, below is the path
sh 6.3_backup , after executing the files will be present in /local/home/TSBackup
RESTORE SERVICE NODE MANAGER

Note: Before executing this step, first restore MX-ONE data
To restore Service Node Manager, do the following:
1. Create a folder named TSBackup in /local/home/mxone_admin
2. Go to the new Service Node Manager installed in the Service Node 1.
3. Copy the Manager Telephony System’s data files (wbm_data_only.sql,
QoS_entire_data.sql, customer.tar) to /local/home/mxone_admin /TSBackup
Directory.
4. Change the permissions on these files using mc or chmod to 755.
Execute the webserver_config script then select other utilities and then select option
“Migrating Old version SNM Data(SNM DB, QoS DB, customer templates) to Current
Version” follow the instructions. This script restores WBM, QoS and customer.tar (customer
templates) to the system.
RESTORE PROVISIONING MANAGER

Note: Restore Service Node Manager before restoring Provisioning Manager in case of Co-
existence system
To restore the backup in Provisioning Manager, execute the following:
1. Copy the Manager Provisioning data files (mpManagerPostgresDumpxxxxxx,
Quartz_data_only.sql, customer_mp.ear) files to /var/opt/mxone_pm_config/ Directory.
2. Make sure that the files are owned by “root” user.
3. Execute mp_config and select “Database restore”. The script takes care of restoring
PM, Quartz databases and Customer_mp.tar (Customer template) data.

4. Remove the Quartz_data_only.sql and customer_mp.tar from

/var/opt/mxone_pm_config directory after data restore.
5. Execute cd /var/opt/mxone_pm_config rm -f Quartz_data_only.sql customer_mp.tar.
2-9
pm_snm_6.x_backup script
#!/bin/sh
backupDir="/local/home/TSBackup/"
function createBackupFolder()
{
if [ -d /local/home/TSBackup ];then
echo " Directory already exists hence clearing the directory";
rm -r /local/home/TSBackup/
mkdir -p /local/home/TSBackup/
chmod 777 /local/home/TSBackup/
else
echo "creating backup directory"
mkdir -p /local/home/TSBackup/
#chown postgres:postgres /local/home/TSBackup/
chmod 777 /local/home/TSBackup/
fi
}
exportpgpass()
{
local jbosshome=/opt/jboss
if [ -f $jbosshome/bin/pgpw -a -f
$jbosshome/bin/DBEncryptedKey.txt -a -f $jbosshome/bin/DBEncryptedPGPW ]
; then
cp $jbosshome/bin/pgpw $jbosshome/bin/pgpw_back
echo `openssl rsautl -inkey
$jbosshome/bin/DBEncryptedKey.txt -decrypt
<$jbosshome/bin/DBEncryptedPGPW` > $jbosshome/bin/pgpw
pgpw_file=$jbosshome/bin/pgpw
pgpwd=`cat $pgpw_file`
cp $jbosshome/bin/pgpw_back $jbosshome/bin/pgpw
else
pgpwd="default"
fi
# timelog "PASSWORD : $pgpwd" common_log $thisFile $LINENO
export PGPASSWORD=$pgpwd
}
backupSnm(){
cd $backupDir
echo "Backing up Service Node Manager";
exportpgpass
su postgres -c "pg_dump -a -d WBM -f wbm_data_only.sql"
#`su postgres -c "pg_dump -a -d WBM -f $backupdir/wbm_data_only.sql"`
su postgres -c "pg_dump -U postgres QoS -f QoS_entire_data.sql -C --
inserts"
#`su postgres -c "pg_dump -U postgres QoS -f
$backupdir/QoS_entire_data.sql -C --inserts"`
unset PGPASSWORD
`tar -cf customer.tar --
directory=/opt/jboss/server/default/conf/templates customer `
}

backupPM()
{
cd $backupDir
echo "Backing up Provisioning Manager";
exportpgpass
#`/sbin/mp_config backup_database`
execScript="$(/sbin/mp_config backup_database)";
filename="$(ls -trh /var/opt/eri_mp_config/ | tail -1)";
#echo "file name is $filename";
`cp /var/opt/eri_mp_config/$filename .`
`su postgres -c "pg_dump -a -d Quartz -f Quartz_data_only.sql"`
unset PGPASSWORD
`tar -cf customer_mp.tar --
directory=/opt/jboss/server/default/conf/templates customer `
}
#main
createBackupFolder
if [ -d /opt/mts_install ];then
echo " SNM is installed";
backupSnm
fi
if [ -d /opt/mp_install ];then
echo " PM is installed";
backupPM
fi
2-11
Using PC-REGEN to Backup/Archive an MX-ONE System
The PC-Regen utility has been a part of the MX-ONE engineer’s toolkit since the first version
of the product. The tool is used as an addition to the normal backup and safety backup
processes mentioned in the MX-ONE I&M Part 1 course.
Whilst the normal backup mechanisms are a crucial part of maintaining an MX-ONE system,
they have one disadvantage, which is that fact that they store a copy of the much of the data
in a non-textual format. This means that if, for whatever reason, the information is corrupted
then the restore of the backup is likely to fail. Also, if an MX-ONE system needs to be
completely rebuilt, every aspect of the new system must be identical in-order to be able to
use the safety backup from the older system.
The PC-Regen utility is different in that it captures the programming on a system by
effectively running every relevant command to print out the current configuration. These
printouts are saved as text files. These files can then be downloaded onto a PC and the
utility reads them and converts the data into the processes/commands that would have been
used to create them in the first place.
These “Regen” scripts can then be executed on a newly built system. The other advantage
of PC-Regen is that the generated scripts can be edited before being executed. This allows
“find and replace” style operations to be performed allowing the possibility to change the
configuration to meet the requirements of the new system.
PC-Regen also offers the ability to scan an older system and generate the regeneration
scripts at a newer release of MX-ONE.
The PC-Regen tool has been changed in recent years and now consists of two distinct parts,
PC-Regen Starter and PC-Regen Compact. We will look at these components over the
coming pages.

Installing and Initializing PC-Regen
The PC-Regen tool that is downloaded from the Mitel Connect KMS consists of two
executables once installed:
• PC-Regen-compact.exe
This is a text menu based, shell program that is run from the Windows command prompt
and performs the main tasks such as regeneration, syntax check, and generation of
batch files.
• PC-Regen-starter.exe
This is the GUI front end that can be used to capture input and calls the PC-Regen-
compact executable above.
Installing the PC-Regen Utility

First download the file PC-Regen-compact-setup.zip file. This is normally downloaded from
the Mitel Connect website via the Knowledge Management System. Unzipping the file
produces the file PC-Regen-compact-setup.msi, run it, and follow the instructions. In most
case the default settings can be used. The whole package including PC-Regen-compact and
PC-Regen-starter is installed.
2-13
Using PC-Regen
Once installed you have a choice of which tool to use:
• The PC-Regen Starter tool has a simple GUI front end that is used to generate the
scripts for data capture and to convert the captured data into the scripts to rebuild a
system.
• The PC-Regen Compact tool is run from the Windows command prompt and prompts
the user for information via text-based menus with numbered options. This tool is
actually used behind the GUI Starter tool, so the end result is exactly the same.

The basic procedure for the regeneration process is:

1. Use one of the tools to create a batch file to use for MX-ONE data extraction.
2. Upload the batch file onto the MX-ONE using a tool like WinSCP or using a USB drive.
3. Execute the batch file on the MX-ONE to run the print capture commands.
4. Download the PC-Regen created capture files back down onto the Windows PC
5. Use either of the tools to Regenerate the data and create the regeneration batch files.
6. Upload and use the regenerated batch files on the target system to recreate the
configuration.
Creating the Initial Capture Batch File

Here we look at the process used to create the initial capture batch file that will be loaded
onto the MX-ONE. On the course we use the GUI Starter version of the tool (but the
compact version could equally be used.
1. Launch the tool and click on the Target drop down list. Choose the MX-ONE version of
the system that the regenerated data will be installed on.
2. Click on the Source drop down list. Choose the MX-ONE version of the current system.
2-15
3. Now we choose where the PC-Regen files will be stored. To specify the path, do the
following:
o Click the Regen path button.
o In the popup windows navigate to the parent folder to be used.
o NOTE:. Below the folder specified, there must be a …/source and a
…/target directory. These folders must be manually created.
The data extracted from MX-ONE and downloaded onto the PC is placed
under the …/source directory. Whilst the regenerated data is stored in
the …/target folder.

4. The Add to Batch option allows for the customization of the of data capture script. A text
file must be created, containing the additional commands that are to be run. This file can
then be specified in this section.
2-17
5. The script file, describes the version specific file that will be used as the basis for the
commands generated by the tool. This is just for information.
The buttons underneath are the main activity options. Strangely they are not displayed in
the order that they are normally used in.
The Syntax check button can be used to ensure the options chosen will generate a
successful batch file. This option is normally only used when additional commands have
been added via the Add to batch option.
The Generate batch file is used to actually produce the text based script files that will be
uploaded and executed on the MX-ONE.
The Run Regenerator is used as the final step of the process to create the scripts from
the captured MX-ONE data.
The Clear log button empties the error.log file which is added to everytime an operation
occurs. The source version can be used before the Run Regenerator to check the
version of the source MX-ONE system from the captured data.
6. After using the Syntax check and Generate batch file buttons a window opens showing
the error.log file. Confirm that the generation has completed successfully.
7. The Generate batch files button generates the print data data_gen.batch. This step also
generates the gjtsp.batch, and the pu_add_info.batch, racep2.batch and
scexp2.batch files. These files are used by the PC-Regen script at data collection time.
These files must now be uploaded to the MX-ONE. A tool such as WinSCP is normally

recommended. The files mentioned above can be zipped up into a single file for ease of
management or copied individually.
It is normally recommended to create a new folder underneath /tmp on the MX-ONE to

store the files. (The examples below assume a folder called pcregenData was created).
Once the files have been uploaded (and unzipped if necessary) the script can be
executed.
Note: It is vital that the MX-ONE system is not actively being used or
programmed when the Regen script is run otherwise the data captured may
be inaccurate. The script could be scheduled to run in the middle of the night
for example to ensure this.
8. Use the Putty utility (or the MX-ONE console) to login and access the Linux command
line.
On the MX-ONE source system, go to the correct directory using the command
cd /tmp/pcregenData
and run the following command:

source ./data_gen.batch | tee logFile.txt
This will execute the script, running commands and collect the print data in this directory.
9. Once the script has finished running (which may take several minutes depending on the
system size), the contents of the folder needs to be downloaded back onto the Windows
PC running PC-Regen. Again the files could be zipped up before transferring but if using
WinSCP this is not necessary.
Ensure the files are copied into the source folder underneath where the capture scripts
were created.
10. Now the Regenerator process can now be run. This reads the contents of the source
folder analyses the individual text printouts and generates the output script files in the
target folder.
11. The contents of the target folder on the windows PC are now ready for use. In many
cases the PC-Regen tool is used as another form of backup and therefore 99% of the
time the scripts in the target folder are not actually used except when a system needs to
be rebuilt .
However, as mentioned previously, the advantage of PC-Regen is that the script files
2-19
(being text) can be reviewed and edited if necessary before being uploaded to the
destination MX-ONE system and executed. A batch file called REGENCMD.TXT can be
used to run all the individual scripts in the correct order.
This ability to edit the scripts (for things like IP addresses for example) can be useful
when migrating from an earlier version of MX-ONE to version 7.

Lab 1 - Installing and Using PC-REGEN
2-21
Service Node Manager Upgrade
New updates and Service Packs/Hotfixes are released regularly for the MX-ONE v7 system.
These add new features, support for new hardware and provide bug fixes.
Each new version comes with documentation including release notes. Release notes should
be reviewed to see which new features or requirements could have been added to the
product. The release notes can be found on Mitel Connect.
IMPORTANT REL 7 INFORMATION:
• As mentioned earlier in the chapter, there is no method for performing an in-place

upgrade from v6 (or earlier) to v7 due to the differing SLES OS and the new Cassandra
database. Therefore, upgrading only applies to future point, service pack or hotfix
releases. Each of these will specify any pre-requisite procedures or restrictions.
A certain Software level of Service Node is always released with a certain OS release and
Service pack.
When updating the MX-ONE, the SLES12/Linux operating system will remain the same, but
a new Service Pack or OS hotfixes may be required
Note: Rollback from MiVoice MX-ONE 7 to an earlier version is not possible.
To recover the old system a safety backup or PC-Regen backup from the
previous version of the MiVoice MX-ONE system and SLES is required.
These must then be restored onto a system build with the older versions of
the software.

OS Upgrade
As stated previously, MiVoice MX-ONE version 7 uses SLES 12 SP3. Periodically the
Operating System will require service pack or hot fix updates to maintain the efficiency and
security of the system. The OS needs to be upgraded separately on each server and the OS
upgrade may disturb MX-ONE operation as a restart of system services or even a full restart
may be required.
It is important to note that you may be advised that special requirements exist for specific OS
upgrades which overrule the standard OS upgrade routine.
The SLES SP upgrade method depends on what MX-ONE version you currently running.
Normally, the OS is upgraded prior to the upgrade of the MX-ONE. However, with some
previous releases the MX-ONE is upgraded prior to the OS, so always check the release
notes.
MiVoice MX-ONE Maintenance Utility

In MiVoice MX-ONE rel 7 there is a Linux Software menu item in mxone_maintenance (as
shown).
This new menu item will facilitate with the upgrade of SLES OS on the MX-ONE. The
advantage of this tool is that the OS upgrade is initiated on Server 1 but can update all
servers in the system remotely. (This makes uses the Linux Zypper utility to distribute the
SLES Linux package to other servers).
2-23
SLES Upgrade Preparation

To execute any SLES Upgrades, you must first copy the relevant SLES .iso or tar file (e.g.
SLES12SP3_updates_20180827.tar) and its checksum file (e.g.
SLES12SP3_updates_20180827.tar.md5.txt) to the MX-ONE.
• One simple method is to use WinSCP to copy BOTH files to the MiVoice MX-ONE.
Since you are using WinSCP the default user account used by WinSCP will be
mxone_admin therefore the local directory on the MX-ONE will be
/local/home/mxone_admin
Create a tmp folder under /local/home/mxone_admin and copy the files to this
location
Make sure that the transfer settings for uploading files are set to Binary on
WinSCP

SLES Upgrade on a System running MiVoice MX-ONE 7.0

This is potentially part of the upgrading process for MiVoice MX-ONE 7.0. If the release
notes for a version 7 update require an OS upgrade too follow this procedure:
The steps are as follows:
12. Open the MX-ONE Maintenance Utility using the normal sudo -H command
syntax. and scroll down to the Linux_software option
1. First, remove any existing SLES software repositories (zypper repositories)
When asked if you want to remove all zipper repositories, select Yes.
2-25
2. Select Add to add a repository for all servers in the system.
The SLES .iso/.tar image file will be added as a source. Select Yes to confirm.
3. Navigate to the directory with the .iso or .tar file in it (using the tab keys to move
between the sections and the spacebar to select the folder and file) and make sure
the entire path is displayed before selecting OK.
The Checksum file must be available in the same directory as the .iso/.tar file to
be successful.
The last step will be the unpacking of the file and copying of the files to the other
servers, before returning the user to the top level mxone_maintenance menu.
3. Select Update to the latest Service Pack or Patches.

Confirm that you want to continue (This update should be done after hours or at
low traffic periods). Select Yes to continue.
4. Confirm either Service Pack (or Patch Package) depending on the type of update.
the .iso files tend to be Service Packs, whilst .tar are typically Patch packages. The
system will normally choose for you based on the repository installed. Select OK to
proceed.
Select the repository to use during the upgrade and OK to proceed.
The system may prompt that the Service Node and Provisioning Manager may
need to be shutdown during the upgrade, select Yes.
The system will proceed with the upgrade and will indicate to the user when the
update is completed on the display.
4. After the successful update, REBOOT all servers using mxone_maintenance.
2-27
Lab 2 - Performing a SLES OS Upgrade

Service Node (Telephony System) Upgrade

All upgrades to the Service Nodes in the exchange are controlled by Server/LIM 1
On Lim 1 execute the following:
1. Backups should be performed before and after the system upgrade!
2. Prior to upgrading you should always check:
• If your system is not current, check the release notes to see if you need to apply any
Service Packs or Licensing changes first.
• How many servers exist in the MX-ONE system that will require upgrading?
Using SSH login (i.e. using PuTTY), use the command mxone_data –p
• You should always check that you have at least 8 Gbyte available on the root
(/dev/mapper/system-root lv) and var (/dev/mapper/system-var lv) partitions.
• Check all servers. In this example there are two servers.
Using SSH login (i.e. using PuTTY), use the command df -h
3. Download the new software version of MX-ONE from Mitel Connect.

4. Upload the relevant software load to the MX-ONE using WinSCP
• When you log in as mxone_admin, your local directory will be
/local/home/mxone_admin.
• Using WinSCP or using SSH, create a directory such as /mxtmp under
/local/home/mxone_admin.
• Copy the software load (bin file) to the newly created “mxtmp” folder.
2-29
5. To start the maintenance utility, enter command

sudo -H /opt/mxone_install/target/bin/mxone_maintenance
6. Once you have logged into the MX-ONE Maintenance tool, select the Package Handling

7. Select Add to Add new package to system and OK to proceed.
8. Navigate to the package you want to install

• Make sure the complete path including the file name are provided in the field
provided (refer to red arrow).
• If the file name is correct in the upper right box, you may use the space bar to enter
the complete file name in.
• Select OK to proceed
2-31
9. Confirm by selecting Yes to add the selected package. This will unpack the upgrade
files.
10. Select the package distribution task and select OK to proceed.

11. Select a package to distribute from the list and select OK to proceed.
12. Confirm that the selection is correct (in this example 1 is entered to confirm
7.0.sp0.hf1.rc3 (7.0.0.1.3))
13. Confirm the selection by entering “y” as shown below
14. After checking disk space, the system will then prompt about the bandwidth utilization.
Unless there are known network issues, choose 0
2-33
15. Select OK to continue with the upgrade process. The system will indicate that the
package distribution was successful
16. Select Prepare for upgrade and the OK button
17. Select the package to which the Service Node will be upgraded, select the OK button.

18. The system will confirm once more that the upgrade should proceed. Click yes.
19. The system will be prepared, and a backup will be performed. The files will then be
unpacked to the new folders on each server in the system
20. The Maintenance tool will indicate that the preparation for upgrade is done (with correct
version listed) and will restart the mxone_maintenance once the OK button has been
selected.
21. Once the maintenance tool has been restarted select Upgrade MX-ONE version and
select the OK button to start the actual upgrade
2-35
22. Select Upgrade select from list from tools menu and the OK button
23. Select the correct package using the spacebar, then OK button to proceed.

24. Confirm your settings by choosing “yes” as shown
25. The system will then start to initiate the new version and switch the services to use that
version..
26. The system will respond with displays indicating first the upgrade is proceeding and then
a display confirming the upgrade is complete.
2-37
Verifying the Upgrade

You can verify the upgrade results by logging back into the Maintenance tool and selecting
Package Handling in the system and the OK button.
Select the list existing packages task and select the OK button.
The older and current versions of the MX-ONE software will be presented on the display.
Select the OK button when completed.

Check the release notes but usually if you are upgrading to a Service Pack, you will not need
to restore data back into the MX-ONE system. Upgrading to another major release may
require a restore of the data.
Most versions allow the system to be rolled back to the previous version in the event of
issues or problems with the new version.
Note: It is a good practice to let the system run for a while to ensure that
everything works ok. After that it is strongly recommended to remove old
versions. Otherwise the file system mounts may become full, especially if
several updates are made to the system. If disk partitions fill up, errors and
malfunctions may occur. Issues usually start with an alarm saying that
filesystem is almost full
(Not enough free space on disk partition, FAULTCODE 1:39)
2-39
Lab 3 - Performing a Service Node Upgrade

Provisioning Manager Upgrade Preparation

The process of upgrading the MX-ONE Service Node also copies the latest version of the
Provisioning Manager installation/upgrade files to the server’s hard drive. However, whilst
the web based Service Node Manager tool is updated during the process, the running
Provisioning Manager system is not. The Provisioning Manager system must be upgraded
as a separate task.
When you run the installation file, it will automatically detect if there is an earlier version of
Provisioning Manager installed and perform an upgrade.
If the installation file is the same as the installed version, the installation/upgrade will stop.
Before starting the upgrade:
1. Go to the Scheduling task in Provisioning Manager and print all scheduled events. The
scheduled events will not be kept during upgrade since the stored commands may not
work any longer in the upgraded version
2. Before performing an upgrade create a backup of current database from a linux shell or
via the web interface
If using the linux shell, type command “mp_config” and choose “Database backup”.
Press the <enter> key
When finished (either via linux shell or web interface), copy the latest file from
directory /var/opt/eri_mp_config to a safe storage. The dump files are named:
“mpManagerPostgresDump.<date+time>-<rpm-version>”
This measure is only as a precaution in case something fails during the upgrade. In
normal circumstances the data will automatically be restored
3. Log out from the Provisioning Manager Graphical User Interface before performing an
upgrade
Run the installation file as described in the chapter Installation and follow the on-
screen instructions.
2-41
Provisioning Manager Upgrade

After the Service Node is upgraded it is now important to upgrade the Provisioning Manager.
Even if PM is installed on the same server as SNM it is not upgraded automatically. This is
covered under the Addon_Software.
1. From SSH enter sudo –H mxone_maintenance to get to the MXONE-Maintenance
display.
2. Scroll down until you are at Addon_Software.
3. Check the current Software versions loaded

To verify that the software required is already loaded, select List Available Addon
Software.

4. The following display will indicate the addon software that is available for installing or
upgrading:
Press any key to return to the previous display

4. Check for Installed Software
To check what software is already loaded, select Check Installed.
2-43
5. The Provisioning Manager should be at an older version after the upgrade of the
Service Node software. The Service Node Manager software is upgraded during
the Service Node update..
• Press any key to return to the previous page.
6. To start the Upgrade of the Provisioning Manager select Install_Upgrade

7. Select Provisioning Manager with the updated version. The PM installation files
are upgraded on disk, when the SN is updated. However, unlike SNM, PM is not
automatically upgraded.
8. Select the target server.
9. The standard bandwidth usage message appears. Choose 0 if no network restrictions

are in place.
2-45
10. A warning will be provided that the upgrade will occur on the targeted server. Choose
Yes to continue.
11. Accept the license by select the Accept License button.
12. Confirm you want to perform the Upgrade by selecting Yes.

13. The Provisioning Manager must be restarted after an upgrade. Select Yes.
2-47
Lab 4 - Performing a Provisioning Manager Upgrade

Call Information Logging
3
Objectives
 Describe the different commands that can be used to configure call

logging
 Describe the different output methods that can be used.
 Describe the different output formats that can be used (predefined and
user configurable/flexible formats)
 Describe how data can be stored (locally or in a central location)

Reference Material
Detailed material for this section may be located in the following documents:
• Feature Description 7/1551-ANF 901 14

• Interworking Description 3/155 19-ANF 901 14
• Operational Directions 20/154 31-ANF 901 14
• Unix commands 201/190 82-ANF 901 14
3-3
Overview
The Call Information Logging (CIL) function permits recording of different types of data. It
can record all types of calls, including quality of service data (if provided).
The Call Information Logging allows customers to analyze call traffic, and therefore control
their telephone usage and costs.
The Call Information Logging function generates records regarding call data. Each record
contains data for one call. All types of calls can be registered, such as internal calls,
outgoing external calls, abandoned calls, and even failed calls (calls to a busy party and
calls to vacant numbers).
The following call data can be included in a record:
• Date
• End time
• Start time
• Call duration
• Calling party number
• First and second access code
• Time in queue to a busy external line or route
• Queuing time for incoming call to PBX operator
• Ring time duration
• Queue time duration
• Dialed number
• Number of metering pulses
• Authorization Code
• Account Code
• Outgoing/Incoming External line identification
• Condition code
• Free of charge call information

The record data for each party may include some of the following QoS data fields:
• Codec type
• Cumulative number of packets lost
• Estimated throughput
• Fraction lost rate
• Mean estimated end-to-end delay
• Mean jitter
• Packet lost rate
• Simple R-value
• Extension TCP/IP address
3-5
Call Information Logging (CIL) Function Description
The call logging feature on the MX-ONE is designed to record call details after the call has
hung up, timed out or been abandoned. These logs can be used for billing/accounting,
auditing and, also for troubleshooting.
Call logging has flexible output types and output data formatting (filters). All output types
write to buffers on their own telephone server.
CIL data from all or selected servers can be forwarded to up to 3 central servers for
centralized output. The following example shows CIL data forwarded from another server.
Additional information:
• There are up to 10 active outputs per server and all data outputs work independently
• It is possible to log approximately 500 calls simultaneously per server
• An administrator can recover data by using conversion from one output to another
• It is possible to mask sensitive digits in calling/connected numbers
• MX-ONE provides a heartbeat output to check CIL function for streaming output
types

Condition Data for Call Data
Condition data is a key element in the call record. It designates the type of call that was
made.
The Condition code field used may have either:
• One character
• Two characters
• three characters
• user-defined string
The one-, two-, or three-character codes are shown below
• The condition fields of two or three characters allow a more detailed description of the
call case
The user-defined condition code string can provide a printout in plain text to enhance
readability. The default for the custom string is to use the three character codes.
Condition data are divided into:
• Segments
• Positions
Depending on the segments, condition codes for one, two, and three characters will differ.
Segments indicate the type of call.
One-Character Condition Code

Example of some of the condition codes used for Segment 0 (zero).
• ( ) Outgoing call
• (A) Call handled by a PBX operator
• (B) Calls to a busy party
• (C) Abandoned calls
• (D) Extremely long call duration
• (E) Group call pickup calls
• (F) Group Hunting calls
• (G) Call has been connected with alternative route selection
• (H) Recall to route
• (I) Incoming call or tandem call
• (J) Internal call
• (K) Calls to vacant numbers
• (L) Conference call
• (M) Least cost routing
• (N) Dialed party not equal to answering party
• (Q) Malicious Call Tracing
3-7
• (R) Intrusion
• (T) Transferred call
• (W) Call terminated due to route optimization
• (X) External follow me
• (Y) Call established due to route optimization
All these condition codes are the same across all the Segments, but some will differ,
i.e. single-character condition codes falling under Segment 1 for Long duration calls
will always display D (for all types of traffic cases).
Single-character condition codes for the traffic cases, Operator Extended (A), ECF
(X), Transfer (T), Route optimization (Y), LCR(M), MCT(Q), Call terminated due to
Route optimization (W) will be the same across all the Segments 2, 3, 5, 6,and 7.
Single-character condition code for the remaining cases will change depending on
the type of call. Single-character condition codes for the traffic case, Group Hunt
Calls displays only F for the Segment 3. Similarly, Group Call Pickup calls will display
only E for the Segment 5. Similarly Direct Diversion calls and Diversion on Busy or
Diversion on No Reply displays only D for Segment 6 and Segment 7, for the
remaining cases displays N for all the Segments.
Two-Character Condition Code

• (DO) Long outgoing call /Direct Divert/Diversion on Busy /Diversion on No Answer
outgoing call
• (DA) Long PBX operator extended call /Direct Diverted /Diversion on Busy /Diversion
on No Reply calls extended by operator
• (DI) Long incoming call /Direct Diverted /Diversion on Busy /Diversion on No Reply
incoming calls
• (DJ) Long internal call /Direct Diverted /Diversion on Busy /Diversion on No Answer
internal calls
• (DX) Long external follow me call
• (NJ) Dialed party is not the answering party on an internal call
• (NI) Incoming DID call when the answering party was not the dialed party
• (NT) Dialed party is not the answering party on a transferred call
• (CJ) Abandoned internal call for Segment 0
• (CO) Abandoned outgoing call in a private network for Segment 0
• (FC) Abandoned Group Hunting outgoing /Incoming /Internal calls for Segment 3 and
Segment 7
• (DC) Abandoned outgoing / Incoming /Internal call due to Direct Diversion /Diversion
on Busy /Diversion on No Reply in a private network for Segment 6 and Segment 7
i.e. double-character condition codes falling under Segment 1 for Long duration calls
will always displays D and followed by the traffic case (for all types of traffic cases),
similarly double character condition codes falling under Segment 4 for Data call will
always displays V and followed by the traffic case (for all traffic cases).

Double-character condition codes for the traffic cases, Operator Extended (A), ECF
Route optimization (W) will be same across all the Segments 2, 3, 5, 6, and 7
followed by a blank SPACE.
Double character condition code for the remaining cases will change depending on
the type of call. Double-character condition codes for the traffic case, Group Hunt
Calls displays only F for the Segment 3 and follows the traffic case. Similarly Group
Call Pickup calls will display only E for the Segment 5 and follows the traffic case.
Similarly Direct Diversion calls and Diversion on Busy or Diversion on No Reply
displays D and follows the traffic case, for Segment 6 and Segment 7. Double-
character condition code for the remaining cases displays N and follows the traffic
case, for the remaining Segments.
Three-Character Condition Code

• (NCJ) Abandoned internal call, dialed party is not the answering party
• (NCO) Abandoned outgoing private network call, dialed party is not the answering
party
• (FCJ) Abandoned internal Group Hunting Call
• (FCO) Abandoned outgoing Group Hunting Call
• (DCI) Abandoned incoming Direct Diversion Call
• (DCJ) Abandoned internal Direct Diversion Call
• (DCO) Abandoned outgoing Direct Divert Call
• (DRI) Incoming call Diverted on No Answer
• (DRJ) Internal call Diverted on No Answer
• (DRO) Outgoing call Diverted on No Answer
• (DRT) Transferred call Diverted on No Answer
• (DA) Operator Extended call after Direct Diversion to the operator
• (DRA) Operator Extended call after Diverted on No Answer to operator
i.e. triple-character condition codes falling under Segment 1 for Long duration calls
will always displays D and followed by the traffic case and a space (for all types of
traffic cases).
Triple-character condition codes for the traffic cases, Operator Extended (A), ECF
Route optimization (W) will be same across all the Segments 2, 3, 5, 6, and 7 and
followed by two blank SPACEs.
Triple-character condition codes for the remaining cases will change depending on
the type of call.
Triple-character condition codes for traffic cases, Group Hunt Calls will display only F
for the Segment 3 and follows either the traffic case or a combinational condition
code or a space. Similarly Group Call Pickup calls will display only E for the Segment
5 and follows either the traffic case or a combinational condition code or a space.
Similarly Direct Diversion calls and Diversion on Busy or Diversion on No Reply
displays D and follows either the traffic case or a combinational condition code or a
space, for Segment 6 and Segment 7. Triple-character condition code for the
3-9
remaining cases displays N and follows either the traffic case or a combinational
condition code or a space Segments.
Triple-character condition codes falling under Segment 1 for all the traffic cases will
display only the appropriate condition code and followed by two spaces.
User-Defined Condition String

User-defined condition code strings can be set with command and will provide a
readable string associated with any segment and position. The default is to use the
three-character format when no custom specification exists. This data field is
available in the general subtype.

Output Types and Subtypes
Commands can be entered to select the output type and subtype. The output type generally
describes the transport mechanism and the target where the data is written. The subtype
describes the formatting rules that apply. The format string is used to define or customize the
output in the desired way. Refer to Output Types and Subtypes.
Each output can be used independently from any other output regarding type, subtype and
formatting rules.
3-11
File and asyncFile (from previous chart)

The type file writes synchronously to the defined filename and system (attempting to access
the storage device regularly). It is efficient, but should only be used with a reliable,
permanently connected local hard disk.
The type asyncFile writes asynchronously to file, in batches or when able to. This means
the logged data may not always appear up to date. However, this does mean that it can
handle unreliable network file systems which may not be available 100% of the time.
If an external NFS-mounted file system will be used to store MX-ONE call logging data , it
should be mounted with the options “soft” and “intr” (from the command line or yast tool).
Output Types
Each output can be assigned to an external device, file, or TCP/IP device by using
the suitable command.
All outputs work independently and can be active all at the same time, writing the
same information on several outputs or using different script filters to output selected
information on different outputs as desired.
The SQL type is used when communicating with an SQL data base. It can be an
internal or external data base. The SQL database, it’s structure and schema must be
created by the partner or customer. It is not created by the call logging process itself.
The type "file" is stored in the file system, locally or over NFS. The data is stored as
daily files during a week on the hard disk before being over written. The file should
have a distinctive file name which the system adds a "day number" to the name
which reflects the day it was produced (example: callData.1.xml callData.2.xml 1=
monday,2= tuesday...). This means that only a weeks worth of logs are stored.
The type "tcp" can be used to connect to an external computer running an application
that will accept a TCP/IP stream of data in the format written.
The type "V24" can be used for writing to a serial port, or any type of streaming
device in the local computer.
Output Subtypes
The PostgreSQL format is always writing all valid data to the data base. It is
assumed that the post processing will take care of all filtering and deleting of
unwanted data.
Comma separated and XML format also writes all data but in a more readable form.
The fixed subtypes fp15, mdfp15, asb501, and asbumdfp15 each have a predefined
format with fixed fields and pre-assigned widths defined. If the width of the field is
defined larger than the actual width, the unused position is padded with spaces. On
the other hand, if the width of the field is defined smaller than the actual width,
truncation will occur.
The subtype "general" allows the customer to completely customize the output in
virtually any printout format. In fact subtypes fp15, mdfp15, asb501, asbumdfp15,
demo1, and demo2 are simply predefined formats using the same syntax as general.
The demo1 and demo2 formats are just sample formats that can be used. They are
made available to demonstrate the potential of the script language, and the user
friendliness that can be achieved by using a verbose printout.
For more details, refer to the command description for Call information logging and
the operational directions for Call Information Logging

Mobility Data
The call information logging function generates records relating to DECT mobility data. Each
record contains data for one mobility event for one extension, i.e. a call between extensions
will result in two records if both extensions are included in the logging. Mobility events which
can be logged are Location Registration, Detach, Handover and Call to/from cordless
extensions (CXN).
The following mobility data is included in a record:
• Date
• Time
• Directory Number
• Board position
• Individual
• Event
Condition codes for Mobility events

The condition code is the key element in the mobility record. It designates the type of
call that was made.
• (AXX) Abnormal Call Release.

• (BCA) Call from Cordless Extension
• (BCB) Call to Cordless Extension
• (CHS) Connection Handover, Successful
• (CHU) Connection Handover, Unsuccessful
• (DS) Detach, Successful
• (DU) Detach, Unsuccessful
• (EHS) External Handover, Successful
• (EHU) External Handover, Unsuccessful
• (HFS) Handover Fallback, Successful
• (HFU) Handover Fallback, Unsuccessful
• (LRS) Location Registration, Successful
• (LRU) Location Registration, Unsuccessful
• (TNA) Temporary Not Available
• (MSB) SMS to Extension, Successful
• (UMB) SMS to Extension, Unsuccessful
• (MSA) SMS from Extension, Successful
• (UMA) SMS from Extension, Unsuccessful
3-13
Mobility Criteria
Commands can be entered to determine what mobility events should be output to the
mobility log. This is done by defining one or more mobility criteria for an output file. The
following mobility criteria can be defined:
• All Mobility Events

• The LIM in which the mobility events occur
• The board position at which the mobility events occur
• Mobility event type
• The mobility event in combination with board position
• Mobility event in combination with a LIM
• Directory number of the involved party
• A directory number in combination with a board position
• A directory number in combination with a LIM
• A directory number in combination with a mobility event
• A directory number in combination with a mobility event and board position
• A directory number in combination with mobility event and a LIM
There are 60 output mobility criteria records. The output criteria records are used as follows
when initiating mobility logging call data:
• A single directory number, LIM or BPOS will use 1 record

• A range of directory numbers, LIMs or BPOSes will use 2 records
• A mobility event will use 1 record
Note: For mobility logging, you must activate the logging first with the
dect_logging command. Please view the online command description for
further information.

Output Formatting
A command is used to set the time zone to use for the time information in printouts for the
fixed output formats (fp15, mdfp15, asb501, and asbumdfp15), allowing use of UTC to
prevent problems with normal or summer time.
Commands can be entered to determine what calls should be output to external equipment.
This is done by defining a formatting string per output by command.
The format string is defined in a script language and can filter the output based on all data
available in the call logging data.
Any field in the output can be tested and used to filter the output of data.
For the subtype "general" the format string is also used to format the data output.
3-15
CIL Heartbeat
This feature is used to monitor the accessibility of the external storage media. It is activated
by an option (-heartbeat) and the record is generated periodically with the time interval of 15
minutes. The Heartbeat record will be output to the ordinary CL output file.
It is only possible to initiate heartbeat for the v24 and TCP types.
The following data is included in the Heartbeat record:
• Year
• Month
• Day
• Hour
• Minutes
• Text HEARTBEAT FROM
• Exchange ID

Capacity
The best way to setup the logging system is dependent on the size of the system and the
output devices and facilities to be used.
Calculations must be made, when using hardware devices (such as V24) on communication
speed and the number of characters to print per call. Consider using more than one device if
the device is too slow. More outputs can be used with different filters. With this method a
simple load sharing is created.
Max. Capacity, Independent of Output Devices

Below follow the maximum capacities independent of the output devices.
• The maximum number of outputs per LIM is 10

• The maximum number of active outputs per LIM is 10
• The maximum number of data forwarding positions per LIM is 3
• The maximum number of simultaneous calls to be recorded per LIM is 500
• Decisions on topics such as, if the SQL data base should reside in the same
computer as the telephone application or on a separate (external) computer need to
be made. In a situation with less than 7 calls/second less than 70,000 call records in
the data base and low query rate, the data base can coexist on the same computer.
If more than 20 calls/second and more than 200,000 call records in the data base
and high query rate a high, an external data base server is needed
System Reliability
The SMDR/CIL/QoS outputs can be configured to have many simultaneous outputs.
They can each have different output types, subtypes, and formats. Thus it is
recommended to initiate one output as a safety backup with type = file, subtype =
commaseparated or xml, storing all data to local files. Then the rest of the outputs
can be assigned to do the main outputs in any type and subtype format as desired.
With this method of overlapping recording it is possible to have a local safety copy in
the case the main device is offline. The safety backup can then be used to create the
missing data to the main device, with the help of the three conversion commands that
are accompanying this feature.
Conversion programs are available to perform conversions of file format in post
production/recovery. These commands can only operate on source types/subtypes
that contain all data. The conversion programs can convert data from -> to in the
following ways:
• file/commaseparated -> SQL

• file/xml -> SQL
• file/commaseparated -> file/all
• file/xml -> file/all
• SQL -> file
3-17
Alarms
The SMDR/CIL/QoS feature generates alarms to indicate:
• Faulty configuration (alarm 1:3)

• Error has occurred during output of call records (alarm 1:4)
• Output device is disconnected or not available (alarm 1:5)
• Output queues are almost full. (indicating low bandwidth on output stream)(alarm 1:8)
• Speech quality is poor (warning)(alarm 1:6)
• Speech quality is bad (alarm 1:7)

CIL Commands
Before exploring the various CIL Commands, it is important to state that an administrator can
find out more information concerning the commands by simply type –help parameter behind
the command (e.g. callinfo_condcode_print –help ).
These commands can be entered in SNM under Tools>Command Line or from an SSH
session using a tool such as Putty.
The following are CIL Commands and their subtype
• callinfo_condcode_print
Description: callinfo_condcode_print command is used to print information about
how a condition code is printed out. The printout can print all codes, a selected
code, or codes that are custom defined. These codes are the codes used in the
call information logging file or printout. The condition code is used in outputs
generated by the callinfo_output_set command and the -format parameter
Example:
• callinfo_condcode_set
Description: callinfo_condcode_set command is used to set information strings
to be printed in the call logging output in the formatting when condition code are
translated to custom format. If a custom code is not set the CC3 condition code is
printed.
Example: callinfo_condcode_set -code 8 -string "Normal call" – this will set
condition code translation for internal call
• callinfo_file_to_sql
Description: callinfo_file_to_sql command is used to extract data from a file into
a data base. This command must be run on the lim/server where the file is
situated. Use callinfo_output_info to print more information about subtypes.
Example: Refer to help file for Command Line example
3-19
• callinfo_file_to_file
Description: callinfo_file_to_file command is used to convert data from one file
to another file, while changing format or selecting what data to be copied
(depending on charged number or time of call). callinfo_file_to_file is an off-line
command. This command must be run on the lim/server where the files are. Use
callinfo_output_info to print more information how formatting is done for type file
and its subtypes.
• callinfo_limit_print
Description: callinfo_limit_print command is used to print information of
Qos alarm. It can be printed for the system or a specific lim
Example:
• callinfo_limit_set
Description: callinfo_limit_set command is used to set the alarm levels and
quality levels used for quality of service supervision in IP telephony. The "bad"
and "warn" levels are used to determine if a call is good, at warning or bad. The
results of the evaluation are stored in in a buffer containing a set of samples.
When more than a "red" number of "bad" samples are in the buffer, the red alarm
is raised. When more than a "yellow" number of "bad" AND "warn" samples are in
the buffer, the yellow alarm is raised. Refer to callinfo_limit_print for an example
of default settings
Example: “callinfo_limit_set -red 5 -yellow 12” to change the alarm levels for red
and yellow
• callinfo_mask_print
Description: callinfo_mask_print command is used to print information regarding
masking of digits when protecting integrity by removing last digits or replacing
them in the call information data output
Example: “callinfo_mask_print -lim 1” to print the masking configuration for lim 2

• callinfo_mask_set
Descriptions: callinfo_mask_set command is used enable the masking of digits
when recording. This maybe to protect the privacy of users or for market specific
legal requirements. This command works by removing trailing digits or replacing
them in the callinfo printout
Example: “callinfo_mask_set –all 4-2, 7-3” Set configuration to replace 2 digits
when at least 4 digits are dialed with “ “ and replace 3 digits when at least 7 digits
are dialed with “ “. “All” means that all types of numbers will be affected
• callinfo_output_change
Description: callinfo_output_change command is used to change the formatting
of printouts from the call information recording function. The command will
substitute or append to the existing formatting rules used for the stated output
• callinfo_output_info
Description: callinfo_output_info command is used to print information of what
types and printouts that are available in the current version of the call information
recording function. The command will list each type and subtype together with
information on what parameters are used for each combination. The command
will also provide several extensive examples how to do a proper setup
• callinfo_output_set
Description: callinfo_output_set command is used to setup an output stream of
call information data. The command will set formatting rules, destination of the
data, together with information used at the destination, e.g. user information,
parameters for data transport etc. Ten output channels can be defined per lim,
each channel will store the data generated to the assigned destination, and in the
assigned format independently from the other channels. In multi-LIM systems one
or more collect-nodes can be assigned where the output can be forwarded. To
prevent duplication of data in central collecting point a local only flag may be set
so that only locally generated data will be stored at that output
Example: callinfo_output_set -output 1 -lim 1 -type sql -subtype postgreSQL -
dbname smdr1 -server my.secure.net -port 123 -user sqlstorer -password
hushhush” will configure lim1 to output all call information on output 1 to
postgreSQL database “smdr1” on server “my.secure.net” on port 123 using
account “sqlstorer” with password “hushhush”
• callinfo_sql_to_file
Description: callinfo_sql_to_file command is used to convert data in the data
base to a file, in the desired format. callinfo_sql_to_file is an off-line command.
This command must be run on the lim/computer where the file is created. Use
callinfo_output_info to print more information how formatting is done for type file
and its subtypes
Example: “callinfo_sql_to_file -sqlsubtype postgreSQL -dbname smdr -server
my.secure.net -port 123 -user sqlstorer -password hush -filename
/var/opt/eri_sn/call_logging/conv -filesubtype xml” will convert the postgreSQL
database "smdr1" on server "my.secure.net" on port 123 using account
"sqlstorer" with password "hush" to xml file /var/opt/eri_sn/call_logging/conv
3-21
• callinfo_status_print
Description: callinfo_status_print command is used to printout where call
information is stored, and in what format. The printout will also print the current
state of the output(s)
Example: “callinfo_status_print -lim 1 -output all” will print lim one configuration
for all outputs. The following example is only showing 2 of the 10 outputs
• callinfo_status_set
Description: callinfo_status_set command is used to enable data to be
forwarded to a specified output, or forwarded to another lim. Ten output
destinations can be defined, each channel will store the data generated to the
assigned destination, and in the assigned format set by callinfo_output_set
command. In multi-LIM systems up to tree central forward-nodes can be
assigned where the data will be handled and stored
Example: “callinfo_status_set -lim all -forward 2,3 -state on” will add lim 2 and 3
to the list of forward lims
• callinfo_tcp_print
Description: Enable test TCP server to print CIL output to console screen.
Additional program, namely, a TCP/IP daemon that will listen to a specific port
and display the received data on the screen. Primarily intended as an installation
and fault-finding tool

CIL Output
For the output number, enter: -output 0 to 9. The location of the output can be listed
as: -lim x (where x is the lim number).
There are four output “types” (defining the transport mechanism):
• To internal or external SQL database: -type sql

• To local or remote file system (synchronously): -type file
• Network over TCP/IP: -type tcp
• Serial to printer or other: -type v24
Each type has a subtype (-subtype) which controls the output format.
There are fixed and flexible output formats for all output types except SQL. Formats
may be:
• Fixed formats containing all data fields (readable and non-readable)

• Fixed formats with pre-defined data fields
• Flexible format with choice of all data fields
CIL Output can be set Local or Centralized
• Output can include local data (-local callinfo_output_set)

• Local data and data forwarded from other servers
For centralized data to a server, the output is set in the callinfo_status_set.
The following is an example of two servers, both set up for local and centralized CIL
data output:
3-23
The following is an example of two servers, on set up for centralized CIL data output
to TCP and the other centralized CIL data output to v24:
Backup CIL Output to File - Recommendations include:
• 1 output per server to a local file with format to include all data (Output 0).
• Use: callinfo_output_set -output 0 -lim all -local -type file -dbname
/var/opt/eri_sn/call_logging/cil_backup -subtype commaseparated
Output 0 does not output forwarded data ( i.e. it is –local only)
Output can be used as backup and converted to file or SQL
cil_backup file is created by system on ALL servers
/var/opt/eri_sn is backed up in safety backup process
• Files should be stored locally (you can backup to NFS but this is not recommended)
NFS information can be found in documentation
• These files should be stored as daily files with unique file names (configurable) + day
number (system added) for 1 week. Remember that files are overwritten on same
day of following week
• Run a crontab job weekly to copy files to avoid overwriting existing files

CIL Output EXAMPLE

To set the output enter (all one line):
• callinfo_output_set -output 0 -lim all -local -type file -dbname

/var/opt/eri_sn/call_logging/cil_backup -subtype commaseparated
To active “backup” CIL output on all servers (in this example there is only LIM1)
enter:
• callinfo_status_set –output –lim all –state on
To print the configuration of the active outputs (Output 0) enter:
• callinfo_status_print –output 0 –lim all
3-25
Fixed Format Example

The following types: file, tcp and v24 can use pre-defined formats with any of the
following subtypes:
• fp15
• mdfp15
• asb501
• asbumdfp15
All types contain: call stop time, duration, condition code, access code, dialed
numbers, calling numbers, account and CIL codes.
• All files start with a header (MMDD) configured with:
Keys:
 [ ] Condition. Header [head] and footer [foot] conditions always true.
 : Separates condition from format information
 { } Format information
 ; Separates format specifications. Must exist after header and at end of
format script
Files must include –format parameter, defining whether date and time are local (-
format “local”) or UTC (-format “utc”)
 UTC means Coordinated Universal Time (replacement for Greenwich Mean
Time)
CIL Output over TCP with Heartbeat Example

To set the TCP output from server 2 for local and forwarded data with fixed format
and heartbeat, enter the following:
• callinfo_output_set -output 1 -lim 2 -type tcp -subtype asb501 -server 192.168.99.20

-port 3500 -format “local” -heartbeat
-server and –port define the receiving network device
Server 2 must be set as “-forward” in callinfo_status_set
• Heartbeat output will be every 15 minutes

Forward All CIL Data to Server 2 for Centralized CIL Example

In this example we will want ALL servers to forward data to lim 2 for centralized
output. Enter:
• callinfo_status_set -lim all -forward 2 -state on

servers to forward data = all (i.e -lim all)
servers to receive forwarded data = centralized server = 2 (i.e. lim 2)
To activate TCP output in server 2, enter:
• callinfo_status_set -output 1 -lim 2 -state on

To confirm your settings, print the configuration of active outputs by entering:
• callinfo_status_print -output 1 -lim 2
To Set CIL Output to a Flexible Format Example

The subtype “general” allows format scripting. Use -format parameter to create a
flexible format.
A format script must be contained within quotations ”…”
Script can define 3 format specifications:
• Header
• Format information (data to be output)
• Footer
Format specifications are separated by semi-colon (;)
-format <header> ;<information> ;<footer>optional mandatory optional
CIL Output over TCP/IP with Flexible Format Example

TCP device with flexible format example:
callinfo_output_set -output 1 -lim 1 -type tcp -subtype general -server
192.168.20.2 -port 3510 –format “[head] :MX-ONE CIL {currentTime year 0R 4
4}{colon} {currentTime month 0R 2 2}{colon}{currentTime day 0R 2 2}
{newline}; {stoptime md110time L 4 4} {duration md110duration L 5 5}
{conditionCode3Character L 3 3} {accesscode1 L 3 3} {dialedNumber R 9 9}
{callingNumber L 9 9} {incTrnkID R 9 9}; [dialedNumber ==
callingNumber]:Faultman’s Ringback; [ogTrnkValid == 1]: {ogtrnkid R 9 9}
;[ogTrnkValid != 1]:{connectedNumber R 9 9}; [callingNumber >=
6000][duration > 00100]: Attention! {callingNumber L 4 4} ;{newline};
• Interpretation:
From [head] to {newline}, contains the definition of the header.
A footer is not defined
Every item is described with name, adjustment, length
 0R 4 4 = right adjusted min and max 4 digits, filled up with 0
 {callingNumber L 9 9} = calling number left adjusted min max is 9 and no 0
to fill up the space
 [callingNumber >= 6000][duration > 00100]: Attention! = when calling
number is greater or equal 6000 AND duration is greater than 100seconds
then we want to store it
3-27
 Attention: comparing of calling numbers is a strict arithmetical operation

To activate forwarding and output:
• callinfo_status_set –lim all –forward 1 –state on

• callinfo_status_set –lim 1 –output 1 –state on
The -lim parameter defines where output is located
Omitting –local allows forwarded data to be output

Lab 1 - Configuring Call Logging to a Local File
Lab 2 - Configuring Call Logging to a TCP Connection
3-29
Recorded Voice
4
Announcements
Objectives
 Understand how the MX-ONE can play recorded announcements

 Know how to record, upload and configure messages
 Be able to apply messages to different types of telephony scenarios
 Use SIP Streaming to send music and messages direct to handsets

Recorded Voice Announcements
The MX-ONE Telephony Server supports Recorded Voice Announcements (RVAs) for a
variety of purposes including things like welcome greetings to Hunt group visitors, individual
extension messages and prompting for a pin number when using Remote Extension R2
numbers.
In modern MX-ONE systems, RVAs are created from .wav files that are uploaded onto the
system via SNM. They can be recorded on a normal PC using a microphone and sound
card or converted from a professionally recorded source. Wav files should be short and
succinct as although a message can be any length, the maximum amount of space
allocated to messages will vary depending on the device used to play out the messages.
On the original MGU board a total of 30MB flash storage was available (which equates to
around 60 minutes of RVA messages). The newer MGU II has 120MB (which equates to
around 3 hours of RVA messages). The Media Server is only restricted by the server it is
running on.
Message files can be recorded as G.711 a or mu law (8k, 8bit mono) or PCM (8 or 16k,
16bit mono) and stored as .wav files . If using Media Servers and the newer SIP Streaming
mechanisms, then version 7 systems also support the .mp3 and .ogg file formats as well.
Up to 250 RVA messages can be stored on a Media Gateway system. In the case of the
Media Gateway the files are stored in a designated directory in the NFS mounted file
system.
The Recorded Voice Announcement (RVA) feature allows messages to be provided to a

calling or connected party to inform of the status of the call in various traffic cases, for
example when:
the call is diverted

the call is in queue
the call is parked
the call is answered by a PBX-operator
The types of calling or connected parties that receive RVAs are, generally speaking,
external lines and extensions, with some exceptions.
For example:
for diversion, group hunting, Automatic Call Distribution (ACD), call to an operator or
to an extension, voice announcements can be provided when the call has originated
from an extension, from a public trunk line, or from a tie line.
Vocal guidance is a service that can be provided for analog (ATS), digital (DTS),
cordless (CXN), and certain mobile (RXN) extensions, as well as for External Follow
Me (ECF) extensions on tie lines or public trunk lines.
Welcome announcement and Music on Wait can be provided for certain call cases
towards group hunting and ACD groups.
All cases can be supported either with SIP based streaming RVA functions
4-3
Initializing Recorded Voice Announcements
As with most aspects of the MX-ONE, Recorded Voice Announcements (RVAs) can be
configured using both the command line and the web based tools, SNM in this case.
In this instance, the gui is the easier option as the uploading of the message files can take
advantage of the http web services, rather than having to manually upload them using a
tool such as WinSCP.
The steps to initialize RVA break down as the following:
Upload sound files and allocate them to an RVA message file

Link a message file to an Announcement
Activate the RVA services and features that are required
Link Announcements to specific groups, extensions or Vocal Guidance
Here we use the Service Node Manager tool to carry out these steps. The RVA feature is
found under the Services / Voice Announcements section.
Upload Sound Files

The first stage is to upload the sound files. Using the Voice Messages option within SNM
automatically uploads the files from the user’s PC onto the Linux server and then copies
the files to the correct storage location. This is the Flash memory of the MGU board or the
correct directory when using Media Servers. The message is also then loaded into RAM so
it can be played out instantly.
1. Click on the Voice Messages option and click Add

2. The system will automatically choose the next available message file
(messageXXX.wav). A description of the message file can be entered and finally
using the Browse button to navigate on the local Windows file system for the audio
wav file to upload. Click Apply.
3. If the file is accessible and the correct format, SNM will upload the file and respond
with a success message. Either add more messages or press Done.
4. Clicking Done shows the messages that have been successfully uploaded to the
system and Media Gateways/Servers.
Note: Message files are stored in folder /var/rva when uploaded
4-5
Link Messages to Announcements

Once messages have been uploaded they can be linked to an Announcement number.
Announcements are used with RVAs to make it easier to quickly change the audio file that
is being played out without having to change the whole configuration of the system.
An example could be a new message needs to be played out to visitors to a hunt group due
to a special event. The new message can be recorded, uploaded as a new message file
and then simply associated with the announcement number that is already linked to the
hunt group queue. When the event is over the original message can be re-associated with
the Announcement.
We use the Announcement Setup option to link the message file to the announcement
number.
1. Click on the Annoucement Setup option and then click Add
2. Enter a descriptive name for the announcement, remembering that more than one
announcement can be linked to single messagexxx.wav file. When choosing a
number for the announcement, the values 1-250 and 256 to 65535 are allowed.
Values 251 - 255 are reserved for internal use and cannot be used. Also note that
some RVA functions only support announcements from 1-250, so normally these
would be used first and higher numbers only for very large systems Click Apply to
save.

3. The system confirms the successful creation of the announcement.
Activating RVA for specific purposes

Before RVAs can be played through the MX-ONE, the system must be told for which
features message announcements should be available. This is achieved using the
Announcement Settings option. The drop-down boxes and tick boxes in the GUI change
Application System parameters that affect the whole MX-ONE exchange. These changes
would traditionally have been carried out using the ASPAC command.
The options split into two main sections, the first half refers to diversion and individual
extension announcements, whilst the second half refers to hunt group, ACD group and
Operator settings for messages.
4-7
The first few boxes define the announcements to play when a caller is diverted. A diversion
announcement can be provided to the calling party if the called extension has activated
diversion to a new destination. The diversion announcement will be provided to a calling
party if the originating calling party type is selected to be provided with the diversion
announcement. There are two types of diversion announcements:
Internal Diversion Announcement
Diversion is to a directory number (extension, operator, group etc.)
External Follow Me Announcement
Diversion is to an external party outside of the exchange (external follow-me)
Diversion Announcement
The three check boxes underneath determine under what diversion scenarios either of the
two announcements are played. Note there is no Diversion on Idle option.
Allow Process Call while Message is Playing
This determines whether the diverted call is allowed to progress whilst the message is
playing or only after the message has been fully played.
Calling Party Selection Announcement
These check boxes determine which type of incoming caller will receive an announcement.
If Internal call is not selected, RVAs will not be presented to extensions within the
exchange.
Continuous, queue- and repeated queue announcement
This applies to calls arriving at hunt groups, ACD/CTI groups and Operators. These
ongoing or queue messages will only be played to the type of calling extensions ticked.
Welcome announcement
This applies to calls arriving at hunt groups, ACD/CTI groups and Operators. The welcome
message will only be played to the type of calling extensions ticked.
ACD Group/Hunt Group Announcement
These check boxes allow special scenarios to be configured for calls to these two types of
groups.

Link Announcements to Specific Components

The final stage is to define which announcements will be played for which specific
telephony components (Operator, Hunt Group, Extension, ACD/CTI group, Vocal guidance)
Each of the remain options under Recorded Announcements haver their own specific
settings. Here we look at hunt group and extensions as examples.
4-9
Lab 1 - Setting up Recorded Voice Announcements

Streaming Audio to SIP Extensions
A new feature that arrived in MX-ONE Release 6.3 was the ability to stream audio (music
or other announcements) direct to SIP 68xxi & 69xxi series extensions.
This allow SIP terminals to get streamed media, like music wav-files or streamed radio or
music, played in specific scenarios.
Examples would be when the terminal is in an idle state (with no call in progress) receiving
audio to playback, in a parked or queuing situation and streaming/music on hold/wait.
The streaming feature require an external source(s) of streamed media, typically located on
a server outside the MX-ONE system. This could also be an external web server hosting
files in a .mp3 or .ogg format, but could also use the media files (wav) already installed on a
Media Server.
The Streaming/Music-On-Idle (MOI) feature allows streamed live or pre-recorded
announcements (for example music or voice) to be provided to a SIP extension which is in
idle state, i.e. not involved in a telephone call. The SIP extension would also have a
dedicated key defined to enable or disable the feature.
The feature Streaming On Idle is supported for Mitel 6800/6900 SIP terminal models and
for later models. It allows the user to connect to a music (or other) media stream, without
any line or MX-ONE management resource being required. The phone will be open to
inward and outward calls (alerting or dialling) and when returning to idle state after a call,
the music can be retrieved either automatically or manually with a single button push.
The other variants of streaming can be used when appropriate in traffic, i.e. in ongoing
calls, in specific cases, like when a call is parked or queuing, or in specific traffic cases, like
diversion and vocal guidance in call failure scenarios.
To use the ’Streaming/Music on idle’ (MOI) feature, a Media Server and specific SW in the
MX-ONE Service Node needs to be present and activated. The SIP terminals in use must
also support the functions. The media server and its interfaces must be initiated and active.
The ’streaming on idle’ feature or the other streaming setups do not require any specific
license on the MX-ONE.
4-11
This streaming function is enabled by ordering SIP terminals to listen to an existing media
stream or to set up a stream, and then order terminals to listen to it. The stream is set up to
always go via a ’media server’. The stream is either dynamic, i.e. set up from the handset
via a button push, or static, where the handset is ordered to listen to the existing stream,
normally using IP Multicasts.
Activating the Media Streaming Server

When a Media Server is added as Media Gateway via SNM, it is also automatically added
as a Streaming on Idle server. Here we discuss the setting up of the Media Streaming
Server services. We will use SNM to perform the programming. (The command line utilities
are media_server and streaming_data)
Using the Services / Media option we see the two options; Music on Idle and Media Server
Message.
Music on Idle
This option is used to define the streams used for both dynamic and static sessions. Here
we see a static multicast setup which requires two channels. The static_1 channel is used
to connect the media server to the source of the audio and generate a multicast from it.
The dynamic channel is used to present the multicast address 232.0.0.2:60000 to the
handsets. There is also the required Stop service to allow all streams to be disconnected
from the handsets.

Here we see the configuration for each of these MOI entries. The first shows the static
(always on) channel and specifies which MS will connect to the Media source and the
multicast address and port that the MS will stream the data on. The second screenshot
shows the dynamic (switch on or off) channel which the handsets will connect to.
Finally, the last entry is the stop session which is used to cancel any streaming audio
session on the handset and would be accessed via the programmed key action uri.
4-13

Media Server Message

The media server message function can be used to convert Service Node based message
announcement numbers to Media Server resources, either a locally stored file or a remote
URL based resource.
This feature is typically used to assign resources to the reserved message numbers that
are traditional linked to external music resources. These are the numbers 251-255 and are
used for traditional Music on Hold etc.
The screenshot below shows three MSMs, one associated specifically with MS 1A, the
others defaulted. Two messages are linked to local files stored on the MS hard drive in
/var/rva, the other accessed via a web URL
These features can also be configured by command using the media_server_message

command.
4-15
Activating on the Mitel SIP Handsets

The Action URI function is supported by the Mitel 6800/6900* SIP phones and is used
many other uses (such as with the MiCC Enterprise Call Center). An Action URI is required
to enable the streaming function. The feature requires a dedicated key for Streaming in idle
state/Music On Idle, (MOI).
Note: * Low-end models, like the 6863 do not have any free key resources, so they are not
suitable for this feature.
There are two streaming configurations supported; multi-cast or unicast. An Administrator
or User of the 6800/6900 phones can configure a specific key (soft-key, programmable key,
or expansion module key, here called streaming/MOI key) on the phone, that allows you to
send/receive a Real Time Transport Protocol (RTP) stream to/from pre-configured multi-
cast addresses without involving SIP signalling.
This is called Paging on the Mitel 6800/6900 SIP phones. You can specify many listening
multi-cast addresses at once. Note that a specific “Off/Stop” menu entry should be initiated
to allow for the switching off of the streaming audio.
After pressing the “Streaming/MOI” key that has been configured on the handset, the
phone receives an RTP stream from a pre-configured multi-cast address (IP port). Any
other phone in the local network listens for the same RTP stream on the pre-configured
multi-cast address. For both sending and receiving of the multi-cast RTP there is no SIP
signalling involved, when the phone sends or receives a multi-cast RTP.
The 6800/6900 SIP telephones currently use a pre-configured G.711 mu-Law CODEC only
to play the audio stream.
The unicast configuration works in a similar way, except that when the key is pressed the
streaming will start to that specific extension as a one to one connection, while for multi-
casting, the streaming will be active all the time.
A proprietary XML protocol is used for the key and display handling from the 68xxi and
69xxi series of handsets. The Media server can take an .Ogg or .MP3 audio stream from an
external media server. The Media Server performs a decoding process with the received
streams, transcoding and resampling to chosen VoIP codec. The performance and audio
quality can be affected by the complexity of transcoding/resampling required. Streams are
always transcoded into 16000 Hz linear 16 bit PCM samples by the Media Server, acting as
an intermediary.
To activate a key on a Mitel SIP handset to enable the Stream on Idle function the following
command could be used:
extension_key -i --dir 1001 --key 5 --function XML --xml-on-demand-uri
'http://$$PROXYURL$$:22222/StreamingMenu?user=$$SIPUSERNAME$$'
--display-text PlayMusic
This would program key 5 on extension 1001 to launch the xml uri listed between the
quotes.
These settings could also be set via the configuration files delivered via the http/tftp/ftp
server at handset startup.

Least Cost Routing and Number Conversion / Translation
Least Cost Routing and

Number Conversion /
5
Translation
Objectives
 Know what role LCR plays in a MX-ONE system

 Be able to configure LCR tables for the main types of routing
 Understand the role of Number Conversion/Translation
 Be able to program inbound and outbound translations
5-17
LCR – Least Cost Routing
Overview
Least cost routing is a mechanism that was introduced to the MX-ONE after basic route
and trunking facilities. LCR allows an administrator to configure various tables which allow
different choices of route to be automatically selected based on the outgoing or called
number. The route chosen will typically be the one that provides the cheapest call costs to
that destination, although alternate routes can be specified to provide redundancy.
The main reason for using LCR is to reduce the cost of calling specific destinations. This
facility has come about due to the proliferation of wholesale communication carriers that
can offer cheaper call charges to specific destinations, such as mobiles and international
calls.
Another reason for using LCR is when calling another office which is using serviced by an
independent PBX. In this instance the two offices may use different telephone access
codes but are connected by a dedicated circuit or IP network. In this instance it does not
make any sense to route calls to this office using a normal public PSTN carrier, when the
private circuit would provide a cheaper option.
The main advantage from the end user’s perspective is that LCR is performed
automatically and transparently. They just dial the number as usual and the system
chooses the best route.
It is also possible to specify different time periods for LCR, allowing even greater control.
This allows different providers to be used for evening or weekend calls.
How does LCR work?

LCR works in conjunction with the standard routing mechanisms configured on an MX-ONE
system. It is primarily designed to be used as a filter for calls that are designated as
external and ones that would normally be sent to the public network. In Number Analysis, a
entry is configured as the LCR Access Code. This code is what the users of the system are
told to use as a prefix when dialling an outside number. In much of the world this is
commonly 0 although 9 is used in some markets.
When a dialled number begins with this code the LCR mechanism receives digits and starts
to process it. LCR route selection is performed using a number of analysis tables. The
dialled number is analysed in these tables and the call is handled according to the data
specified in the tables.
There are five analysis tables in total. These are:
o External Number Table (ENT).
o Number Length Table (NLT).
o Destination Number Tables (DNT1 and DNT2).
o Fictitious Destination Table (FDT).
The way these tables process a dialled number are discussed over the next few pages.

LCR Number Processing Flow - Table order
External Number Table

The External Number Table (ENT) is used to process the outgoing dialled number so it can
be changed if necessary. ENT is typically used to convert a number that would otherwise
be routed externally out of the MX-ONE and re-number it so it is handled internally.
A typical example would be a staff member dialling the full DDI number of their own
company’s helpdesk. The LCR ENT table would recognise the dialled digits and manipulate
them to produce the internally routable number. In this way the company’s costs are
reduced.
The table can perform the following options:
Delete a number of leading digits from the dialled number
Insert digits at the beginning of the dialled number
Determine whether the dialled number is in conflict
In most cases after a match has been found in the ENT table the resulting converted
number will no longer be considered to be a LCR number and will be released to the MX-
ONE for internal routing.
Conflict number
Conflict numbers are numbers with the same leading digits but with different number
length, e.g. if both 12 and 123 are valid numbers they are in conflict and a timeout value is
used after the second digit in order to see if any more digits will arrive.
If no match is found for a dialled number in the ENT table, the number will be passed for
analysis in the Number Length Table.
The ENT table can contain up to 50000 entries with up to 16 digits.
5-19
Number Length Table

After being analysed by the ENT table the dialled number will either now have exited the
LCR process (if the converted number in now not an LCR one) or it is passed to the NLT
table.
The NLT is used to identify conflict numbers and to avoid conflict situations which may
occur for markets with a complex numbering plan with differing length number beginning
with the same digits. A typical scenario will be where the same access or area code can be
followed by a differing number of digits. The US market is most affected by this, where
different carriers can use the same area codes but have a different total number of digits in
the final number. The use of minimum and maximum number lengths can be used to
identify and handle these conflicts and adapt the numbers accordingly.
This table should be used when an exchange has a remote LIM in a different area (with
another area code).
The NLT table will often be empty in many markets (this is typically the case in most
European countries, which have more controlled or regulated PSTN numbering)
This table can perform the tasks listed below:
Determine whether the dialled number is in conflict
Specify the maximum number length
The minimum number length indicator is used to decide if the systems own area code
should be inserted between the LCR Access Code (LAC) and the rest of the analysed
number.
If no match is found for the dialled or rearranged number in the NLT, the number will be
passed to the Destination Number Tables.
The NLT table can contain up to 1000 entries with up to 6 digits.
Destination Number Tables (DNT1 & DNT2)

The Destination Number Table is divided into two tables, i.e. the Exceptions Table (DNT1)
and the Number Table (DNT2).
The Exceptions Table holds those numbers which are exceptions to the more general
cases which exist in the main DNT Number Table. This means that a number which is to be
analysed, is first passed to the Exceptions Table (DNT1) and if found there the destination
number analysis is completed. If the number is not found in the Exceptions Table, the main
number table (DNT2) is tried instead.
An example of how these tables are used could be in the analysis of calls to mobile (cell)
phone numbers. A company may have an arrangement with the mobile phone carrier that
provides the handsets and network for all employees which allows a SIP trunk to be used
to pass all calls from the MX-ONE to company mobile phones on that network free of
charge. The company also has another SIP carrier that provides cheaper call costs (than
their regular carrier) for calls to mobile phones in general.

In this scenario entries would be placed in the DNT1 table matching the specific leading
digits that identify the company’s mobile phone number range. These would be tagged with
the FDT entry aligned with the free SIP trunk. Whilst the more general leading digits for
mobile phones would be placed in the DNT2 table and point to the cheaper SIP carrier.
This allows the different number ranges, that would otherwise be in conflict (same leading
digits), to be processed differently.
For each number stated in the Exceptions (DNT1) and Number (DNT2) Tables the
following data may be given:

Whether account code is required or not.
Link to the Fictitious Destination Table (FDT) where the required routing destination
code is stored.
Indicator stating which Toll Restriction Class of Services are allowed to complete
the call.
What type of external number the dialled (or rearranged) number is.
Information about this destination's Call by Call service number.
Which Transit Network Selection to use for this destination.
Which local or network operator to access for this destination (Operator System
Access).
Both the DNT1 & DNT2 tables can contain up to 35000 entries with up to 16 digits for
DNT1 and 8 for DNT2.
Fictitious Destination Table

The Fictitious Destination Table is used to link a fictitious destination referenced in the DNT
1 & 2 tables to a real MX-ONE routing destination.
The FDT can also be used to provide LCR time of day functionality if required. This allows
multiple time zones to be created which can then be configured to use different routes
depending at what time the call was made. This allows a customer to take advantage of
carriers which offer cheaper calls at certain times of the week or in the evenings for
example.
The Time of day function allows:

Up to three periods
Mon-Fri, Sat, Sun
24 hour period can be divided into 3 sections
The dialled number enters ENT table first. After the being processed by the tables:
o a timer is initiated if the number is marked as CONFLICT
o or the number is rearranged and transferred to NLT (if a match is found)
o or the unchanged number is transferred to NLT (if a mismatch is found).
5-21
A similar procedure is used when checking in the NLT, to decide whether that number is
transferred to DNT1. If a match in DNT1 is found, the FDT is used for fetching an external
destination for External Analysis. If there is a mismatch, DNT2 receives the number.
If a match in DNT2 is found, the same procedure as for DNT1 is applied. In the case of a
mismatch, the call is routed to a predestined default destination
The FDT table can contain up to 72 entries.
ERWT – Expensive Route Warning Tone

The Expensive Route Warning Tone or ERWT feature provides a warning tone to the user
when the system has selected (with least cost routing) an expensive route for the outgoing
call.
When the user has dialled a complete external number and the system has chosen a route
that is marked expensive, the user receives a warning tone. The expensive route is seized
and all digits except the last one are sent to other system.
At the warning tone, the user can either terminate the call or wait for the time out of the
warning tone. On time out, the system will continue to process the call by sending out the
last digit.
Digits which are dialled during the tone sending (ERWT) are ignored by the system.
PDC - Public Destination access Code

The LCR function also includes handling of the Public Destination access Code (PDC)
which is mainly used in the US as a complement to the LAC. When using a PDC the
call is not least cost routed, but external numbers may be (selectively) barred for calls
by using the LCR features, Toll restriction and Forced account code. A comparison to
help under-standing PDC:
To use only basic routing (no LCR), the user dials a standard access code to the
public network and the dialled number is sent for external analysis. Toll restriction
and Forced account code cannot be used since they are LCR features. A basic
route access code is initiated with the number type ED
To use LCR, the user dials a LAC and the dialled number is modified, is Toll
restricted, and so on, before the modified number is sent to external analysis. A
LAC is initiated with the number type LC
To use LCR with PDC, the user dials a PDC and the dialled number is LCR-
analyzed, but only Toll restriction and Forced Account Code are applied on the call.
The dialled number is not modified before it is sent to external analysis
A PDC is initiated with the number type PD
No other LCR features, for example Time of day, than the two mentioned above
may be applied to a PDC call.

LCR Initiation
LCR has traditionally been implemented using the command line utilities which are MML
based beginning with LC. However, in recent MX-ONE releases, it has been possible to
configure and edit LCR information using SNM. Note that the FDT table must be created
before DNT1 and DNT2 to ensure the FRCT entries exist and can be selected.
In SNM, the LCR options are found under Number Analysis. This allows new entries to be
added and existing settings to be viewed and edited (regardless of whether they were
configured via the web or command line.
First choose the table to be edited.
Then complete the LCR fields for the table specified.
5-23
Many administrators still use the command line though, especially for initial configuration
due to the repetitive nature of LCR entries, the ability to copy and paste (and script) the
commands can be hugely time saving
The LCDDX commands are used initiate, end and print the tables that are used to
configure the major parts of LCR. The Initiate command has the most available parameters,
which include:
LCDDI:TAB=[,ENTRY=] [,TRC=] [,PRE=] [,CONF=] [,ACCT=] [,MIN=] [,MAX=] [,ACF=]
[,FRCT=] [,TOLL=] [,TZONE=] [,CBCS=] [,BTON=] [,TNS=] [,OSA=] [,OPT=]
The most commonly used parameters are as follows:
TAB = Table name.

ENTRY = Number to be analysed.
& is allowed for this parameter.
TRC = Number of leading digits to delete.
If the parameter is omitted, No digits to delete is assumed.
PRE = Digits to insert at beginning of number.
If the parameter is omitted, No prefix digits is assumed.
CONF = Conflict number flag.
This is set to Y if the ENT or NLT number is a conflict number.
ACCT = Account Code information.
This applies to the DNT1 & 2 tables. Used to specify that an account code is
required for this entry to be used.
If the parameter is omitted, Never require account code is assumed.
MIN = Minimum number of digits in analysed number.
MAX = Maximum number of digits in analysed number.
ACF = Area Code flag.
This is used with the LCLDI command. It can be used to insert the area code
into the dialled number
If the parameter is omitted, Do not prefix with own AC is assumed.
FRCT = Fictitious Route Choice Table
This is used with the DNT1 & DNT2 entries to link with the FDT table entry
TOLL = Toll restriction indicator.
If the parameter is omitted, it is assumed that the call is allowed for all TCD
categories.
CBCS = Call By Call Service number.
This specifies the ISDN service number to be requested
BTON = Type of external B-number.
Used to specify the dialled number type (National, local public etc.)
If the parameter is omitted, the type of number will be unknown.

TNS = Transit Network Selection.

Used when MX-ONE Transit Networking is in use. This specifies the routing
access code for the transit network
If the parameter is omitted, No Transit Network Selection, is assumed.
OSA = Operator System Access. Call operator in chosen network.
This would provide the Operator Access code that would be used on the
destination network (rather than delivering the call direct)
If the parameter is omitted, No Operator System Access, is assumed.
TZONE = Time Zone
This specifies the time zone when using Time based LCR. This parameter
must be set to 1 for syntax reasons even when this feature is not being
used.
For example :
This command will add the number 90123411122 to the External Number Table, truncate
the first 9 digits, and add 5 to the remaining digits (22 plus any further digits). In this case
the resulting number is now internal and is routed accordingly.
LCDDI:TAB=ENT,ENTRY=90123411122,TRC=9,PRE=5;
This pair of commands will create an FDT table entry (which adds the route access code
71) and then add the number 901146455 to the Exceptions table, truncate the first digit (9)
and prefix it with 019 and then complete it with the prefix specified in the Fictitious table
entry 27.
LCDDI:TAB=FDT,FRCT=27,TZONE=1,PRE=71;
LCDDI :TAB=DNT1,ENTRY=901146455,TRC=1,PRE=019, FRCT=27,
TOLL=111011100000000,BTON=0;
The second group of commands allow LIM data, needed to support LCR, to be configured,
ended and printed. The command is used to define the code for that area in which a
specific LIM is situated. It is also used for defining a default external destination for the
same LIM for routing of calls if no match is found in the LCR analysis tables. The Initiate
command is mentioned again:
LCLDI :LIM=...,AC=,DEST=;
LIM = LIM-number.
&, && and ALL are allowed for this parameter.
AC = Area Code.
The Area code to be prefixed if required
DEST = External destination.
The default route access code to use when no LCR match is made.
For example, the command below would place LIMs 11 & 12 in area code 208 and would
use route destination 15 if there is no LCR match.
LCLDI :LIM=11&12,AC=208,DEST=15;
5-25
Lab 1 - Configuring Simple Least Cost Routing

Number Conversion
The Number Conversion service within the MX-ONE also include the ability to
define/change the ISDN layer 3 Bearer Capability and High-Level Compatibility facilities as
well. Number conversion is used for many tasks but the most common is to convert the
public PSTN DDI numbers that are linked to the incoming routes on the MX-ONE into
internal extension numbers. This is necessary to ensure a direct dialled number is delivered
to the correct MX-ONE extension number rather than going via an Operator / Attendant.
The service is based on a number of programmable data tables, which are initiated,
erased, and printed using commands or using the SNM .
It is possible to convert the following numbers:
Received B-number
Sent A-number
Sent connected number
Received A-number
Received connected number
Conversion is performed whenever a number is sent or received to or from the network,
independently of the type of signalling system. The number conversion can be made for the
whole system or depending on the route number of the route that delivers or receives the
call.
What can make number conversion more complicated is that for each of the conversion
types listed above, it is possible to provide different conversions or translations based on
the number type. These can be:
Unknown public number
International number
National number
Network specific number
Local public number
Unknown private number
Local private number
Level 1 Regional number
Therefore, in order to convert a number (especially received/inbound) it is important to
know the number type labelling the system at the other end of the route is using.
If using the command line, the commands used to manage number conversion are
number_conversion_intiate, number_conversion_print & number_conversion_end
Note these commands, whilst of Linux style, were added very early on in the life of the the
MX-ONE system and therefore use the older single hyphen syntax for all parameters. e.g.
number_conversion_initiate -conversiontype 0 -numbertype 6 -entry 28 -truncate 2 -pre 57
This will convert a local private incoming number beginning with 28, removing the first two
digits and replacing them with 57. i.e. 28011 is the number arriving via the incoming route.
This would be converted to 57011.
It is also possible to use SNM to initiate number conversion. This can be easier as the
conversion type and number type are selected from lists rather than specifying a numerical
value.
5-27
Using SNM to configure Number Conversion

Using the web GUI can provide a more gentle introduction to configuring number
conversion than the command line. It is also a better way to view existing programming
regardless of how it was originally entered.
SNM allows an administrator to add entries to the various conversion type tables. The
number conversion options are found under Number Analysis / Number Plan
The main screen list a variety of search options. Remember these options are only for
filtering the view of existing programming.
1. To create new number conversions just click the Add button and click on the Type
of Conversion drop down to see the choices. We will choose Received B number

2. Now enter the number that will be received on the incoming route. We use
01222152 in this example. Then click Next.
3. On the second page, choose the number type (Unknown public in this case as we
are assuming the number has come from the PSTN carrier), enter the number of
digits to truncate from the received number and the digits to add to the remaining
digits after truncation. It is also possible to continue the conversion, change the
number type and restrict the conversion to a specific route number but these are not
necessary in this case.
4. The system confirms the successful number conversion.
5-29
5. Finally change the Number Type to All, leaving the Conversion Type as All to
display all number conversions programmed.
Note that on a large system this could include many 1000’s of entries. Only the first
200 are shown. Use the other search fields to filter the search.
In this case we can see the programmed Number Conversions. Use the table
heading to sort the results differently.
6. After the number conversions have been defined, test that they are working
correctly with live calls. If the conversion does not work, verify the received number
and the number type are correct.

Number Conversion Bulk Upload

The SNM web page also provides a method for importing larger volumes of number
conversion data. Using the normal method, only 5 entries can be added per page. The
Upload feature provides a Microsoft Excel based spreadsheet template that can be
completed offline and then imported into the MX-ONE via the screen below.
The Excel template looks like this:
5-31
Lab 2 - Configuring Number Conversion

Fault locating & Recovery
6
Objectives
 Know what log files are important and where to find them
 Understand the Fault Location Flow used by Product Support
 Have a list of Fault Codes that you can use as future reference
 Be able to repair & recover an MX-ONE system after faults and
failures

Overview
This module will give you an introduction to the different services and tools that are available
that may be helpful in locating faults in the MiVoice MX-ONE Service Node. We also look at
the methods of recovering an MX-ONE system after faults caused by hardware or software
failures.
Several commands can be used on the MiVoice MX-ONE to check and/or locate problems in
the system. The commands are broken up into several categories as shown below:
• Alarm log: Use the command alarm -p to print (list) alarms in the alarm log
To update the alarm log with an alarm or to put in extra information regarding a
specific alarm, use the command alarm_noticed
• Diagnostic history log: Use the trace command
The trace command allows the tracing of messaging communication within and
between program units
Use trace -print 0 to clear the history log
• System Status: Use the status command
Use status -system to see the operational history and queue
Use status -lim to see the start phase history
Use status -unit to see program unit statuses
Use status -interlim to see the status of the links between servers
Use status -comfunc to see the distribution and active/passive state of common
functions
• System Logs: Refer to the Logs section later in this module
• Program unit information (version, type): Use the pu_info command
The following utilities may also be useful during troubleshooting:
• The pu_name command translates from program unit number to program unit name
Caution: Using the trace and trigger commands may degrade system
performance.
When a fault has occurred, it may be necessary to recover the system as per the operational
directions from the ADMINISTRATOR USER'S GUIDE.
6-3
Logs
System Logs
The system logs used by the MiVoice MX-ONE Service Node are based on the newer
Linux/Unix system logging service called journald as most services are now managed by the
systemd mechanism. Journald also provides protection against filling your hard drive with log
files.
Log Entries
Whilst the traditional syslog logs are still present (/var/log/messages &
/var/log/localmessages) their content, especially /var/log/localmessages, is majorly reduced.
Instead now in SLES12 the journald service is used to record events about system
services. These log files are stored in the /var/log/journal directory but they are no longer
text files.
To read these log files the command journalctl is used. By default this command shows the
entire log paged for readibilty. There are numerous parameters that can be used with the
command. These can be displayed by running the command
journalctl --help
Some of the most useful versions of the command are:
journalctl --no-pager
This displays the whole log in one go. This can then be piped to a grep command for
searching or redirected to a file for viewing in an editor like mcedit.
jounalctl -r
Displays the log showing the most recent entries first
journalctl -f
Displays the last 10 lines and then continues to display new entries as they arrive. Like the
tail command.
A typical portion of a journalctl output is shown in graphic below:

Log Configuration
The configuration of the Linux/Unix system log uses the journald infrastructure which is
controlled by the /etc/systemd/journald.conf configuration file.
Note: journald can be customized but this is optional and must be done
manually after installation. In order to do this, you require a good working
knowledge of Linux/Unix.
6-5
MIVoice MX-ONE Service Node Manager Logs
Log Settings
Log settings should not be change without the explicit direction from Mitel Product Support.
The material provided is for your information only.
When faults are traced, there are logging level settings that can be changed to provide more
information in the syslog.
Maintainers and administrators should know log locations and should not change the
locations without direction from Mitel Product Support.
To change logging level settings, the setloglevel.sh command should be used. There are 4
levels of logging for the service
• i = Info (Lowest level) Default value

• d = debug (Medium level)
• t = trace (Highest level)
• c = check (Verify current log level)
Logs to verify:
/opt/jboss/server/default/conf/log4j.xml
All files in the /opt/jboss/server/default/log folder

Fault Location Subflow
6-7

6-9
Subflows
Subflow 1: Collection of Further Information

When an alarm has been received, try to gather as much information as possible about the
nature of the fault and the status of the installation.
This advanced collection of data, in certain cases, can facilitate the elimination of faults
reported by a user. The advanced collection of data could indicate that it's a handling
(procedural) fault.
In other cases, the collection of this data could indicate to the technician what tools and
instruments are required. Ideally, the issue could be resolved in only one visit.
Fault Report from Extension

Collect the following data:
• Type of extension
• Extension number
• Whether the fault has occurred once or several times
• A detailed description from the person reporting the fault
With the person reporting the fault, verify:
• That the correct procedure is being used

• That the extension is authorized to use the facility in question
From the logbook (or similar) obtain:
• The correct address of the installation (customer's address)

• The customer's contact person for keys (if required) or other assistance
• Status of the PBX
Fault Report from the PBX Operator

Collect the following data:
• A detailed description of the fault and at what stage and time the fault arose
• Find out if this is the only disturbance that has occurred
• Find out from the operator if any work has been done recently in the exchange
If the PBX operator has received only one alarm class on the console, only relevant
questions should be asked.
Ask the operator:
• If the fault also affects other extensions with, for example, the same first digit

• If the fault concerns external lines and whether the entire route has been put out of
action
Request help with the following:
• The correct address of the installation (Customer's address)

• The costumer's contact person information
Ascertain from the logbook:
• The status of the PBX
Alarm on the alarm panel

If the PBX operator or other responsible person at the customer site is available, it is
advisable to contact this person and request additional information.
If it is non-office hours, using operating routines, ascertain how important the alarm
class is.
Ascertain from the logbook:
• The correct address of the installation (customer's address)

• The customer's contact person for keys (if required) or other assistance
• Status of the PBX
6-11
Subflow 2: Initial Fault Locating

With the Initial Fault Locating procedure, in certain cases, it is possible to avoid traffic
disturbances caused by route blocking or the inability to make a call.
Fault Locating
Attempt to make contact with the person responsible for the telephony traffic at the
customer or, for smaller PBXs, the PBX operator. Question this person fully, in order
to obtain as complete a picture of the fault as possible.
Find out:
• If further faults have been reported

• In case it's an extension fault, what the geographical locations of the extensions
affected are
After this information is available, fault locating in the MiVoice MX-ONE can start.
14. Examine the PBX fault diary/logbook to learn whether comments from previous visits
by technicians can provide guidance
15. Commence fault locating by checking a number of peripheral matters:
Verify that power exists and if it does, verify the level.
Verify that no fuses have been blown.
Verify that the cabling has not been affected negatively.
Verify that no manual blockings have taken place.
16. Continue the fault locating process by using an I/O terminal
Subflow 3: Print Alarm List or Log

Enter the command alarm to print (list) alarms in the alarm log.
Subflow 4: Individual Fault Code Flows

All fault locating directions for fault codes from the logbook can be found in their respective
groups in the Fault Codes section later in this module.
Subflow 5: Verify if it's a Software or Hardware Fault

The fault locating directions flows for the fault codes included in this version require no extra
verification, that is, each flow for each fault code contains all measures.
Subflow 6: Verify that the Fault is Unambiguous

The fault locating directions for the fault codes included in this version contains all the
information necessary for the identification of the faulty unit

Subflow 7: Block HW Unit

The hardware (HW) unit can be the Media Gateway or a printed board assembly (board) in
the MiVoice MX-ONE classic.
Subflow 8: Replace HW Unit

Before replacing the unit, ensure that no functions are associated with it and that there is
currently no traffic on the unit.
Subflow 9: Restart HW Unit

Restart the unit as per the ADMINISTRATOR USER's GUIDE.
Subflow 10: Verify Functions of the Replaced HW Unit

To verify that the replaced unit is working properly, use normal routine procedures.
Subflow 11: Deblock HW Unit

For detailed instructions see the ADMINISTRATOR USER's GUIDE.
SubFlow 12: Acknowledge the Alarm

Enter the command alarm to erase (reset) alarms in the alarm log.
Subflow 13: Reporting

The importance of reporting cannot be emphasized enough. A correct report is the best
feedback to the responsible design instance. A good report is also an invaluable aid the next
time fault elimination takes place.
Measures
After the fault has been dealt with and an alarm acknowledgement has taken place,
all measures are to be documented.
• Document the fault in the diary or logbook according to existing routines

• Write a detailed fault report
• Send the fault report on the relevant instance so that Mitel receives a copy
Before leaving the location, the following measures must be taken:
• Obtain new prints in respect of the altered data and file these in accordance with the
applicable routines
• Inform the person in charge of the system about the measures that have been
executed in the system
• Set the alarm so that it is issued to the PBX operator and exterior alarm points
6-13
Subflow 14: Measures to take if it is not possible to communicate

with the MiVoice MX-ONE
Before restarting the faulty MiVoice MX-ONE Service Node check:
When connected via the console:
• That the I/O terminal is set up correctly

• That the cable between the I/O terminal and the MiVoice MX-ONE Service Node is the
one specified in the documentation, and that there is no visible damage
• That power exists to the relevant units.
Should the above not have the desired effect, try the following:
• Change the virtual terminal (when using a console) and make a new attempt.
• Use the ping command to check if the server is alive.
As a last step, restart the MiVoice MX-ONE Service Node
Subflow 15: Restart

Attempt to restart the MiVoice MX-ONE using the operational directions in the
ADMINISTRATOR USER's GUIDE.
Subflow 16: Measures to Initiate when Irrelevant Information is

Obtained
In the case of a physical MiVoice MX-ONE system, if the information obtained from the I/O
terminal is unusable, check the following:
• That the I/O terminal is set correctly (consult the I/O terminal instructions)
• That the cable between the I/O terminal and the MiVoice MX-ONE Service Node is the
one specified in the documentation, and that there is no visible damage
If nothing seems wrong, the I/O terminal and the cable are to be replaced one by one. Check
the function after each replacement.
As a last step or if you're using a Virtual MiVoice MX-ONE, restart the MiVoice MX-ONE
Service Node.
Subflow 17: Measures when the above steps do not work

If the Media Gateway has been replaced but still does not function after verification, check
whether:
• A restart of the new unit has been carried out to allow the system to discover the new
unit
• The NFS server is active on the MiVoice MX-ONE Service Node
• The front cable (if any) is connected correctly
• The correct IP address is set on Media Gateway interface eth0 (If not changed, address
192.168.1.1. is used)

MX-ONE Classic:
If a relevant board in the MX-ONE Classic has been replaced but the unit still does not
function after verification, check whether:
• A restart of the new unit has been performed to enable the system to discover the new
board
• The device board is placed in the correct position
• The front cable (if any) is connected correctly
• A good contact with the backplane has been obtained. Check the board contacts in the
backplane
• The board receives the correct voltage
6-15
Fault Codes
The events that occur are stored in the system alarm log. Each type of event has its own
unique fault code. For the fault code to be stored in the alarm log it is necessary that it be
assigned an alarm class (1-4). The alarm class states which priority an alarm has. Alarm
class four has the highest priority.
The alarm that has been acknowledged by the system has an alarm class of zero.
By command it is also possible to define how many alarms may occur in a specific alarm
class before an alarm in the next alarm class (incrementation alarm) is generated.
The following alarm domains exist:
• 0 MX-ONE compatible alarm

• 1 SES - Service System
• 2 ACS - MX-ONE (Advanced Communications System)
• 3 Other MX-ONE Service Node
• 4 WBM - Web Based Management
• 5 Media Gateway.
The following is valid only for Domain 0 - MX-ONE compatible alarms. The fault codes are
divided into two different alarm groups:
• SES Operational and maintenance system (fault code 1-255)

• ACS MX-ONE (fault code 257-511)
Fault codes 1-255 refer to the Service System (SES). For explanations, see Service System,
SES, fault codes 1 - 255
Fault codes 257-511 refer to the Advanced Communication System (ACS). For explanations,
see Advanced Communications System, ACS, fault codes 257 - 511.
On delivery, the fault codes are assigned an alarm class and an alarm class after system
acknowledgment. An incrementation alarm has also been set.

Domain 0 - MiVoice MX-ONE Compatible Alarms
Service System, SES, Fault Codes 1 - 255
6-17

6-19
Advanced Communications System, ACS, Fault Codes 257 - 511

6-21

6-23

6-25

6-27

Domain 1 - SES
6-29

Domain 2 - ACS
6-31
Domain 3 - Other MiVoice MX-ONE Service Node

Domain 4 - WBM - Web Based Management
There are currently no alarms defined in Domain 4. This was kept for future development,
but has not been used as yet in 7 versions of the MX-ONE!
6-33
Domain 5 - Media Gateway

Lab 1 - Reviewing Logs and Alarms
6-35
Recovering an MX-ONE System
In the event of a problem with the MX-ONE system or one of the servers/LIMs, there are
many ways of recovering from a fault or failure of a component. We will look at the following
processes:
Restoring a configuration using backups / config_mirrors
Restoring a configuration using a safety backup
Replacing a failed server/LIM using the recovery process
Note: If an entire exchange has been lost or severely compromised a PC-

REGEN (as discussed earlier in the course) can be used to rebuild the data
on a system once the servers have been rebuilt. If any of the names, DNS or
IP address information is changed, then the PC-REGEN scripts will need to
be manually edited to reflect this change.
Restoring using Backups / config_mirror

Backups are a standard administrative event in the life of an MX-ONE system. Three
backups are stored on the system, regardless of whether the data_backup command or
SNM/PM backup mechanism is used.
When there is inconsistency in the exchange data or changes have been made which need
to be undone a restore from a data backup should be performed.
If the command line was used to perform the backup then the data_restore command
should be used to restore exchange data. The command can be executed on any MX-ONE
Service Node.
If SNM or PM (via the sub-system) was used to create the backup, then SNM should be
used to perform the restore, to ensure that the SNM postgresql database is restored as well.
Either method will restore the Cassandra database to the state it was in when the backup
was taken.
Restoring the data on an MX-ONE system is not normally traffic affecting , except for
changes between the current and restored data set.
If there are problems that a restore of a recent data_backup cannot solve, it may be necess
to restore from a configuration mirror. The configuration mirror saves files and settings
stored in text files as well as the data stored in a normal backup.
Use the command config_restore to restore a configuration mirror from MX-ONE Service
Node 1 to all MX-ONE Service Nodes. The command is executed on MX-ONE Service Node
1 and the most recent configuration mirror is used.

Restoring a configuration using a safety backup

If an MX-ONE Service Node has major issues with it’s configuration (for example, mismatch
between exchange data and configuration files), or if the MX-ONE Service Node has
reported a missing or faulty exchange data file or configuration file, it may be necessary to
restore from a safety backup.
A restore from a safety backup may be required when a system needs to be taken back to
point in time before the most recent data backups or configuration mirror.
It is always recommended to restore all the files from the safety backup since only restoring
a subset of files is likely to cause inconsistencies. The safety backup should match the
installed MX-ONE Service Node programs.
1. Make the correct safety backup file accessible from MX-ONE Service Node 1. This may
involve uploading the file from a remote machine using WinSCP.
2. Check the safety backup and make sure that the files that need to be restored are
available in the backup.
3. On Server 1, change the working directory to / (root directory).
Note: It is very important to change the current working directory to
/ (root) to prevent the safety backup from being restored in the wrong
directory. The safety backup will always be restored to the current working
directory (according to the pwd printout).
When accessing MX-ONE using ssh (i.e. PuTTY), "su -" should be used. This
is because "su -" switches to the superuser and sets up the environment so
that it acts like you have logged directly into the / root directory.
Logging in using just "su" switches to the user named root but doesn't
simulate directly logging in to ~ root.
e.g.
4. List the files in the safety backup with the command tar -t --file=xxx, where xxx is the
safety backup file.
It is possible to find the differences between the safety backup and the file system
with the command tar -d --file=xxx (current working directory must be / ). For more
information about tar, use the command tar -help
5. To restore all the files from the backup and overwrite the existing files, enter the
command: tar -x -p --overwrite -v --file=xxx
6-37
6. Restore the configuration mirror from MX-ONE Service Node 1 to all MX-ONE Service
Nodes by the command config_restore.
7. Restore the data backups by the command data_restore.
8. Enter the command start --system to coordinate the system.
9. Enter the command restart --system to restart the system.

Replacing a failed server/LIM using the recovery process

If the event of failed server/LIM, due to hardware failure or complete corruption it may be
necessary to replace and rebuild the failed LIM. Here we look at the procedure for this.
This process can only repair one server at a time. In the event of the failure of more than one
server, they must be repaired one at a time.
These requirements apply when repairing a server using the Repair Server script:
IP addresses of the failed server
An up to date copy of the configuration mirror (the /mxone/mirror/ directory.) The
mirror for each server is a zipped file i.e. mxone_server1.tar.gz.
A Recovery Image (on USB, recommended), .ova/.ovf image for virtualized system or
installation files for the SUSE Linux operating system and the MX-ONE Service
Node.
mxone_admin user credentials.
root user credentials.
The new server must have same amount of memory and network interface
configuration as the server that should is being repaired.
The installation media must have the same version as the installed system (that
needs to be repaired).
If SN Server 1 (LIM1) is the faulty server that needs to be recovered, a new license
file has to be ordered.
Note: If using physical servers with a physical fault. It may be possible to use
the hard drives from the failed server in a new machine. In this case the new
network interfaces would need to be associated with the logical Linux eth0 /
eth1 interfaces using Yast. If the server is LIM 1 a new license may be
required too.
If using Virtualization it may be possible to restore the virtual machine from a
snapshot. However, care must be taken to not cause synchronization issues.
In this scenario, for safety, all VM LIMs in the system should be restored to
snapshots taken at the same time.
Restoring a Server in a Multi-LIM System
The process to recover an MX-ONE suffering from a failed LIM is as follows.
1. First the failed server must be replaced with a new system.

If using a physical server, then this should be rebuilt using the Recovery DVD
mechanism. The .iso file should be downloaded from Mitel Connect. It is important that
the new system is built using the same software version as that running on the remaining
working servers.
If using virtualized servers, it should be built from the correct .OVA/.OVF file
2. Now return to a working server. Normally this would be LIM 1, however if LIM 1 is the
failed one, another server can be used.
Run the mxone_maintenance tool using the sudo command and choose the repair
option.
sudo -H /opt/mxone_install/bin/mxone_maintenance
6-39
3. Now choose the option to generate_netconfig and choose the server that has failed
from the list. This will generate the configuration file that will automatically populate all of
the options normally entered during the net_setup process when commissioning a new
server.
Note: The option generateAll could also be used as this creates all the files for all
servers.

4. The files created by the process are shown below (in Midnight Commander). This used
the GenerateAll option. The relevant file (for the failed server) should be downloaded
and copied to removable media. For a physical server, a USB drive is preferable. For a
virtual machine, an .iso file may need to be created as the file needs to be made
available on the new server immediately on running the net_setup command, at which
point no IP networking will be configured.
5. Go to the new server and logon as root (pw changeme) and mount the USB / .iso
device on the new server using commands like those below. The device names may
vary depending on the hardware configuration of the server
o mount /dev/sdc1 /mnt
o mount /dev/cdrom /mnt
6. Now launch the net_setup tool, choose the keyboard and timezone settings and then
choose the Repair option. This will launch the folder browser which can be used locate
the config repair file.
6-41
7. After the system reads the configuration file it may ask to confirm the FQDN on the
server to repair. Choose the correct name.
8. After checking the config and setting the network configuration, the process will ask for
the passwords for the three default MX-ONE users. After these have been entered, the
system will start to unpack the Telephony Service installation files.
9. After this has completed the new server displays the message below and the repair
continues back on the working server.
10. Returning to the working server and mxone_maintenance. Choose the repair option
again and this time choose Repair Server

11. Select the server to repair from the list, confirm the selection and finally enter the
mxone_admin password for the server.
12. The system will now run the repair script completing the restore of the data and
settings onto the new server and starting the services. The system confirms the repair
at the end of the process and the multi-lim system should now be fully functioning
again.
6-43
Restoring a Server in a Single LIM System

In the event of the failure of a single LIM system (with no redundant server), the repair
process is much more straight forward.
Note: This relies on the existence of a safety backup which was stored away from the server
that failed.
1. Install and configure a new server using the same configuration as the old one. This
includes: IP addresses, hostname, DNS domain name, market etc.
2. Now we must restore system data from safety backup.
o Upload the most recent safety backup to the new MX-ONE Service Node using
WinSCP or similar to a suitable folder under the /tmp directory.
o Check the safety backup has been uploaded correctly.
3. On Server 1, login with root user credentials and change the working directory to /
(root directory).
4. Note: It is very important to change the current working directory to / (root) to prevent
the safety backup from being restored to the wrong directory. The safety backup will
always be restored to the current working directory (according to the pwd printout).
5. List the files in the safety backup with the command
tar -t --file=xxx
where xxx is the full directory path to the safety backup file.
6. To restore all the files from the backup and overwrite the existing files, enter the
command
tar -x -p --overwrite -v --file=xxx

7. This process will restore the configuration mirror files to the correct locations on the
disk. There is no need to use config_restore in this case as this is a single LIM
system, so there is no need to distribute them to other servers.
8. Restart the system database (Cassandra) and the MX-ONE Service Node, key the
command
sudo -H /opt/mxone_install/bin/mxone_maintenance
9. Select the option repair / restart_db_and_serviceNode

10. A new license file must be ordered to match the new server. Use the
mxone_maintenance tool to obtain the new hardware id and install the new license
when it is received.
11. Your system should now be operating correctly.

Optional Lab 2 - Recovering a Failed Server
It may not always be possible to perform this Lab, or may be left until the end of the course.
Your Instructor will guide you.
6-45
Security
7
Objectives
 Understand Certificate Management

 Understand how VoIP security works in the MiVoice MX-ONE

Security
Certificate Management
Certificates are used to authenticate the communicating parties in a networked system. In

the MiVoice MX-ONE, the certificate handshake is carried out via TLS.
OpenSSL is used by the key management scripts and is also used as a component doing
the TLS handshake and handling the encoding/decoding of messages. When using SIP
security, OpenSSL is handled via the SIP stack, reSIProcate is used for securing the SIP
signalling. For more information. please visit http://www.openssl.org/.
Certificates and Key Management

x509 v3 is the standard used for the certificates. According to this standard, there are two
types of certificates:
• Certified Authority (CA)

• Signed Certificate
The Certified Authority has the X509v3 extension "X509v3 Basic Constraints" set to
CA:TRUE while the same parameter for the signed certificate is CA:FALSE.
The root CA can sign another CA and thereby create a chain of trust. TLS clients trusting the
CA will thereby trust the servers signed by the intermediate certificate. The certificate
management tool can't create a chain of trust between CA's, but it supports the importing of
intermediate CA's and root CA's. The MiVoice MX-ONE Enterprise CA is only a root CA.
Both client and server certificates are signed certificates. In 802.1x the phone will have client
certificates as they are validated as radius server clients. The MiVoice MX-ONE Service
Node is validated as a server, in relation to other servers or phones.
The certificate management tool allows you to either create a generic wild card certificate
distributed to all the MiVoice MX-ONE servers (auto) and/or a local certificate for a certain
server which can use a certain root CA. This may be required for certain TLS SIP routes.
The MiVoice MX-ONE stores certificates in the native format for openssl, PEM, which is an
encode 64 format. The format is easily verified when looking at the file using an ASCII editor
since the certificate bob is wrapped with ------BEGIN CERTIFICATE---- and -----END
CERTIFICATE-----. The PEM file used by the MiVoice MX-ONE is a "PEM with Certificate
chain" stored at /etc/opt/eri_sn/certs/eri_sn_cert.pem. This file includes, in the following
order, the server certificate private key, the server certificate and the CA.
TLS Handshake
A certificate is used for public-key cryptography, where each certificate has a private key and
a public key. The sender (client) of a message will start a TLS handshake in which the initial
message is encrypted with the server certificate public key. Only the owner of the server
certificate private key may decrypt the message. The initial message may include a
symmetric secret session key, which will be used for this TLS session. Session keys are
required for persistent TLS on phones to work, the server will reuse the session originally
setup by the phone when sending messages.
A simple TLS handshake is where only the client checks the validity of the server. This
makes sense when the client is a web browser where the focus is to protect the web client.
In order to better secure the MiVoice MX-ONE server it makes sense to validate the client’s
certificate in the TLS handshake
7-3
Mutual TLS (MTLS) is a TLS handshake where the TLS server sends its server certificate as
normal, but also asks the client to send its certificate. In a SIP route, both endpoints will have
certificates and can honour this handshake, but IP phones that uses persistent TLS only
need the public root CA and have traditionally not made use of MTLS even though it is
possible to enable it for some SIP clients.
The MiVoice MX-ONE SIP stack will not support MTLS, but since a TLS connection is
terminated at the destination of the IP header, an SBC or Security gateway may be
terminating TLS and can direct the package according to the destination in the SIP request
URI header. An SBC or security gateway may support MTLS for SIP phones if the client
certificate is validated based on the fact that it is signed by the same CA as the SBC server
certificate and that it is not expired.
The SIP stack has the same check for the client certificate as it would towards a server
certificate, which is to validate the destination against the DNS. As phones usually acquire
their IP address via DHCP, the IP can't be part of the client certificate (CN or SAN:IP).
In the SIP stack, TLS is configured per LIM. In order to avoid conflicts with phones, you can
setup a LIM dedicated to a SIP route were TLS is required. LIM configuration,
/etc/opt/eri_sn/ip_telephony.conf { TlsClientVerificationMode: none|optional|mandatory }.
For an outbound message to a SIP route, the SIP stack validates the other party’s server
certificate in a TLS handshake. An outbound SIP message request URI host must be
resolvable in a DNS server and the host shall match the certificate Common Name (CN) or
Subject Alternative Name SAN:IP or SAN:DNS of the TLS destination. If the request URI
host is an IP address, the certificate of the TLS destination must contain that IP address in
either CN or SAN.
When using an auto generated server certificate from the MiVoice MX-ONE, the SAN:DNS is
a (Fully Qualified Domain Name) FQDN format, which shall match the server’s DNS A or
AAAA Record pointing to its IPv4 and IPv6 address respectively.
Another option is to use DNS SIP SRV Records. The SIP service request, _sip._., will result
in a list of access points offering SIP service. In the MiVoice MX-ONE, this would be a list of
LIM IP addresses or FQDN DNS names.
Preparation and Work Process

In the MiVoice MX-ONE, all certificate management is handled via the mxone_certificate
and mxone_maintenance script suite which MUST be run with root access. The certificate
handling for the MX-ONE web based management is part of "webserver_config", which is
defined in the CPI. The certificate handling for securing call control signalling, phone
configuration and phone key management is run from mxone_certificate or Certificate
option from mxone_maintenance and is further described in this module.
Note: Consult your PKI or IT/IS department as they may want to sign your
server certificates instead of using a MiVoice MX-ONE CA.
The output of the certificate management tool is to activate TLS for the MiVoice MX-ONE
VoIP. What certificates to create are described further in this section under "Strategies for
Certificate Handling". How to execute these strategies is also described further in this
section. No extra preparation is needed to use the HTTPS feature for XML keys on SIP
phones.

Security
Additional preparation for VoIP communication when certificates are

activated.
1. The license VOIP-SECURITY is not enabled in trial licenses due to export control on
media encryption. For SIP the license is only required for secure media (SRTP).
Check whether VOIP-SECURITY is set to yes using the license printout from
Provisioning Manager / System /Subsystem:
2. Follow the instructions in this module to create the server certificate

3. When a certificate is created by the script, the CA is extracted and stored at
/etc/opt/eri_sn/certs/ca.pem.
Procedure for TLS on terminals: No handling is required if a commercial CA
(Verisign, Thawte etc), preloaded in the phone FW was used to sign the server
certificate. Otherwise the CA, /etc/opt/eri_sn/certs/ca.pem, needs to be copied
to the key storage of the terminal. This is usually the same directory as where the
terminal’s configuration files are stored. See Installation Instruction for your SIP
model. As the terminal will normally only have a CA (not a client certificate), the
TLS method to be used is ‘persistent TLS’. This means that the TLS session
setup by the client is kept as long as the terminal is logged on and that negotiated
session keys are reused by the server when signaling to the client.
Procedure for TLS on route (trunk): The same root- or intermediate certificate
needs to sign the Call Managers’ server certificates accessing the route.
4. Enable secure VoIP by using SNM / Telephony / IP Phone / Media Encryption
or by entering the command below:
>media_encryption_enable -type extension

(and any other type of end-point that should be secure "media_encryption_enable -
type route, media_encryption_enable -type intermgw").
and then perform a backup followed by a reload --system (or if only to enable SIP
over TLS, just run, reload -u SIPLP.
5. Check that the MiVoice MX-ONE has TLS ports activated:
SIP - port 5061 is used for both extension and trunk.
Use the following command to list the listening TCP ports (TLS is based on TCP):
>netstat -ltn tcp :5061 LISTEN
7-5
Strategies for Certificate Handling
The MiVoice MX-ONE only accepts inbound SIP messages that are directed to the system.
The official identification of the MiVoice MX-ONE system is the LIMs IP addresses and the
LIMs host names, limX, where X is the LIM number. E.g. If a SIP phone logs on to LIM2 in
the domain mx.corp.net, it shall be addressed as lim2.mx.corp.net, matching the wildcard
certificate *.mx.corp.net.
A wildcard certificate only covers one level of sub-dmains. As the server certificate is to be
used for the MiVoice MX-ONE LIMs only, the system should be a sub-domain in the
corporate network.
Setting up a SIP route

For SIP routes, both end points need to trust the CA, signing their server certificates.
If your company has a Public Key Infrastructure (PKI) responsible for authentication of your
network elements, choose to send a certificate request to their CA.
If two MiVoice MX-ONE systems shall have TLS SIP routes between them, one of the
systems shall be chosen to act as a PKI and have the root CA.
The route is setup towards the DNS FQDN of the call manager’s host (For SIP trunks this is
set by the command, sip_route -uristringX), and the TLS handshake will verify that the
server certificate’s CN or SAN:DNS name field matches the DNS FQDN of the destination of
the route.
The default MiVoice MX-ONE server certificate will have the official FQDN DNS name as
SAN:DNS.
If the official FQDN is not known by the DNS server used in the network, the server
certificate must match what the LIM is addressed as.
Assuming that the FQDN used for a LIM is malmo.mx.corp.net, this must be a domain
accepted as being part of the MiVoice MX-ONE, sip_domain --local -domain
malmo.mx.corp.net. If the other SIP route server supports SAN, then the default MiVoice
MX-ONE System server certificate may be modified and you can add an extra SAN:DNS:
malmo.mx.corp.net. From the default config file you may make the changes required
before creating the CSR based on the modified configuration file.
A valid approach if there is no DNS is to assign the server certificate using the IP address of
the MiVoice MX-ONE Service Node as CN. Per default SAN:IP is already set in a MiVoice
MX.One server certificate.

Security
Execution
This section describes the headings in the certificate option of the mxone_maintenance
tool.
Create and Install a default certificate and activate TLS

auto: Create and install a default certificate and activate TLS
This script combines the default choices of the following individual choices:
• Manage Root Certificate -> Create Root Certificate

• Manage Server Certificate -> Create Server Certificate
You will be prompted to enter a root CA password and a server certificate password. The
certificate will be valid for 364 days for both the root CA and the server certificate.
The root certificate created is an Enterprise CA (MXOneEnterpriseCA), which signs the
server certificate in the next step.
Per default, the server certificate will be the same for all LIMs. The Common Name (CN) is
*.<mxone-domain>, e.g. a wildcard certificate. All LIMs FQDNs and IP addresses are set in
the extension, Subject Alternative Name (SAN), IP and DNS.
When the certificate is activated, you are asked to check what is described in the
"Preparation and Work Process" section above.
Create a ROOT Certificate

Manage Root Certificates -> Create Root Certificate
Create or Renew a Certificate

The definition for renewal of a server certificate is that only the expiration dates (“Before” and
“Not After” expiration has occured) are updated. The same procedure applies to updating a
certificate as for installing a certificate. The CA is kept consistent as long as the CA private
key is kept the same.
Create the default server certificate signed by MXOneEnterpriseCA:
• Manage Server Certificate -> Create Server Certificate

Create a server certificate based on manual changes to the configuration file being added to
the signed server certificate:
• Manage Server Certificate -> Create CSR (Certificate Signing Request)

The script will use the certificate private key used earlier or create a new one which is tied to
the CSR. Only this private key can be used with the signed server certificate. The script will
create both the configuration file and a CSR file which is the output of the configuration file. If
the collected data for CN and SAN needs to be changed, you can change the configuration
file and choose “Create CSR from configuration file”.
If your Enterprise CA is installed on a Microsoft Server, you can order a server certificate by
browsing to the server with to http://<your company's enterprise CA>/certsrv
Import of a Signed Certificate

Create a folder on the MiVoice MX-ONE system where you will upload the signed certificates
and the CA using WinSCP.
When using PEM files, you have one server certificate PEM file and a CA PEM file.
7-7
If you were to use a commercial CA or Mitel CA (which Mitel Canada may sign) the CA pem
file actually is both an Intermediate CA and a CA which has a trust chain, where the root CA
has signed the Intermediate CA. The file has two certificates, i.e. two blobs, --BEGIN
CERTIFICATE --, --END CERTIFICATE--
If another MiVoice MX-ONE has signed the certificate, the CA PEM file only contains a root
CA.
The import signed certificate script also supports other certificate formats:
• Chained certificate (*.p7b) PKCS7 in DER format, containing both server certificate and
the CA certificate(s) in one file.
• PKCS12 (*.pfx) which is a complete signed certificate and does not require a CSR. Input
may just be an e-mail as the PKCS12 includes the signed certificate private key.
PKCS12 is mostly used when deploying certificates for clients which can’t create a CSR.
The following two options are used to install the certificates:
• Certificate Management -> Import Signed Certificate

• Certificate Management -> Install Certificate
The output of the installed certificate is /etc/opt/eri_sn/certs/eri_sn_cert.pem and the
configuration file /etc/opt/eri_sn/cert_- password.txt. The PEM encoded file,
eri_sn_cert.pem, contains the following concatenated certificate files in the exact order:
• The private_key obtained during the CSR generation

• The signed server certificate.
• The single or multiple intermediate CA. If multiple, the secondary should be before the
primary
• The root CA.
Note: Depending on your certificate provider, you might have to ensure that
the "-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----”
statements are on their own separate lines in the Allcerts.pem file.

Security
Managing TLS in the MiVoice MX-ONE

In order to enable the use of the installed certificates, you must configure the MiVoice MX-
ONE to use TLS. This is done through the use of the certificate option of
mxone_maintenance. Once started as the root user, you must go to "Manage TLS in MX-
ONE" and then "Configure MX-ONE to use TLS".
To disable TLS, you must go to the same location but this time you will select "Configure
MX-ONE not to use TLS".
Once done, you must restart the services that will be using/not using TLS. This is done with
the following linux command:
reload -u SIPLP,IPLP,TLP65
Alternatively, you can also restart the system which will have the same effect.
7-9
VoIP Security
The IP Phones support a transport protocol called Transport Layer Security (TLS) and
Persistent TLS. TLS is a protocol that ensures communication privacy between the SIP
phones and the Internet. TLS ensures that no third party may eavesdrop or tamper with any
message.
TLS is composed of two layers: the TLS Record Protocol and the TLS handshake protocol.
The TLS Record Protocol provides connection security with some encryption method such
as the Data Encryption Standard (DES). The TLS Handshake Protocol allows the server and
client to authenticate each other and to negotiate an encryption algorithm and cryptographic
keys before data is exchanged. TLS requires the use of the following security certificate files
to perform TLS handshake:
• Root and Intermediate Certificates

• Local Certificate
• Private Key
• Trusted Certificate
When the phones use TLS to authenticate with the server, each individual call must setup a
new TLS connection. This can take more time when placing each call. Thus, the IP phones
also have a feature that allows you to setup the connection to the server once and re-use
that one connection for all calls from the phone. It is called Persistent TLS. The setup
connection for Persistent TLS is established during the registration of the phone. If the
phones are set to use Persistent TLS, and a call is made from the phone, this call and all
subsequent calls use the same authenticated connection. This significantly reduces the
delay time when placing a
call.
Notes:
1. There can be only one persistent TLS connection created per phone.
2. If you configure the phone to use Persistent TLS, you must also specify
the Trusted Certificate file to use. The Root and Intermediate Certificates,
Local Certificate and Private Key files are optional.
On the IP phones, an Administrator can configure TLS and Persistent TLS on a global-basis
only, using the configuration files or the Mitel Web UI.
There is a keep-alive feature for persistent TLS connections only. Administrators can
configure this keep-alive feature using the parameter called “sip persistent tls keep alive”.
When this feature is configured, the phone will send keep-alive pings to the proxy server at
configured intervals. The keep-alive feature for persistent TLS connections performs the
following functionalities:
• After a persistent TLS connection is established or re-established, activate the keep-

alive, which will send CRLF to peer periodically.
• The phone will retry the connection automatically when a persistent TLS connection is
down.
• When a persistent TLS connection is re-established (primary is up or primary is down
and backup is up), refresh registration of the accounts associated with the connection.
• When a persistent TLS connection to primary is down, switch to backup if connection to
backup is working.

Security
Additionally the “sip send sips over tls” parameter allows administrators the ability to
manually configure the IP phones to use either the SIP or SIPS URI scheme when TLS or
persistent TLS is enabled. Disabling the “sip send sips over tls” parameter (i.e. defining the
parameter as “0” in the configuration files) ensures the IP phones use the SIP URI scheme
when TLS or persistent TLS is enabled. Enabling the parameter (i.e. defining the parameter
as “1”) ensures the phones use the SIPS URI scheme in such scenarios. The SIPS URI
scheme is used by default.
Configuring TLS using the configuration files

You use the following parameters to configure TLS in the configuration files:
• sip transport protocol

• sips persistent tls
• sip persistent tls keep alive
• sip send sips over tls
• sips root and intermediate certificates
• sips local certificate
• sips private key
• sips trusted certificates
Note: More information on the file configuration parameters can be found in

the SIP Phone Administrator Guide in Appendix A in the section Transport
Layer Security (TLS) Settings section.
Configuring TLS using the Mitel Web UI

To configure TLS using the phones Web UI, you must enable TLS or Persistent TLS first.
Then you must define the TLS certificate file names that you want the phone to use. Use the
following procedure to configure TLS using the phones Web UI.
7-11
3. Click on Advanced Settings > Global SIP > Advanced SIP Settings
4. In the Transport Protocol field, select TLS or Persistent TLS
Note: If configuring Persistent TLS, you must go to Advanced Settings >

Global SIP > Basic Network Settings and configure the Outbound Proxy
Server and Outbound Proxy Port parameters.
5. Click Save Settings to save your changes
6. Click on Advanced Settings > TLS Support
7. Enter the certificate file names and the private key file name in the appropriate fields.
The Root and Intermediate Certificate files contain one root certificate and zero or more
intermediate certificates which must be placed in order of certificate signing with root
certificate being the first in the file. If the local certificate is signed by some well known
certificate authority, then that authority provides the user with the Root and Intermediate
Certificate files (most likely just CA root certificate).
The Trusted Certificate files define a list of trusted certificates. The phone’s trusted list
must contain the CA root certificates for all the servers it is connecting to. For example, if
the phone is connecting to server A which has a certificate signed by CA1, and server B,
which has a certificate signed by CA2, the phone must have CA1 root certificate and
CS2 root certificate in its Trusted Certificate file
8. Click Save Settings to save your changes

Security
Notes:
• If configuring TLS, you must specify the files for Root and Intermediate
Certificates, the Local Certificate, the Private Key, and the Trusted
Certificates in order for the phone to receive calls.
• If configuring Persistent TLS, you must specify the Trusted Certificates
(which contains the trusted certificate list). All other certificates and the
Private Key are optional.
• The certificate files and Private Key file names must use the format
“.pem”.
• To create custom certificate files and private key files to use on your IP
phone, contact Mitel Technical Support.
Changing the Security Policy

When the security policy needs to be changed in an existing system, the following procedure
should be followed:
1. If the new security policy will be All Secure or All Secure with Exception Type. Check that
all the extensions have the right security exemption parameter value.
You can view this using the extension -p command. Look for the security-exception
parameter and ensure it is set to NO.
If any extensions have the security-exception parameter set to YES, you can change it
using the extension command with the --security-exception parameter.
E.g. extension -c -d xxxx --security-exception no

2. Set the new security policy
3. Unregister all terminals (by extension_unregistration). When the IP extensions then
register, they will get the new security policy activated.
Steps to install and setup VoIP security

1. Install the security certificate for the system. (See the Certificate Management section)
2. Set the Security Policy using the sec_policy command. (This will affect the entire system)
3. Changing the policy will not affect the extensions that are already logged on. For the new
policy to be used by the logged on sets, they must be re-registered.
No Security Policy
When a system doesn't have a security policy set, the system is open for all types of
initiations and registrations.
To remove a security policy, use the command: sec_policy -remove.
The parameter effects of the command extension --security exception can be summarized
by the table below (RAC: Regional Authorization Code, also known as a Registration PIN):
7-13
All Secure Policy

When a system is configured as "All Secure", it will only accept connections from sets that
are configured with the security-exception parameter set to NO and that sends a PIN.
To set the system security policy to ALL_SECURE, you must use the following command:
sec_policy -set 1.
See table below for the system behavior based on these scenarios.
If the system has any registered extensions that aren't configured for this security policy,
when attempting to change the security policy, you will get this error:
>sec_policy -set 1
NOT EXECUTED
DIRECTORY NUMBERS WITH SECURITY EXCEPTION EXIST

Security
All Secure with Extension Exception

This policy can be enabled by using the following command: >sec_policy -set 2.
The following table provides the system behavior when this security policy is used:
All Secure with Exception Type

This policy can be enabled by using the following command: >sec_policy -set 3.
The following table provides the system behavior when this security policy is used:
Note: With SIP extensions, this policy will have the same behavior as the
ALL_SECURE policy.
7-15
Media Encryption
IP Extensions
Media encryption is disabled by default. If the VoIP security license is enabled, use
the command media_encryption_enable -type extension to enable SRTP
encryption. This setting affects both gateway and non-gateway calls for SIP
extensions.
You can also disable media encryption by using the following command:
media_encryption_disable -type extension.
Note: Attempting to disable media encryption will only be succesful when

there is no security policy configured on the system. For any other security
policy, the command will fail.
You can print the media encryption settings by entering the command:
media_encryption_print -type extension.
IP Routes
Media encryption is disabled by default. You can use the command:
media_encryption_enable -type route to enable SRTP encryption for IP Routes.
This will only affect the gateway calls made from or to IP Routes. For non-gateway
calls, the command has no effect. For non-gateway calls, the SRTP support depends
on the SRTP support of the endpoints.
You can use the media_encryption_disable -type route command to disable the
encryption.
You can also verify the media encryption settings using the command
media_encryption_print -type route.
Inter Media Gateway Connections

Media encryption is disabled by default. You can use the command:
media_encryption_enable -type intermgw to enable SRTP encryption in inter
media gateway connections.
media_encryption_disable -type intermgw can be used to disable SRTP
encryption.
Use the command media_encryption_print -type intermgw to print it's media
encryption settings.
Check Signaling Security

In order to verify that TLS is working in the system, you can use the command ip_extension
-p. Verify that the secure SIP terminals are registered on the secure port 5061 instead of
5060.

Security
Configuring PM & SNM to use HTTPS
Both Provisioning Manager and Service Node Manager can be configured to use HTTPS to
secure all communication between administrators and the web services used to administer
the MX-ONE.
Configuration of this feature is handled separately from the previous process enabling TLS
and SRTP for SIP extensions and trunks. Instead it is configured using the Webserver
Management option within mxone_maintenance. It is also possible to use the
webserver_config command directly.
NOTE: If PM and SNM are installed on different servers then the process below must be
repeated on each server. This also applies to Standby Servers that are used with webserver
redundancy. The tool will specify at the top title line which web service is being configured.
Choose option A to configure HTTPS
Choose option B to change to HTTPS
7-17
Note the warning that the installation must complete and the webserver restarted to ensure
the correct configuration of the secure protocol.
There is then a choice of which certificate to use to authenticate and initiate the HTTPS
protocol. If a certificate has been generated by an external CA then this can be uploaded
using a tool like WinSCP and then selected using option A and the file browser.
Otherwise choose option B to generate a self-signed certificate. Note this option will typically
require the certificate to be added to the web browser otherwise a warning message is likely
to be displayed to the user everytime SNM or PM are accessed.

Security
Assuming the self signed certificate is chosen, you will be asked for a password to create it.
You are then asked to confirm and also make a secure note of it for possible future use
The system will then ask for the bit size and Digest type for the certificate creation. The
higher the number the more secure the encryption will be but at the expense of additional
cpu usage and possible latency.
7-19
Finally the license will be created and installed.
Once complete the system will then restart the relevant web service.

Security
After the service has been restarted it will typically take a few minutes for the web server to
reload and should now be accessible via HTTPS in a suitable web browser.
NOTE: Remember to repeat the process on all other servers running a web service
(SNM,PM and standby servers involved with webserver redundancy)
7-21
Tracing
8
Objectives
 Understand what trace options are available


Tracing
Trace Functionality
The trace functions in the MiVoice MX-ONE Service Node is an integrated part of the
system.
The function consists of the following parts:
• Commands to administer the function : trace

• A program unit running on the processor: LOGGER
• Components integrated into the signaling mechanism
• Code components specified in the design rules
• Code provided from the designer
The trace functions make it possible for the administrator to analyze the system performance
and trace error conditions. The trace functions can be used when integrating the system to
verify the intended functions or to find problems in a system with traffic.
Trace Types
The MiVoice MX-ONE handles the following types of trace data:
• Trace Error Log: This log is dedicated to trace individual 0. This trace is always active
and will record any abnormality detected in the MiVoice MX-ONE. The log is cyclic, that
is, it overwrites the oldest entries when the log becomes full. This log filters which signals
to store and it's possible to alter the size of the storage (From 1 to 10000 entries, the
default is 5000). This trace can't be removed or stopped.
• Unit Trace: Can be initiated on the MiVoice MX-ONE program units in one or all the
MiVoice MX-ONE nodes.
• Exception: LLP and dynamically loaded commands or daemons (e.g. board_sw and
snmpd). Unit trace is setup by command and has no restrictions on options like filter,
etc.
• Sequence Trace: This trace can be initiated in several ways depending on what is
known of the function that is to be analyzed. It's possible to start on a specific signal, with
or without specific data and to start on a known directory number, or a known EQU
position. Sequence trace is set up by command and has no restrictions on options like
filter etc.
• Exception: The directory number must be associated to a terminal, that is, not a
group number. EQU positions must be an interface, for example, trunk line interface,
extension line interface or operator line interface, not auxiliary device interfaces.
• Hardware Trace: This trace is performed by copying all signals to or from hardware
positions. The trace is started on a complete group of 32 components in the addressing
range. It is possible to exclude individuals in the group from the trace by setting a mask.
Each signal sent in the hardware interface will be recorded twice, once in signal format
and once in raw format. This is done to help the debugging of signaling to and from a
new interface board. (Filtering can be used to omit the unwanted copy).
Hardware trace is set up using SNM or by command.
8-3
Perform a Trace
Initiation using SNM
Service Node Manager can be used to initiate a signal trace. The feature is accessed via the
Tools / Signal Tracing option.
1. Clicking Add brings up the first screen of the two step setup process. First choose the
type of trace to initiate from the drop down list.
2. Having chosen the trace type, the second screen will vary depending on the choice.
Here we show a program unit trace, recording all information about the SIPLP unit in
LIM1, storing up to 5000 lines and labelling the trace with a text description.

Tracing
3. Once the trace has been initiated the screen shows the traces currently initiated. To start
recording, click on the red activate button.
4. After completing the activity you wish to trace, click on the now green button to
deactivate the trace.
5. The trace can be viewed by clicking on the Trace Info hyperlink which allows the trace to
viewed or downloaded on the local PC.
6. Click on the red x to remove the trace
8-5
Initiation using Command Line

Using the command line, signal tracing is initiated using the trace command. Note, there is
also a Linux OS command called trace, so the MX-ONE version must be executed from the
MDSH shell.
7. Enter the command trace -display to check if there are free trace.
8. Initiate the trace by using one of the commands below:
• Trace started on a specific program unit:
trace -lim -unit
• Trace started on a specific signal number:
trace -lim -unit -signo [-byte]
• Trace started on a specific signal name:
trace -lim -unit -signam [-byte]
• Trace started on a directory number:
trace -dir
• Trace started in a equipment position:
trace -equ
• Trace started on a backplane 32 group:
trace -hwpos [-mask]
• Trace started on the switch specific functions (LSU/DSU or Media Gateway internal
functions):
trace -hwpos -switch [-mask]
Modification
It is also possible to modify the behaviour of the trace.
Note: The change command can be used any number of times as long as the
trace has not started
The following can be changed:
• The trace individual

• The trace individual can stop when maximum copies are received or overwrite the oldest
• The size of the trace buffer
• The signals to include or omit in the trace
• The kind of text trace copies to include in the trace
• A stop signal that will stop the trace if included in the trace
• Stop conditions if an error signal is received
• An information text to the trace individual (reminder or message to other users)
Note: Several trace individuals can use the same stop condition.
Start Trace
Tracing
Enter the command trace -start to start the trace or traces.
Note: Several traces can be started with the same command.
Stop Trace
Enter the command trace -stop to stop the traces.
Note: Several trace can be stopped with the same command..
Display Trace Status

It is possible to check the status of the traces at any time. Status information can be printed
without starting a trace. This will give a print of all 16 trace statuses. If only one trace is
given, only that trace will be printed.
If there is no LIM parameter, all buffer counters of the MiVoice MX-ONE Service Nodes are
added and printed. If there is a LIM parameter, the counter from that MiVoice MX-ONE
Service Node is printed. Depending on what type of trace that is initiated, different layouts
will be used. All parameters entered are presented. Some additional information like pointers
and program units, where a directory number resides, are also printed to help the
administrator to identify the right data in the trace printout.
Related command and parameters are: trace -display [-lim]
You can also use trace -attach -lim x to print traces in real time. The trace will be displayed
directly on the terminal. This is used when the traces are expected to become huge. You can
redirect the terminal to a file on the local storage media but you need to ensure that it
doesn't fill up the disk space. Another option is to log towards an external storage device or
simply have PUTTY log all text for the session to a local file on the PC. Because this trace
could cause a kernel module fault in SCTP which causes the LIM to stop sending SCTP
packets between LIM's, you must be logged on to the LIM you want to run the trace on and
you must use the -lim parameter.
Print Trace Results
When a trace is stopped, it is possible to print the trace results. In a multi Server system, the
trace copies will be printed in chronological order. It is possible to print from a specific
MiVoice MX-ONE Service Node with the LIM parameter. It is also possible to print copies
containing a certain signal number, or to print a range of copies. To change the printout
format a show parameter can be given to omit the parts of the signal that are regarded as
irrelevant in the printout format.
Related command and parameters are:
trace -print [-lim] [-from] [-to] [-signo] [-show]
Note: The trace information and status are always printed in the header
before the actual trace information, so that the trace setup can be examined
when analyzing the result.
8-7
Clear the Trace Buffer

Enter the command trace -clear to clear the content of the trace buffer.
Note: Several traces can be cleared with the same command.
Remove a Trace
If a trace is not needed any more, free the trace by removing the trace configuration and
placing the trace in idle state. The related command and parameter is: trace -remove

Tracing
Lab 1 - Configuring an MX-ONE Signal Trace
8-9
SNMP and DHCP
9
Objectives
When you finish this module, you will be able to:
 Understand the MiVoice MX-ONE SNMP implementation

 Know how to configure and test the SNMP sub-system
 Understand the role of DHCP
 Configure DHCP Options required for Mitel SIP/IP handsets
MiVoice MX-ONE Advanced Installation and Maintenance Course

SNMP and DHCP
Overview
The MiVoice MX-ONE can be supervised from a Simple Network Management Protocol
(SNMP) management system, and it can be configured to send alarm notifications by SNMP
traps, e-mail or text messaging (using the Short Messaging Service (SMS)).
This module describes the MiVoice MX-ONE SNMP support and how the basic configuration
of alarm notification is set up.
The MiVoice MX-ONE can be monitored from an SNMP management system using the Mitel
MIB implementation.
The SNMP implementation that the MiVoice MX-ONE is based on is net-snmp. More
documentation can be found in the /usr/share/doc/packages/net-snmp folder on the
MiVoice MX-ONE system or at http://www.net-snmp.org.
Net-snmp is installed by default and it's configured to use the AGENT_X protocol.
The program AALSNMP (Mitel MIB) is part of the system and communicates with the SNMP
daemon via the AGENT_X protocol.
The SNMP daemon (snmpd) is installed in each LIM (node) of the MiVoice MX-ONE system.
Consequently, the network management system needs to get traps from all the nodes
individually in order to get the complete system view.
In the normal setup, each node sends traps directly to the SNMP management system but
they may also be configured to route traps through a proxy. The SNMP daemon has a
default setup and is operational after installation, but requires additional configuration for the
traps to be sent to the management system.
The snmptrapd daemon is also used for additional features like proxy agent for traps and to
log traps locally to disk. These features require additional configuration in order to function.
The snmptrapd daemon is installed but isn't activated by default. But in order to enable e-
mail, SMS or other features, additional configuration is required.
9-3
MiVoice MX-ONE SNMP Implementation
The OID that represents the MiVoice MX-ONE system alarms is the following:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).aastra(11268).aastraMibs(2).
aastraOidMX-ONE(8).tsAlarm(1).tsAlarmR1(1)
The MiVoice MX-ONE will send system alarm traps to the Network Management System
(NMS) when an alarm occurs.
A query can also be used to fetch alarm information from the MiVoice MX-ONE Service
Node.

SNMP and DHCP
This is what it would look like in a SNMP Browser. In this case a Freeware product called
ManageEngine MiB Browser
Note: The NMS needs to be customized to display the MiVoice MX-ONE

information and have the MX-ONE MIB files downloaded to it.
The OID that represents the MiVoice MX-ONE functions and devices is the following:
aastraOidMX-ONE(8).tsAlarm(1).tsObjects(2)
9-5
From the tsObject MIB, the MxSystemStatus and mxinterfaces sub-mibs provide MiVoice
MX-ONE information regarding the items below. This information can be queried by the
NMS, they are read-only.
mxSystemStatus(1)
• MiVoice MX-ONE release version number

• System Status
• Number of servers, IP's, backup status and info, GSM sync info, Service Node Status
mxinterfaces(2)
• Trunk
• Type, description, bearer capabilities, route number, trunk identification (TRU), EQU,
status
• Operator
• Directory number, type, EQU, operation and busy status
• Call Information Logging
• Output, type, subtype, dbname, server, operational status
• Computer telephony integration 3 (CSTA III)
• CTI group, server, IP, operational status
• Computer telephony integration 1 (CSTA I)
• CTI group, server, IP, operational status
• Interception computer (ICU)
• Individual, type, interface, server number, information, operational status
• Gateway
• Type, identification, description, operational status, IP
• Media Gateways
• Type, identification, description, operational status, IP
• Inter server signaling
• GJU side: Type, identification, remote side, description, status
• GSM side: identification, synchronism, operational status A and B, active side
• Voice cards (VCU)
• Type, identification, description, operational status
• CAS boards
• Type, identification, description, operational status

SNMP and DHCP
When there is a change on the status of the following MiVoice MX-ONE items, the Service
Node will send a trap.
mxtrap(3)
• Trunk
• Operator
• Call Information Logging
• Computer Telephony Integration 1 (CSTA I)
• Computer Telephony Integration 3 (CSTA III)
• Interception Computer
• Gateway
• Media Gateway
• Inter Server Signaling
• Voice Cards
• CAS Boards
9-7
The SNMP Licensing Mechanism
The SNMP license in the MiVoice MX-ONE is divided into two parts and they are called
basic and advanced.
Basic: It allows the MiVoice MX-ONE to send alarm information via traps to a NMS. The
system administrator can query the system to get some alarm information (tsAlarmR1 as
seen below)
Advanced: In addition to the features provided by the Basic license, the additional SNMP
Advanced license allows all of the snmp objects under the tsObjects tree to be interrogated
as well (tsAlarmR1 and tsObjects as seen below).

SNMP and DHCP
Supported Objects in the MiVoice MX-ONE MIB (MX-ONE-TS-

ALARM-MIB)
Supported traps in the MiVoice MX-ONE MIB (MX-ONE-TS-ALARM-

MIB)
9-9
System Status MIB Detailed Description
Interfaces MIB Detailed Description

Route and Trunk Information
aastraOidMX-ONE(8) tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfTrunk(2)

SNMP and DHCP
9-11
Operator or Attendant Information

aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfOperator(3)

aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfCil(5)

SNMP and DHCP
CSTA I and CSTA III Information

aastraOidMX-ONE(8) tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfCsta(6)
9-13
System Computer Information (ICU)

aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfGici(7)

SNMP and DHCP
Gateways Information
aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfSwitch(9)
9-15
Group Switch Information

aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfInterlim(10)

SNMP and DHCP
Voice Compression Cards (VCU) Information

aastraOidMX-ONE(8) .tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfVoiceCard(11)
CAS Boards Information

aastraOidMX-ONE(8).tsAlarm(1).tsObjects(2).mxInterfaces(2).mxIfCasBoards(12)
TRAPS
The table below shows the IODs that are available in mxTraps. One trap is sent when the
MiVoice MX-ONE status for one of these objects is changed.
9-17
*) Additionally, the following information is also presented mxObjectStatus,

mxalHandle, mxalFrom, mxalFaultCode, mxalSeverity,mxalWhere, mxalExplanation,
mxalNoticed, mxalNoticedNote.

SNMP and DHCP
Configuration
SNMP is preconfigured at installation and can be reconfigured by editing the configuration

files in the /etc/snmp directory on the MiVoice-MX-ONE system or by using the
mxone_maintenance tool.
Configuration files are found on the MiVoice MX-ONE system in the /etc/snmp path.
Example files are found on the MiVoice MX-ONE system in the /opt/eri_sn/etc/templates
path.
snmpAction.pl is a pearl script that can be found in the /opt/eri_sn/bin path.
traptoemail is a binary file that can be found in the /usr/bin path.
SNMP Configuration using using mxone_maintenance

The SNMP agents configuration is kept in /etc/snmp/snmpd.conf. The
mxone_maintenance tool provides a menu driven method for editing this file and activating
the snmpd service with the changes. This method allows for the basic configuration of the
snmp service.
1. Use the more configuration option from mxone_maintenance.
2. Choose the snmp option
9-19
3. This gives three options, List, Add and remove.
4. Choose the list option to check if any configuration exists.
5. Click OK and then choose the add option. Enter the IP address of the computer running
the SNMP Network Management Station and add the community names (passwords)
used to authenticate the MX-ONE to the NMS. These should be reasonable complex
strings for security.
6. Once the settings have been saved the NMS can be configured using the credentials
above. The screen grab shows a Freeware SNMP Trap viewer

SNMP and DHCP
9-21
SNMP Configuration using the command line / manual file edit

The SNMP agents configuration is kept in /etc/snmp/snmpd.conf. This can be edited via
Midnight Commander or the vi editor. If you make changes to this configuration file, the
SNMP daemon needs to read the file again. This requires a daemon reload, this can be
achieved by entering the following command via SSH: sudo -H /etc/init.d/snmp reload
At a minimum, the following entries should be updated on every LIM:
• syslocation: Physical location of the system

• syscontact: Contact information for the administrator of the system
In most cases, the default community settings should be changed to prevent easy access to
the SNMP information.
• rwcommunity: The community name to allow write access (Not used by the MiVoice
MX-ONE)
• rocommunity: The community name to allow read access
If external trap monitoring is required, the following entries should be changed as well.
• trap2sink: A list of the NMS's that should receive the traps from the MiVoice MX-ONE
(One per line)
• trapcommunityname: The community name that will accompany the sent trap
At installation, the default trap2sink is defined as localhost, thus, sending all traps to the
snmptrapd process running on the same MX-ONE node.
If the snmptrapd functionality to send an email or SMS is not required, then delete the
default line containing localhost.
Additional trap2sink addresses may be added to send information to several trap monitors
or management systems.
If the system needs to have a common trap sender, set the trap2sink in all LIMs to the
same address (e.g. LIM 1). Then, let the snmptrapd daemon in that LIM forward (proxy) the
traps to the NMS.
The default installation will send a trap at startup (cold start) and traps if authentication fails.
Additional traps like disk monitoring can be enabled by changing the configuration. See the
manual pages for the configuration file by typing in the following command while connected
to the MiVoice MX-ONE system via SSH: man snmpd.conf
Configuration of Alarm Notification using E-MAIL and SMS

The MiVoice MX-ONE service node can be configured to send alarm notifications by e-mail
or directly via SMS. The notices are based on the SNMP daemon snmptrapd. The daemon
receives and logs the SNMP TRAP messages, then translates them into an e-mail format. A
public e-mail to SMS server can then be used to forward the notification to a mobile phone
using SMS.
Enabling Mail from SNMP Traps

Mail notification is configured by editing the /etc/snmp/snmptrapd.conf file. Enter the
destination e-mail address(es) for the notifications after uncommenting the desired trap(s).
For additional information regarding configuration of this feature, type the following
command while logged into the MiVoice MX-ONE via SSH: man snmptrapd.conf

SNMP and DHCP
To start the daemon (once the configuration changes have been made), run chkconfig
snmptrapd on from the SSH command line, this will configure the snmptrapd service for
automatic startup at boot time. Then, use the command /etc/init.d/snmptrapd start to start
the service now.
Proxy Traps to the same destination

If the NMS being used requires only one trap sender from the system, you can use the
snmptrapd proxy functionality.
1. set the trap2sink information in the configuration file on each LIM to the IP of LIM 1
2. Configure the /etc/snmp/snmptrapd.conf file in LIM 1 to include "forward default
DESTINATION". DESTINATION is the ip address of the network management center.
(e.g. forward-default 192.168.1.1)
3. Disable the snmptrapd daemon in all LIMs except LIM 1. (It is disabled by default)
Disabling the Trap Daemon

If the snmptrapd functionality to send mail or SMS is not required, then delete the line in the
trap2sink section of the /etc/init.d/snmptrapd.conf file that contains the word localhost
Stop the service by executing the commands chkconfig snmptrapd off, and
/etc/init.d/snmptrapd stop.
Restarting the Trap Daemon

If you ever need to restart the Trap daemon (e.g. configuration change), use the following
command:
/etc/init.d/snmptrapd restart
9-23
Verifying the Installation
To ensure that nothing occurred during installation that could have prevented SNMP from
working, verify that this files exist:
• /usr/share/snmp/mibs/MX-ONE-TS-ALARM-MIB.txt
Also, verify the /etc/snmp/snmp.conf file. Ensure that the following entries are in this file:
mibs+Ericsson-DNA-SNMP-MIB:Ericsson-MD110-SNMP-MIB: MX-ONE-TS-ALARM-MIB
Checking the status of the Daemons

You can verify the status of the daemons by running these 2 commands from a SSH
session.
chkconfig snmpd
chkconfig snmptrapd
If a daemon isn't running, you can use the command chkconfig xxxx on (xxxx is the
daemon name, e.g.: snmpd or snmptrapd) to enable the service to be started at next boot
and you can use the command systemctl start xxxx (xxxx is the daemon name, e.g.:
snmpd.service or snmptrapd.service) to start the service.
Using NET_SNMP tools to check alarms

You can use a built-in net-snmp tool called snmpwalk to verify that the daemons are running
and that they can communicate with the ALSNMP/AALSNMP program(s).
Verifying the MITEL MIB

Use the command alarm -i to create a test alarms with different severities.
E.g. alarm -i -C 666 -D 1 --alarm-severity 4 --alarm-text "Test alarm"\ --faulty-lim 1 --
add-text "I did this"
This alarm should show up at your NMS as a trap.
Use the command snmpwalk to verify that the fake alarm shows up.
E.g. snmpwalk -v 2c -c public -m all localhost 1.3.6.1.4.1.11268.2.8.1.1.1 (will only
print active alarms.)
Use command alarm -e to remove alarm when ready.
E.g. alarm -e -C 666 -D 1
Verify Trap sending

To verify that the alarms are forwarded, you may use alarm commands to create,
change and remove alarms.
You can verify the changes made by looking at the following log files on the system.
 /var/log/messages
 /var/log/net-snmp.log
 /var/log/mail

SNMP and DHCP
Example:
Use the command alarm -i to create a test alarm with different severities.
alarm -i -C 666 -D 1 --alarm-severity 4 --alarm-text "Test alarm"\ --faulty-lim 1 --add-
text "I did this"
Use the command alarm -p to verify that the alarm exist, and to get the alarm
handle.
alarm -p -C 666 -D 1
Check that a trap was sent to the management system and/or mail system.
Use the command alarm_noticed --alarm-handle XX to change the noticed state of
the alarm.
alarm_noticed --alarm-handle XX
Check that a trap was sent to the management system and/or mail system.
Use the command alarm -e --alarm-handle XX to remove alarm.
alarm -e --alarm-handle XX
Check that a trap was sent to the management system and/or mail system
9-25
SNMP Version 3
Many organisations now require version 3 of the SNMP protocol as this ensures that all
traffic is encrypted before it is sent to the snmp manager system.
It is not currently possible (in version 7.0) to configure this via the mxone_maintenance
tool. Instead the protocol must be configured from the command line. The recommended
procedure has yet to be added to the CPI documentation but involves two stages:
Creating a SNMP v3 user

First a user must be created to authenticate the SNMP v3 connection this achieved by
stopping the snmpd service and then using the net-snmp-config command to create the
user. The service can then be restarted. All the commands must be executed whilst logged
in as a root user. In this case the command creates a user called fred with password
secret123 for SHA authentication and secret456 for AES encryption.
systemctl stop snmpd.service
net-snmp-config --create-snmpv3-user -a SHA -A secret123 -x AES -X secret456 fred
systemctl start snmpd.service
Update the SNMP config file

Now the snmp configuration file must be updated to send traps using v3. First look at the file
/var/lib/net-snmp/snmpd.conf this will contain the engine ID at the bottom of the file.
This is needed to add to the line below that must be added to /etc/snmp/snmpd.conf file.
trapsess -v 3 -u fred -e 0x80001f8880d720a770ae21365c00000000 -l authPriv -a SHA -A secret123-
x AES -X secret123 192.168.0.33
In this case the user name has been added after the -u option, the engine ID has been added after
the -e option, the passwords added as created above. Finally the ip address at the end is the
destination where the v3 snmp traps should be sent.
To test the config use the Linux command snmpwalk. In the example below we use the same
credentials as above and localhost at the end to test the local machine.
snmpwalk -v3 -u fred -l authPriv -a SHA -A secret123 -x AES -X secret456 localhost

SNMP and DHCP
Lab 1 - Enabling SNMP on MX-ONE
9-27
DHCP
Networking 4 VoIP or an industry standard Networking course is required as a prerequisite

to taking this training. Therefore DHCP should be understood by all students taking the
MiVoice MX-ONE training. This section will outline the DHCP requirements for MX-ONE SIP
Phones.
IP Configuration Data from DHCP

The Mitel 67xxi, 68xxi & 69xxi SIP phones all support DHCP and can receive the following IP
configuration data:
• Own IP address, subnet mask and default gateway, received in the DHCP standard
fields (1 and 3).
• The VLAN used for the phone can generally be set in option 132 or be part of Option 43.
If the phone’s configuration has another value than that of the option value it will
configure according to the Option 132 value and making a reboot. Take care that the
phone does not have a vlan affiliated, where it can't reach DHCP. It is always
recommended to default to factory defaults before deploying a new phone
• IP address to the software server. The path to the firmware to be downloaded from the
software server can also be provided as well as the protocol to be used. The
recommendation is to use DHCP option 66 (TFTP server name), but DHCP option 60
(vendor class identifier) and option 43 (vendor specific information field) can also be
used
• Additionally, they can also receive standard options like the DNS Server and NTP server
addresses.
The following examples show the different possibilities on how to use option 66,160 or 159 in
order to get the IP address or host and its path to the software server. For http and https it is
possible to define the port.
Default port for http is 80 and default port for https is 443:
http://192.168.1.45
http://192.168.1.45/path
http://192.168.1.45:8080/path
http://srv.example.com/path
The default dhcp precedence order is 43, 160, 159, 66. So if the phone receives the
software server configuration in both option 66 and option 43, then option 43 takes
precedence over option 66.
If option 66 is already in use, it is possible to set the configuration server in either option 160
or 159 instead.
DHCP Settings for Option 66

Enter the URL to the software server according to the example explained in the previous
section.
DHCP Settings for Option 43 and 60

DHCP option 60 (vendor class identifier) and option 43 (vendor specific information field) can
also be used to get the software server address and also to load a unique configuration file
dependant on telephone type.

SNMP and DHCP
The first step is to initiate option 60 for each telephone type (shown on the next page).
After option 60 has been entered into the DHCP server, the data in option 43 has to be
entered. The following options exist:
9-29
Below is an example showing how to configure DHCP in a Windows 2012 environment. It

may look different in a newer Windows environment.
Define Vendor Class

Select Define Vendor Class in the drop down list.
To enter the Vendor Class ID, click on the right side below ASCII in the large form
field. Enter the Identifier Value from table above.
Repeat this step for each phone model that should be served by this DHCP server.

SNMP and DHCP
Set Predefined Options

Select Set Predefined Options to get the menu to enter the option 43 data.
Select appropriate option class from the drop down list and press the Add button.
The data in the Option Type menu has to be entered manually:

Name: Configuration Server URL
Data type: String
Code: 02
Repeat this for each phone model that should be served by this DHCP
server.
If the VLAN identity is to be provided via option 43, repeat this for code 08 and
code 09, see table Options that can be set in option 43.
9-31
Set Scope Options

The last step is to set the URL string.
Select appropriate Vendor class and set the User class to Default User Class. Activate
option 002 and enter the URL of the software server (configuration server) in the input field
String value.
Repeat this for each phone model that should be served by this DHCP server.
If VLAN identity shall be provided via option 43, repeat this for code 08 and code 09, see
table Options that can be set in option 43. For more information on specific terminals that are
supported by the MiVoice MX-ONE, please use the CPI documentation.

Appendix A - MiVoice MX-
10
ONE Extensions using the
Command Line Interface
Objectives
 Understand the different extension types

 Be familiar with the extension and ip_extension commands
 Understand Common Service Profiles (CSP)
 Configure the IP Phone Software Server

Appendix A - MiVoice MX-ONE Extensions using the Command Line Interface
IP/SIP/Virtual
Commands used for generic extensions (IP, SIP, Virtual):

extension -i -d xxxx --csp y --lim z xxxx=extension number, y = CSP, Z = LIM
that you want to configure the extension on
extension -i -d xxxx --csp y --language- You can also use the optional --language-
code en --lim z code parameter to choose a language that
isn't the default system language. (e.g. en
for English, fr for French, etc)
extension -i -d wwww..xxxx --csp y --lim z You can also create multiple extensions at
the same time
extension -i -d vvvv,wwww,xxxx --csp y -- Another option is to create individual

lim z extensions with one command. (e.g.
extension -i -d 3000,3221,3991 --csp 1 --lim
1)
extension -i -d xxxx --csp y --max- You can also create an extension that allows
terminals w --lim z multiple terminals to be registered with the
same number (forking). This specific
example would allow w terminals to register
with extension xxxx
extension -i -d xxxx --csp y --domain- When an ip domain exists in the MiVoice

name z MX-ONE, this command will distribute the
extensions defined evenly between the
domains defined servers. Applicable
configuration files will cause the terminals to
register at the preferred servers, avoiding
unnecessary LAN connections and
distributing load.
extension -e -d xxxx Delete extension xxxx (-e is the erase

parameter)
extension -e -d wwww..xxxx This deletes the range starting at wwww and
10-3
end at xxxx
extension -e -d vvvv,wwww,xxxx This deletes extensions vvvv, wwww and

xxxx
extension -p Display all the generic extensions in the

system
extension_info -p -d all Displays all the available information for all

the generic extensions in the system
extension_info -p -d all --terminal-info Displays all the available set type

information for all the generic extensions in
the system
extension_info -p -d all --terminal-info | Displays all the available sets that have a
grep 57i set type that includes 57i for all the generic
extensions in the system
extension_unregistration -d xxxx Unregister set xxxx from the system
extension_unregistration -d xxxx --reset Forces the set to clear it's configuration data
extension_unregistration --lim z Unregister all sets from LIM z
Generic extension parameters worth mentioning for this release:

--csta-support Valid values are:
00= Default, Presence/Status for Mitel
applications
01=Presence/Status for Mitel and third party
applications
02=Presence/Status for Mitel and full support
for third party applications
10=Full support for Mitel applications only
11=Full support for Mitel applications and
Presence/Status only for third party
applications
12=Full support for Mitel and third party
applications.
--feature_level Required for systems running in "Feature

Based" mode
--free-on-second-line Values that change your second line

behavior:
0= Default, Configurable with the SIP
terminal menu "Services"
1= Busy on Line 2 when on a call on Line 1
2= Always available on Line 2

3= Always busy on Line 2
--language-code Possible values are:

en=English, fr= French, de=German, see
CPI for more languages
Commands used for IP extensions (IP and SIP):

ip_extension -i -d xxxx Create an IP extension from the generic
extension xxxx
ip_extension -i -d wwww..xxxx Create a range of IP extensions from the

corresponding generic extensions (wwww to
xxxx)
ip_extension -i -d vvvv,wwww,xxxx Create individual IP extensions for vvvv,

wwww, xxxx from the corresponding generic
extensions (vvvv, wwww, xxxx)
ip_extension -i -d xxxx --max-terminals y Create an IP extension that can register y

devices with the same number (Forking).
The Max terminals value cannot exceed the
value defined in the extension command
used for the same directory number.
ip_extension -e -d xxxx Delete an IP extension
ip_extension -e -d wwww..xxxxx Delete a range of IP extensions
ip_extension -e -d vvvv,wwww,xxxx Delete extensions vvvv, wwww and xxxx
ip_extension -p Display all IP extensions
ip_extension_info -d all Display all the available information for all IP

extensions.
IP extension specific parameters worth mentioning for this release:

--protocol Values are:
SIP: allows SIP only registration
IP: allows SIP and H.323 registration
The default is IP.
Virtual IP extension creation command

ip_extension -i -d xxxx --terminal-identity "sip:xxxx@0.0.0.0" --uri "sip:xxxx@0.0.0.0"
10-5
Password creation for a SIP extension (Used for Free seating (hot
desking))
auth_code -i -d xxxx --customer 0 --auth- An authorization code of 1234 is created for
code 1234 --cil 1234 --csp 1 extension xxxx.
Note: There is no range programming
available for authorization code creation.
Each user must be done individually
auth_code -e -d xxxx Remove the authorization code from

extension xxxx
auth_code -e -d wwww..xxxx Remove the authorization code from all

extensions in the range specified
auth_code -p Shows all initiated authorization codes,

common and user associated.

Common Service Profile (CSP)
A common service profile is a number that represents a combination of service, traffic,

routing and feature characteristics. These common service profiles are assigned as
categories for extensions.
It is important to realize that are two very similar settings in MX-ONE for extensions
depending on whether they are for traditional - or legacy extensions (analog or digital or
ISDN) or for generic - not hardware affiliated extensions such as IP (H.323/SIP) extensions,
integrated DECT, REX. The Common Service profile is used for all generic extensions and
Category profile is used for all legacy extensions.
• Common Service Profiles (CSP) and Common Category Codes (CAT) contain or
describe mainly the same characteristics, but they are grouped differently
• CSP and CAT are independently programmed
• CSP with command lines extension_profile and CAT with exccs have no impact on
each other. Therefore, CAT 1 cannot be mapped with CSP 1 or the other way round
In some traffic cases, an extension will use a default category which is stated in CSP = 0.
Due to this, CSP = 0 has to be the first CSP initiated in the exchange.
If the CSP entered is different from the value 0, then CSP = 0 has to be initiated first.
In any case (when CSP = 0 or different from 0) the common service profile should not have
been initiated previously.
Common Service Profile (CSP) can be found in the SNM GUI under Telephony >
Extensions > Common Service Profiles.
Use the command line extension_profile -p to print the existing common service profile and
check if there are any free common service profiles to be used. The example below was
taken from the same Telephony Server as the previous example.
To view all of the extension_profile parameters enter the command line:

extension_profile --help-complete
Parameters
The following section will outline the usage and settings for Common Service Profiles. The
following is an example of a section of a Common Service Profile as shown on the SNM.
10-7
To view the same example (CSP 0) using a command line (extension_profile –p;) is
expressed as:
Please note that the data provided in the previous example does not follow the same pattern
as the SNM GUI (e.g. Number presentation category is the second category on the GUI but
is the seventh category when using CLI)
The next section will go through each CSP parameter. Command lines as shown in the
previous example have Data numbers set to a number based on what is being enabled or
set. For example under TRAF there are 8 numbers representing the overall
settings/parameters. Most parameters need 1 to turn on a feature or 0 to turn off the feature.
However, some parameters may need numbers greater than 1 or 2 digits for the parameter
(e.g. setting a specific 2 digit day service). Each Data number will be designated with a Dx
where the x is the bit number in order of appearance from the left to right (e.g. D1, D2, D3,
D4, D5, D6, D7, D8).

Main Command Line Parameters

More information can be found in the MiVoice MX-ONE Technical Reference
Guide, Unix Commands document. Not all parameters are shown below. Enter the
command line: extension_profile --help-complete for more details.
Basically the following parameters are used in this module for the extension_profile
command.
-c
Change some settings, that is, reconfiguration of an item (or several items); the
switch takes no arguments
--csp
Each Common Service Profile (--csp) represents a combination of characteristics
for --ext-cdiv, --ext-npres, --ext-roc, --ext-serv, and --ext-traf; the range can be 0 –
256; the switch requires an argument and the argument is single-valued
-e
Erases a csp
-i
Initiate a csp
10-9
Example:
The following is an example of setting Common Service Profiles using the command
line. Each command line parameter used can be verified using the command line
extension_profile –p --csp x (where x = the common service profile) or checking
the Command Service Profile settings in the SNM GUI.
An example of setting a parameter is as follows: extension_profile – c --csp 0 --ext-npres
1001000;
In this example the administrator is changing the Number Presentation Category,

first digit to 1
This means the extension is allowed to request an A-number from the PSTN
The remaining information in this section, outlines the major Categories for the
Common Service Profiles. The order of the categories follows the order of the SNM
GUI for Common Service Profiles as shown previously.

Number Presentation Category

• The command line parameter is - - ext-npres
• A switch that has a collection of individual settings. Each individual setting is a digit in
the numerical value string. Pad to length is enabled for this switch. The digits have
the following meaning:
D1 = A-number request from PSTN. This field represents whether the extension
is allowed or not allowed to request an A-number from the PSTN (if the feature
is offered)
 0 - no
 1 - yes
D2 = Number presentation restricted. This field states whether the number is

restricted or not (internal and network), that is, if the A-number is presented to the
B-party or not
 0 - no
 1 - yes
D3 = CLIR per call. This field states whether number restriction (CLIR) is
permitted per call by dialing the procedure *42# before the B-party number
 0 - no
 1 - permitted (yes)
D4 = Extension number to PSTN. This field states whether the extension number
or common public number is sent to the PSTN (For this to be permitted, the
extension must belong to the public number series of the PBX)
 0 - no
 1 - yes
D5 = CLIP restriction override:

 0 - CLIP restriction override not permitted when type of connected party is
private1) or public 2)
 1 - CLIP restriction override is permitted when type of connected party is
private
 2 - CLIP restriction override is permitted when type of connected party is
public
 3 - Both 1 and 2 above are permitted. Extension is able to display the A-party
number even if the presentation is restricted. Private means an extension
within the private network. Public means an extension in the public network
D6 = Never display number from PSTN. This field states whether number from
PSTN should be displayed or not. No means that the number will be displayed
 0 - no
D7 Use group identity for non group incoming calls. This field states if the group
number and name shall be used when sending the number and name identities
to the calling user. No means that the user number will be sent. Note: The group
number to be used is set by the procedure *FC*group-number#
 0 - no
The switch requires an argument. The argument is single-valued
10-11
Traffic Category
• The command line parameter is - - ext-traf
• The Traffic Category, states the traffic characteristics that an extension may
generate. A switch may have a collection of individual settings. Pad to length is
enabled for this switch. The digits have the following meaning:
D1 = Emergency Switching: States whether the extension is blocked or open for
traffic in an emergency switched PBX
 0 - Blocked
 1 - Open
D2 = Direct indialing: States whether direct in-dialing traffic to the extension is

blocked or open
 0 - Blocked
 1 – Open
D3 = Rerouting Limitation: States whether incoming calls towards the extension is

permitted to be rerouted. This facility makes it possible to avoid rerouting calls to
an extension, which can be, for example, a facsimile, even though the incoming
route is categorized to allow rerouting
 0 - No limitation
 1 - Rerouting blocked
D4 = Common abbreviated number class: States the class of common

abbreviated numbers that the extension should belong to. One 'abbreviated
dialing common number' is assigned to one or several classes in another
command
 0, 1, 2 or 3 – depending on the Common abbreviated number class
D5,D6 TCD Night = Trunk Call Discrimination at night provides the ability to block
extensions from dialing specific numbers. The category states the TCD category
in the number analysis that should be mapped to the extension during Night
service. The category states the numbers the extension may dial
 00..15: where 15 - Fully Open
D7,D8 TCD Day = Trunk Call Discrimination during the day provides the ability to
block extensions from dialing specific numbers. The category states the TCD
category in the number analysis that should be mapped to the extension during
Day service. The category states the numbers the extension may dial
 00..15: where 15 - Fully Open
D9D10 = Traffic Connect Class. It states the traffic class in the traffic group matrix
to which the extension belongs. The value in the interception point of the traffic
group matrix between the traffic class belongings of the A-party and B-party,
decides whether they are permitted to connect. (see operation directions 'Traffic
connection matrix')
 00..15: where 15 = Fully Open

Service Category
• The command line parameter is --ext-serv
• The Service Category states the characteristics for services that may be initiated to
or from an extension. A switch has a collection of individual settings. Pad to length is
enabled for this switch. The digits have the following meaning:
D1 = Callback characteristics as calling party
 0 - Not permitted to initiate call back
 1 - Permitted to initiate automatic call back towards another extension in the
same exchange or the private network
 2 - Permitted to initiate automatic call back towards another extension in the
same exchange, in the private network or towards an external line (no
restriction)
 3 - Permitted to initiate automatic call back towards the private network and
towards an external line, without dialling a procedure. (No restriction and
automatic initiation of callback at busy. This value is mostly used if the
terminal is controlled by an application)
NOTE: D2, D3 and D4 define the characteristics for the busy service, Call
Waiting. If the called party (B-party) is busy, the calling party (A-party) may (after
receiving busy tone) request (initiate) Call Waiting via DTMF signaling (standard
market: '5') for an analog phone, however, IP and Digital phones would send a
message and not DTMF. The settings for B-party (D3) and C-party (D4) will have
no effect for SIP terminals and for H.323 terminals with Free-On-2nd activated.
Call Waiting as busy service is not supported on SIP. However, a multiline
terminal (as for free-On-2nd) will display incoming calls on a terminal Line key
which also may generate a local Call Waiting tone. The A-party will just get
alerting/ring tone]
D2 = Call waiting request permission. This field states whether call waiting is
permitted to be requested
 0 - no
 1 - yes
D3 = Call waiting protection B. The B-party is the target of the Call Waiting
request. B terminal is notified via call waiting tone and/or blinking led on a line
key
 0 - Full protection. No Call Waiting notification
 1 - Only Call Waiting notification from another extension
 2 - Only Call Waiting notification from another extension and PBX operator
 3 - No protection. Call waiting notification from another extension, PBX
operator and external line
D4 = Call waiting protection. The C-party is the one in speech with the target of
the Call Waiting request
 0 - no call w. tone
 1 - yes, call w. tone
D5 = Intrusion capability level (ICL). The intrusion requester capability level,

which will be compared to the intruded and third party intrusion protection level
 0 - Intrusion request is not allowed
 1 - Intrusion capability level 1
 2 - Intrusion capability level 2
 3 - Intrusion capability level 3 (highest)
10-13
D6 = Intrusion protection level (IPL). The intruded or third party's intrusion

protection levels, which will be compared to the intrusion capability level (ICL) of
the requester
 0 - No protection. Intrusion always allowed
 1 - Protection level 1. Can be intruded by users who have ICL higher than 1
 2 - Protection level 2. Can be intruded by users who have ICL higher than 2
 3 - Protection level 3. Cannot be intruded
D7 = Malicious call tracing. This field states if an extension is authorized to initiate

malicious call tracing
 0 - no call tracing
 1 - call tracing
D8 = Manual message waiting. This field states if an extension is allowed to use

the service Manual Message Waiting
 0 - not allowed
 1 - allowed
D9 = Call Metering
 0 - Per route (exchange)
 1 - Per extension
D10 = A-Number request from MFC. The extension is allowed or not allowed to
request an A-number from the MFC trunk (swiss)
 0 – Not allowed
 1 - Allowed
D11 = A-Subscriber charged. Specify if the A-number will be charged or not (only
for Swiss MFC DID trunks)
 0 - normal
 1 - not charged
D12 = Permission to activate Individual do-not-disturb (DND). A call to an

Individual Do Not Disturb-marked extension will not be signaled on the receiving
extension. An Individual Do Not Disturb-marked extension can still make outgoing
calls in the normal way
 0 - DND not permitted
 1 - Individual DND permitted
D13 = Unused
D14 = Hospitality class. This field states the privilege classes
 0 - normal extension (default)
 1 - room vacant
 2 - room occupied
D15 = Collect call. This field specifies if an extension is permitted to accept

incoming collect calls
 0 - not allowed
 1 - allowed
D16 = Is reserved and always set to 0

D17 = Unconditional forced Gateway. This field states whether all the calls
to/from IP extensions will be unconditionally forced gateway
 0 - no (default)
 1 - yes
D18 = Free seating permitted. This field states whether the extension is permitted
free seating. This field does not affect IP terminals with capability to logon/logoff

 0 - no (default)
 1 - yes
D19 = SMS permitted

 0 - no
 1 - SMS service permitted for extension
D20 = External Controlled Call distribution. This field states whether the external
controlled call distribution is permitted. If value 1 is set the switch '--offered-time'
has to be set as well
 0 - Normal call distribution
 1 - Call distribution controlled by external application
D21 = Common authorization code forbidden

D22 = Multiple terminal service busy option. This category is valid at calls
towards a user/person which has the multiple terminal service
 0 - If any of the users/persons logged on terminals is busy, the user will be
treated as busy (default)
 1 - If any of the users/persons logged on terminals is busy, the system will
ignore the user/person busy status and always try to seize the logged on
terminals. If any of the users terminals replies busy during the seizure, the
terminal and the user are treated as busy for the actual call
D23 = Extended services in Intrusion state
 0 - No extended services
 1 - Extended services: Parking, Inquiry and Single Step Transfer is permitted
for the extension
D24 = Call list deactivation permission. The category controls if the extension
user is allowed to deactivate his/her call list
 0 - Call list deactivation is allowed (Default)
 1 - Call list deactivation is forbidden (Primarily for SIP extension users with
only default call list)
D25 = Programming Of Group Do Not Disturb category
 0 - Extension does not have permission to activate Group do not disturb
(Default).
 1 - Extension has permission to activate Group do not disturb
D26 = Automatic answer. This field states whether the extension shall be ordered
to answer automatically or not. This function is only supported by SIP extensions.
Automatic/immediate answer should not be initiated for an extension number that
has Shared Call Appearance, Multiple representation, Parallel ringing or similar
‘multiple terminal services’
 0 - Automatic/immediate answer will not be ordered (Default)
 1 - Automatic/immediate answer will be ordered
10-15
D27, D28 = Transfer permission. This field states whether call transfer of an
outgoing PSTN call is permitted or not (e.g. A transfer of an internal call to a
public external line or to transfer a public external line in an outgoing call to an
internal extension). The Transfer category determines whether the extension is
permitted to transfer an internal call to a public external line in an outgoing call, or
to transfer a public external line in an outgoing call to an internal extension.
Authorization is required both for transfer and for receipt of transferred outgoing
public external calls. The necessity of a category for this type of transfer depends
on the AS parameter. As intruding party in an intrusion conference the user is
permitted to change the conference type from intrusion to normal. This is done by
executing call transfer in the intrusion conference. When calling an extension
conference leader and performing an intrusion the intruding party is permitted to
transfer a call into the ongoing conference
 00 - Not permitted to accept transferred or to transfer outgoing external public
calls to an internal party or this feature is not used in the system
 01 - Permitted to transfer outgoing external calls
 02 - Permitted to accept transferred outgoing external calls. (Above can be
altered through command ASPAC, PARNUM=67)
 04 - Not used
 08 - Permitted to transfer a call into intrusion conference. (If intrusion
conference is set, consider SYDAS parameter CNFREL)
 The value D27, D28 is the summation of the above categories. The switch
requires an argument. The argument is single-valued
D29 = Answer handling. This field states whether the extension user shall be
ordered to answer via terminal or via an external application (e.g. SeC Call
Center application). Tone shall be provided if answered by external application
 0 - Answer is controlled by the extension user (Default)
 1 - Answer is controlled by an external application (via CSTA). Tone shall be
provided
 The switch requires an argument. The argument is single-valued
D30 = Log-off restriction (for SIP extensions). This field states whether the
extension shall be fully restricted, semi-restricted or not restricted from log-off
 0 - Not restricted. (Permitted to log off, default)
 1 - Semi-restricted. The first registration will be considered as the “default
extension”. The log-off key will then be labeled “TempUser”, allowing
temporary registration to own extension. An automatic registration back to the
default extension will take place if the log-off key is pressed, or after 4 hours.
(Example: Conference phone)
 2 - Fully restricted. Log-off is not allowed. (Example: Elevator or reception
phone)
 The switch requires an argument. The argument is single-valued

Call Diversion Category

• The command line parameter is --ext-cdiv
D1 = External Follow-me. This field states whether a user is permitted to do
external Follow-me using service code *22# (or equivalent soft key)
 0 - no
 1 - yes
D2 = Follow-me. This field states whether a user is permitted to do internal

Follow-me using service code *21* (or soft key 'Follow-Me')
 0 - no
 1 - yes
D3 = Diversion bypass. This field states whether diversion bypass is permitted or

not. (Bypass of diversion can be set to always permit by using an AS parameter
(PARNUM=75))
 0 - no
D4 = Diversion on origin extension. This field states whether diversion on origin

(internal extension) is permitted or not and if common or individual diversion
position should be used
 0 - Default or feature not permitted (DiversionBypass=no)
 1 - Individual diversion position
 2 - Common diversion position
D5 = Diversion on origin public line. This field states whether diversion on origin
(public external line) is permitted or not and if common or individual diversion
D6 = Diversion on origin private line. This field states whether diversion on origin
(private external line) is permitted or not and if common or individual diversion
D7 = Auto bypass of FM for SMS. This field states if diversion bypass for SMS is
permitted for follow me
 0 - no
 1 - permitted (recommended)
D8 = Auto bypass of EFM for SMS. This field states if diversion bypass for SMS
is permitted for external follow me
 0 - no
 1 - permitted (recommended)
D9 Permits direct diversion to:

 0 - only an individual divertee position (**)
 1 - an individual or common divertee position (*)
10-17
D10 Permits diversion to an individual divertee position on busy (**)

 0 - no
 1 - yes
D11 Permits diversion to an individual divertee position on no-answer (**)

 0 - no
 1 – yes
D12 = Multi Directory Diversion/Do Not Disturb. This facility is only allowed for
ODN, on DTS or SIP terminals)
 0 - no
 1 - yes
D13, D14 = Remote programming of diversion:

 00 - Default or feature not permitted
 01 - Permitted to initiate Follow-me on other extensions or groups
 02 - Permitted to initiate External follow-me (ECF) on other extensions or
groups
 04 - Permitted to initiate Diversion on no-reply on other extensions or groups
 08 - Permitted to initiate Diversion on busy on other extensions or groups
 16 - Permitted to initiate Direct diversion on other extensions or groups
 By allowing an extension to perform remote programming of diversion, the
extension can be used for remote initiation of diversion on other, internal
extensions or groups. (Provided that the selected diversion type is allowed for
these extensions/groups)
(*) If an individual divertee position has not been initiated the common divertee
position is chosen. If no common divertee position has been initiated the
procedure for diversion cannot be done
(**) If no individual divertee position has been initiated the procedure for this
facility cannot be utilized

Routing Category
• The command line parameter is --ext-roc
D1 = Facility restriction level (0..7). Attribute level to make a selective restriction
of the use of the outgoing routes
D2 = Account code for LCR (0..2). States forced account code when the value of
the ACCT parameter stated in the LCR tables is X
D3 = Off-hook queuing level (0..3). Specifies the off hook queuing level, it is
compared against the outgoing routes threshold level
D4 = Authorization type for route selection. Attribute to make a selective
restriction of the use of the outgoing routes
 0 - Normal extension
 1 - Class A
 2 - Class B
 3 - Class C
 4 - Class D
 5 - Data extension
 6 - PABX operator
 7 - Class E
D5,D6 = Toll Exchange. Attribute level (category) to make a selective restriction

of the use of the outgoing routes
 01 - (default) Toll exchange not used or extension authorized to make
outgoing calls towards automatic zone, trunk and international network
 02 - Hospitality extension authorized for outgoing calls as category 01
 03 - Extension authorized for local calls only
 04 - Extension with priority, authorized to make outgoing calls towards
automatic zone, trunk and international network as well as chargeable
services
 05 - Extension without priority, free of charge, authorized to make the same
calls as category 04
 06 - Trunk coin box or post office switch board authorized to make the same
calls as category 01
 07 - Extension without priority, authorized to make calls as category 04.
 09 - Coin box
 11 - Dispatcher (used for private networks)
10-19
IP Phone Software Server
A basic requirement for setting up the IP phone is to have a configuration server (also known
as the SIP IP Phone Software Server).
The configuration server allows you to:
• Store the firmware images that you need to download to your IP phone
• Stores configuration files for the IP phone
The software and the configuration files used by the IP phones are stored on a server where
the IP phones can fetch them. The server is called IP Phone SW Server.
The following is a deployment scenario where Telephony domains were using different IP
Phone SW servers.
In the Telephony Server you can define multiple telephony domains. The telephony domains
are managed through the SNM web interface.
The IP phone configuration files are preferably generated through the SNM. Once generated
the configuration files can be viewed directly on the IP Phone SW Server.
The IP phones can use the following protocols to download the software and configuration
file(s): http, https, ftp, tftp. The recommendation is to use the http protocol and it is described
in these installation instructions.
Setting up the Software Server

The software and the configuration files used by the IP phones shall be stored on a server
where the IP phones can fetch them. The server is called IP Phone SW Server.
Before the installation of the IP Phone SW Server you have to install the Java Runtime
Environment. When you run IP Phone SW Server wizard the Tomcat is also installed.

System and Program requirements
• Java Runtime Environment (JRE) version 6 (32- bit) or later

• Windows 32 bit or 64 bit
• Tomcat version 8.5.9 (apache-tomcat-8-windows x86.zip), is installed via the wizard
Prerequisites
• Check if Java Runtime Environment version 6 or later is installed. If not, install JRE
before you start the IP Phone SW Server wizard
• If an older version of IP Phone Server is installed, uninstall the program before you
start the wizard
For more information see the IP Phone SW Server release notes for additional installation
information.
Setting up the software server comprises the following steps:
1. Install the IP Phone SW Server Configuration Management Application
2. Reconfigure Microsoft IIS web server, if it exists on the same host
3. Create a directory structure on the IP Phone SW Server
4. Copy the IP phone application and language files to the IP Phone SW Server. The
configuration files shall not be copied, these are created by SNM
10-21
Install IP Phone SW Server
Install IP Phone SW Server (and Tomcat)

Do as follows:
1. Download and click Setup.exe. The window Installer Language is displayed.
2. Select Language from the list
3. Click OK. The window Welcome to the IPPhone SW Server Setup Wizard is
displayed
4. Click Next. The step License Agreement is displayed

5. Click Agree. The step Tomcat Port Number is displayed
6. Type the port number in the field, default port is 80
7. Click Next. The step Tomcat Administrator is displayed
8. Click Next. The message window “Do you want to continue without configuring a
Tomcat administrator?” is displayed
9. Click Yes. The step Choose Install Location is displayed
10. Click Install. When the installation is complete you will get the message “Installation
Complete”
11. Click Next. The step “Completing the IPPhone SW Server Setup Wizard“ is
displayed
12. Click Finish

Microsoft IIS Web Server

If a Windows IIS web server is running on the same host as the IP Phone SW Server there
will be a port conflict with the IP Phone SW Server Configuration Management Application
since they are both using port 80 by default.
The reason that you need to have the Tomcat web server running instead of just using the
IIS web server is that the IP Phone SW Server Configuration Management Application is
developed in Java and IIS can only host web applications developed in the Microsoft
environment.
Perform the following steps to resolve the port conflict.
1. Keep IIS running on port 80
2. Reconfigure the IP Phone Configuration Management Application to run on eg. port
82 instead
• Edit the apache-tomcat-8.5.9\conf\server.xml (where -8.5.9 is the version currently
installed) and change the port 80 to 82
• Restart Tomcat by going to Control Panel/Administrative Tools/Services and
restart the service Mitel IPPhone SW Server
3. Connect SNM to IP Phone SW Server Configuration Management Application on port
82, using the SNM task IP Phone SW Server
4. Create the configuration file in the SNM task IP Phone Configuration File and it will
be stored on the IP Phone SW Server
5. The .cfg, .st, .txt and .tuz file types must be enabled. Follow the steps below to
enable these file types:
• In IIS Manager, select File Type, select DefaultWEB Site.
• Select Properties and edit HTTP header. Apply the following settings:
Associated extension: .cfg, .st, .txt and .tuz (encrypted .cfg file)
Content type (MIME): application/octet-stream
6. Redirect IIS web server to Tomcat web server for the IP phone’s requests like this:
• Open C:\WINDOWS\system32\inetsrv\inetmgr.exe, navigate to Default Web Site
• Right click on Default Web Site and select New Virtual Directory. A wizard will start
10-23
• Enter the directory name to where the telephone firmware shall be stored as Alias,
example: aastra67xxi
• Enter the path to the folder under Tomcat, for example:
C:\Program Files (x86)\Mitel\IPPhoneServer\apache-tomcat-
8.5.9\webapps\ROOT\aastra67xxi
• Enable the Read option and finish the wizard

• You can now access the Tomcat folder with terminal settings on port 80 as well as
82, while SNM can update the configuration file on port 82
• If subnets or telephony domains are defined for the configuration file in SNM, the
path under Tomcat will include the subnet/telephony domain in its path. Update the
IIS virtual directory link accordingly

Appendix B - MiVoice MX- 11
ONE Telephony Features
using the Command Line
Interface
Objectives
 Understand MX-ONE Telephony features

 Be familiar commands used to program these features
11-25

Appendix B - MiVoice MX-ONE Telephony Features using the Command Line Interface
Parallel Ringing (Multiple Terminal Service)
This feature allows for multiple terminals with different extension numbers (max of 2
additional extensions) to ring at the same time.
Here are the commands to make this happen:
parallel_ringing -i -d vvvv --secondary-dir This configures parallel ringing on extension

wwww,xxxx, vvvv so that extensions wwww and xxxx ring
when vvvv receives a call.
If wwww and xxxx are IP extensions, then
vvvv's number is displayed, the name
however will be of the extension that
answers.
parallel_ringing -e -d xxxx Deletes the parallel ringing configuration for

extension xxxx
parallel_ringing -p Displays all the parallel ringing

configurations in the system
You can also configure a delay before ringing starts on the secondary extensions
delay_seizure_list -i --delay-seizure-list-number 1 --delay-seizure-identifier qqqq --
delay-seizure-option rrrr --delay-time ssss
parallel_ringing -i -d xxxx --delay-seizure-list-number 1
For more information on these options, please read the Parallel Ringing document in CPI.
Here are the same steps using the graphical user interface:
1. Select the extension you want to add parallel ringing to and edit it
11-27
2. Scroll down to the Advanced button and click it.
3. Configure one or both of the secondary numbers here. You can also select a seizure list
if one has been created. Information on how to create a seizure list in the graphical user
interface is on the next page.
A delay seizure list can also be created through the graphical user interface at the following
location.

Forking (Multi Terminal Service)
Users can have multi-terminal groups, these groups can be comprised of the following.
4. Arbitrary type of generic extension (Virtual, H.323, 3rd Party SIP, etc.)
• But only one of each type. (Note: One single SIP terminal is permitted if it's a third
party phone)
• This functionality exists already with forking.
5. Desktop SIP terminal, 67xx, 68xx, 69xxi or BluStar
6. PC softphone
7. Remote extension over SIP (e.g. mobile client)
8. SIP DECT
The following commands show you how to create 3 terminals as part of a multi-terminal
group.
( one Mitel 6700i, one BluStar softphone, one mobile client)
extension -i -d xxxx --csp 1 --max- This creates a generic extension that will
terminals 3 --lim 1 accept multiple registrations of the same
number.
ip_extension -i -d xxxx --max-terminals 3 Create the IP extension from the generic

extension that will allow a maximum of 3
registrations
parallel_ringing -i -d 3000 Configure parallel ringing so that all the

extensions ring at the same time
In the event that the extension you want to add exists already. You can modify it's
configuration using the following commands.
extension -c -d xxxx --max-terminals 3 Modify the existing extension by adding the

max-terminals parameter to it
ip_extension -e -d xxxx Delete the existing ip extension since you

can't edit add max terminals to an existing ip
extension
ip_extension -i -d xxxx --max-terminals 3 Re-create the ip extension with the max-

terminals parameter
You can also define a delay on seizure list for these groups. Please see parallel ringing
section for instructions on how to do this.
11-29
In the graphical user interface, these are the steps required:

1. Search for and edit the extension in question, please note the extension must have been
created as a multi-terminal extension
2. Add the extra terminals (You will have to click on the Advanced button again in order to
get to the Delay Seizure List field.)
Note: It's good to know (particularly with mixed types of terminals), that all
required features have to be configured. e.g. If one of the terminal supports
video, then this feature needs to be configured.
You can find more details about Forking in doc 61/1551-ANF 901 14 of the
CPI documentation.

Personal Number List
In order to create a personal number list:

1. Edit the extension in question by going to Services > Extension and searching for the
extension you want to modify
2. Click on Edit next to the Personal Number List field
11-31
3. Click on the Personal Number List you want to edit.
4. Configure your Personal Number List and then click Continue to save it

5. Click Continue again and it should bring you to the next screen. Here you want to click
the Change button for the Function Keys field so we can create a key on the phone that
will control this personal list.
6. Configure a key on the set for the list. Click OK and then Apply
11-33
7. Once the phone has updated it's display, you should see something similar to the
following:

Hunt Groups
Single Selection Hunt Groups can be configured as sequential, rotational or according to

free list (Longest waiting).
Here are the commands required to create these groups
number_initiate -numbertype EX -number Create the number range that will be used.
xxxx -customer 0 In this case, one number
GHGRI:GRP=xxxx,SERV=xxxxxx,TRAF=xx, Configures the hunt group

SEL=xxxxxx,QUE=xx,LIM=x,RGTIME=xxx;
Note:See example below for clarification
on these parameters
GHGRE:GRP=xxxx; Deletes a hunt group
GHDAP:GRP=xxxx; Display a hunt group with its configuration

and members
GHGMI:GRP=xxxx,DIR=yyyy; Add extension yyyy to hunt group xxxx
GHGME:GRP=xxxx,DIR=yyyy; Removes extension yyyy from hunt group

xxxx
name -i --dir xxxx --number-type grp -- Add a name to the hunt group
name1 "FirstName" --name2 "LastName"
name -e -d xxxx Delete the name off xxxx (which is a hunt

group in this scenario)
name -p -d xxxx Display the name associated with xxxx
diversion -i -d xxxx --div-destination- Configure diversion on the hunt group in

number zzzz the event no members are available. In this
case, calls for xxxx will divert to zzzz
Here's an example of the hunt group creation process
GHGRI:GRP=8000,SERV=1000000,TRAF=15, SEL D1:0 = Linear hunt group

SEL=000201,QUE=10,LIM=1,RGTIME=30;
SEL D1:1 = Rotational hunt group
SEL D1:2 = Everyone rings for every call
maximum of 16 members
QUE (max calls to group) must be
greater than zero or it's always
considered busy
all phones will ring until they are all
picked up or until the QUE value is
hit (in this case, 10 calls).
RGTIME: ( minimum: 5 seconds, default is

30 seconds)
11-35
Linear/Rotation
Duration in seconds a call will
ring an agent before it's sent to
the next available agent
If an agent doesn't answer, he's
taken out of the hunt group for
180 seconds. Configurable in
Serv D7 for generics.
Parallel
If not answered, all calls to the
group will stop as this means
no one is available.
GHGMI:GRP=8000,DIR=533; Adding extension 533 to the hunt group
diversion -i -d 8000 --div-destination- On no answer, divert the call to 1111

number 1111
Feature access codes to stop and start taking calls from a hunt group that you're a member
of
#29*8000# Temporarily stop taking calls for hunt group

8000
*29*8000# Start taking calls for hunt group 8000

Pickup Group
Pickup groups enable extensions to take over an alerting call from another group member by
a simplified procedure. It is also possible to affiliate up to 4 answer groups to a primary
pickup group. In this scenario, users will be presented with calls from their primary group and
if no calls are waiting, calls from their other 3 groups will be presented.
Here are some commands that allow you to create and manage a pickup group
GPGRI:GRP=x,LIM=y; Create a pickup group
GPGRE:GRP=x,LIM=y; Delete a pickup group
GPDAP:GRP=x; Display the members of a pickup group
GPGMI:GRP=x,DIR=yyyy; Add extension yyyy to pickup group x
GPGMI:GRP=x,DIR=yyyy&zzzz; Add yyyy and zzzz to pickup group x
GPGMI:GRP=x,DIR=yyyy&&zzzz; Add the range of yyyy to zzzz to pickup

group x
GPGME:GRP=x,DIR=yyyy; Delete yyyy from pickup group x
Here's an example of these commands being used:
GPGRI:GRP=1,LIM=1; Create pickup group 1 on LIM 1
GPGMI:GRP=1,DIR=333; Add Extension 333 to pickup group 1
11-37
Free Seating (Hot Desking)
The free seating feature can be used by a company where most of the employees have an
out of office work situation. This means that the number of in-office telephones doesn't need
to be the same as the number of employees.
There are a few commands and feature access codes that you need to know about in order
to configure and use this feature.
auth_code -i --auth-code xxxx --cil xxxx -- Create a password for a specific

csp x --category x -d yyyy extension/user
auth_code -e -d yyyy Delete a password for extension yyyy
auth_code -p Show all the passwords configured
auth_code -p -d yyyy Show extension yyyy's password
Feature access codes for this feature
*11*yyyy# To log in as extension yyyy when no

password is configured (Only valid for IP
Phones which are by default free seating
extensions)
*11*zzzz*yyyy# To log in as extension yyyy when a

password of zzzz is set
#11# To log out of the set
Capacity
The number of free seating users are limited by the number of individual authorization code
licenses and the maximum number of generic extensions per line interface module (LIM).

Restrictions
It is not possible to log in to:
• A host telephone where another free seating extension has already been logged on
• A telephone that has a parked call
• A telephone that acts as an InterCeption Computer Services (ICS) answering point
• A telephone that acts as a common/night bell answering position
• A dual telephone
• A telephone that acts as an emergency extension
• A telephone that has auto-answer enabled
• A telephone with MDN busy
• A telephone that acts as an internal group hunting extension
• A telephone that is a member of an Automatic Call Distribution (ACD) group
• an ADN extension, that is, dial free seating log-on procedure after pushing an ADN key
• an MDN key, that is, dial free seating log-on procedure after pushing an MDN key
• a PBX operator console
• an IP telephone
Note: Although it's not possible to log on for Free seating from an IP
telephone, it is possible for an authorized user to use the logon/logoff function
of an IP extension to create a function that is similar to the free seating feature
between IP telephones.
11-39
Call Forwarding
A user can call forward his extension directly from his set but in order to enable call
forwarding remotely, the CSP option "Allow Remote Programming" needs to be enabled on
his set.
*2*yyyy# From the set itself, this will forward your

phone to the yyyy destination
*2*xxxx*yyyy# From a different phone you can enable call

forwarding on set xxxx and send the calls to
set yyyy if xxxx's CSP allows it
#2# This disables call forwarding on the set that it

was entered on
From the command line, the following will achieve the same result
extension_procedure -d xxxx --proc "*2*yyyy#*"
Forwarding your phone to an external number is just as simple.
*23*Nxxxxxxx# This would forward your phone to an

external number. N would be your leading
digit to send the call out
#23# This will deactivate the call forwarding
Note: The service codes used in the tables above are the default for North
America. Please verify which code you should be using by looking at the code
defined in Service Codes on teh system for "Activate Follow-me or
Diversion on no answer for the specified number (remote)" and "Activate
External Follow-me for specified number (remote)"

Appendix C -
External Survivable Gateway
Appendix C -
12
Objectives
 Understand the two Branch Office Gateway offerings

 Be aware of the differences between the two models
12-41
In MX-ONE version 7, the External Survivable Gateway product has been introduced. This is
a hardware-based product that is designed to be installed in remote branch offices to provide
telephony services to replace those offered by the MX-ONE exchange.
The systems are Mitel badged units from Media5 (who have partnered with Mitel since 2008,
providing software components on the SIP 6xxx handsets and soft SIP phones)
The unit is designed to be used where the cost of installing a full MX-ONE LIM (and possibly
an MGU based media gateway) would be prohibitive.
There are two versions of the product; the entry level GX model is aimed at smaller offices
requiring just basic telephony services.
The EX version is a more powerful platform that provides full virtualisation capabilities. This
allows the unit to run a version of the actual MX-ONE Service Node software which can be
configured to offer a more complete and compatible set of functionalities than the GX. It also
offers a more modular infrastructure from a hardware point of view.

Appendix C -
Mitel GX
The Mitel GX Gateway combines a Session Border Controller and a Media Gateway in a
robust survivable platform for remote office SIP deployment providing QoS monitoring,
security, survivability, and PSTN access. The GX’s SBC / SIP session capability starts from
5 channels and scales to 120 concurrent sessions.
The GX Gateway provides a web-based configuration environment which allows the
engineer/administrator to configure SIP accounts and basic telephony facilities. Under
normal circumstances the GX operates as a SIP Pass-Through device. All the local branch
office SIP handsets and softphones are configured to register to the IP address of the GX
unit which then forwards or proxies the registrations to the MX-ONE LIMs.
In the event of loss of contact with one or several of the MX-ONE LIMs, the SIP phone
registrations will be handled by the GX unit directly. Calls can then be established locally and
also routed out of local SIP or ISDN trunks to a public carrier for continued connectivity.
For the unit to operate properly, whenever a new branch extension is configured on the MX-
ONE it must also be created via the web interface of the GX unit. The GX has a large
number of menu options available via the web interface. Many of these are not required or
only small parts need configuring.
Examples of the GX configuration environment can be seen below. Please note this is not
the complete configuration process. A separate configuration guide is available which details
the sections which must be defined.
Logging on to the GX
The GX gateway is administered via standard HTTP/HTTPS web browser based tools. Login
credentials are configurable by the installer.
Some sample menus from the configuration tools are shown below. Consult the Mitel CPI
documentation for more detail and the recommended procedures to configure the GX for
connection to the MX-ONE system.
12-43
Top Level GX Web Menu Options
Initial Network Configuration
Network Interface Configuration
Session Border Controller - Call Agents

Appendix C -
SBC - Routing Rulesets
Services
12-45
ISDN Routing

Appendix C -
Extension Registrations
Extension Authentication
12-47
Mitel EX
The Mitel EX Controller is an altogether different piece of equipment. It comes with a more
powerful CPU and a higher amount of RAM and storage. The EX Controller bundles the
capabilities of a Session Border Controller and a Media Gateway.
With its higher hardware specification, the EX Controller comes equipped with KVM
virtualization support which allows an MX-ONE version 7 VM to be loaded and run from the
unit. This allows the EX branch solution to have full a MX-ONE feature set for local SIP
devices in medium size remote sites. The Media Server can also reside onboard to offer
local conferencing and MOH/MOW resources.
The EX Controller is aimed at remote sites of up to 600 users. It can be connected to the
main site using SIP trunks and the public network via SIP or ISDN. It can be configured as a
standalone local branch node or as a local back-up node for survivability.
As the EX Controller runs exactly the same MX-ONE software as the main system,
Provisioning Manager can be used to configure the unit as a separate subsystem.
NOTE:
The EX Controller is not a remote LIM on the existing main MX-ONE
exchange. Think of it as a single LIM, remote exchange with connectivity
back to the main site.

Appendix C -
Both the EX Controller and GX Gateway are designed to provide a large telephony feature
set. The slide below lists the features provided. Note: the GX Gateway tries to emulate the
functions found on a full MX-ONE system, but the user experience may vary a little when the
branch office is isolated from the core MX-ONE exchange.
12-49
EX Controller & GX Gateway Usage and Operation
The two products have differing roles to play in a branch office scenario. In this section we
look at some of the different implementations and the role the products play in maintaining
telephony services to end users.
As mentioned above the simplest (and cheapest) model in the family is the GX gateway
which is a self-contained unit which operates as a SIP pass-through proxy under normal
operation, passing on SIP Register, Invite etc. messages to the MX-ONE Service nodes
(primary or secondary). Analogue extensions are registered by the GX on the MX-ONE as
SIP extensions. There are numerous levels of redundancy offered, plus the ability to still
record the SIP call speech via a third party voice recorder located in the main HQ site. Here
we look at the two most common scenarios; Normal operation and when the WAN link fails
to the HQ site, containing the MX-ONE Service Nodes.
When the link from the Branch Office to the main MX-ONE fails the following scenario
occurs:

Appendix C -
The EX Controller is different in that it runs exactly the same software as a normal MX-ONE
Service Node except it is running under the KVM virtualization environment on the EX.
It is important to remember that the EX is NEVER configured as an additional Service Node /
LIM on the main exchange. It is always used as separate system, which happens to have
feature programming for the users in the branch office that matches that on the main system.
Under normal circumstances, the SIP extensions register directly (or via SBCs) to the MX-
ONE’s in the main site but use the EX/Media5 gateway locally for conferencing, RVA and
Music On Hold. Analogue extensions and faxes register to the EX hardware which presents
them as SIP extensions on the main MX-ONE.
In the event of WAN failure to the main site, the SIP extensions are configured to register to
the virtualized MX-ONE system running on the EX hardware. All outgoing calls can then be
routed via SIP/ISDN/Analogue trunks to the public network.
The main advantage of the EX is that the facilities and services provided to the local branch
office users in a failure scenario are exactly the same as those when working normally as
the phones are still connecting to an MX-ONE system.
12-51
Using SNM to add a GX Gateway

The SNM web gui can now be used to configure the GX gateway and link it to the system.
The option is found under Services / Enterprise Gateway
The configuration is used to inform the MX-ONE of the IP address of the GX.

T-MXONE-7-0-C2-IM v1.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T-MXONE-7-0-C2-IM v1.2

Uploaded by

Copyright:

Available Formats

MiVoice MX-ONE

Core Part 2 Installation and Maintenance course

© 2018,2019 Mitel Networks Corporation

Student Code of Conduct ..................................................................................................... xiii

Course Description ............................................................................................................... xiv

Information Icons ................................................................................................................... xv

Product Documentation ........................................................................................................ xvi

Getting Help ........................................................................................................................ xvii

Technical Certification .........................................................................................................xviii

Installing MX-ONE with Redundancy........................................................................... 1

Network Redundancy design .............................................................................................. 3

Network redundancy by using Ethernet bonding ................................................................. 4

Lab 2 - Setting up the MiVoice MX-One system on Server 1 and 2 ..................................... 5

Home Location Register (HLR) Redundancy .......................................................................... 6

Lab 3 - Installing Provisioning Manager .............................................................................. 7

Lab 4 - Creating Extensions and Registering Phones ......................................................... 7

Lab 5 - HLR Redundancy.................................................................................................... 7

Server Redundancy ................................................................................................................ 8

Configuring and using server redundancy ........................................................................... 8

Display the cluster status ...................................................................................................17

Display the cluster configuration ........................................................................................19

Lab 6 - Creating a Cluster ..................................................................................................20

Lab 7 – Displaying the cluster status and configuration ......................................................20

Adding a LIM to a cluster ...................................................................................................21

Execute a manual fallback to a regular server ....................................................................23

Change fallback type and server priority ............................................................................25

Execute a manual ordered synch of data ...........................................................................28

Lock or unlock a LIM to a specific server............................................................................29

Lab 8 – Displaying the cluster configuration and status ......................................................31

Lab 9 – Testing a Standard MX-ONE Standby Server cluster ............................................31

Lab 10 - Change the Fallback and Priority of a Cluster ......................................................31

Lab 11 – Performing a manual ordered synch of data ........................................................31

PreLoaded Cluster .............................................................................................................37

Converting a Cluster to a Pre-Loaded one .........................................................................37

Lab 11 – Performing a manual ordered synch of data ........................................................40

Lab 12 – Locking and Unlocking a LIM ..............................................................................40

Lab 13 - Removing a LIM from a Cluster ............................................................................40

Lab 14 - Removing a Cluster..............................................................................................40

Lab 15 - Creating a new PreLoaded Cluster ......................................................................40

Installing Provisioning / Service Node Manager Redundancy ................................................41

Configuration of the Master Server.....................................................................................41

Configuration of the Standby Server ..................................................................................45

Web Redundancy Utilities ..................................................................................................47

Lab 16 - Configuring Web Service Redundancy .................................................................49

VMWare High Availability and Fault Tolerance ......................................................................50

MiVoice MX-ONE Migration and Advanced Backup ................................................... 1

UPGRADE USING REGENERATION SCRIPT UTILITY..................................................... 4

COLLECTION REGENERATION OF DATA, VIA REGENERATION SCRIPT UTILITY....... 4

INSTALL THE MIVOICE MX-ONE 7.X ................................................................................ 4

RESTORING SAVED DATA INTO THE MIVOICE MX-ONE 7.X ........................................ 5

MIGRATING PROVISIONING MANAGER AND SERVICE NODE MANAGER ...................... 6

BACKUP SERVICE NODE MANAGER (MANAGER TELEPHONY SERVER IN MX-

TEMPLATE DATA BACKUP ............................................................................................... 6

BACKUP PROVISIONING MANAGER (MANAGER PROVISIONING IN MX-ONE

MANAGER PROVISIONING TEMPLATE DATA BACKUP ................................................. 8

RESTORE SERVICE NODE MANAGER ............................................................................ 8

RESTORE PROVISIONING MANAGER ............................................................................. 8

pm_snm_6.x_backup script ...............................................................................................10

Using PC-REGEN to Backup/Archive an MX-ONE System ...................................................12

Installing and Initializing PC-Regen .......................................................................................13

Installing the PC-Regen Utility............................................................................................13

Using PC-Regen ................................................................................................................14

Creating the Initial Capture Batch File ................................................................................15

Lab 1 - Installing and Using PC-REGEN ............................................................................21