Redundancy

Chapter 4 - Redundancy 2

4.1 Objectives 2

4.2 Glossary 2

4.3 Redundancy - Overview 3

4.4 Network Redundancy 4

4.5 Server Redundancy 6

4.6 HLR Redundancy 8

4.7 Redundancy considerations 9

4.8 Exercise: Redundancy 10

LZU 103 1013 Rev B

Page 1 of 10

A&STflA

Redundancy

Chapter 4 - Redundancy

4.1 Objectives

The objectives for chapter 6 are:

o Understand the role and importance redundancy

o Understand the implementation of redundancy in MX-ONE VA.O

o Describe network, server and HLR redundancy

o Describe impact on installation and maintenance

o Instruct on how the connections are made in case of redundancy

4.2 Glossary

Acronym Definition
CMG Contact Management Suite
D.N.A Dynamic Network Administration
DNS Domain Name Server
ESU Embedded Server Unit
GW Gateway
LAN Local Area Network
LIM Line Interface Module
LSU-E LIM Switch Unit - Ethernet
MG Media Gateway
PSTN Public Switched Telephone Network
WAN Wide Area Network LZU 103 1013 Rev B

Page 2 of 10

Redundancy

4.3 Redundancy - Overview

In IT networks redundancy has a big importance since many years. The reason for this is that there are a lot of services like a central user database (authentication), DNS (address resolution), DHCP (address and configuration distribution) and others that are vital for functionality of the network. That means if just one of these services would fail, all functionality would be lost (in case that the user database is not available it would not be possible to log on and so it doesn't help that DNS, DHCP and other services are working well).

To solve this problem of a "single point of failure" it is needed to provide vital services in the network redundantly (more than once).

The concept of redundancy involves servers as well as clients.

On the one hand servers that offer vital services need to be available redundantly, on the other hand clients need to know where to connect to if one server (the default server) is not available (i. e. configuration of a second DNS server address on a client).

If a client is not aware about implementation of redundancy, a redundant server (the standby server) needs to take over the identity (i. e. IP address) of the failed server.

The goal of redundancy is to have the vital services of the network as high available as possible.

There are several "classes" or "levels" of High Availability. The table below shows the "class" or "level" of availability and the associated max. downtime per year.

Availability Max. downtime per year
99 % 3.65 days
99.9 % 8.76 hours
99.99 % 0.876 hours IV 52.56 min.
99.999 % 5.256 min.
99.9999 % 0.5256 min. IV 31.5 sec.
99.99999 % 3.15 sec. Figure 1: Availability and max. downtime per year

Regarding Telephony Server we are in the range of the so called "five nine availability" (99.999 %).

LZU 103 1013 Rev B

Page 3 of 10

N1ST~A

Redundancy

In MX-ONE 4 three types of redundancy are implemented,

o network redundancy

o server redundancy

o SIP proxy/Gatekeeper redundancy (HLR redundancy)

Network redundancy is a prerequisite for server redundancy and is also strongly recommended in it's own right. Without network redundancy, a single fault in the IP infrastructure can eliminate all telephony services.

The new Media Gateway Unit introduced in MX-ONE V4.0 provides two Ethernet interfaces where either can be used for both control and media. Thus, with MGU based Media Gateways, there is no loss of functionality or gateway capacity if one of the redundant networks fails.

Server redundancy and HLR redundancy are mutually exclusive and should not be used in the same system.

Switch layer:2:

Figure. A set up of redundancy with MGU based Media Gateways without any single point of failure

4.4 Network Redundancy

When MX-ONE is implemented with network redundancy, three networks are involved, two inside the server room (a primary network and a secondary network for redundancy) and one network outside the server room (the corporate LAN).

LZU 103 1013 Rev B

Page 4 of 10

Redundancy

These three networks are connected with each other with a router.

Figure 2: Basic Connectivity of different Media Gateways with redundancy

During installation the IP addresses (and subnet masks) on both networks are configured along with the IP address of the default gateway in each network.

Figure 3: Configuration for network redundancy

In normal operation the primary network is used to communicate with the devices on the corporate LAN (the routers IP address in the primary network is used as default gateway address).

The Aastra service "mxone_def_gw_sup" is used to check frequently whether the default gateway is answering. As long as this is the case everything is alright and no action is necessary. As soon as the default gateway is no longer answering (because i.e. the switch of the primary network failed or the network interface of the router connected to the primary network failed) it is needed to switch to the other default gateway. In this case, that is automatically done by the service "mxone_routing" by modifying the metric values of the two default gateways to give the desired default gateway a "higher priority".

If the primary network comes back (that is the default gateway address in primary network responds again) the services will switch back the default gateway address to the routers address in the primary network.

LZU 103 1013 Rev B

Page 5 of 10

A4ST~A

Redundancy

Note: Previously this was done by usage of Linux garbage collection but because of some limitations and unwanted effects, now the services "mxone_routing" and "mxone_def_gw_sup" are used.

4.5 Server Redundancy

Server redundancy is achieved by adding one or more standby servers to the network and by using Linux HA (High Availability).

The Linux-HA project is a widely used and important component in many interesting High Availability solutions, and ranks as among the best HA software packages for any platform.

The central component of Linux HA is heartbeat. MX-ONE V4.0 uses heartbeat and CRM (Cluster Resource Manager) for server redundancy.

Server redundancy in MX-ONE V4.0 is N+ 1 redundancy that is for N servers there is exactly 1 standby server. The N servers plus the standby server form a so called "cluster".

During installation of MX-ONE V4.0 the configuration data regarding clusters is entered in lCT.

Figure 4: Cluster configuration Step 1

Every cluster needs a name, the LIM numbers of the cluster members (only LIMs which are configured with network redundancy will be available there), the name and the type of the standby server and the sync time (this will set up a cron job, executing the command "resync_cluster _data" at the specified time).

LZU 103 1013 Rev B

Page 6 of 10

Redundancy

stalldby Server Netwark Interface!: 1

~ !192.Hi8,1 00.20 st:Indby Server Netw()rk Interlace!: 2

~ 1192,16B.200.20

Figure 5: Cluster configuration Step 2

In step 2 the IP addresses of the standby server are configured, one address in the primary network and one address in the redundancy network.

Cluster C>:.:mfgguratkm ~ .Add - Step :3 I 3- CIUs:tH tnfo3

LIM 1

A!ia5Netv.torklnmrfa~-1

Figure 6: Cluster configuration Step 3

In step 3 all the N servers in the cluster (all servers except the standby server) are configured with so called "alias addresses". Alias addresses are additional IP addresses for an interface.

LZU 103 1013 Rev B

Page 7 of 10

AASTQA

Redundancy

Figure 7: Cluster configuration successful

Finally, the cluster configuration is complete.

The idea behind heartbeat is that a service (the heartbeat service) runs on all members of a cluster and sends heartbeats to the other servers in the cluster. These heartbeat signals are much more than ping responses or something like that. While a ping response just shows that IP protocol is configured and functional, heartbeat can give information i.e. whether a service is running or not. In MX-ONE V4.0 the heartbeat is looking for service "eri_sn" and the alias IP addresses.

As a result of the heartbeat communication the heartbeat service running on the standby server knows which servers in the cluster are able to run eri_sn and have alias IP addresses configured.

In normal conditions all N servers in the cluster should run eri_sn and should have alias IP addresses configured. If one server fails, this is no longer the case and as a result the standby server will detect this because it will no longer get the heartbeat signals from that server.

The reaction of the standby server to this is to start the service "eri_sn" with the configuration of the failed server (the configuration was synchronized by command "resync_cluster _data" automatically every day) and configure the alias IP addresses of the failed server to the own interfaces.

4.6 HLR Redundancy

Generic extensions, (users that do not have individual physical wires connected to an interface board in MX-ONE) have been implemented according to the HLR/VLR architecture used in mobile networks.

The HLR redundancy feature copies all HLR data into the LDAP database. This data is automatically replicated to the LDAP database present in every server.

The effect is that a user

LZU 103 1013 Rev B

Page 8 of 10

Redundancy

a) can register when the home-server is dead and can be handled even by a remote, isolated LIM

b) can be found by incoming calls even if the home-server is dead MX-ONE version 4.0 provides HLR redundancy for IP extensions (SIP and H.323).

The HLR redundancy feature in MX-ONE V4.0 will allow a user to register, to be found by incoming calls and will provide the vast majority of system and end user features.

Data for specific features using large volumes of data, e.g. secretarial monitoring and parallel ring are not copied to LDAP in MX-ONE V4.0 so certain end-user features will be lost if the home-server cannot be accessed.

4.7 Redundancy considerations

Because of the characteristic properties of some components of the MX-ONE TS 4.0 system there are some considerations to take care about.

D An application server may need a special connection or configuration to one Telephony Server (i.e. GICI). If the TS fails, application server can not operate.

D IP phones must be configured with two gatekeeper or SIP proxy addresses (use DNS, configuration files or possibly multicast).

D IP operator equipment can only connect to one Telephony Server port.

For operator redundancy, operators must be distributed across both subnets.

D Since the existing Enterprise Media Gateway (EMG) has dedicated interfaces for media and control it can't be connected to both networks (regardless which network would fail the Media Gateway would be lost) but has both interfaces connected to one of the two networks. If that network fails, the Media Gateway is lost.

D In an upgraded Media Gateway Classic with LSU-E and all upgraded legacy cabinets, a switch must be introduced to secure control of the hardware when a network fails.

D With MGU based media Gateways, if network redundancy is not used, only eth 0 shall be connected to the network.

D If server redundancy is configured for any servers in the system, the HLR redundancy feature must be switched off.

D In server redundancy the service "eri_sn" is under control of service "eri_heartbeat", thus it is strictly forbidden to start or stop the service "eri_sn" directly - "eri_heartbeat" has to be used instead (same applies to "eri_om" and "heartbeat_om" (only on LIM 1), even that this service is not subject to be taken over from the standby server).

LZU 103 1013 Rev B

Page 9 of 10

>u c ro "0 c :J "0 Q)

cr::

>-
u
c
co
""0
C
::J
""0
(!)
c::::
(!)
~ (J)
u
~
(!)
~ ><
w
:i 00
.
V -
.-
ra
+I
Q)
C
........
"C
C
ra
E
E
0
U
"'0
C
co "'0
C
~ co
!.....
0 (f)
3: .s:
!.....
.j.J 0
Q)
c 3:
.j.J
>- Q)
!..... C
CO
E ..c
-I-'
"i: 0
0.. ..0
E E
0 0
!..... !.....
4- 4-
(f) (f)
E !..... E
Q) Q) Q) !.....
E .j.J > .j.J
(f) 0 (f) Q)
Q) >-- >->
.j.J (f) "CO (f) 0
(f) -
>- Q)4- Q) "-
(f) ..c~ ..c~
.j.J .j.J !..... .j.J !.....
C 4- 0 4- Q)
CO 0 3: 0 >
"'0 Q) .j.J Q) !.....
Q) Q)
c c c c (f)
C ::J 0 0
"'0 .j.J Q) .j.J Q)
0 Q) u..c u..c
;:; !..... Q).j.J Q).j.J
u CO c Q) c Q)
::::I - c > c >
J.. - 0 !..... 0 !.....
+I CO U Q) U Q)
II) .j.J (f) (f) (f) (f)
(f)
e c .- ..0 .- ..0
1-1 ...... 0 0 o 0 o T"""I

"o

o T"""I

Q) en ro 0..

co > Q)

cr:: [V) T"""I o T"""I

[V) o T"""I

::::> N _J

Licensing

Chapter 5 - Licensing 2

5.1 Objectives 2

5.2 Glossary 2

5.3 Licensing Description 3

5.4 License Application and Installation 3

5.5 Update System with New License .4

5.6 Replacing Hardware 4

5.7 Exercise: Licensing 5

LZU 103 1013 Rev B

Page 1 of 5

Licensing

Chapter 5 - Licensing

5.1 Objectives

The objectives for chapter 5 are:

D Describe the licenses in MX-ONETM Version 4.

D Describe the information required to apply for a system license. D Define and complete the process for installing a license.

D Update the system with new license file.

5.2 Glossary

Acronym Definition
Server Line Interface Module
MAC Media Access Control Address
Nrc Network Interface Card
SN Service Node Conventions

D Commands or parameters in the text of the document are quoted in quotation marks, " ..... ", When using the commands and parameters on the command line, the quotation marks are omitted.

D Commands are shown in Courier 12pt bold. The command prompt is not bold.

LZU 103 1013 Rev B

Page 2 of 5

Licensing

5.3 Licensing Description

The licensing in MX-ONeM Version 4 is controlled by a single license file. The license file is made up of a number of licenses, one license for each sales object.

MX-ONeM Version 4 is moving towards more user oriented system than extension oriented system. Even this the licensing of the Telephony part has still port based licensing and every type of initiated extension/functionality needs their own specific license.

A sales object may be defined for individual elements, such as IP extensions or lines within an IP route, or system elements such as network services. Licenses for sales objects that are individual elements are defined for a number of "ports". The license is composed of four parts:

1:1 A unique license tag of up to 40 characters.

1:1 Product number for the sales object - called a FAL number.

1:1 Number of currently used instances of the sales object defined by the license.

1:1 Maximum allowed number of instances of the sales object defined by the license.

The license file, called "Iic.dat" is installed and stored in proprietary binary format on LIM1 under /etc/opt/eri jsn.

The Telephony System software includes a trial license file that lasts for 1440 hours or 60 days. The license file includes unlimited ports for all individual sales objects and allows all system sales objects. A valid customer license file must be applied for and installed within 60 days. At the end of the trial time, the trial license file becomes invalid. The Telephony System will not function without a valid license, it will start, but not allow configuration changes.

5.4 License Application and Installation

The customer license file is a binary file linked to the hardware identity in the Server 1 Telephony Server. A customer license file is ordered from Aastra using the web based licensing centre LISA. The license file is emailed to the responsible Service Partner. To order a customer license the Service Partner must supply LISA with the hardware identity of the customer's system.

The command "Iicense_status" is used, to print information about the currently installed license. The command, used with the "-s" parameter, returns the hardware identity of the server.

The hardware identity and other relevant customer/site information are used to order a customer license file. The license file is emailed as a file called

"Iic.dat". The file is small eno h to fit easil stick.

LZU 103 1013 Rev B

Page 3 of 5

NlSTQA

Licensing

Make a copy of the trial license file "Iic.dat" before copying the customer license file to /etc/opt/eri jsn on Server 1. The trial license file may be needed if the customer file does not contain the correct licenses. If you do not make a copy of the trial license file! the new "lic.dat" will overwrite the trial license file.

Before "updating" the customer license file into the system! check the contents with the "license_print" command as shown below.

5.5 Update System with New License

After verifying the contents of the customer license file! update the license to the MX-ONETM system with the "license_reread" command. The command should run in Server 1 only because the license server is located in Server 1.

The "license_reread" command updates (overwrites) the license server with information from the updated license file

Check the status of the active license with the "license status" command. The first customer license for an MX-ONETM system has a sequence id of 1. If the customer subsequently wants to purchase more or new licenses! the current license file is replaced with a new customer license file. The hardware identity remains the same but the sequence number is increased.

In the trial license the "Allowed" column reads 0 for all licenses. There is an additional line of text underneath "Licensed to hardware id" stating the length of time left to run on the trial license.

After the license file is updated! a coordinated start is executed in the system. The "start -system" does not disturb traffic.

5.6 Replacing Hardware

Hardware replacement will only cause a problem if the Server 1 server or Ethernet card in the Serverl is replaced.

If the server or Ethernet card is replaced! a new license file must be applied for from LISA and installed. A new license file should be made available within a few days.

With the new hardware in place! it is possible to use the old license. Fault code 117 ("Hardware ID does not match license file") is generated and no changes can be made but the system will continue to function.

LZU 103 1013 Rev B

Page 4 of 5

0"1
C
III
C
Q)
u
::J
Q)
III
g_ ·u
L
Q)
~ X
ui
r-,
l./") -
.-
ra
....
G)
C
.......
'C
e
ra
E
E
0
u
E
Q)
.j...J
(J)
>-
(J)
Q)
..c
.j...J
c
0
Q)
(J)
c
Q)
u
.-
-
e 3:
0 Q)
:jj c
u ro
::I -
'- -
.... ro
III .j...J
(J)
e C
1-1 ...... If) 4- o

l1) (J) OJ ro c,

co > (J)

c::: (Y/ ,-j o ,-j

(Y] o ,-j

::l N ...J

A4ST~A

Manager TS and Manager Provisioning

Chapter 6 - Manager TS and Manager Provisioning " .. ", .. """"""" ........ , .. , .. ,2

6,1 Objectives""""", .. "" .. , .... "" .. "", .... ", .. "" .. ", .. " .. """ .. , .. """, .. """""", 2

6,2 Glossary""""""""""""""""""""""" """ "',.,"" """"'" """""" """",,2

6,3 General Overview""""""""""""""""." "" .. " .. """ .. """""""""".", ,4

6.4 Manager Telephony System - Overview 4

6,5 Manager Telephony System - User Privileges 5

6,6 Using Manager Telephony System , ,7

6,7 Manager Provislonlnq.v.v.v.. .. """"", "" .. , .. "", .. " .. """"""""" ", 12

6,8 Manager Provisioning Installation Considerations , 12

6,9 Manager Provisioning Installation " 15

6,10 Exercise: MTS and MP""""""""""" .. "" .. """, .. " .. """ .. ", .. """""""",,24

LZU 103 1013 Rev B

Page 1 of 24

Manager TS and Manager Provisioning

Chapter 6 - Manager TS and Manager Provision i ngobjectives

The objectives for chapter 5 are:

o Describe and check status of the Manager Telephony System

application.

o Define the user privileges for Manager Telephony System.

o Describe login and Manager Telephony System functionality.

o Describe menus, submenus and tasks in Manager Telephony System.

o Explain help and shortcut functions.

o Introduce the new Manager Provisioning Tool.

o Describe the Manager Provisioning tool.

o Describe Manager Provisioning User types.

o Complete the Manager Provisioning installation. Glossary

Acronym Definition
API Application Programming Interface
CMG Contact Management
CPI Customer Product Information
CTI Computer Telephony Integration
DMG Directory Manager
EMG Extension Manager
GUI Graphical User Interface
HTIPS Hyper Text Transfer Protocol (Secure)
ICT Installation Configuration Tool
LAN Local Area Network
MML Man Machine Language
MTS Manager Telephony System
RVA Recorded Voice Announcement
SSL Secure Socket Layer
SOAP Simple Object Access Protocol
TCP Transmission Control Protocol
TS Telephony System
UDF User Defined Fields
XML Extensible Markup Language
TTY TeleType LZU 103 1013 Rev B

Page 2 of 24

Manager TS and Manager Provisioning

I wbm

I web based manager

Conventions

o Commands or parameters in the text of the document are quoted in quotation marks, " ..... If. When using the commands and parameters on the command line, the quotation marks are omitted.

o The command prompt is not bold.

LZU 103 1013 Rev B

Page 3 of 24

A4STQA

Manager TS and Manager Provisioning

6.3 General Overview

Manager Telephony System (Manager TS or MTS) and Manager Provisioning (MP) are both web-based applications, providing a Graphical User Interface (GUI) for intuitive, easy to use system configuration and maintenance.

Tasks that would normally been done by typing commands (linux-style or mml) on the command line (in mdsh or bash).

Although both applications have purposely the same look and feel and therefore look almost similar they differ in intention.

While Manager TS is designed to provide a GUI for initial system configuration, the purpose of MP is to have an GUI for configurations that are done almost on daily basis. So Manager TS is an application for a technician while MP is for the customer (end user, administrator).

Both GUIs have in common, that they simply translate the input that is done in the GUI in commands (Iinux-style or mml). Since from version to version and from SP to SP commands or command parameters change (mml commands are converted in linux-style commands) it is extremely important to have the right version of Manager TS and MP, matching to the installed Telephony Server version.

This should be not a problem in case of MTS since this is included in the installation file (the .bin file) of the Telephony System. But since MP is a separate installation file it is needed to take care on the version.

Since Manager TS is running on server 1 it is an easy task for Manager TS to execute commands on the Telephony System. When commands or command parameters in the Telephony System change, these changes need to be programmed in Manager TS also. Doing the same regarding MP would mean to have the double work, so the approach is different there. MP is designed to make usage of Manager TS. MP sends commands (in Simple Object Access Protocol SOAP) to Manager TS and Manager TS then translates the command in linux-style or mml commands that are suitable for the Telephony System.

6.4 Manager Telephony System - Overview

Manager Telephony System (Manager TS) is the web-based, operation and maintenance GUI providing "point and click" operations to configure and service the MX-ONeM Version 4. Manager TS is running on server 1 of each Telephony System. It is controlled by service "eri_om" which simply starts the application server "jboss" (which includes a web server) serving the java archive containing Manager TS.

Manager Telephony System provides secure and encrypted access to the Telephony System from a standard web browser through a HTTP or HTTPS interface.

LZU 103 1013 Rev B

Page 4 of 24

Manager TS and Manager Provisioning

The Telephony System operation and maintenance daemon (eri_om) is automatically started in server 1. The daemon takes around 40 - 50 seconds to start (depending size of RAM and CPU speed).

Manager Telephony System clients use the web server port on the Telephony Server that is defined during Telephony System installation. The port number defaults to 80 (443 if HTIPS is used) but can be configured during installation in ICT (respectively the configuration file eri_ts.conf). On an installed Telephony System the port can be changed using "ts_conf_install".

6.5 Manager Telephony System - User Privileges

The user privileges in Manager Telephony System are defined in one of two ways depending whether Manager Provisioning is used or not. If Manager Provisioning is used, user privileges can be set in Manager Provisioning. Without Manager Provisioning user privileges are defined by group membership of a linux account in server 1.

Which of these methods is used is set during installation in ICT but can be changed later by running the ts_conf_install command (which modifies a configuration file) and restarting "eri_om".

6.5.1

Manager TS User Privileges with Manager Provisioning

When Manager Provisioning is installed it can be used to control the privileges to Manager TS. When Manager Provisioning is installed on server 1, Manager TS will be configured automatically to use MP for authentication. If MP is installed on an other TS server or stand alone server the configuration need to be done manually by using the ts_conf_install command if Manager TS should use MP for authentication (which of course is not a must).

6.5.2

Manager TS User Privileges with Linux Account

When the MX-ONETM system is managed without using the Manager Provisioning application suite, user access rights to Manager Telephony System are defined by local Linux user group assignment. Manager Telephony System privileges are tied to the Linux user group assignments.

During installation of the Telephony System, eight groups (snlevO - snlev7) are created. By setting the default group of a user to one of these groups, privileges to Manager TS are defined. The MTS superuser is set to membership in snlev7 during installation by ICT. What exactly a user (having the default group set to snlevO - snlev7) can do in Manager TS is defined by Aastra and can't be changed (but may change from one release to the next).

LZU 103 1013 Rev B

Page 5 of 24

Manager TS and Manager Provisioning

6.5.3

Configuration which Method to use

The preferred way to change which method to use to grant privileges to a user for Manager TS (Linux Account or Manager Provisioning) is the ts_conF_install command.

The following information is for reference only.

The configuration file that controls which method to use to grant privileges to a user for Manager TS (Linux Account or Manager Provisioning) is "/opt/jboss/server/default/conf/login-config.xml".

In this file there is a section "<application-policy name="WBMLogin">" (WBM refers to the predecessor of Manager Provisioning which had the name "Web Based Manager").

This section looks like this if Linux Account is used:

<application-policy name="WBMLogin">

<authentication>

<login-module code="se.ericsson.ebc.em.security.LinuxLoginModule" flag="required">

</login-module>

</authentication>

</application-policy>

If Manager TS should use Manager Provisioning for authentication this needs to be changed in (if Manager Provisioning is installed on server 1 the change will be done automatically during installation of Manager Provisioning):

<application-policy name="WBMLogin">

<authentication>

<login-module code="se.ericsson.ebc.em.security.SoapLoginModule" flag="required">

LZU 103 1013 Rev B

Page 6 of 24

Manager TS and Manager Provisioning

<module-option name=''java.naming.provider.url''>http://localhost:8080</modul e-option>

</login-module>

</authentication>

</application-policy>

If Manager Provisioning is installed on an other server (or on a stand alone server) the appropriate section in the configuration file should look like this:

<application-policy name="WBMLogin">

<authentication>

<login-module code="se.ericsson.ebc.em.security.SoapLoginModule" flag="required">

<module-option name=''java.naming.provider.url''>http://192.168.100.50</modul e-option>

</login-module>

</authentication>

</application-policy>

(where "192.168.100.50" needs to be replaced with the IP address of the server where Manager Provisioning is running on).

6.6 Using Manager Telephony System

During the installation of the Telephony Server, Manager TS is installed on server 1 and configured to start automatically when the system starts.

The script controlling the service is jetcjinit.djeri_om.

LZU 103 1013 Rev B

Page 7 of 24

Manager TS and Manager Provisioning

6.6.1

Login

To connect to the Manager Telephony System application, start a browser and type the IP address of the server 1 corporate LAN interface (ethO) in the address bar of a web browser.

Note: If Manager Provisioning is installed on server 1 also, Manager Provisioning login page will appear. In this case it is needed to add "/mts" or "/wbm" to the IP address.

If the web server port is configured to something other than 80 (for example 1234) then the port needs to be added to the IP address, separated by a colon (Le. "192.168.100.10:1234/mts").

The screenshot below shows the login screen for Manager Telephony System. In the "User" and "Password" fields, enter the username and password of the user created in Manager Provisioning or in Linux. If the user has not been created with the correct privileges, the rejection message "You are not authorized" is seen. Multiple users can login to Manager Telephony System at the same time. It is also possible to have multiple sessions with the same username and password.

Screenshot 1: Login to Manager Telephony System

6.6.2

Welcome Screen

The slide below shows the first screen, the welcome screen, after login. There is a main menu with the seven entries "Initial Setup", "Number Analysis", "Telephony", "Services", "System", "Tools" and "Logs". Clicking on one of the menu entries will show the appropriate submenu. A click on one of the entries there opens a task menu.

LZU 103 1013 Rev B

Page 8 of 24

Manager TS and Manager Provisioning

MX-ONE!MManager Sit",

Telephony System Logged In as MTSAthnUl About Site f¥1ap User

Inff;;SifulfIlklll¥;;wJlgTl-;~i~~ se&iteti Systm Tool;-W;;;=~-- -~-

This application hil.J1d1e"the system settingsfOftheMX.ONE 'reteohorw systern Fcr user setting" please use the "MX-ONE Manager Provi'iioning" application

Screenshot 2: Welcome Screen

The number of entries that are displayed in the main menu, the appropriate submenu and the corresponding task menu depends on the privileges of the user that logged on to Manager Telephony.

The next two screenshots show the task menu that will appear when "Telephony" - "Extensions" is clicked with highest (snlev7) and lowest (snlevl) privileges (snlevO is not allowed to log on). Please note that the prefered way to grant privileges should be Manager Provisioning rather than snlevx group membership.

Screenshot 3: Task menu of "Telephony" - "Extensions" with highest privileges

LZU 103 1013 Rev B

Page 9 of 24

Manager TS and Manager Provisioning

Screenshot 4: Task menu of "Telephony" - "Extensions" with lowest Privileges

Help is available wherever you are in Manager TS and there is even an user guide that can be viewed and downloaded (click on "User Guide" and in online view "Printable version" to download).

revtstcn -wiitlQut notice due to continued progress have no liability for any error or damage 01 any kind

Screenshot 5: Manager Telephony System User Guide

LZU 103 1013 Rev B

Page 10 of 24

AIlSTQA

Manager TS and Manager Provisioning

Screenshot 6: Manager TS User Guide download

LZU 103 1013 Rev B

Page 11 of 24

N1STQA

Manager TS and Manager Provisioning

6.7 Manager Provisioning

While MX-ONE Telephony Server is an application to provide the functionality of a telephony switch, another application (or suite of applications) is responsible for management of devices and user database, including additional functionality.

Applications like D.N.A. (Dynamic Network Administration) or CMG (Contact Management Application Suite) used to be used for this and until MX-ONE 3.2 it was the only alternative. (D.N.A. is not adapted for MX-ONE 4.0 and the combination of CMG and MP is replacing.)

In MX-ONE 3.2 Manager Provisioning was introduced as an web based application for user and extension management plus some additional functionality.

Manager Provisioning is a tool for user management in the MX-ONETM, used to configure and assign services to MX-ONETM users. Users are defined in one interface and then data is automatically propagated to the relevant components: Telephony Server, Messaging Server, CMG Server, Other management application, AMC Provisioning Server. Manager Provisioning also provides an import from and export to other data formats (DNA, CMG ... ).

Manager Provisioning has its own PostgreSQL database for storing information.

Manager Provisioning needs to be configured with one or several subsystems. The following subsystems are supported by Manager Provisioning:

1. Telephony Server

2. Messaging Server

3. Contact Management (CMG) Server

4. AMC Provisioning Server

5. Other management application

For communication with the subsystems, SOAP protocol is used. SOAP protocol is a simple XML based protocol to exchange information between applications over HTTP. For enhanced security HTTPS can also be used.

Basically MP can be seen as a "interpreter" that translates the configuration that is done in the graphical interface into SOAP and sends it to MTS. MTS on the other hand translates the received information into mml or Iinux-style commands and sends it to the MX-ONE Telephony Server.

Because of this it is extremely important to set the version of the subsystem to the correct value (especially after upgrades), since otherwise MP creates the wrong commands.

6.8 Manager Provisioning Installation Considerations

Manager Provisioning can be installed in 3 different scenarios:

o Stand alone

o Coexistence on Telephony Server 1

LZU 103 1013 Rev B

Page 12 of 24

Manager TS and Manager Provisioning

o Coexistence on Telephony Server X

The installation will run more ore less the same way in all three situations. There are just some considerations regarding security, performance (cpu and memory usage), limitations and costs.

6.8.1 Considerations regarding security

An MX-ONE Telephony Server is hardened during installation. The hardening increases the security of the server. Installing Manager Provisioning in coexistance on a server (lor X) means that Manager Provisioning benefits from the hardening of the Telephony Server.

However, if Manager Provisioning is installed on a stand alone server the hardening is not applied automatically during TS installation (since TS will not be installed) and must be done manually.

There are many alternatives how to apply a hardening. One could be to use the script that is doing the hardening of TS during installation. The script "hardening.sh" is stored in joptjeri_snjetcjhardening and the file "iptables" (containing the configuration of the firewall) is there also.

Another approach to apply hardening could be the usage of the "Bastille Unix" (formerly known as "Bastille Linux").

The installation of Manager Provisioning includes the installation of jboss application server (including web server) and the installation will prompt for whether to use HTTP or HTTPS.

6.8.2

Considerations regarding performance (CPU and RAM)

When Manager Provisioning is installed on a Telephony Server (lor X) it uses cpu and memory of the Telephony Server. Both applications compete regarding resources. Since java based applications like Manager Provisioning are known to use a lot of memory it is advised to have enough RAM in the system. If server 1 is used the size of RAM should be 2GB (or more) because on server 1 there is already the java based Manager TS installed. If Manager Provisioning is installed on server X there should be at least 1GB or RAM.

6.8.3

Considerations regarding limitations

When Manager Provisioning is installed on server 1 it will use the jboss application server that is already installed there (for serving Manager TS) which means that the same protocol (HTTP or HTTPS) is used. It is not possible to use different protocols for Manager TS and Manager Provisioning.

Furthermore it is not possible to start the Manager TS and Manager Provisioning independently from each other - starting one of both means the other is started automatically. This is because Manager TS as well as Manager Provisioning are just directories on a web server. As soon as the web server starts, all directories that are served by the web server are available.

LZU 103 1013 Rev B

Page 13 of 24

Manager TS and Manager Provisioning

(In fact Manager TS and Manager Provisioning are not directories on the web server but java archives but the behavior is - at least regarding this aspect - quite similar).

6.8.4

Considerations regarding costs

The conclusion of the above considerations is to install Manager Provisioning stand alone but this approach of course means to spend additional money for an additional server.

LZU 103 1013 Rev B

Page 14 of 24

AJlSTQA

Manager TS and Manager Provisioning

6.9 Manager Provisioning Installation

6.9.1 Prerequisites

Prerequisite for the installation of Manager Provisioning is a SLES10 SP2 installation with the xml file (autoinst.xml) provided by Aastra. Furthermore ethO needs to be configured (otherwise the port redirection with iptables is not established).

Since these prerequisites are automatically met when Manager Provisioning should be installed on a LIM, it is only an issue for the stand alone installation.

6.9.2

Manager Provisioning Installation Procedure

The Manager Provisioning installation is started by executing the mp_installxxx.bin file where xxx is indicating the version of Manager Provisioning.

This file can be executed as "root" or as "eri_sn_admin" where "root" is much more preferable since "eri_sn_admin" needs to run the file with command "sudo" and the /etc/sudoers needs to be updated to allow this. This task is performed by running the script "createMPuser" which is inside the bin file and needs to be unpacked first (by executing the bin file with option "-unzip"). After that the bin file needs to be copied to a special directory "/home/eri_sn_admin/mp_install_sw/" and renamed to "mp_install" (this is necessary to match the appropriate line in the /etc/sudoers file).

Conclusion: installation is easier as "root".

To start the installation process, log on as "root" and execute the bin file (in case of stand alone installation install SLES10 SP2 with xml file and configure ethO first):

Screenshot 7: Start installation of Manager Provisioning

LZU 103 1013 Rev B

Page 15 of 24

Manager TS and Manager Provisioning

Screenshot 8: Unpacking files ... please wait ...

Screenshot 9: Display version of rpm file.

LZU 103 1013 Rev B

Page 16 of 24

A4ST~A

Manager TS and Manager Provisioning

Screenshot 10: Installing rpm file ...

Screenshot 11: iptables ... create MP database

LZU 103 1013 Rev B

Page 17 of 24

Manager TS and Manager Provisioning

Screenshot 12: create SuperUser

Enter the first name, the last name and the user id of the system Super User. Super User has rights to all tasks within the system. This user will be created during installation; this user account cannot be removed.

Note! Moving between different lines happens with arrow keys and not with tab key.

Screenshot 13: Enter SuperUser password

Enter and confirm a password for the Super User. It can be changed later and it can be set (as root) without logging on to Manager Provisioning.

LZU 103 1013 Rev B

Page 18 of 24

Manager TS and Manager Provisioning

Screenshot 14: Creating first department

Enter the department name, location and a location description.

The Main department is also called the Root department; this will be the main department that all customer departments and users will be created under. This department can be changed later, but cannot be removed from system.

Location is needed for every subsystem and for every user. You may setup several locations but only one (Main location) during installation.

When the information has been accepted the installation is complete, the following window should appear.

Screenshot 15: Install finished

During the installation the following two log files are created:

o /var/tmp/mp_install.log

LZU 103 1013 Rev B

Page 19 of 24

Manager TS and Manager Provisioning

o /var/log/eri_mp_rpm.log

The script controlling the service is /etc/init.d/erijnp.

Upgrade of the Manager Provisioning software will be started in the same way as the installation was started. The system discovers if old software exists on the server and performs the upgrade instead of installation.

In any case when the upgrade is run a backup of the database will need to be performed prior to the upgrade procedure.

6.9.3

Manager Provisioning Post-Installation

In case that some data corruption occurs it might be necessary to repair Manager Provisioning data. Of course this can't be done in Manager Provisioning because it may not be possible to start Manager Provisioning or log on to Manager Provisioning.

The script for post installation tasks is (available in two locations):

o /home/eri_sn_admin/mp_config.sh

o /home/eri_sn_admin/mp_install_sw/mp_config.sh

Screenshot 16: Manager Provisioning Post-Install Configuration

Selection is made using space bar, several options may be chosen at the same time. Execution order is started from the lowest choice number.

The options on this menu are mostly self explanatory:

6.9.4

Configuration of the system

After installation basic data will need to be created. This must be performed in the correct order:

LZU 103 1013 Rev B

Page 20 of 24

A4STt1A

Manager TS and Manager Provisioning

1. Add locations.

Location is required during the creation of departments and subsystems.

2. Register subsystems. Name and setup of connection detail.

3. Modify User Defined Fields (UDFs) for departments as required.

There may be a need to comply with the customer's database to have specific UDFs.

4. Add or import departments.

These are the basis for user creation; they are located under the main (root) department created during installation.

5. Add or modify security profiles if needed.

For different user types the system has predefined security profiles, these can be modified on demand.

6. Add users and promote them to administrators with different security

profiles.

7. Add or modify service profiles if needed.

8. Modify UDFs for users if needed.

9. Add or import users and configure services for the users. lO.Perform a backup of the system.

LZU 103 1013 Rev B

Page 21 of 24

Manager TS and Manager Provisioning

6.9.5

Log in to Manager Provisioning

When logging onto the system for the first time the Super User account must be used. All tasks will then be available.

Screenshot 17: Manager Provisioning - log in

MX'()NE'J'Manager Sit",

PrOvtS!OtHJ1g Logged m as MPAdmin About Site Map User G

u~'L ~Ri¥~es" ,- ~M1om $Yam fliti'I h "Ownsi(ls ffi' ~r "''''¥ x ~ " "t: ;1; ~ :<ifu\WS\

Tnls application handles the user settings tee me MX-Or-lE

Screenshot 18: Manager Provisioning - Welcome

The "look and feel" of Manager Provisioning is absolutely similar to Manager TS. There is a User Guide for online viewing and for download.

LZU 103 1013 Rev B

Page 22 of 24

Manager TS and Manager Provisioning

26i1553-ANF90116UenPDl

© Gapyrig:ht Aesna 'recrmctcqrea Limited, 2009. All rights reserved.

Disclaimer

No part of ttlls document may be reproduced in any form Without the wnlten permission 01 tI1e copyright owner

TIle contents 01 Ihi:;; document are SUbject 10 revision Without nonce due to connnuec progress ill methodology. enc manufacturing, Aastra shall nsve [10. liability lor any error or damage or any kina resultlng from 1M

Screenshot 19: Manager Provisioning - User Guide

Screenshot 20: Manager Provisioning - User Guide download

LZU 103 1013 Rev B

Page 23 of 24

en c

c o Vl

.;;:

o "- 0..

"QJ

en 10 C 10 L "0 C 10

(f) f-

"QJ

en 10 C 10 L

c,
z
"0
C
ro
(f)
I-
z
(!)
g_ (/)
U
!....
(!)
~ ><
ill
0
:l ,..-t
.
\.0 -
.-
ra
...,
OJ
C
........
"tI
C
ra
E
E
0
u
c
0
01
0
-
""0
C
CO
!.....
Q)
Ul
::J
.j..J
CO
..c
.j..J
4-
0
0..
.-
..c
Ul
!.....
Q)
!..... ..0
Q) E !.....
Ul
::J Q) Q)
E Ul
X ::J
::J 0.. CL (f)
C ::J ~ f- CL
.-
- 0 ~ ~
Ul !..... Ul
CO 01 CO C C
>< .- .-
(f) (f) Ul Ul
C f- > f- .s: .:::t..
~ Q) ~ Ul Ul
0 -
c co co
:0 0 Ul CL 0 .j..J .j..J
U -I-' z .j..J E E
::::I c Q) C
01 - !..... !.....
I- -
0 c c CO 0 0 0
..., .- .j..J 4- 4-
III 01 CO CO Ul 01 !..... !.....
C 0 ..c 01 c 0 Q) Q)
1-1 _J U CO ........ _J CL CL <:j" N 4- o

<:j" N QJ en 10 0..

co > QJ

cc (Y) ,...;

o ,...;

(Y) o ,...;

A4STQA

Extensions

Chapter 7 - Extensions 2

7.1 Objectives 2

7.2 Glossary , 2

7.3 Process Description 4

7.4 Licenses and Number Series 5

7.5 View and Update Hardware §,.~/ ./~( G=e=lo='s=Ch=t=: 7=====~l

7.6 Information for ATS and DTS §,.~./ .{~G=e=lo=·sC=h=t:=9======:l

7.7 Initiate Analogue/Digital Extension §,.// { Geloscht: 10 1

7.8 Exercise: Analogue and Digital Extensions §,./ .. { Geloscht: 14 1

7.9 Information for Generic Extensions §,./ ./{ Geloscht: 15 1

7.10 Information for IP Extensions §,./ .{ Geloscht: 17 1

7.11 Exercise: IP Extension §,./ { Geloscht: 20 =-:J

7.12 SIP in MX-ONETM Version 4.0 §,./ { Geloscht: 21 J

7.13 SIP Extension §,.//., { Geloscht: 22 1

7.14 IP Phone configuration management via Manager TS §,../ .. ··lie'oscht: 25 )

7.15 SIP-INFO §,.~.//{ Geloscht: 28 1

LZU 103 1013 Rev B

Page 1 of 28

Extensions

Chapter 7 - Extensions

7.1 Objectives

The objectives for chapter 7 are:

D Describe the process of extension initiation. D Check licenses.

D Create number series for extensions. D Check hardware for spare equipment.

D Initiate analogue and digital extensions.

D Describe CLIP functionality of Dialog 4187 analogue telephone. D Initiate generic extensions.

D Initiate and register IP extensions.

D Describe and initiate SIP Extensions. D Define SIP-INFO.

7.2 Glossary

Acronym Definition
ATS Analogue Telephone Set
DTS Digital Telephone Set
ELU Extension Line Unit
GUI Graphical User Interface
HTTP Hyper Text Transfer Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
IPLU IP Line Unit
MP Manager Provisioning
MTS Manager Telephony System
RTP Real time Protocol
TS Telephony System
SIP Session Initiation Protocol
VOIP Voice over IP LZU 103 1013 Rev B

Page 2 of 28

Extensions

Conventions

o Commands or parameters in the text of the document are quoted in quotation marks, " ..... ". When using the commands and parameters on the command line, the quotation marks are omitted.

o Commands are shown in Courier 12pt bold. The command prompt is not bold.

LZU 103 1013 Rev B

Page 3 of 28

AIlSTQA

Extensions

7.3 Process Description

Extensions can be created and managed in Manager Provisioning and by command line in the MX-ONETM Telephony System.

Manager Telephony System (Manager TS) can be used to create number series, extension class of service and check for free equipment.

Manager TS and Manager Provisioning cannot be used for:

o Installing or updating hardware.

o Configuration of RTP resources.

Of- Command line can be used to configure extension and extension data for all extension

-If Manager can be used in addition to user

to provide GUI for extension management.

-If Manager Telephony can be used to number

series, create CoS and search for spare equipment.

IfGUI limitations - configuration that must be completed command

line - for

-Installrupdate hardware.

RTP resources.

Slide 1 Process Description

LZU 103 1013 Rev B

Page 4 of 28

Extensions

7.4 Licenses and Number Series

7.4.1 Licenses

Extensions are licensed. Each analogue, digital, IP, DECT, Mobile and ISDN extension to be initiated requires a license. Generic extensions initiated with a freeseating service license ("lic=2") also require a license and numbers initiated with freeseating and IP extension usage capability require two licenses (IP-EXTENSION and FREESEATING). Some of the FAL numbers for the relevant licenses are listed in the slide below.

The number of free licenses can be checked by comparing the "Allowed" and "Used" columns in the "license_status" print. If there are no free licenses, the commands to initiate extensions are rejected. You can also check this in Manager Provisioning in the subsystem task.

)f Extensions are licensed for pv~'m'~IA'

• FAL 1045303 ANALOGUE-EXTENSION

• F AL 1045502

• FAL 1045302

DIGITAL-EXTENSION IP-EXTENSION

""Check available licenses with:

I MDSH> license_status

Slide 2 Licenses

Chapter 6 describes the initiation of analogue, digital IP and SIP extensions. Information on ISDN and DECT can be found in ALEX. Chapter 9 covers Mobile Extensions.

LZU 103 1013 Rev B

Page 5 of 28

NlSTQA

Extensions

7.4.2

Number Series

A number series for extensions must exist prior to extension initiation. The number type "ex" is used for all extension types. Using the command line, the number series can be initiated, viewed and deleted from any LIM. Commands must be run from the mdsh shell.

Alternatively, the number series can be configured in the "Number Plan" submenu of Manager Telephony System.

Slide 3 Number Series

LZU 103 1013 Rev B

Page 6 of 28

AAtSTQA

Extensions

7.5 View and Update Hardware

A maximum of 4 analogue extensions can be initiated in a LIM with Media Gateway on the virtual ELU29 (board id=87). The LIM with Media Gateway does not support digital, ISDN or DECT extensions.

The number of analogue, digital and ISDN extensions supported by a Media Gateway Classic LIM is dependent on the number of ELU34, ELU33 and ELU26 boards respectively. Each ELU34jELU33 board can support 32 analogue (ELU34) or digital (ELU33) extensions. The number of DECT extensions is limited, indirectly, to the number of ELU31j3 boards.

A maximum of 128 ISDN extensions can be initiated in anyone Media Gateway Classic LIM.

The availability of boards in the LIMs can be printed with the "board_list" command. Use the "-lim" parameter to view the print a LIM at a time.

Analogue boards (virtual and real), digital and ISDN boards that have extensions initiated on at least one of the board individuals show "Assigned" in the "Status" column.

If the "board_list" command returns blank for any LIM, use the command "board_config -scan" command to update the board list. New boards, physically installed in the Media Gateway Classic LIM, can be registered using the "board_config -scan" command.

Use the MML command "syevp" to check for free individuals on the analogue, digital and ISDN extension boards. Alternatively, find spare equipment through the Manager TS GUI in the "System Data" submenu of "Telephony". Manager TS cannot be used to "scan" LIM hardware.

LZU 103 1013 Rev B

Page 7 of 28

'fTo list existing boards and "virtual" ):

I MDSH> board_list [-lim x]

If To find spare

I MDSH> syevp:type=kll;

Use Manager TS to search for free equipment:

Slide 4 View and Update Hardware for ATS and DTS

LZU 103 1013 Rev B

Extensions

Page 8 of 28

Extensions

7.6 Information for ATS and DTS

The slide below lists the information required to initiate analogue and digital extensions.

Free directory numbers and equipment can be printed with "suvip.numtvp=" and "syevp:type=" respectively.

Each extension needs a class of service or category. The category ("cat") controls the features and facilities that are available to the extension user.

For analogue extensions, the "type" parameter is always "elo", The "ltype" parameter for digital extensions varies depending on the telephone model. Use ALEX to check the "itype" number:

1:1 Dialog 4000 series telephones: itype = 25 - 37.

Consideration must be given to the number of RTP resources that are needed for inter LIM and external calls. The table in the slide below shows RTP resource usage for calls from an analogue extension in a LIM with Media Gateway (LIM1) and from an endpoint in a Media Gateway Classic LIM (LIM3).

All calls in or out from the Media Gateway Classic LIM (5 - 8) use an RTP resource on an IPLU board in that LIM if the calling/called party is non-IP. The use of an RTP resource in a LIM with Media Gateway LIM depends on the calling parties - calls in to or out from an IP extension or route do not use an RTP resource.

information for

• Directory numbers to use

• Hardware individual (e qu). -Class of service (cat).

of extension (type: el6 or .itype: model ¥RTP resource

and

extensions:

Slide 5 Information for Analogue and Digital Extensions

LZU 103 1013 Rev B

Page 9 of 28

Extensions

7.7 Initiate Analogue/Digital Extension

7.7.1 Initiate Common Category

Categories for analogue, digital and ISDN extensions must exist prior to initiating the extension. Use "exccs" to create a category and "exccp" to print category details. Categories can be created simply in Manager TS, in the "Extensions" submenu of "Telephony".

7.7.2

Initiate Extension

With the relevant information, the "extei" and "ksexi" commands are used to initiate analogue and digital extensions respectively. The commands must be run from the mdsh shell.

Slide 6 Initiate Analogue/Digital Extension

The "it" commands are used to initiate and manage ISDN extensions.

LZU 103 1013 Rev B

Page 10 of 28

~STQA

Extensions

7.7.3

Initiate Extension with Manager Provisioning

In Manager Provisioning application extension initiation is made via graphical user interface. The set up can be be during a creation of user (add services to him) or as an separate task to just define extension. The initiation is made in two steps the first one is used to define type of extension and the second one is to define categories, equipment position and so on for this particular extension.

'if. Using Manager Provisioning, 2 steps

initiation.

- Step 2/ 2

IP (SIP, H.:n3, Ip·OECT)

G~lll',raJ (t1ieJephcmv server: z?J Extension Number:

Backup Answering Position Number:

® Boss secretarv:

N~nu~ Identity MrsttMrtll":: last Name:

C!) personal Numb-er List:

Function Keys. Phonli!: T),p'e:

FvnctiQ:nKI':'Ys:

Slide 7 Initiate Analogue/Digital Extension with Manager Provisioning

LZU 103 1013 Rev B

Page 11 of 28

Extensions

7.7.4

Dialog 4187 Analogue Telephone

The MX-ONeM Version 4.0 supports the Dialog 4187 analogue telephone. The telephone supports presentation of calling line identity, that is, A-party name and number. The feature, known as CLIP (Calling Line Identity Presentation), is achieved via FSK (Frequence Shift Keying) signaling, between the telephone and the extension board ELU34. Name and number CLIP is only valid for extensions in a Media Gateway Classic LIM.

When connected to the Media Gateway, DTMF signaling is used between telephone and server. DTMF signaling only provides support for calling party number presentation.

Presentation (CLIP) via FSK.

~Offers Calling Line

• Connected to EUJ34 for FSK or DTMF signaling support e Connected to EMG for just DTIV1F signaling.

l,vaiting LED

~ speech and loudspeaker

integrated headset port. v amcnu

.{ 2 line x 21.1 alphanumerical display

)(- Date and time Integrated local ';f Alarm clock function :,.. 10 ring tone options.

Slide 8 Dialog 4187 Analogue Telephone

To enable name and or number presentation, the "icat" parameter is used in the "extei" command. Digits 1, 5 and 6 are relevant to calling line identity presentation.

LZU 103 1013 Rev B

Page 12 of 28

Extensions

If Instrument

Slide 9 ICAT for analogue extension

In Manager Provisioning two options are available for setup view basic and Advanced. The later one can be used for example to setup different instrument category values for one extension. The possibility is shown in slide 10 above.

LZU 103 1013 Rev B

Page 13 of 28

(/) co
c N
0
'00 "-
C 0
ill '>t
X .-l
ill Q)
(J)
C1l
0... - .-

III

+I OJ Q) .....,

C ro ...... ~ 't:J c III

E E o u

::J C

(f) u u X (])

(]) .....,

X (])

(]) .....,

X (])

(]) U L

::J o (f) (]) L

d

t

(]) U L

::J o (f) (]) L

I 0. .....,

L

(/) C o (/) c OJ .j.J

>< ui

ro .j.J

CJl o "'0 C rn

OJ ::J CJl o

ro c

«

OJ (/)

'0

L

OJ >< W

~

...... _J

19 ~

<, (/)

l.e u ro (])

C

(f) C o (f) C (]) .....,

X (])

(]) ::J OJ

o

ro C ro (]) .....,

ro :iJ

>ro

::;: (]) .....,

ro 19 ro u (])

z (]) s: .....,

C

(f) C o (f) C (])

.....,

X (])

ro

~

OJ

U

L

o

(])

::J

OJ

o

roi

c ...... ro_J

2 .~

ro (f)

~~ 50

~

...... _J

(])

E

ro (f)

(]) .e .....,

C

(f) C o (f) C (]) .....,

X (])

(]) ::J OJ o

ro C ro

C (]) (])

::;:

.....,

(]) ..0

ro u

ro

~ (]) U ~ (]) ro .e ~ U

(]) OJ ro (f)

::J (]) U L

::J o (f) (]) L

0. .....,

L

::;: (]) ";;:

o .....,

....., C .;::

0. (]) U L

::J o (f) (]) L

d

.....,

L

('.. u (]) (f) ::J (f) (]) U L

::J o (f) (]) L

0..

......

I C o C

ro o .....,

T-i

~

...... _J

C

C o

(f) C (]) .....,

X (])

(]) ::J OJ

o .

-~

ro ...... C_J

ro L C (]) ro.e

.....,

E 0 o C L ro

~c

(]) OJ ro (f)

::J

(]) U L ::J o (f) (]) L

0.

t

::;:

(])

s o .....,

....., C .;::

0.

(]) U L

::J o (f)

~ I 0.

t

('.. u (]) (f) ::J (f) (]) U L

::J o (f) (]) L

C

......

ro :iJ C (]) ::J 0- (]) (f)

E

o u C ro L '--'

Q) (J)

.~

Q) >< ill

c

.Q

(J) c Q) ...,

>< ill

C1l ±: (J)

o

u c C1l Q) :::J (J) _Q C1l c « o .-l

Q) :2 (f)

1:0 > Q)

IX (Y) .-l o .-l

(Y) o .-l

u (]) .....,

ro u o

ro (f) (]) U L

::J o (f)

~

0. t

(]) L ro

::;: o I

Extensions

7.9 Information for Generic Extensions

The slide below lists the information required to initiate generic extensions. Generic extensions can exist in their own right as freeseating or Mobile extensions or the generic extension can be used to create an IP extension.

Free directory numbers in the "ex" number series can be printed with the "suvip" command.

The common service profile data for each generic extension is stored in the LIM where the generic extension is initiated. The "home" LIM is not necessarily the same LIM where the freeseating/IP extension is subsequently logged on/registered.

Each extension needs a class of service or common service profile ("csp"). The common service profile, like the "cat" for analogue and digital extensions, controls the features and facilities that are available to the extension user. A common service profile for generic extensions must exist prior to initiating the extension. Use "extension_profile" to print existing csps.

Common service profiles can be viewed in the "Common Service Profiles" submenu of Telephony in Manager TS. In Manager TS, a csp is created with a name. New common service profiles are allocated a csp number, sequentially, from 0 - 256 by the application. For example, the csp named "Training" in the example below is the first and only csp. It would have been allocated csp=O.

Slide 11 Information for Generic Extensions

LZU 103 1013 Rev B

Page 15 of 28

Formatiert: Englisch ; (GroBbritannien)

rF~idi~nkti~~9~~~d~rtmmml

, ,

, , , ,

,

,

Extensions

7.9.1

Create New Common Service Profile

A new csp can be created by MML command ("extension_profile"), in Manager TS or Extension Manager.

7.9.2

Initiate Generic Extension

Generic extensions are initiated with the "extension" command.

if Use MML command or Manager TS:

MDSH> extension_profile -i --csp 0 --ext-traf 0103071514 --ext-serv 2121101000111011100 --ext-cdiv 001021000110

--ext-roc 222201 --ext-npres 000110

Of Initiate generic extension:

I MDSH> extension -i -d 1002 .. 1010 -I 1 --csp 0

Slide 12 Initiate Commands

LZU 103 1013 Rev B

Page 16 of 28

Extensions

7.10 Information for IP Extensions

An IP extension is created from an existing generic extension. IP extensions may have unique or a common password (but users cannot change their own password). Passwords are recommended to increase system security.

With the relevant information, the "ip_extension" command is used to initiate an IP extension. The commands must be executed in the mdsh shell.

The number of digital, H.323 and DECT correspond to the existing limits per media gateway/server in MX-ONE 3.2, but they can now be combined in one server and spread over multiple media gateways, it is therefore possible to initiate the maximum capacity for each of following in one and the same server.

This means that the MaXi Telephony Server can manage 5000 legacy and 10000 SIP/ME or 15000 SIP/mobile extensions, based on an "average user set-up profile".

An RTP resource is only needed for calls to analogue extensions and ISDN routes in the LIM. The RTP resource limitation would be a problem if there were multiple ISDN lines in the LIM. For example if three of the virtual TLU76/1 boards were configured, there would be 90 lines in the LIM. If the LIM was populated with IP extensions, the RTP resources would "run out" before there were no free ISDN lines.

The table below shows call scenarios when RTP resources are used.

information for IP extensions:

• Directory numbers to use (d ir ) .

• Password :

> If needed setup 2S local authorization code. > auth_codejnil

\( MML command:

IIVI~s~~i~~extension=i __ d 1002

LZU 103 1013 Rev B

Page 17 of 28

Extensions

·If-IP extension setup with Manager + Generic + IP in a same page.

Slide 13 Creation of ip extension

As other user service types also IP extension can be setup using Manager Provisioning. With aid of this application the generic extension with common service profile (category) together with other features like name, groups he belongs to and other needed services can be implemented via one information page. Viewing and changing of these settings can easily be made via this GUI as well.

LZU 103 1013 Rev B

Page 18 of 28

Extensions

7.10.1 Register IP Extension

The Gatekeeper address for IP extension registration may be configured manually. The Gatekeeper address is ethO of the Telephony Server.

With a DHCP server in the customer LAN, the majority of the IP addressing information required to configure the "Network" data in the IP telephone is supplied automatically.

Automatic Gatekeeper discovery and load distribution are supported in MXONeMo

To find the IP address of the acting Gatekeeper, either:

D Check the Gatekeeper setting in the Network menu on the IP telephone.

D Use a web browser to check the IP telephone configuration under Network/Settings. To browse the extension configuration, enter the IP address of the telephone (print in "ip_extension") into the address bar of a web browser. At the login page, type "Ericsson" (without quotation marks) in the login field. The web browser can be used to re-register the extension toward another Gatekeeper if required.

·IP address of the • Extension number and numerical

if to (can

'IP subnet mask and default gateway.

·IP address of the SW server 'IP address and port number for SW proxy server (optional).

-set--gatekeeper-auto-ciiscovery

Slide 14 Register IP Extension

LZU 103 1013 Rev B

Page 19 of 28

(J) c o '00

c Q)

X w

III ..... Q)

o ........ "C C III

E E o u

(]J ....... ro :;::;

c

I c o U1 C (]J .......

>< (]J

c o

U1 C (]J .......

>< (]J

c o U1 C (]J .......

x (]J

I o,

(]J

~

:::J o U1

~ I o,

t

(]J U L

:::J o U1 (]J L

I o,

t

(]J U L

:::J o U1 (]J L

I o,

t

c o Vl C QJ +J >< W

c,

~

e o :;; u ::s L. ..... II! C ....

:E:

......

_J

19 :E:

- {f)

I..c: u CU (]J

C

U1 C o U1 C (]J .......

>< (]J

c,

......

(]J ....... CU

±: c ......

"0 C CU

:E:

...... _J

(]J

E

cu U1

(]J ..c: .......

U1 C (]J

.......

>< (]J

c,

......

c (]J (]J

~

....... ""

(]J U1

..o:E:

~~

u c CU (]J

(]J g!

.:Y. > CU .......

:E:15

c

(]J 01 cu U1 :::J

(]J U L

:::J o U1 (]J L

c,

~

~ (]J

> ('0.

.8~

U1 U1 ....... :::J

C U1 "C (]J O_U

L (]J :::J U 0 L U1

i5 ~ gj:E:

L ......

I_J O_L t (]J

....... .:Y.C U·_

(]J >..c:c U CU

c o U1 c

2

>< (]J

(]J :::J 01

..2

cu c cu

"0 C cu

c

.Q

U1 c (]J .......

>< (]J

c,

......

c ro

c (]J (]J

~

....... (]J

..0

-

-

cu u

(]J 01 cu U1 :::J

"0 L

cu o ..0

(]J U L

:::J o U1

~

o,

~

~ (]J

S o .......

U1 ....... C ·c o,

(]J U L

:::J o U1 (]J L

I o, ....... L

c cu

o .......

rl

:E:

......

_J

c:E:

...... c_J

o L

"Vi 1!

c ....... (]J 0

x c (]J CU

o, c

...... -_

L C (]J 0

£3 'Vi

o C C (]J

cux E (]J o CU J::±: _01

(]J 01 CU U1 :::J

"0 L

CU o ..0

(]J U L

:::J o U1

~

U1 C o

(J) N

"-

o

o N Q) OJ <1J c,

c

.Q

(J) c Q)

~

>< ui

c,

......

('0. "0 (]J U1 :::J

U1 (]J U L

:::J o U1 (]J L

00 > Q)

0::: (Y) M o M

(Y) o M

:::> N ...J

Q) .~ u '-

Q)

x w

l[) M Q) :2 If)

Extensions

7.12 SIP in MX-ONeM Version 4.0

SIP is a protocol, designed by the IETF and derived from HTTP, specifically for Internet-based VoIP. There are many resources on the web providing comparisons between SIP and H.323. Some comparisons are written favoring SIP, some favor H.323. Both technologies are still current and are continually being developed and improved.

Telephony Server 4.0 and Media Gateway Classic support SIP extension and SIP trunks.

The SIP protocol was introduced in MX-ONETM mainly to provide support for WLAN terminals, analogue terminals via desktop gateway and connection of third party SIP terminals.

The Aastra Dialog 4000 and 5000 range of IP telephones, as listed below, are both SIP and H.323 compatible.

use on Internet-

of applications.

in servers with MG and SIP is

• WLAN terminals.

terminals via "'''"'''''',,,,J

(DRG).

• Connection of third party SIP terminals.

SIP IP

• DBC 420 .323 and SI

e DBC 422 (H.323 and SI

• DBC 425 (H.323 and

• DBC 446

• Wireless

© Aastra - 2009 -1 S

Slide 16 SIP in MX-ONETM Version 4.0

LZU 103 1013 Rev B

Page 21 of 28

Extensions

7.13 SIP Extension

SIP extensions are supported in both Media Gateway LIMs and Media Gateway Classic LIMs. There must be a sufficient number of IPLUs in a Media Gateway Classic LIM to provide RTP gateway resources, not only for interLIM traffic, but also for the SIP extensions. The same IPLU can be used for interLIM calls and calls between SIP and non-SIP extensions in the same LIM.

SIP extensions support basic call, and caller ID (name and number).

SIP and H.323 extensions may coexist in the same LAN and in the same LIM. Calls between SIP and H.323 extensions are not direct media calls. A gateway resource is required to translate SIP traffic to H.323 traffic and vice versa. Calls between SIP and H.323 endpoints are always gateway calls.

Although a mix of H.323 and SIP extensions is technically possible, it is not advisable. The functionality differs between H.323 and SIP extensions, because of the differences between the signaling protocols. Users will be unaware of what type of extension they have and may expect to have functions that are not available or have to be executed differently.

The program unit handling the signaling and traffic for SIP extensions is called SIPLP.

server > IPLUs required in Media offer

Classic with LSU-E. caller name and

to

similar

> In same LAN,

> In same server - calls between SIP and H,323 endpoints do not have direct

media connection. Calls are calls.

-* advisable to SIP H in same

> Calls between are

> Due to differences in extension differs,

> Users, unaware whether their extension is SIP or H,323. may expect to have functions that are not available.

* PU P extension SIPLP.

© Aastra - 2009 19

Slide 17 SIP Extension

LZU 103 1013 Rev B

Page 22 of 28

A4STQA

Extensions

7.13.1 Initiate SIP Extension

SIP extensions are initiated using a procedure similar to the procedure used for H.323 extensions:

o Initiate generic extension with "extension" (a csp must be initiated with "extension_profile" before "extension" can be executed).

o Assign an IP extension number to the generic extension with "ip_extension".

o Edit the telephone configuration file for SIP protocol usage.

o Download the new configuration file to the telephones.

o Select "SIP" in the telephone menu.

.shoV\J?an.exarnpl.e . .ofa.configuratic)rlJilethClthas .. tJ~~rl .. ~dited .. t().deRI()y .. SIP. on the IP telephones in the system.

LZU 103 1013 Rev B

Page 23 of 28

1 ~eI6scht: 'II

A&STQA

Extensions

The table below explains the fields that must be completed in the file:

Field Name Explanation
SIPProxyAddress Up to 5 SIP proxy server addresses can be stated. The IP
telephone uses the first available server after searching
from the first SIP Proxy Address downwards.
SIPProxyPort Each SIPProxyAddress has an associated port number.
SIPUseTelAddress When "NO", the signalling address number format is to be
"SIP: name".
SIPHookFlash Defines how to send hookflash to the exchange and how
SIP _DTMF to carry DTMF tones to the MX-ONeM • The semicolons at the start of each field must be removed to enable the data in the field to be read. The file is saved in the appropriate directory on the web server. When the telephones are rebooted, the edited configuration file is downloaded by all telephones and the new SIP settings take effect.

LZU 103 1013 Rev B

Page 24 of 28

Extensions

7.14 IP Phone configuration management via Manager TS

IP Phone configuration file handling is made available via Manager TS application. This applies only to Dialog 4000 version 2 and Dialog 5000 version 1 IP Phones abd the 67xxi phones.

The application has a new tab named "IP Phone". The tab includes the following functionalities: Please update, it contains more ...

1:1 IP Phone Administrator 1:1 Telephony Domain

1:1 SW Server

1:1 Configuration file

The first one is used to have an overview of the connected IP phones and there status. Via Telephony Domain session you may set up the data to create or change Telephony Domains for the IP phone users.

SW server is used to store the configuration files for IP phones and used by them to fetch their configuration and possible updates for the phone firmware.

Using the configuration file setup needs some preparation prior its usage. The IP Phone Software Server Application software server must be installed using following application available in Aastra Info Channel (Linux version exists later):

for

Info

installed in www-server.

Slide 18 IP phone configuration handling via Manager TS

LZU 103 1013 Rev B

Page 25 of 28

Extensions

The software installation installs Management Software and it includes Apache Tomcat web server software which is essential when using Manager TS for the phone configuration handling. After the software is installed it is needed to configure the web server software to use port 80 instead of the default port 8080. For this change the application service must be stopped. This can be made via a control panel:

select services/Jakarta-tomcat; stop the service

In a directory "/Jakarta-tomcat/confj" a server.xml file can be found. Open it using Notepad and find the lines stated in following slide and edit the port number to "80". After the change is made the service can be started and the web server should be ready for usage .

.of. 'I/VWW-server • Root

• Configuration defaults to port 8080

'f Configuration (jakarta-tomcat service be

stopped/restarted) .

• Stop the

• Directory with noteoao and

port value

• Restart the service

<Connec e="org.apache.coyote.tomcat4.CoyoteConnector"

port="SOSO" inProcessors="S" maxProcessors="7S" enablelooku ="true" redirectPort="S443"

i'roCElj;!.tQ~rt:= "100" debug ="0" connectionTimeout= "20000" useURIValidationHack="false" disableUploadTimeout="true" />

Slide 19 WWW-server installation

Next step is to download from the Aastra Info Channel the corresponding IP phone software files. These files must be stored under jakartatomcat/ROOT/dbc42x02 directory or Jakarta-tomcat/ROOT/dbc44xOl but without any configuration file. Thus the software consist of

D Application file D Boot file

D Language file.

Now the software server is prepared and the Manager TS software can be used to point out the server in SW server task. Setup the name for the server, IP address for the server and the used port number (80).

LZU 103 1013 Rev B

Page 26 of 28

Extensions

Slide 20 WWW-server setup in Manager TS

After the sw server setup was made it is time to start the creation of the IP phone configuration file via the configuration file task. The creation of a configuration file results the corresponding files to be created under the sw server ROOT directory. After configuration file was created via Manager TS they can be handled (change, delete, check) with the same software.

Slide 21 WWW-server setup in Manager TS

LZU 103 1013 Rev B

Page 27 of 28

Extensions

7.15 SIP-INFO

SIP-INFO is the method by which session related control information, generated during a SIP session (= telephone call), is carried. SIP INFO is used to signal DTMF digits for the request of services such as parking, transfer and conferencing.

Any SIP terminal with support for SIP-INFO will have the same level of services and functionality as a Mobile Extension. There is no display support for SIP terminals with the exception of A-number presentation.

'4 .. Method which session related control information, n""'"lAr·",t~,rl

a session (=call) is carried. '4Signais DTMF digits for service requests conferences

*,SIP terminals with support for SIP-INFO have same level of as a Mobile Extension.

Slide 22 SIP-INFO

LZU 103 1013 Rev B

Page 28 of 28