Ot2.6 SD Generalarchitec 8AL90509USAG 1 en

OpenTouch Solutions
General Architecture
Release 2.6 - March 2020
8AL90509USAG Ed. 01
Legal notice
The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. To view other
trademarks used by affiliated companies of ALE Holding, visit: http://www.al-enterprise.com/en/legal/
trademarks-copyright. All other trademarks are the property of their respective owners.
The information presented is subject to change without notice. Neither ALE Holding nor any of its
affiliates assumes any responsibility for inaccuracies contained herein.
© 2020 ALE International. All rights reserved. http://www.al-enterprise.com
Disclaimer
While efforts were made to verify the completeness and accuracy of the information contained in this
documentation, this document is provided “as is”. To get more accurate content concerning Cross
Compatibilities, Product Limits, Software Policy and Feature Lists, please refer to the accurate
documents published on the Business Partner Web Site.
In the interest of continued product development, ALE International reserves the right to make
improvements to this documentation and the products it describes at any time, without notice or
obligation.
The CE mark indicates that this product conforms to the following Council Directives:
• 2014/53/EU for radio equipment
• 2014/35/EU and 2014/30/EU for non radio equipment (including wired Telecom Terminal
Equipment)
• 2014/34/EU for ATEX equipment
• 2011/65/EU (RoHS)
• 2012/19/EU (WEEE)
Table of
contents General Architecture
Chapter 1
Reference documents
Chapter 2
Introduction
2.1 Scope.....................................................................................................................................................10
2.2 Overview.............................................................................................................................................10
2.3 High level architecture diagram.................................................................................. 10
2.4 System architecture components overview....................................................12
2.5 Commercial packaging using the OpenTouch..............................................14
2.5.1 Bare metal packages........................................................................................................................ 14
2.5.2 Virtualization packages.................................................................................................................... 15
Chapter 3
Topology aspects
3.1 Overview.............................................................................................................................................16
3.2 Telephony.......................................................................................................................................... 16
3.3 Applications.................................................................................................................................... 19
3.4 Localization..................................................................................................................................... 19
3.5 OpenTouch Networking.......................................................................................................20
8AL90509USAG - Ed. 01 - March 2020 - General Architecture 3/59

Table of
Chapter 4
Mobility/Remote Access
4.1 Use cases.......................................................................................................................................... 22

4.2 Edge elements.............................................................................................................................. 22
4.3 Edge FQDN blueprint............................................................................................................. 23
4.4 Remote Access Topologies.............................................................................................26
Chapter 5
Ecosystem integration (Microsoft, Google)
5.1 Microsoft............................................................................................................................................ 29
5.1.1 On customer premises..................................................................................................................... 29
5.1.2 Cloud integration................................................................................................................................. 33
5.2 Google.................................................................................................................................................. 34
Chapter 6
Openness
6.1 Functional API.............................................................................................................................. 36

6.1.1 Architecture............................................................................................................................................36
6.1.2 Compatibility/versioning...................................................................................................................36
6.1.3 Security.................................................................................................................................................... 36
6.1.4 Published services and Licensing...............................................................................................37
6.2 Configuration API...................................................................................................................... 40

Table of
Chapter 7
Operation, Administration, Maintenance and Provisioning (OAM&P)
7.1 Overview.............................................................................................................................................41
7.2 OAM&P Functions.................................................................................................................... 42
7.2.1 Configuration Management............................................................................................................42
7.2.2 Device Management..........................................................................................................................43
7.2.3 Performance Management.............................................................................................................43
7.2.4 Fault Management..............................................................................................................................43
7.2.5 Trouble Management........................................................................................................................ 44
Chapter 8
Security
8.1 Security Management............................................................................................................45

8.1.1 Authentication....................................................................................................................................... 45
8.1.2 Authentication configuration.......................................................................................................... 45
8.1.3 User authentication credentials....................................................................................................46
8.1.4 Authorization configuration.............................................................................................................46
8.1.5 Digital certificates management...................................................................................................46
8.2 Functional security.................................................................................................................. 47
8.2.1 Media Applications Encryption..................................................................................................... 47
8.2.2 Applicative flow encryption............................................................................................................. 48
8.2.3 Management flows encryption......................................................................................................49
8.3 Vulnerability management integration..................................................................49

Table of
Chapter 9
Licensing
9.1 Non virtualized OpenTouch............................................................................................. 50

9.2 Virtualized OpenTouch......................................................................................................... 51
9.2.1 Embedded license server............................................................................................................... 51
9.2.2 Centralized/External license server........................................................................................... 51
9.3 License fault control and consequences...........................................................54
9.3.1 Time bound licenses and grace periods verification..........................................................54
9.3.2 Consequences of license inconsistencies.............................................................................. 54
9.3.3 Consequences of corrupted, unreadable or unaccessible licenses...........................57

Chapter
1 Reference documents
The OpenTouch documentation consists in separated documents, each corresponding to a specific

aspect of necessary and optional installations/administrations.
The full set of all available documents is updated every week and can be accessed on the BPWS TDL.
In the present document, cross-references are identified by the number in the first column of the table
below.
Part numbers are given in the last column, where the first two xx correspond to the language code of
the document, and yy to the incremented edition of the document.
The documents for OpenTouch are:
table 1.1: OpenTouch documentation structure
Documentation title Part number
[2] OTMS Installation Manual on a Physical Machine 8AL90512xxyy

Summary: this document describes the software layout of an Open-
Touch Multimedia Services on the provided hardware. Hardware and
software installation are explained in detailed procedures. Post installa-
tion, connection and the basic configuration are also described with
procedures. Software major and minor updates are explained and trou-
bleshooting guidelines are provided.
[3] OTMS Administrator Manual 8AL90505xxyy

Summary: this document describes all the necessary procedures to im-
plement an OpenTouch Multimedia Services system: from user configu-
ration to advanced applications, devices (including video devices), con-
ferencing and collaboration features, as well as call restriction manage-
ment. CAC management, backup and restore procedures and IP flows
are also detailed.
[4] Installation Manual on a Virtual Machine 8AL90507xxyy

Summary: this document describes prerequisites and topologies for an
installation of the system on a virtual machine. The installation proce-
dure is described in detail for every system element. License manage-
ment and license updates are also explained. Appendixes provide
guidelines on the recommended software installation tools.
[6] OpenTouch General Architecture 8AL90509xxyy

Summary: this document presents the available systems in relation to
the actual customer needs. Topologies and software architectures are
presented for OpenTouch Multimedia Services, and the native contact
center. Hardware compatibilities are detailed per system.

Chapter 1 Reference documents
[7] OpenTouch System Documentation 8AL90510xxyy

Summary: this document describes the services and applications spe-
cific for OpenTouch users, including the One Number Service. It also in-
cludes up-to-date recommendations on system security, certificates,
encryption and best practices.
[8] OpenTouch Maintenance and Supervision 8AL90511xxyy

Summary: this document describes the available tools to monitor and/or
troubleshoot the OpenTouch and its ecosystem. This document also
provides guidelines on the maintenance portal and the supervision of
server(s), devices and calls. A list of useful maintenance command is
included, with explanations and examples.
[11] Description of IP flows in OpenTouch solution 8AL220303381xxy

y
Summary: this document describes the IP flows involved for the sys-
tem. This allows to configure firewall rules precisely, to open the optimal
amount of ports required for an operating OpenTouch system, accord-
ing to customer requirements.
[12] OpenTouch Web Services Technical Overview 8AL90532xxyy

Summary: this document describes how to develop, integrate and de-
ploy third party applications with an OpenTouch, via API. This docu-
ment includes a description of the available web services as well as in-
formation on authentication and licensing.
[15] OpenTouch Client Administration Manual 8AL90638xxyy

Summary: this document describes the implementation of an Open-
Touch ecosystem for clients connecting from remote locations. It also
provides deployment and configuration procedures, for each client on
PCs, smartphones, or from the web.
[16] OTMC Installation Manual 8AL90120xxyy

Summary: this document describes the installation of an OpenTouch
Message Center server on a physical server or on a virtual machine.
Procedures detail the various steps of installation, as well as post-in-
stallation, initial configuration on an OmniPCX Enterprise, TUI configu-
ration and software upgrades.
[17] OTMC Administrator Manual 8AL90121xxyy

Summary: this document provides all the necessary configuration pro-
cedures to implement an OTMC, from voice mail and user profiles, to
mailboxes, e-mail, sms notifications, automated attendant, VPIM, IMAP
and backup/restore.
[20] OpenTouch Conversation for PC User Guide 8AL90631xxyy
[30] OpenTouch Conversation for iPhone Release User Guide 8AL90884xxyy

Chapter 1 Reference documents
[31] OpenTouch Documentation Note 8AL90911xxyy

This document lists all the modifications and updates since the previous
documentation release.
[34] ALE NFC Extended OXE Mobility Administration 8AL90614xxyy

Summary: this administration manual describes the implementation of
transparent call shifts from a device to the other via NFC tags. NFC tag
generation is detailed with screenshots from the application.
[36] OpenTouch Session Border Controler Configuration Guide 8AL90065xxyy

Summary: this document describes the implementation of this server to
control media (voice/video) communications between OpenTouch client
applications used off-site and the OpenTouch server, so as to secure
the system. Installation, configuration and maintenance procedures are
detailed in this document.
[37] OpenTouch Suite for MLE in virtualized environment, overview TBE031

This pre-sales document describes the OpenTouch Suite for MLE prod-
ucts virtualization capabilities and the main principles regarding FlexLM
deployment
[38] Virtualization Design Guide TBE043

This pre-sales document describes the deployment of OpenTouch Suite
for MLE products in a virtualized environment
[39] S.O.T. 8AL90559xxyy

Summary: this document describes the implementation of this deploy-
ment tool in the various compatible topologies. This documents in-
cludes requirements and procedures to install each software, among
which the OpenTouch solutions. Software deployments and updates
are explained for physical and virtual machines.
[40] OXE System: Dedicated Sets 8AL91024xxyy

Summary: this document provides a detailed description of the propriet-
ary sets and generic sets (including heavy-duty sets), available for the
OmniPCX Enterprise.
These telephones sets can be TDM, IP or mobile. Ergonomics, environ-
mental constraints, power supply, initialization and configuration are ex-
plained for each set.
[41] User Services 8AL91003xxyy

Summary: this document describes how to implement basic telephone
features such as broker call and transfer, as well as more advanced
collaboration features such as call pick-up, conferences and twin sets.
Each feature is presented in a separated chapter providing a descrip-
tion, the necessary configuration and, if need be, how to operate it.

Chapter
2 Introduction
This document describes the general architecture on which OpenTouch is built. It explains the role and
responsibilities of each system components and how they collaborate with one another. It is
recommended as the first document to read for anyone new to OpenTouch and interested into
understanding how it works.
2.1 Scope
This document describes the architecture, as implemented in the OpenTouch solution, release 2.6 or
higher. It corresponds to the commercial offer that is described in details in the Product Offer
documentation available on BPWS.
The following paragraphs provide a high level but complete view of OpenTouch architecture.
2.2 Overview
The OpenTouch communication solution is a client-server software solution providing a broad range of
communication services to enterprises. It is made of various technical components that are combined
and configured to deliver various commercial packages. Its current release addresses Customer
Premises Equipment (CPE) or hosted deployments, for a population of up to several thousand users. It
provides applicative and multimedia services to users over multiple devices, including the range of
OpenTouch Conversation clients and business phones. The available features range from basic audio
communication to multi participant audio/video collaboration sessions. The OpenTouch integrates with
the enterprise eco-system (mail, directory, AAA etc.) and is administered by the OmniVista 8770.
OpenTouch services are available for users who require advanced business telephony features and
whose devices are controlled by the OmniPCX Enterprise. Applicative services are provided by the
OpenTouch.
OpenTouch users are powered by OTC clients, available for desktop and mobile platforms.
2.3 High level architecture diagram

From a high level architecture point of view, the OpenTouch solution is made of three sub systems:
• The Communication Infrastructure sub-system
• The Applications sub-system
• The OAM&P subsystem

Chapter 2 Introduction
OpenTouch Clients Web clients
SIP
OTC
Mobile OTC OTC
PC Web
8770
HTTPs HTTPs
Published
APIs
OXE devices OpenTouch Server
Applications sub-system
Eco system
NOE/IP- LINK/SIP....
OAM&P sub-
system
SIP trk+
OXE
CSTA/PRS… Communication Infrastructure sub-system
….
Figure 2.1: OpenTouch sub-system overview
The Communication Infrastructure sub-system is in charge of providing all means to support

multimedia communications, both internally and externally, to the enterprise and media processing.
Support of external communications relies on the OmniPCX Enterprise, used as a gateway to other
networks for applicative services. The Communication Infrastructure also provides audio and video
processing capabilities. It mainly interacts in SIP and RTP with other pieces of equipment and offers an
applicative interface (SIP-CSTA/VxML) to the Application sub-system. The communication
infrastructure can be seen as the SIP and RTP engines of the OpenTouch.
The Application sub-system is made of a collection of applications that run natively on OpenTouch.
They implement a rich set of unified communication and collaboration features, on a user-centric multi-
device model. They make use of the Communication Infrastructure sub-system to interact with devices,
gateways and media servers.
The OAM&P sub-system is in charge of providing management facilities to every components of the
solution and to the solution itself. It centrally manages alarms, faults, licensing and performances, and
provides a repository for configuration data. It also provides solution control and device management.
The OpenTouch is ecosystem friendly by supporting standards for IT services (SNMP, Radius, etc.) and
telecom services (SIP and others).

Corporate
LDAP
Directories
3rd Pty On-Site
Fixed SIP OTC-PC
OTC-WEB IP-Touch
80x8
S4B + OTC
S4B Pane
Microsoft
Exchange
email Server
email server
Microsoft
OXE + MGW Legacy
DMZ devices
HTTPs Fax Server
(SAGEM T37
Reverse Fax oIP T38)
Google Proxy
OT-SBC
3rd Pty (SIP+Media) OT Servers
Fixed SIP
OTC-WEB OTC-PC OTC iPhone (dual mode)

OTC Android
Off-Site OTC - iPhone (dual-mode)
Remote user OTC Android
Figure 2.2: OpenTouch components
2.4 System architecture components overview

This picture below represents all the system components that form the OpenTouch.
Each blue box represents a system component that belongs to the OpenTouch solution and is part of
the ALE International solution delivery. These components are developed and improved over time by
ALE International. The solution centralizes solution management as much as possible. However
internal components of the OpenTouch server core can be configured by solution administrators, for
some specific features and logs.
Green boxes represent OmniPCX Enterprise solution components that the OpenTouch complements
to enrich OmniPCX Enterprise/OpenTouch users with Unified Communication and collaboration
features.
In addition to system components, the OpenTouch can also interact with eco-system components
found into the enterprise. These are video systems, e-mail and directory servers, AAA. Some have
been represented below by Red boxes. Some network and security infrastructure elements are
necessary for several use cases, and may either rely on existing IT infrastructure, or be brought by the
OpenTouch solution in the form of OEM (e.g. OTSBC), or partner products (e.g. NGINX-Plus Reverse
Proxy).

OpenTouch System Components
OpenTouch Software Clients OT Web clients
OTC OTC
OTC Smartphone Desktop Web
8770 NMS Outlook

OpenTouch Server extension
Applications sub-sys
OXE Devices/Apps
Control
Sol.
extension
ICS ACS
OAM&P sub-sys
4059EE OXE video

Infra
device
ACS
Communication Infrastructure sub-sys

3p video
Infra
OT
SIPS XS VM-SIPS AMS Email

server
OXE
Directory
server
Reverse SBC
OXE PCS OXE MGW Proxy
Figure 2.3: OpenTouch system components
The OpenTouch server is the core of the solution, implementing UC&C services for users The
description of the OmniPCX Enterprise solution and OmniPCX Enterprise telephony devices is out of
the scope of this document.
OpenTouch clients deliver OpenTouch services to users from a vast variety of platforms, mobile and
desktop, and interact with the OpenTouch via web services for applicative services, and SIP for media
services (with OmniPCX Enterprise). The desktop client is complemented with a set of plug-ins that
allow integration to existing Microsoft or Google environments, enabling to easily reach OpenTouch
services from other applications. OpenTouch APIs further enables integration of OpenTouch services in
other métier applications.
The OTC Web client enables anyone, who has been invited, to reach OpenTouch, by simply clicking an
URL, from inside or outside the company (through a Reverse Proxy/SBC in the latter case). It supports
browser based WebRTC VoIP for external participants.
The Alcatel-Lucent OmniVista 8770 Network Management System application is the central
management point for the OpenTouch solution, interacting with OpenTouch and OmniPCX Enterprise
nodes for operation, administration, maintenance & provisioning.
Edge elements, reverse proxy and OpenTouch SBC, enable OpenTouch users with mobility/remote
access, and providing OpenTouch conferences to external participants (corporate and non-corporate
users).

2.5 Commercial packaging using the OpenTouch

The OpenTouch technical solution is used to deliver a number of commercial packages to address
different market segments and business needs.
OpenTouch packages can be deployed as bare metal or entirely virtualized under VMWare in their
OTxx–V version.
2.5.1 Bare metal packages

table 2.1: OpenTouch Bare-metal packages
OTMS OTMC
Subsystem 5000 users 15000 users
OXE
8770 + OTCC-SE (optional)
OT core Linux Linux
Messaging only
DCS (optional) Windows Desktop under KVM

OXE-MS (optional)
Flex Server Embedded within OT core Embedded within OT core
Protection ALUID ALUID
Prepackaged Appliance Dropped since 2.2
Software only
OTMS - OpenTouch Multimedia Services

The OpenTouch Multimedia Services is an add-on package addressing the large market segment,
necessarily deployed with an external OmniPCX Enterprise or an OmniPCX Enterprise network. A
separate OmniVista 8770 server provides unified management for the overall population, of up to 100
thousand users or 600 nodes.
Users have their devices handled by the OmniPCX Enterprise
Users of extra OmniPCX Enterprise nodes may also benefit from applications provided by the
OpenTouch Multimedia Services appliance.
The package includes an optional Document Conversion Server (DCS), hosted as a KVM process
within the OpenTouch core Linux.
The package is distributed as software only, to be deployed on a server provided by the customer.
Since R2.2, it is no longer available on prepackaged appliance servers.
The number of media ports or resources is only limited by the server capacity. The use of OpenTouch
Capacity Planning, introduced in R2.1, is mandatory to determine server requirements, driven by
provisioning level, options and deployment conditions.
OTMC – OpenTouch Message Center
OpenTouch Message Center is an add-on package dedicated to voice messaging and Automated
Attendant capabilities. The OpenTouch Message Center targets OmniPCX Enterprise configurations in

the mid to large market segment, aiming at replacing both the existing 8440 and 46x5 external voice
mail systems.
Note: In the early stages of the project, the OpenTouch Message Center was initially named OTVM.
For this reason, the OTVM acronym may still appear in some documents.
The OpenTouch Message Center package is built on OpenTouch technology and benefits from all
OpenTouch enhancements and capabilities (e.g. double release deployment, HA, virtualization
capabilities, management from the OmniVista 8770, performance monitoring) and to leverage voice
messaging developments with local storage voice mail through telephony and web access – no unified
messaging is supported.
Other packages
In addition to pure OpenTouch packages described above, the OpenTouch solution optionally relies on
additional components enabling remote access to OpenTouch services, further described in Mobility/
Remote Access on page 22:
A Session Border Controller (OTSBC)
A reverse proxy – 3rd-party AAPP element, replaces the OpenTouch® Edge Server altogether, as of
R2.2.1
2.5.2 Virtualization packages

OpenTouch solutions can also be bought to be deployed as VMWare 5.x and 6.x virtual machines on
physical servers provided by the customer. In this case, each subsystem constitutes a separate virtual
machine (VM).
The OTMS-V is the virtualized version of an OpenTouch Multimedia Services package, except for the
Windows-based DCS, which is necessarily deployed as a separate virtual machine.
The OTMC-V is the virtualized version of an OpenTouch Message Center package.
table 2.2: OpenTouch Virtualized packages
OTMS-V OTMC-V
Subsystem 5000 users 15000 users
OXE
8770 VM + OTCC-SE (optional)
OT core VM Linux Linux
Messaging only
DCS VM (optional) Windows Desktop

OXE-MS VM (optional)
Flex Server Embedded within OT core or Embedded within OT core or
external VM external VM
License Protection dongle dongle
Specific virtualization aspects are discussed in Ecosystem integration (Microsoft, Google) on page 29.
The sizing of an OTMS-V or OTMC-V virtual machine is determined by using OpenTouch Capacity
Planning.

Chapter
3 Topology aspects
3.1 Overview
This section describes topology aspects of OpenTouch solutions with respect to the commercial
packages defined in Commercial packaging using the OpenTouch on page 14.
An OpenTouch deployment is designed to be associated with one or more OmniPCX Enterprise
Communication Servers.
OpenTouch packages are designed to match possible OmniPCX Enterprise topologies as much as
possible, addressing anything, from single-site deployments to distributed or centralized topologies,
possibly with branch offices.
The OpenTouch Multimedia Services provides UC services to all or to a subset of OmniPCX Enterprise
users, whose endpoints are handled by OpenTouch users.
As a messaging-only version, an OTMC server is destined to be associated to one or more OmniPCX
Enterprise Communication Servers and provide its services to all or to a subset of the corresponding
OpenTouch users.
Topology aspects also include edge elements to handle remote user access / mobility, covered in
Mobility/Remote Access on page 22.
3.2 Telephony
This section focuses on the telephony aspects pertaining to OpenTouch Multimedia Services, referred
to as “OpenTouch server” in the following paragraphs.
The OmniVista 8770 NMS provides unified user management, automatically taking care of dual
configurations in the two servers: the OpenTouch and the associated OmniPCX Enterprise.
The following rules apply in all cases:
• An OmniPCX Enterprise node can only be associated to one OpenTouch server.
• An OpenTouch Multimedia Services can be associated to and provide UC services to users of up to
20 OmniPCX Enterprise nodes, belonging to the same homogeneous sub-network.
• A given OpenTouch Multimedia Services server cannot be associated with independent OmniPCX
Enterprise nodes, or OmniPCX Enterprise nodes of different subnetworks of a supra-network.
Single OpenTouch
A standalone OpenTouch deployment highlighting user declarations can be illustrated with two OXE
nodes belonging to the same sub-network and linked together by an ABC-F link, and an OpenTouch
node interfacing the two OXE nodes through one SIP trunk group per node.

Chapter 3 Topology aspects
Site 1
Alice Bob
PSTN OXE A OTMS B
Zoe
Site 2
PSTN OXE C
Carol Ben
Figure 3.1: Single OpenTouch example
Alice is an OXE user declared in OXE A

Bob is declared as an OpenTouch user in OXE A and OTMS B
Carol is an OXE user declared on OXE C
Ben is declared as an OpenTouch user in OXE C and OTMS B
Zoe is external to the system, reached through PSTN.
Note:
In this example illustrating telephony aspects, Alice and Carol do not benefit from the UC features provided by the
OpenTouch.
As a general rule, the deployment of an OpenTouch server connected to an OXE network requires the
update of OmniPCX Enterprise nodes linked to the OpenTouch to compatible release levels (refer to
cross compatibility documents for precise information). Note: the cross-compatibility constraints are
stronger between the OTMS and an OmniPCX Enterprise node linked by a SIP connection (with the
OXE acting as SIP front-end to OpenTouch Multimedia Services), than when the OmniPCX Enterprise
only interfaces with OpenTouch through CSTA (with the OmniPCX Enterprise catering for OpenTouch
users only and not being the SIP front-end for the OpenTouch Multimedia Services)
Multi-OT
The current solution supports up to 20 OpenTouch servers in an OmniPCX Enterprise sub-network,
with one OmniPCX Enterprise node being connected to only one OpenTouch Multimedia Services (i.e.
typically for PRS link uniqueness). In such multi-OpenTouch deployments, OpenTouch users could be
spread on the different OpenTouch nodes and benefit from telephony interactions between one
another, thanks to the underlying OmniPCX Enterprise network.

Master site
Alice Ben
PSTN OXE A OT B
Zoe
Slave site
PSTN OXE C OT D
Carol David
Figure 3.2: Multi-OpenTouch example
Alice is declared as an OXE user on OXE A (no UC)

Ben is declared as an OpenTouch user in OXE A and OT B
Carol is an OXE user declared on OXE C (no UC)
David is an OpenTouch user declared on OXE C and OT D
IVR access
The OTMS subsystem provides telephony access to the OTMS voice mail, automated attendant and
other IVR functions to OpenTouch users within an OmniPCX Enterprise subnetwork. Such access is
centralized through an extension number handled by one OmniPCX Enterprise node only, acting as the
unique gateway, on behalf of all the other OmniPCX Enterprise nodes of the sub-network, using a
unique SIP trunk group with the OTMS.
As a subset of the OTMS providing voice mail and automated attendant to OpenTouch users, access to
the OTMC follows the same centralization rule as for the OTMS.
Conferencing
The OpenTouch® Multimedia Services subsystem provides conferencing access to OpenTouch users
within an OmniPCX Enterprise subnetwork. Such access may be configured individually on each
OmniPCX Enterprise node, using a dedicated SIP trunk group with the OpenTouch® Multimedia
Services, and/or centralized through one of the OmniPCX Enterprise nodes, acting for the other
OmniPCX Enterprise nodes of the underlying sub-network. In any case, a distinct extension number
must be used on every OmniPCX Enterprise node with a direct SIP link to OpenTouch® Multimedia
Services conferencing.

3.3 Applications
An OpenTouch server provides applications to a number of OmniPCX Enterprise users of any site, up
to the maximum provisioning level of the OT server.
London Oxford
OXE A m OXE A s
New York HQ HA
8770
A C D A2
OTMS B A1
A1 C1 D1
OXE C s OXE C m C
HA WAN
Paris
WAN
D
OXE D m OXE D s
PCS C
C2
D1 D2
C1
Chicago Los Angeles
Figure 3.3: Applications example
In the example above, ICS/ACS applications are provided by OT to the following populations:
• A subset A1 (London) of population A of OpenTouch users
• A subset C1 (Chicago) of population C of OpenTouch users
• A subset D1 (Paris) of population D of OpenTouch users
OpenTouch users may take advantage of local media processing resources.
Mixing OTMS and OTMC on the same OXE node
To address voice mail capacity needs for some customer, deploying an OTMC (green field or NGVM
migration) on the same OmniPCX Enterprise node as the OTMS is possible. As a single PRS link is
supported on an OmniPCX Enterprise node, the PRS component can be active on only one of OTMC
or OTMS. The recommended deployment is to configure voice mail for OpenTouch users on the
OTMC, and make PRS applications available on the OTMC so OpenTouch users benefit from visual
voice mail on their IPTouch phones.
3.4 Localization
Multi-timezone
OpenTouch users may be configured in their own specific timezone, different than that of the system
itself. Multi time zone information on end points is handled differently according to device type:

End points using the NOE protocol (for OpenTouch users): local time information is handled and
provided by the OmniPCX Enterprise system
Managed SIP deskphones: local time information is provided through the device configuration file and
handled locally by the device
3rd party SIP end points: device dependent
Software clients: local time information is provided through the Operating System of the device and
handled locally by the device
Multi-country
In a centralized configuration, the system may have to handle users located in different countries
inducing some constraints: dialing plan, barring, prompts etc. The rules driving OmniPCX Enterprise
multi-country configurations are described in a dedicated presales presentation (available in eBP/
Presales Corner)
In an OmniPCX Enterprise with OpenTouch Multimedia Services deployment, multi-country
configuration is supported for OpenTouch users..
3.5 OpenTouch Networking

Release 2.2.1 introduces the ability to go beyond multi-instance and truly federate OpenTouch
Multimedia Services systems with each other, using dedicated links between instances to share
information. Networking is not subject to licensing and targets both bare-metal and virtualized
OpenTouch Multimedia Services versions, but not OpenTouch Message Center.
An OpenTouch network is comprised of a number of OpenTouch systems or instance, each handling
a given user population – in the context of which they are referred to as OpenTouch nodes – and
maintaining two levels of dialog over dedicated links between each other for a number of purposes:
• At the system level, discovering user populations handled by other OpenTouch nodes, and
synchronizing periodically for relevant changes (add, delete users, change of attributes)
• From a given OpenTouch node standpoint, remote users are created with a limited set of
attributes as specific entries in the node database, and associated to their respective remote
node. Entries are checked for unicity and consolidated with other sources such as the
associated OmniPCX Enterprise phonebook and external LDAP directories, which should be
shared by all OpenTouch nodes for consistency sake.
• At the user level, handling remote users from other nodes as if they were local users belonging to
the same node, including:
• Getting extended attributes when looking up OpenTouch users hosted on other OpenTouch
nodes belonging to the network, in particular avatar pictures
• Exchanging presence change events in real-time, sharing IM sessions and collaborating as
logged users in an ubiquitous way between local and remote OpenTouch nodes
Unlike OmniPCX Enterprise networks, an OpenTouch network is a fully connected topology where
each node is linked to every other node within the network, subject to periodic synchronization with
each other.
An OpenTouch network is defined by a network name, shared by all OpenTouch nodes comprising the
network. An OpenTouch node can only belong to one OpenTouch network at a time. The design allows
for standalone OpenTouch systems to co-exist within a given topology, with simple multi-instance
capabilities, as well as the co-deployment of multiple OpenTouch networks within an enterprise. There
is no further notion of group of networks or supra-network in the OpenTouch world, and the only
relationship between two OpenTouch networks is that their respective nodes may be managed by the
same OmniVista 8770 instance.

OpenTouch nodes comprising an OpenTouch network may also be deployed in different sites, possibly
in different IP networks to address local autonomy.
Whether networked or not, OpenTouch systems remain associated to their respective OmniPCX
Enterprise Communication Server(s), limited to one OpenTouch node per OmniPCX Enterprise
Communication Server, and through which audio is carried as in simple multi-instance setups. An
OpenTouch network assumes that all OpenTouch nodes are associated to OmniPCX Enterprise nodes
belonging to the same sub-network with a consistent dial plan. Association with OmniPCX Enterprise
nodes belonging to separate OmniPCX Enterprise sub-networks is not supported.
OT Network
OT networking link
OTMS A OTMS B
OXE/OT SIP Trunk
OXE C OXE D
ABC-F
OXE E OXE F
OXE sub-network
OTMS G
Standalone
Figure 3.4: OpenTouch networking example
In the example above:

• OTMS A provides UC services to OpenTouch users handled by OXE C
• OTMS B provides UC services to OpenTouch users handled by OXE D and F
• OXE C, D, E and F belong to the same OXE sub-network. OXE F is only linked through OXE D.
OTMS G is a standalone system providing UC services to OpenTouch users handled by OXE E

Chapter
4 Mobility/Remote Access
4.1 Use cases

The OpenTouch solution allows users to benefit from telephony and UC&C services from remote
locations out of the enterprise LAN. This aims at enabling two main use cases:
• Remote/Home Worker: OpenTouch users can connect remotely to the solution and benefit from all
OpenTouch services, using their OpenTouch clients, as if they were on the LAN. This use case can
be enabled by deploying a reverse proxy and an SBC in the corporate network DMZ. It can also rely
on an existing VPN infrastructure, if available on the corporate IS/IT network.
• External Guest access to OpenTouch conferences: remote anonymous users can join scheduled
conference bridges held on the OpenTouch. Such users cannot be authenticated at the corporate
border and the services they access to must be tightly controlled. The OpenTouch solution provides
guidelines for configuring a reverse proxy in the DMZ as a way to securely give access to
conferences for non-corporate users. The SBC is deployed conjointly to enable WebRTC browser
based media for remote participants
4.2 Edge elements

Remote access to the OpenTouch is enabled by a security infrastructure deployed in the customer
DMZ.
The OpenTouch supports a VPN-less solution, with a reverse proxy and an SBC, acting as applicative
layer gateways (ALG) removing the need for VPN clients on endpoints, and easing user experience (no
VPN client to install and manage, better QoS thanks to overhead reduction, no double encryption). L3
VPN solutions are however supported as a possible alternative to ALG components, typically when
such a VPN infrastructure is already used by the end-customer to enable remote access to corporate
LAN from computers, and possibly from mobile devices.
This section gives more insights into the nature and role of each of these components.
Reverse Proxy (RP)
The reverse proxy (RP) is in charge of managing all HTTP(S) sessions involved between remote
clients and telephony and UCC services offered by the OpenTouch solution. The reverse proxy enables
remote workers and remote conference guests use cases, through two different virtual interfaces that
can be enabled independently, according to the targeted use cases.
The RP exposes a “connected users” interface/FQDN to support remote workers. It authenticates
corporate users, and acts as an applicative gateway between remote clients and the OpenTouch
server. Authenticating users at the RP ensures unauthorized accesses are blocked at the DMZ rather
than internal servers. The RP generally relies on an external corporate LDAP or RADIUS AAA server,
that can be different from the one used by the OpenTouch. There is no Single Sign On (SSO) between
RP authentication and the OpenTouch. Therefore clients support two sets of credentials when the RP
and OpenTouch use different authentication databases.
The RP also exposes a “web collaboration” interface/FQDN to enable access to OpenTouch scheduled
conferencing services for remote guest participants. This interface does not implement user
authentication but filtering rules are enforced so that only the relevant resources can be accessed. Web
access codes are used to control access to conferences at OpenTouch level.
The reverse proxy is a 3rd party product that is currently not delivered as part of the OpenTouch
solution. ALE International qualifies and recommends a set of reverse proxies through the Application
Partner Program (AAPP), for example NGINX-Plus. Refer to the AAPP documentation for an up-to-

Chapter 4 Mobility/Remote Access
date list. Other reverse proxies are authorized as long as they comply with OpenTouch Conversation
applications requirements, but ALE International provides limited support in this case.
Note: Since OpenTouch 2.2.1, the reverse proxy endorses the role that was previously addressed by
the OTES to enable guest access to conferences. Therefore an OTES is no longer needed.
Session Border Controller (SBC)
The SBC is required whenever VoIP is involved from remote OpenTouch SIP clients (PC, Dual mode
smartphones, etc.), and also to enable WebRTC media for remote guest users joining OpenTouch
scheduled conferences.
The SBC role is to securely relay SIP signaling and media flows between remote clients and LAN
components. It supports encryption and can relay between encrypted traffic on the WAN side to clear
traffic on the LAN. It acts as a WebRTC gateway in the remote conference guests use case, relaying
WebRTC-based signaling and media (SIP-WS and DTLS-SRTP) to SIP/RTP on the LAN.
The SBC does not authenticate SIP endpoints, but rather delegates authentication to the backend SIP
server (OmniPCX Enterprise for OmniPCX Enterprise and OpenTouch devices). All unauthenticated
endpoints are considered untrusted and strictly controlled on all SIP interactions before they
successfully authenticate (typically only REGISTRATION is allowed).
OTSBC (Audiocodes OEM) is the SBC component of the OpenTouch solution. It uses its own
configuration tools.
L3 VPN Gateway
As an alternative to deployments based on the edge elements described above, remote user
deployment can rely on an existing layer 3 VPN tunnel infrastructure, in which case neither the
OpenTouch server nor endpoints are aware of the remote working situation. Network connections
between remote devices and LAN components are direct, and only encapsulated on the WAN portion,
with possible double encryption (HTTPS in IPSec, SRTP in IPsec).
There is no particular recommendation regarding the IPSec VPN solution used for OpenTouch clients.
It is considered an infrastructure layer, independent from our OpenTouch applications. Some
qualification is however recommended for mobile platforms, to ensure that the user experience is not
affected by possibly unstable IPsec VPN connections (due to data connection persistence, standby
mechanisms) that may require the VPN to be re-established frequently with credentials provided by the
user.
4.3 Edge FQDN blueprint

RP and SBC edge elements are associated to public FQDNs that allow devices located on the public
network to reach OpenTouch services. This set of public FQDNs comes in addition to the private FQDN
of LAN servers, which must be used when the client is running on the corporate LAN. OpenTouch
clients are therefore provisioned with both sets of FQDNs, and some rules must be respected so they
can properly determine their location and connect through the edge elements when remote, or directly
to the OpenTouch when on the LAN.
On the WAN, the following public FQDN are necessary for remote clients:
• One FQDN for remote “connected” users, necessary to enable the remote worker use case. It is
provisioned in OpenTouch clients, and exposed on the RP
• One FQDN for the “Web Collaboration” interface, necessary to allow remote participants to reach
OpenTouch scheduled conferences, and offered on the RP. This FQDN is included in OpenTouch
conferences URLs, that are therefore valid regardless of the user location
• One FQDN for SIP services, exposed on the SBC. The FQDN can be shared for several backend
SIP servers (e.g. the OmniPCX Enterprise for remote workers, and OpenTouch for WebRTC

conferencing), with discrimination based on ports. It is however possible to use separate SIP public
FQDN for each backend OmniPCX Enterprise and OpenTouch node
Public SIP FQDN for reaching

Private FQDN of OXE (one per
SIP and Media services of OXE
OXE node)
and OT from the Internet
Only exposed on the OXE on LAN
Exposed by the SBC only
DMZ
Public SIP FQDN OXE Configured at OT
server installation
pub-sip-services.company.com (eg post-install
SBC wizard)
Internet oxe.company.com
Connected Users FQDN
pub-ot-services.company.com OpenTouch Private FQDN of OT
Used to reach OT services on
RP LAN (DM, UCWS, SIPs,
APIs…)
ot.company.com OT Private Only exposed on OT on the
FQDNs LAN
conference.company.com conference.company.com
Public FQDN for connected users Web collaboration FQDN
Used by connected OTC clients to
join all OpenTouch server services Enterprise network
Exposed by the Reverse Proxy only
Web collaboration FQDN corresponding to

OT conferencing&collab Service FQDN (ACS
cluster FQDN)
This FQDN is exposed by the RP for enabling
joining conferences with OTC Web from the
internet (external guest users or corporate
users). Configured at OT
server installation
This FQDN is also exposed by the OT server, (eg post-install
so LAN users’ OTC Web connects directly to wizard)
the OpenTouch server when joining a
conference
Figure 4.1: Edge FQDN example
Public FQDNs are configured through the OmniVista 8770, and automatically pushed to remote clients
when they connect to the OpenTouch. End-Users of OpenTouch Conversation client applications only
have to provision the public FQDN of the “connected interface”, to reach the OpenTouch and access
the full set of public FQDNs to use. Participants of OpenTouch conferences must only click the
conference URL containing the “web collaboration FQDN”. The following picture illustrates how FQDNs
are configured.

❸ ❷ ❶
Users providing the bootstrap FQDN that allows IS/IT configuring the Public DNS to allow
OT Admin declaring in 8770 the public
reaching OT in on-site or off-site situation resolution of OT Edge components from the
FQDNs to be used by remote clients
(manually entered through QR code) public Internet
Private DNS
DMZ
ot.company.com → @IP OT
conference.company.com → @IP ACS cluster of OT
oxe.company.com → @IP OXE
Public DNS
pub-sip-services.company.com SBC
OXE
Pub-sip-services.company.com → @IP SBC
Pub-ot.company.com → @IP RP
Conference.company.com → @IP RP
NB: No public DNS entry for ot.company.com oxe.company.com
Remote OTC clients
pub-ot.company.com RP
OT User configures OTC client with:
- Private server FQDN: ot.company.com OpenTouch
- Public server FQDN (Connected Users interface FQDN):
pub-ot.company.com
conference.company.com
Internet
Then all other FQDNs are pushed by the server through ot.company.com
IcsLocator and DM OT Private
conference.company.com FQDNs
This web collab interface FQDN is not
pushed to connected clients who only
Enterprise Network
deal with the « connected clients »
interface FQDN
OTC Web (anonymous)
Anonymous User clicks on conference URL:
Join online meeting:

Https://conference.company.com/call/7384972
SBC parameters and association to devices done in 8770 Public URLs of OT Services declared in 8770
Figure 4.2: Edge FQDN example 2
For data services (configuration and web services), OpenTouch Conversation clients rely on the
provisioning by the CMS of private/public FQDN pairs to reach OpenTouch applicative services. These
FQDN pairs are retrieved by requesting the IcsServiceLocator Web service. The general principle,
implemented in OpenTouch connected clients, is that failure to resolve the OpenTouch private FQDN,
or inability to connect through the private FQDN, results in the client detecting that it is located on the
WAN and must use public URLs for all data services.
For SIP services, SBC parameters (FQDN, transport protocol, encryption parameters) are provisioned
to clients by the DM, through dedicated configuration parameters of the SIP configuration files of the
clients. Clients with different SIP proxy candidates (typically the OpenTouch for LAN, an SBC for WAN),
manage cycling through different SIP proxy candidates according to the same DNS resolution failure
principle.
For these location mechanisms to work, the FQDN configuration must comply with the following rules:
• The public OpenTouch server FQDN (connected users interface FQDN) must be different from the
private OpenTouch FQDN
• The private FQDN of the OpenTouch server, must be different from the SBC public FQDN
• When access OpenTouch conferences is implemented for remote guest users, the Web
Collaboration FQDN must be offered both on the public DNS (resolving to the RP IP address), and
on the private DNS (where it resolves to the OpenTouch conferencing service IP address). This
ensures that OpenTouch conferences URLs are reachable from the Internet and the Intranet alike
• Other private FQDNs of OpenTouch server and OmniPCX Enterprise must not be published in the
public DNS
In case the IS/IT manages a private domain on the corporate network, that is not exposed on the public
DNS, then the Web Collaboration FQDN of the OpenTouch server cannot be part of this private
domain, because it must be resolved from both LAN and WAN. The other FQDNs of OpenTouch and
OmniPCX Enterprise may be part of the private domain. The DNS server of the LAN must therefore be

able to resolve names of the private domain, and also enable resolution of the public domain to which
the Web Collaboration FQDN belongs to.
Public DNS
pub-sip-services.company.com -> @IP SBC Private DNS
pub-ot.company.com -> @IP RP ot.company.local -> @IP OT
conference.company.com -> @IP RP oxe.company.local -> @IP OXE
DMZ conference.company.com -> @IP ACS cluster of OT
pub-sip-services.company.com
SBC
OXE
oxe.company.local
Internet
pub-ot.company.com RP OpenTouch
ot.company.local → @IP OT
OT private FQDNs
conference.company.com conference.company.com → @IP ACS cluster
Enterprise Network
4.4 Remote Access Topologies

The solution can be deployed to enable either one of remote worker and remote guest access use
cases, or to enable the two types of accesses, leading to three main possible configurations, all based
on the same edge components but providing one or the two “connected users” and “web collaboration”
FQDNs.
❶ Remote Workers only ❷ Remote Workers and Guests users openness
Public FQDNs Public FQDNs
OXE
pub-sip-services.company.com pub-sip-services.company.com OXE
SBC SBC
Remote Corporate User with
Remote Corporate User with connected clients:
connected clients: oxe.company.com OTC PC
OTC PC OTC Smartphone Connected Users public interface oxe.company.com
OTC Smartphone pub-ot.company.com RP
Connected Users public interface OpenTouch OpenTouch
Internet pub-ot.company.com Internet
RP
Web collaboration public interface
ot.company.com ot.company.com
DMZ conference.company.com DMZ conference.company.com
LAN LAN
Conference Guest/External user

(OTC Web)
❸ Guests Users only (no remote workers)
Public FQDNs
OXE
SBC
oxe.company.com
Internet RP
OpenTouch
Guest/External user
Web collaboration public interface
(OTC Web)
ot.company.com
DMZ conference.company.com
LAN
Figure 4.3: Remote Access Topologies example
The following picture illustrates flows between remote users, edge components and LAN components,
in the second use case combining remote worker and guest access cases.

HTTPS (ics WS + config) HTTPS Device Management for remote

OTC PC pure softphones
HTTPS (acs services, data conferencing)
SIP Signaling WebRTC Signaling
Audio/Video media WebRTC Audio/Video media
Private DNS
Public DNS Public FQDNs
pub-sip-services.company.com → @IP SBC oxe.company.com → @IP OXE
pub-ot.company.com → @IP RP ot.company.com → @IP OT
conference.company.com → @IP RP conference.company.com → @IP ACS cluster of OT
NB: No public DNS entry for
DMZ Enterprise Network
oxe.company.com and ot.company.com
SBC
OXE
oxe.company.com → @IP OXE

Connected Users public interface
Internet pub-ot.company.com
RP OpenTouch
Remote OTC users
(connected clients) ot.company.com → @IP OT
Private FQDNs
Web collaboration public interface conference.company.com → @IP ACS cluster
OV8770
OTC Web
(external guests users or remote
corporate users joining from OTC Web)
Figure 4.4: Flows between remote users, edge components and LAN components in remote worker
and guest access cases example
From OpenTouch 2.2.1, OpenTouch servers can be networked to extend the scalability and topology
capabilities of the solution, while providing collaboration services for users across the different
OpenTouch nodes (see Topology aspects on page 16).
In such topologies, the reverse proxy must expose both the “connected users” interface and the “web
collaboration” interfaces for the backend OpenTouch server it is associated with, even if only remote
workers are deployed (no external guests). This is necessary for connected users to benefit from full
collaboration features between each other, regardless of the OpenTouch server they are located on.
This configuration can be implemented with a single RP addressing several OpenTouch nodes, or with
several RP for topology or scalability reasons. If a single RP covers several OpenTouch nodes, the RP
configuration for “connected users” and “web collaboration” interfaces is strictly identical to what it is for
a single OpenTouch configuration, with the difference that it must be replicated for each public FQDN of
backend OpenTouch instances.
HTTPS (ics WS + config)
Web collaboration flows with OT1 users/conf

Public FQDNs
OT1 Remote Corporate Users
Joining a conference of an OT2 user
ot1.company.com
conferenceot1.company.com OpenTouch1
Internet
pub-ot1.company.com
conferenceot1.company.com
RP
pub-ot2.company.com Network OpenTouch
OpenTouch2
Centralized DMZ ot2.company.com

LAN

HTTPS (ics WS + config)

Public FQDNs
OT1 Remote Corporate Users
Joining a conference of an OT2 user
Site 2
ot1.company.com
conferenceot1.company.com OpenTouch1
pub-ot1.company.com
Internet RP
DMZ Site 2
Network OpenTouch
pub-ot2.company.com
RP
OpenTouch2
DMZ Site 1
ot2.company.com
Site 1

Chapter
5 Ecosystem integration (Microsoft,

Google)
This section describes how the OpenTouch solution integrates with the customer existing applicative
ecosystem, bringing added-value OpenTouch telephony and UC&C services to end-users with no
disruption of their work environments.
5.1 Microsoft
The figure below represents an architecture overview of all OpenTouch/Microsoft interactions.
The OpenTouch is linked to Microsoft on clients (OpenTouch Conversation/Skype/Outlook/Office) as
well as on the server (OpenTouch/Exchange) on customer premises and cloud configurations, in order
to deliver integrations with MSFT clients and server-based features such as unified messaging,
calendar synchronization or directory look-ups.
Related information is provided in the following chapters.
Integrate with Microsoft apps

(Office, Lync/Skype for Business)
Communicate with Microsoft Lync/Skype for

Business users from an external organization
On-premises, or Cloud
services (Office 365), or
hybrid topologies
Unified Messaging
Meeting sync.
Calendar info.
Lync/Skype Microsoft
Edge OpenTouch Microsoft Microsoft Active
for Business Lync/Skype for
server server Exchange server Directory
server Business server
(*) Searching for people in the organization is not available

Directory lookup (LDAP) *
when Microsoft Active Directory is installed in the Cloud
Figure 5.1: OpenTouch/Microsoft interactions
5.1.1 On customer premises

5.1.1.1 Client integration
5.1.1.1.1 Office integration / Persona card
The OpenTouch client (OpenTouch Conversation) implements the MSFT IM Provider interface, which
can add communication features thanks to the native persona card of all Office applications (even
though most use cases concern Outlook).

Chapter 5 Ecosystem integration (Microsoft, Google)
This integration is made available to OpenTouch users thanks to a unique client in OpenTouch2.2.
With this feature, it is possible to check the availability of a contact (OpenTouch presence, including
phone presence), see the contact’s picture (OpenTouch avatar), start a chat, or an audio call with this
contact, retrieve the OpenTouch status message (mood phrase) and reply to an e-mail with multi-chat
instant messages.
Start an OpenTouch Conversation video call on the

computer (not available with Office 2010)
Check the availability of your

favorite contacts.
Presence is provided by the
OpenTouch server.
OpenTouch contact picture is

displayed (not available with
Office 2010) if there is no local
Start an OpenTouch Conversation phone call (OpenTouch
Outlook contact picture
Conversation will use your current phone). Select the phone
Start an OpenTouch number to dial if the contact owns several numbers.
Conversation chat session
Figure 5.2: Office integration / Persona card example
To provide this integration, the OpenTouch Conversation must be installed with the option ‘im provider’
validated. On first start, users are prompted to set OpenTouch Conversation as the default IM Provider
on their local machine (only one IM Provider is active on the machine). The information is set in the
machine registry (HKEY_CURRENT_USER\Software\IM Providers\DefaultIMApp).
Once this has been done, the OpenTouch Conversation starts a specific executable:
OTCPCLyncIMProvider.exe that implements a set of Microsoft COM APIs. Outlook (or another Office
application), on application startup, dialogs with the IM Provider using these COM API
(UCCollaborationLib namespace: ILyncClient, IUCOfficeIntegration, IAutomation, IContact, etc.) in
order to discover the features.
Interfaces are also implemented so that IM Provider delivers events to Outlook or Office applications
(Contact presence update).
The link between the IM Provider and the OpenTouch Conversation is also defined though the COM
interface and allows the IM Provider to receive contact information and request contact information
(presence, avatar), starting a chat, an audio, video session etc.
5.1.1.1.2 Outlook integration
The OpenTouch Conversation is delivered with two add-ins to integrate to Outlook (OL2010, 2013):
Conversation add-in
Messaging, contact synchronization and telephony features
Cannot be installed independently of the OpenTouch Conversation
Add-in built using the VSTO development tool: .NET based add-in.
This add-in is built on top of Outlook APIs (Outlook Object Model) and allows to manage e-mails,
appointments, contacts etc. within the Outlook client. The Outlook Object Model is described here.

Caution:
This add-in has no direct connection to the OpenTouch server: all requests go through the OpenTouch
Conversation application via the HTTP localhost proprietary API (the OpenTouch Conversation delivers an
HTTP localhost for add-ins). The OpenTouch Conversation must be running to deliver features.
This add-in is hosted in OutlookSynchroContact.dll and is in charge of:
• Messaging features:
• Play a voice message on phone
• Record and send a voice message
• Display the voice mail icon in front of voice messages (based on the template field)
• Analyze specific e-mail information and SMTP headers (ecc sender ID, message ID) in order to
call back the sender or play the message of the currently selected e-mail
• Contact synchronization
• The add-in retrieves all local Outlook contacts and provides information to the Windows contact
service through a proprietary API. The OpenTouch Conversation can display local contact results
in its directory lookup window through a dialog with the contact service.
• Telephony features
• When the OpenTouch Conversation runs in IM Provider mode, behaviors are limited to display
actions on right click menus. Main features are delivered through the persona card.
• When the OpenTouch Conversation is not the IM provider (for instance: Skype is the IM
provider), the add-in integrates to the Outlook ribbon (thanks to Outlook APIs) to offer options
such as: make a call, start a video call or start IM. The action buttons are available for the
currently selected e(mail, contact etc.
Conferencing add-in
This add-in delivers conference management: end-users can add/modify/remove conferences,
identified as Outlook appointments.
This add-in also allows to join conferences on line from:
• The body of the appointment (HTTP link)
• A custom ‘reminder’ window, built in the add-in
• The join online button available from the Outlook ribbon
This add-in is built on a 3rd party applicative framework: addin Express.
It is hosted in the MTWOutlookConfAddin.dll file.
The add-in relies on Outlook APIs to integrate into Outlook (ribbon, appointments, etc.) and is directly
connected to the OpenTouch server (no need to have an OpenTouch Conversation running) to manage
conferences and their participants.
The link between the add-in and the OpenTouch server is done with the OpenTouch/ACS VCS API.
The title, date, time, roster of participants are synchronized between Outlook and the OpenTouch
server.
This component currently has several limitations that will be addressed in future releases:
• No support of reverse proxy, in other words, this requires the computer to use VPN to connect to the
corporate network
• No support of Kerberos SSO, users are asked to enter their OpenTouch applicative password to use
the plug-in
5.1.1.1.3 Skype For Business integration
Selected on installation of the OpenTouch Conversation, Skype For Business integration runs on the
two SFB and Lync systems. This mode allows a user to use SFB for contact management/presence,

Instant Messaging and to use OpenTouch Conversation features (mainly remote call control on a
Skype contact, using the deskphone) through actions available on SFB or on a pane displayed at the
bottom of SFB. The OpenTouch Conversation can retrieve SFB contacts, make directory look-ups in
the Active Directory and start IM sessions using the SFB windows.
When implementing this solution, it is important to ensure that ALL users are configured alike: there
cannot be users using an OpenTouch Conversation in standalone mode and others integrated with
SkypeFB. This would lead to undelivered Instant Messages and bad user experience.
Set and manage your routing profile
Connected USB audio device(s) when using

the computer
Conversation history
Visual voicemail Settings of OpenTouch Conversation control pane
Manage OpenTouch meetings
List of active conversations
Figure 5.3: Skype integration example
This feature is managed on the client:

• Specific UI of OpenTouch Conversation to integrate SFB
• Pane
• Adaptations: do not display presence in the OpenTouch Conversation etc.
• Registry settings
• To display actions in SFB menus: make an audio call, video call, start sharing
• Registry settings launch OpenTouchConversation.exe when a user clicks on an action button (for
instance: select contact>right click>start audio call) with the information of the SIP URI of the
given contact(s). From this information, the OpenTouch Conversation proceeds to a reverse
lookup using LyncWrapper.dll (see below), to retrieve phone numbers for instance.
• These settings are set in the HKLM section of the registry and cannot be modified during
execution. This is why several configuration options are available in the OpenTouch
Conversation setup.
• LyncDocker.dll
• The OpenTouch Conversation instantiates this library in SFB mode
• The lib is in charge – using low level Win32 primitives – to hook the SFB main window and to
move or resize the OpenTouch Conversation pane when the SFB main window also moves. Two
versions of this library exist depending on the SFB version (32b/64b).
• This lib offers an API to the OpenTouch Conversation to dock/undock (attach/detach the pane)
• LyncWrapper.dll
• Heart of the SFB integration
• C#/.NET library that implements the Lync object model (assembly registered) to deliver features
such as:
• Get Lync/SFB contacts info
• Make a directory lookup on Lync/SFB contacts + Active Directory

• Start IM in Lync/SFB
• Offering a COM interface to the OpenTouch Conversation so that the OpenTouch Conversation
can implement the corresponding features
• IM Provider
• The IM Provider has been adapted in OpenTouch2.2 to make it context transparent (whether the
OTC is running in standalone or in Skype integration mode).
• In the Skype mode, when a user clicks send IM from persona card, a Skype IM session is
created, while clicking start audio call starts the call from the OpenTouch Conversation. This is
managed by the OpenTouch Conversation application. The IM provider has no direct link on the
LyncWrapper.dll for instance.
The Skype For Business integration mode must be defined in the OmniVista 8770 through the
declaration of a Skype For Business server (IT servers). The consequences of doing this are:
• OpenTouch mobile applications do not offer to send Instant Message (it would have been done on
the OpenTouch when all users use Skype)
• Some parts of the OpenTouch Conversation (MDW) based behaviors in the information is set in the
OmniVista 8770 (and provided through OpenTouch REST API)
5.1.1.2 Server integration

5.1.1.2.1 Exchange integration
The OpenTouch integrates with the Exchange CPE server to deliver Unified Messaging, calendar
synchronization (OpenTouch conferences/agenda) and calendar presence features.
These features are all hosted in an ICS component called WireAl running on the OpenTouch server.
The link between WireAl and Exchange is done through the implementation of Exchange Web Services
(EWS). Through EWS, the server component can access mailboxes and calendar, or contacts, or end-
users.
To do so, a delegation account must be created in Exchange and assigned with privileges right to
access (read and write) mailboxes and calendars. This information (delegation account credentials)
must also be set in the OmniVista 8770 so that the WireAl component can retrieve and use these
credentials to access mailboxes and calendar with EWS (on behalf of end-users).
5.1.1.2.2 Skype for Business/Teams integration
There is no integration with the Skype For Business/Teams server, the integration is done at the Skype
For Business/Teams client level. However Skype For Business/Teams server entry must be defined in
OpenTouch configuration, so that client applications (notably OTC PC) can adapt their behavior to
Skype/Teams integration mode.
5.1.1.2.3 Active Directory integration
The OpenTouch server integrates the Active Directory through the LDAP interface of the UDAS
component. This allows the OpenTouch server to make directory look-ups on Active Directory users.
There is no other specific API necessary to reach Active Directory.
5.1.2 Cloud integration

Integration with Office 365 only concerns the support of Exchange On Line.
On the client, integration is made transparent by the fact that client apps and APIs are installed on the
local machine: only the server runs on the MSFT cloud. Integration with MSFT Web Portal is not
supported in OpenTouch.
Reminder: the OpenTouch offers no integration at server level with Skype For Business.
Exchange

Adaptations have been made in the WireAl/Exchange Connector in order to support an Exchange On
Line server.
PUBLIC DNS PRIVATE DNS
Pub- ot.company.com ot.company.com
Enterprise network
EWS requests
HTTP Proxy My IC Phone
EWS notifications
Reverse Proxy
pub- ot.company.com:443/<UnifiedMessagingURL
>
DMZ OpenTouch
pub- ot.company.com:443/<CalendarSycnchroURL
> ot.company.com:443 Multimedia Services
CMS DB
- - Public/ Private FQDNs
Public FQDNs Private FQDNs - - HTTP proxy
- - Exchange mode
These adaptations concern:

• The authentication method (support of BASIC authentication – note: OAUTH2 must be implemented
in the future release as BASIC has security issues)
• The use of an HTTP proxy for WireAl’s outgoing requests to Exchange online
• The providing of a public URL by WireAl to Exchange for notifications (Unified Messaging and
calendar)
• Internal refactoring (WireAl is made of two parts dealing with UM and calendar. For this feature,
common components were shared: get configuration (http proxy etc.), SOAP engine for EWS
requests etc.)
5.2 Google
Unified Messaging is now available on Gmail.
This connection between the OpenTouch and Google Servers is done with OAUTH2 authentication call
flows. For this purpose, the IT Manager must manually configure multiple parameters in Google to
define an application with a secretID/key that must be pushed to the 8770 (IMAP mail server added to
a Gmail server, and an OAUTH2 authentication to set the Gmail application ID and key).
This configuration is described in the Messaging FSD (8AL_22030_3601_BEZZA) – chapter 6.5.
Voice mail deposit is done using the SMTP protocol. Getting voice mails and Message Waiting
Indicator (MWI) is done using the IMAP protocol.
Google does not notifying the OpenTouch server of new voice mails/e-mails , consequently a polling
mechanism is put in place (with a default timer of 60 second per mailbox) to verify the arrival of new
voice messages (and more generally to monitor changes in the mailbox status: deleted voice message,
read/unread message(s) etc.). This polling mechanism implies a restriction of the number of users with
a Gmail voice mailbox per OpenTouch server. The limit is currently set to 500 users, when the default
polling period is used. It is possible to adjust the polling period to reach higher capacities.
This polling mechanism removes the need to define a public URL for the OpenTouch server, as the
OpenTouch server is always at the origin of any request regarding Google whether it relies on the
IMAP or SMTP protocol.
Ports 587 (default SMTP) and 993 (default IMAP) must be opened to the internet for the OpenTouch
server to send SMTP & IMAP requests.

It may occur that an SMTP relay must be used (a common setup of IT is to define a single point in the
network, authorized to send outgoing SMTP requests: the SMTP relay). In this case, the SMTP relay
can be defined in the OmniVista 8770 (SystemServices/Applications/Messaging/VPIM).
Voice message access from any device and client application, anywhere.
User centric: same message state across all devices and client applications.
A
Voice message
deposit (A to B)
B
Message deposit / SMTP
User is busy
OpenTouch
or absent
server
Message retrieval / IMAP
Note:standard ports for IMAP and SMTP

need to be opened on enterprise firewall
SIP
HTTPS
Deskphone Smartphone
PC

Chapter
6 Openness
6.1 Functional API

In order to open OpenTouch to 3rd party applications, a set of APIs is published on top of the
“exposure framework” of the OpenTouch, following the unique design consideration and technology
(REST). This public API aims to serve OpenTouch users.
6.1.1 Architecture
As described below, the “exposure framework” is made of the following components:
• An http server (apache/muxer)
• A Tomcat server hosting the chameleon web app
• The chameleon web app implementing the business logic of the API through some dedicated
modules, such as the “rest enabler” and the “openness controller”
The “exposure framework” is part of the OpenTouch software stack and runs on the OpenTouch server.
Public User
3rd party CRUD api
3rd party
3rd party
app 8770 MyIc-PC MyIc-mobile OTC
Public
functional api
Private
functional Private
Private config
api ACS
api
api
http srv
Chameleon/Tomcat Exposure
framework
Openness Rest
controller enabler
Infra components
OTMS flexlm Infra components
ACS
6.1.2 Compatibility/versioning
The evolutions of OpenTouch and 3rd party applications are not synchronous (roadmaps are different).
This is why it is important to guaranty a certain level of stability of the public API across OpenTouch
releases.
The compatibility of a public OpenTouch API is guaranteed for a minimum of three OpenTouch
releases. Therefore, if an API must evolve and if backward compatibility cannot be maintained, the
existing API must be left untouched and a new API must developed to introduce the required evolution.
The old API remains part of the OpenTouch for the two next releases, at least.
6.1.3 Security
A 3rd party application must be logged to the OpenTouch (user or administrator account) before it is
authorized to call the public API.

Chapter 6 Openness
A web service dedicated to the user/admin authentication is published. This web service serves
internal authentication (internal OpenTouch user referential) as well as external authentication (the
enterprise LDAP server) with no difference for the third-party application which requests it. The only
difference is that the account login/password to enter by the end user is the login/password managed in
the OpenTouch/OAMP user/admin object for internal authentication or the OpenTouch/OAMP user/
admin object, managed outside the OpenTouch for external authentication.
In both cases, the authentication web service returns a session identifier. The third-party application
must set this session identifier as a parameter with any further request on the public OpenTouch API.
The chameleon systematically controls this session identifier.
The data transported in the requests is secured by HTTPS.
6.1.4 Published services and Licensing

The published API is divided in different functional groups: telephony, messaging …
In each API group, the available features can be distributed in sub-groups, named ApiSets. These
ApiSets are associated to a license and to a corresponding user right in the user object. An ApiSet
offers different methods/urls that the user can access to when he is granted with the corresponding
right.
A first level of ApiSet, generally free of charge, contains a limited number of feature enabling building
basic applications. Enhanced applications require the developer buying licenses for usage of a richer
ApiSet. For example, for the telephony API group, the free ApiSet will offer make call, take call, release
call only.
It should be noted that even for a free ApiSet, a license item must exist in the Flexlm file. It is
positioned to the value of ICE_BUSINESS_COMMUNICATION by Actis/elp and controlled by the
framework/OAMP exactly the same way as for non-free licenses.
The table below provides a view of the features available for ApiSets exposed in OpenTouch2.2.1.
Refer to API documentation for more details and up-to-date information.

Chapter 6 Openness
table 6.1: TELEPHONY
ApiSet Features License Perimeter

Basic telephony Make call ICE_TELAPI_BASIC User
Take call
Release call
Note:
OpenTouch2.2 adds possibility to call a
number from any OmniPCX Enterprise
device (not necessarily being a device of an
OpenTouch user)
Advanced telephony Events subscription ICE_TELAPI_ADVA User

NCED
Make call
Take call
Release call
Send DTMF
Conferencing (3 parties and N parties)
Call Recording
• Start, Stop
• Pause, Resume
Call Completion
• Redirection
• Pickup
• Overflow to voice mail
• Invoke a call back
Rich Presence (set / get )
Devices states monitoring
Call history
Directory search
• NEW OpenTouch2.2 : concurrent
searches support

Chapter 6 Openness
table 6.2: INSTANT MESSAGING

Instant Messaging Events subscription ICE_TELAPI_ADVA User
NCED
Manage IM session (list, create, get,
delete)
Get, Add, Drop participants
Send an IM
Set typing state
Get deferred messages
Get / Delete all deferred messages
Acknowledge / Unacknowledge defer-
red messages
table 6.3: PRESENCE

Presence Events subscription ICE_TELAPI_ADVA User
NCED
Published presence information con-
sists in:
• User IM Presence (ability of the user
to send/receive IM)
• Basic user presence (free, busy, be-
right-back, out-to-lunch, appear-
offline, custom)
• User phone presence (on-the-
phone, not-on-the-phone)
• User mood phrase
• User calendar presence (in-a-
meeting, free + end date) – NEW
OpenTouch2.2
OpenTouch2.2 brings new features:

Chapter 6 Openness
table 6.4: CONFERENCE

Conference Events subscription ICE_CONFERENCE User
Management of conference
• Creation / modification / deletion of
a conference
• Participants managements (add/
remove/promote/demote)
• Attach documents management
• Delegation mode
• Get all conferences (as organizer,
as delegate, as invitee)
• Support of iCal standard
OpenTouch2.2 also brings the VCARD relative URL path on every API where a participant, a contact is
described. This gives possibility to 3rd party developer to access rich data about the contact including
photo, company name, job title etc.
6.2 Configuration API

There is currently no public configuration API on top of OpenTouch, but as shown in the architecture
diagram above, a simple user create, update, delete API is published on top of the OmniVista 8770 to
allow simple day-to-day operations.

Chapter
7 Operation, Administration,
Maintenance and Provisioning
(OAM&P)
7.1 Overview
OAM&P (Operation, Administration, Maintenance and Provisioning) corresponds from a system
architecture point of view to a particular sub-system of the OpenTouch. The main objective for OAM&P
is to provide FCAPS management functions (Fault, Configuration, Alarm, Performance and Security).
OAM&P highly contributes to enhancements in the level of serviceability, leveraging the “Easy-admin”
approach. The OAM&P sub-system focuses on:
Configurability
OAM&P offers an intuitive management tool providing:
• Consistent look and feel and consistent ergonomic views. Homogeneity and clear identity of the
active function and scope.
• Graphical presentation views of the well-known domains to configure (Users, Topology, Security,
Applications, etc. ) rather than a list of obscure software components.
• Pre-set default values for each parameter, where possible
• Pre-set automatic values calculation or recalculation
• Presentation views depending on the expertise level of administrators (role based management)
• Minimized numbers of data elements to manage
The single graphical interface is provided by the OmniVista 8770 management platform. The
OmniVista 8770 uses OpenTouch configuration management APIs, based on the web services
technology.
Deployability
This solution aims at simplifying software installation (setup) or re-installation (setup/migration) of all
the OpenTouch relevant modules on one physical server. Device management contributes to increase
the level of deployability by providing automatic device software installation/update on the devices
themselves, as well as automatic device configuration with zero touch deployment.
Device management is “hardware” agnostic, meaning that for administrators, management of devices
does not require any hardware identifier. For deskphones, device management is based on the MAC
address, but the MAC is auto-discovered when users plug their device. For mobile phones and
softphones, it is based on the user login (when the user logs to the OpenTouch application), and does
not require any hardware id.
Maintainability
This covers preventive maintenance and corrective maintenance.
For preventive maintenance, OAM&P:
• Provides and publishes usage metrics of the level of capacity utilization (Hardware, Operating
System, Virtualization, Application services, Communication Services)
• Provides and publishes VoIP metrics to measure voice over IP quality (for the OmniPCX Enterprise
only).
For corrective maintenance, OAM&P (also based on the OmniVista 8770 for the GUI interface):
• Detects the fault, evaluates the severity and sends alarms to the administrator in case of troubles
• Specifies precisely where the fault is
• Allows reconfiguration or modification of the network in a way that minimizes impact

Chapter 7 Operation, Administration, Maintenance and
Provisioning (OAM&P)
• Allows repairing or replacing the failed servers without service discontinuity.

The Alcatel-Lucent OmniVista 8770 Network Management System application is deployed on a
dedicated server to support management of the OpenTouch Multimedia Services/OpenTouch Message
Center software, or the management of heterogeneous OmniPCX Enterprise software releases
simultaneously.
7.2 OAM&P Functions

The OAM&P OpenTouch infrastructure is the main part of global OpenTouch management functions,
managing components of the application and communication infrastructure subsystems. It provides a
central point for all the private web service based management APIs, used by the OmniVista 8770
Network management platform.
The configuration data managed by the administrator is persisted in an SQL database driven by the
OpenTouch infrastructure.
7.2.1 Configuration Management

The configuration management function allows MACD (Move, Add, Change and Delete) corresponding
to daily configuration actions applied to the OpenTouch domain, it also allows bulk-provisioning of
users and devices.
OpenTouch domains related to configuration management are:
• User/Device domain
This domain allows for declaration of users, devices, voice mailboxes, departments where users are
logically aggregated, and geographic sites associated to the OmniPCX Enterprise Communication
Server where users are located.
It also allows to associate devices to users.
• Ecosystem domain
This includes the IP declaration of all IT servers of the ecosystem (e-mail servers, LDAP servers,
SMS gateways etc.)
• System services domain
This includes configuration of security parameters as well as system parameters related to the
OpenTouch topology (list of OpenTouch servers) and applications (Collaboration, Advanced
Telephony, Messaging etc.)
All domains are managed via the OmniVista 8770 client except for certificates management where the
OmniVista 8770 provides only access to the OpenTouch Web-Based Management, launched from the
OmniVista 8770 client.
The OmniVista 8770 client provides for OpenTouch configuring, with:
• The OmniVista 8770 OpenTouch Configuration, connected to the OpenTouch, it deals with the
OAM&P database.
• The OmniVista 8770 Unified User Management, an application dedicated to users and devices. It
provides a centralized and simplified user device management. Depending on the type of user or
device, the OmniVista 8770 UUM can manage data on the OmniPCX Enterprise or data on the
OpenTouch from a single GUI.
Regarding Fax application, this 3rd party product uses its own management tool and no unification is
provided.
The central component dealing with configuration is named CMS (standing for Configuration
Management Service).

7.2.2 Device Management

7.2.2.1 Device configuration
The principle of “Device management” (DM) is to provide configuration parameters for SIP devices, i.e.
OpenTouch clients (except for the OpenTouch Connection for PC when declared as OmniPCX
Enterprise softphone, for which 8770 DM is used). Devices get their configuration by requesting the file
from the OpenTouch server (https request) at startup time, then through polling of notification for
conversation hardphones. The Device Management server enforces authentication of devices before
delivering configuration files, either based on prior user applicative authentication for clients, or on
terminal digital certificates for hardphones.
7.2.2.2 Firmware deployment

From the Alcatel-Lucent OmniVista 8770 Network Management System application, you can configure
the upload of firmware or applications to deploy on a group of devices (VHE 80xx, 4008/4018,
mobiles). Firmware or applications, embedded in a zip file, are pushed by the OmniVista 8770 to the
OpenTouch server via FTP, then a deployment profile is created by the OmniVista 8770 in OpenTouch
OAM&P. Upon this profile creation, the CMS-DM unzips the uploaded file and notifies the devices listed
in the deployment profile (SIP notification for VHE only). The notified devices download their new
firmware or applications via https requests from the OpenTouch server.
7.2.2.3 Device Inventory

As of OpenTouch R2.0, Device Inventory is added for VHE 80xx, VLE/VLE+, Android and iPhone
mobiles. The goal of this device inventory is to obtain device information coming from the devices
themselves. Device inventory data illustrates data information which is not configured in the Device
Management (IP address, hardware version of the device for example) or data information which is
installed into the device (binary or mobile application for example).
7.2.3 Performance Management

With the need to unify communication networks and the continuous increase of system complexity, it is
necessary to provide administrators with relevant information on system health, service quality and/or
user experience. To do so, the system provides Key Performance Indicators (KPI, also called metrics).
This information must be published (or at least offered) by the system making it possible for a third
party hypervisor to retrieve it for real-time monitoring, post analysis or more complex report
computations.
These metrics are published, using SNMPv3, to any 3rd party hypervisor and are retrieved through
periodical polling.
7.2.4 Fault Management

The OpenTouch Fault Management infrastructure is in charge of detecting, collecting and dispatching
alarms to the system and/or management applications, for information or corrective actions. A
dedicated java component named AMS (Alarm Management Service) collects alarms from all
OpenTouch sub-systems, sends them as SNMPv3 traps to the declared OmniVista 8770 and/or
hypervisors and then stores them in the database. The OmniVista 8770 can also request OpenTouch
OAM&P, for synchronization purpose, to resend part of the stored alarms. All administrator actions on
alarms (displaying, purging etc.) are done through the OmniVista 8770 NMS.
In addition of the OmniVista 8770 NMS alarm GUI, the OmniVista 8770 provides an SNMP proxy which
collects OpenTouch alarms (and OmniPCX Enterprise alarms) into the centralized OmniVista 8770
system, and can re-send them to hypervisors. It also provides filters to select which alarm to re-send.

7.2.5 Trouble Management

7.2.5.1 Monitoring
The OpenTouch OAM&P framework monitors software components and provides their states (started/
stopped). A graphical display of components states is provided by a WBM page launched from the
OmniVista 8770.
7.2.5.2 Backup-Restore
The backup Restore Utility automatically saves configuration and applicative data on a daily basis as
well as on request on a live production system. It is also used to restore data but the restoration
operation causes an interruption of service.

Chapter
8 Security
8.1 Security Management

This section presents security management and features addressed in the OpenTouch.
OpenTouch provides the configuration tools to manage security parameters of the system using the
OmniVista 8770 NMS, different WBM management tools, or file configuration. Security management
must be differentiated from functional security exploitation (see the following section). OpenTouch
security management covers the management of accounts: user and administrator authentication
configuration; user and administrator authorization configuration; integrity/confidentiality for flows and
database configuration. It also covers the configuration of the authentication referential (internal, LDAP,
Microsoft Kerberos) and Certificate Management functions required for authentication of devices and
external servers.
8.1.1 Authentication
Authentication covers the functional mechanisms that allow the OpenTouch server to check that it
communicates with confirmed trusted user/admin/devices/servers.
Users/Admin authentication
The current authentication methods supported for user/admin authentication are:
• Login/password checked against the internal LDAP database
• Login/password checked against the external authentication referential, allowing to leverage the
corporate authentication database. Radius or LDAP are supported, depending on the corporate
database to access.
• Single Sign On (SSO) based on Kerberos (only supported on MSFT PC platforms), where the
OpenTouch solution uses the Windows session authentication as a way to silently authenticate the
end-user
Devices and Servers authentication
Digital certificates are used to authenticate servers whenever secure flows are used between different
components. These flows are typically based on SSL/TLS and consist in:
• SIP-TLS for SIP-based communications security (only between clients and an SBC, in remote
working cases)
• HTTPS for the security of applications and administration flows
• Other protocols at stake in the solution (LDAPS, IMPA4S…)
The TLS protocol requires at least that the server host (OpenTouch in most IP flows) has a digital
certificate. The OpenTouch server generates a self-signed certificate at installation for TLS purposes,
but this certificate can be replaced by another certificate emitted by the customer PKI, if the IS/IT policy
requires so.
8.1.2 Authentication configuration

Authentication of users and administrators can be based on login/password or on SSO, using
Kerberos.
When using passwords, OpenTouch administrators and users must provide a personal login/password
when starting their applications using OpenTouch Clients. Similarly, OpenTouch administrators must
provide a personal login/password to use WBM applications.

Chapter 8 Security
Login/Password credentials are checked thanks to an internal OpenTouch SQL user/administrator

authentication referential or thanks to an external corporate AAA server (Radius/LDAP/AD).
The solution can also be configured so that it enables Kerberos SSO authentication, saving users
entering their corporate credentials into OpenTouch applications, when already logged in their
Windows session.
As not all devices support Kerberos SSO (only OTC PC for Windows), the solution allows cascading
authentication methods, so that computer users benefit from SSO experience, whereas authentication
on other devices can be done through login/password (generally based on the same external AAA
server). This cascading also allows OTC PC on Windows to fall back on login/password authentication,
when used from a remote location through a reverse proxy, as Kerberos authentication is not supported
in this case.
8.1.3 User authentication credentials

User authentication is managed differently for VoIP services and “other” application services
SIP digest credentials management
SIP endpoints are authenticated on the SIP server by the digest method.
SIP digest credentials are strong passwords, automatically generated and provisioned by the DM to
SIP endpoints, and are not known by users. This password can only be changed by the administrator.
The transport of the password from the DM to the endpoint is done in a secure way to ensure no
unauthorized user or device can get the configuration file from another device or user.
Password summary
Users must passwords are:
• A TUI-like password for their voice mail access code: this is a PIN-like password
• An applicative password, for OpenTouch applications and device lock. This password follows stricter
rules on length, expiry etc., as enforced by the OpenTouch policy, in case of internal authentication
database, or by the central authentication repository of the company, in case of external
authentication.
8.1.4 Authorization configuration

To prevent unauthorized use of resources, “Authorization” control must be done very close from the
resource’s access point and after authentication.
Applicative rights and telephony rights are defined by the administrator in user profiles and are
configured with OmniVista 8770 applications.
8.1.5 Digital certificates management

The OpenTouch WBM provides Certificate Management tools allowing to change the default certificate
by another certificate that can be issued by the customer’s PKI or by a public trusted authority
(Verisign, Cybertrust, etc.).
In most cases, clients connecting to the OpenTouch do not send digital certificates and the TLS
protocol is only used for server authentication. User authentication is provided at application level.
Mutual certificate authentication is only available for device management connections from ALE
International MyIC Phones to the OpenTouch server (client and server certificates are both exchanged
and authenticated).
Certificate deployment
The OpenTouch server uses a digital server certificate to authenticate itself to the device fleet and
connecting hosts using TLS protocol. A self-signed OpenTouch server certificate is generated by

Chapter 8 Security
default after installation. At any moment, the administrator can access a Certificate Management tool
via the WBM in order to check, manage, import or export the server certificate of the OpenTouch as
necessary. The OpenTouch server certificate is automatically deployed to the OpenTouch devices fleet
to perform server authentication.
8.2 Functional security

8.2.1 Media Applications Encryption
The OpenTouch is compatible with the OmniPCX Enterprise IP Touch Security solution, and its media
applications (voice mail, AA, conferencing) can benefit from encryption when accessed from OmniPCX
Enterprise encrypted devices and gateways.
Enabling encryption for the OpenTouch requires deploying an MSM-RM module in front of the
OpenTouch server. On the OmniPCX Enterprise, the OpenTouch media server address must be
configured as protected by the frontal MSM-RM, leading the OmniPCX Enterprise to negotiate
encryption keys between the MSM-RM and encrypted terminals and gateways, when a call is
established to OpenTouch media applications.
Encryption of OpenTouch media applications is available for OpenTouch Multimedia Services and
OpenTouch Message Center packages.

Chapter 8 Security
OXE OTMS/OTMC
External
Fax Server
Media Server
NOE RTP
SSM-RM MSM-RM
Media keys
signaling protocol
SIP
NOE-IPSec
SRTP
(terminals to
media server)
40x8
NOE Phone
SRTP
(peer to peer calls)
RTP
OTC PC (No encryption for OTCT Softphone)
Pre-requisites and restrictions:

• Fax encryption is not supported and the fax server must be deployed on a separate server (the
OpenTouch embedded fax cannot be used in this configuration)
• Only one MSM is allowed in front of the OpenTouch, and the amount of simultaneous media
sessions is limited to the MSM-RM capacity. This capacity is currently of 400 bi-directional media
sessions for IP Premium MSM, and of 250 for MSM-RM. Please refer to the product limit
documentation for up-to-date figures. Limits must be checked while quoting the solution, please
refer to the How-to-Quote documentation for details
8.2.2 Applicative flow encryption

As in the current solution, applicative flows are all encrypted by default, by the HTTPS protocol. In
order to achieve authentication before encrypting data, the server certificate for the HTTPS connection
must be verified. This means that the HTTPS client trusts the root certificate of the solution’s PKI or
trusts the server certificate.

Chapter 8 Security
8.2.3 Management flows encryption

Management flows between the OmniVista 8770 and the OpenTouch are encrypted by HTTPS for web
services, SNMPv3, and SSH.
8.3 Vulnerability management integration

Platform hardening
In order to limit the attack surface on the OpenTouch servers and to avoid non relevant vulnerabilities,
all unnecessary services and protocols are disabled on the software platform.
Automated tools are run over all OpenTouch builds, created before production. CIS-CAT, Netstat and
Nmap tools are used daily to detect possible variations on available ports and services.
Integrity checks
Based on the existing ICS integrity tool, the OpenTouch provides means to verify if the files delivered
by ALE International have been tempered with on an installed system, by comparing checksums
computed at build time versus production versions.
Vulnerability handling
As every ALE International product, the OpenTouch follows the Product Security Incident Response
Team (PSIRT) process, to analyze and solve security vulnerabilities appropriately. Solution and Product
Security Primes, and Single Points of Contact for security topics are identified and responsible of
vulnerability handling for all OpenTouch components.
Visit ALE PSIRT web page for more details: http://enterprise.alcatel-lucent.com/?
content=ALEPSIRT&page=overview

Chapter
9 Licensing
The OpenTouch (OTMS, OTMC) relies on a 3rd party license server named FlexLM and provided by
the Flexera software company for internal license control. It has been tuned for ALE International
needs and can be either embedded in the OpenTouch server itself or provided as an external/
centralized license server for virtualized solutions.
To ensure protection against piracy, the license file is signed by a host ID, which is a kind of hardware
ID. The license file is valid only if the given hardware device is connected or present in the server. The
following host IDs are supported:
• Non virtualized OpenTouch: the ALUID, a hardware fingerprint of the physical server running the
OpenTouch, is used. It depends on the motherboard and on the network cards. If one of these items
is changed, a new license file must be signed with this new ALUID.
A tool, getaluid, included in the OpenTouch software delivery is used to determine the ALUID of a
server.
The ALUID is not a generic host ID provided by Flexera but an OmniPCX Enterprise proprietary
“vendor defined host ID”.
The ALUID is a 32 hexadecimal digits string of the form:
ALUID=81D3C23B644ACB118DE6D4972012A1B2
• Virtualized OpenTouch: The ALUID cannot be used, as the ALUID of the physical host is
meaningless (a virtual machine can run on different physical hosts) and the ALUID of the virtual
machine can be easily spoofed.
• If the associated OmniPCX Enterprise is connected to the Cloud, the MAC address is used.
A license file signed by a MAC address includes a server line as follows:
SERVER this_host 00095BECEEF2 27000
Where 00095BECEEF2 is the MAC address (12 hexadecimal digits)
For green field, it is recommended to use the embedded license server. An external license
server can be used in case of upgrade because there is no easy way to switch from an external
license server to an embedded one.
• If the associated OmniPCX Enterprise is not connected to the Cloud, the signature license file
relies on the dongle ID. This is a regular host ID provided by Flexera. This kind of signature
requires an Aladdin dongle to be physically connected to a USB port of the server running the
OpenTouch. A license file signed by a USB dongle ID includes a server line as follows:
SERVER this_host FLEXID=9-12345678 (the number nine, followed by a hyphen and 8
hexadecimal digits).
9.1 Non virtualized OpenTouch

In this topology, the license server is always embedded in the OpenTouch itself and the license file is
signed by the ALUID. External license servers are not supported.

Chapter 9 Licensing
ALUID
Embedded
OT FlexLM
Linux
This topology is applicable for OpenTouch Multimedia Services and OpenTouch Message Center.
9.2 Virtualized OpenTouch

In case of virtualized OpenTouches there are more supported topologies. This chapter describes the
most common ones.
The license server can be embedded in the OpenTouch virtual machine or centralized and running on
its own virtual machine.
An embedded license server can serve only one OpenTouch and up to five OmniPCX Enterprises. It is
associated to a USB dongle or the MAC address of the OpenTouch virtual machine.
A centralized license server can serve up to 50 OpenTouch and 100 OmniPCX Enterprise. It can be
associated with a USB or the MAC address of the license server virtual machine.
9.2.1 Embedded license server

This is the easiest virtualized topology to deploy and it is the recommended topology when there is no
specific requirement that rules it out (green field only, there is no simple procedure to switch from an
external license server to an embedded license server). It is similar to the topology used when the
OpenTouch is not virtualized. The main difference is that the ALUID cannot be used anymore to ensure
protection against piracy. It is replaced by a USB dongle or a MAC address.
9.2.2 Centralized/External license server

As soon there is more than one OpenTouch, more than five OmniPCX Enterprises or when OXE spatial
redundancy is deployed, the OpenTouch embedded license server is not sufficient or even not
supported.
The OpenTouch only supports one license server. It is not possible (as with an OmniPCX Enterprise
which supports two separate license servers) to simply duplicate the license server to ensure high
availability of the licenses. A VMware HA must be deployed to provide licenses (cold) redundancy and
offering one license server.
If the OpenTouch is associated to an OmniPCX Enterprise connected to the Cloud, the license file
(xxx.ice) is signed by the MAC address of the license server. It does not require any USB dongle.
The centralized license server is delivered as an ovf archive, a pre-installed virtual machine containing
both the operation system and the license server. It is available in two versions, one for the KVM
hypervisor, one other for ESXi.
The FlexLM virtual machine can be deployed on the physical host running the OpenTouch or on the
OmniPCX Enterprise, or on a different physical host.

Chapter 9 Licensing
9.2.2.1 OpenTouch with HA and with USB dongle

One of the most common usages of the external/centralized license server is to serve several
OpenTouches with a unique pair of USB dongles, as is the case in OTEC configurations.
WMware HA is used to provide licensing HA.
Redundant and non redundant products can be served by a unique license server.
VMware HA
Vmware HA
USB dongle 1 USB dongle 1
OpenTouch main OXE stdy OXE FlexLM
Linux Linux Linux Linux
VM#5 VM#1 VM#2 VM#1 VM#4 VM#5
Hypervisor Hypervisor Hypervisor Hypervisor
9.2.2.2 Spatial redundancy

The topologies described in this document do not support redundancy natively for distant geographical
locations, with a redundant OpenTouch system. Several constraints must be kept in mind:
• Actis / eBuy rules force the use of the same FlexLM license server for the OmniPCX Enterprise and
its associated virtualized OpenTouch system.
• The VMware HA service, used to implement FlexLM server redundancy in case of an OmniPCX
Enterprise+OpenTouch topology with an external FlexLM server, requires to work within a single
local IP subnetwork.
In the two cases, the Communication Server, located in a remote data center, cannot access the
FlexLM server (be it internal or external) in case of inter datacenter link failure.
VMware stretched cluster
This solution, based on a VMware stretched cluster, provides an inter-site VMware HA and primarily
targets customers who already have such an expensive and complex infrastructure, which cannot be
recommended, only to provide OpenTouch redundancy.
It allows to stretch the server cluster, on which relies VMware HA, and the L2 network between
geographically distant datacenters, allowing virtual IP based HA (e.g. OpenTouch HA) between sites,
moving virtual machines between sites, etc. It can also provide SAN replication to extend VMware HA
over distant sites.
This solution is available regardless of dongle implementation, the FlexLM choice (internal or external).
In case of an OTMS-V, it remains available when the OmniPCX Enterprise is not virtualized.

Chapter 9 Licensing
To implement a VMware stretched cluster some pre-requisites must be met, among which: an inter
datacenter delay below 5ms, a minimum 622 Mbps redundant network link, less than 100km between
datacenters. Refer to VMware for the exhaustive pre-requisites list.
Additional VMware documents may be consulted for more information:
• Stretched_Clusters_and_VMware_vCenter_Site_Recovery_Manage_USLTR_Regalix.pdf
• vSphere5.0 Metro Storage Cluster Case Study.pdf
This has no impact for ALE International servers (either at product level or at quotation / ordering level),
but some warnings must be considered.
This topology allows:
• To enable OmniPCX Enterprise geographical redundancy, while keeping OpenTouch system local
redundancy. This capability is however limited to a layer two connectivity between the two
datacenters.
• To provide layer 2 geographical redundancy to an OpenTouch system, based on VMware HA and
stretched cluster. Today, this is the only available solution to provide spatial redundancy for a
virtualized OpenTouch system.
Three dongle solution
This solution allows to retain full OmniPCX Enterprise spatial redundancy capabilities. However it
cannot provide geographical redundancy to the OpenTouch system, be it an OpenTouch Multimedia
Services or OTMC.
This solution does not require any specific (network/storage) infrastructure, nor has any product
impacts. It is available regardless of dongle implementation, the FlexLM choice (internal or external),
the OpenTouch VMware HA and, in case of an OTMS-V, remains available if the OmniPCX Enterprise
is deployed on a physical platform.
Example of a redundant topology with OTMS-V VMware HA, internal FlexLM server and USB dongle
implementation:
OT & VMware
OXE CS A OXE CS B FlexLM 2
Flex 1
HA
Linux Linux
VM#2 VM#2
OK Linux Linux
VM#1 VM#4 VM#5
Hypervisor
Crash Hypervisor
USB dongle 3
Hypervisor
USB dongle 2
USB dongle 1 WAN
Data Center A Crash Data Center B
License control when server 1 or FlexLM 1 is down

License control when WAN is down
However this topology has an impact at ordering/licensing level and demands a dedicated manual
process to be carried out:
Based on quotation, Actis natively generates two dongles: dongle 1 and dongle 2.
Dongle 3 must be ordered independently via eBuy.

Chapter 9 Licensing
The BP must sign the license server file(s) with dongles 1 and 2, based on the selected dongle
implementation (USB or USB/IP): the license file xxx.ice associated with dongle 2 must be stored on
the datacenter B FlexLM server.
The BP creates an eSR to perform a license rehosting (replacement of dongle 2 by dongle 3).
License server file(s) must be generated again, but signed by dongles 1 and 3 and then stored on
datacenter A FlexLM servers.
In this process, it is assumed that dongles 1 and 3 are localized in datacenter A, hosting the
OpenTouch system, and dongle 2 in datacenter B (refer to the above example).
At the end of this process, dongles 1 and 3 are the ones specified by eBuy for this offer and therefore
the ones used to sign any updated license files in case of add-ons / upgrade. Dongle 2 and the
associated license file are only used to verify the OmniPCX Enterprise virtual CPU-ID and therefore
does not need to be changed in case of an add-on / upgrade.
9.3 License fault control and consequences

9.3.1 Time bound licenses and grace periods verification
Grace periods are started when there are inconsistencies between what was purchased and the actual
system configuration.
The Content Management System (CMS) audits the consistency of licenses and actual OpenTouch
configuration every day, with a CMS audit performed 15mn after system startup and every day at
2:00am.
• Each license item is controlled at each audit and OpenTouch configuration is compared to the
maximum allowed value (MAX_NUMBER) read from the license.
• When detecting inconsistencies between configured items and the MAX_NUMBER values read in
licenses, the CMS starts a grace period and switches the state of the concerned licenses to
inconsistent.
• This inconsistent state lasts until any of the following takes place:
• A valid license is installed
• Administration is corrected to remove exceeding rights
• After a maximum of 30 days
• During the grace period, it is not possible to assign rights related to the inconsistent license item to
new or existing users
• When licenses are found inconsistent at the 2 am audit, the CMS generates alarms for inconsistent
items, typically CMS_AUDIT_<license_name>_LICENSE_INCONSISTENT.
• At the end of the 30 day grace period , the CMS audit applies sanctions by automatically removing
rights on faulty items. This reverts to a normal situation where configured items cannot be more
than indicated in licenses. Users rights are removed at random among the configured users. To
come back to a valid situation, deploy a valid license file matching the customer configuration, and
either grant rights to all concerned users manually, or use a database restore from before the end of
the grace period.
9.3.2 Consequences of license inconsistencies

Licenses are considered inconsistent and the grace period applied when:
• A license item exists and can be read but the MAX_NUMBER read from the license is less than the
number of configured items. The grace period applies to the faulty item only.
• The license item is missing from the license file (the CMS considers the license as equal to zero).
The grace period applies to the faulty item only.

Chapter 9 Licensing
• The license item exists but is associated to an expired validity date (the CMS considers the license
as equal to zero). The grace period applies to the faulty item only.
• The OpenTouch release is obsolete (ICE_RELEASE or OTVM_RELEASE < installed version). The
grace period applies for this item only, and rights associated to other licenses can still be configured
until expiry of the grace period on this ICE_RELEASE or OTVM_RELEASE item. At the end of this
grace period, rights associated to all other license items are removed.
Note:
An exception may occur if major changes between two releases require so. Not all versions accept running
with an older license, even during the grace period.
• The UCAAS license (ICE_UCAAS) are missing. The grace period applies to all license items
controlled by the CMS Audit.
• If ICE_GR_LOCK is different from 2 and release version is 2.0/2.0.1/2.0.2 (more precisely between
implementation of PR463104 which may be delivered in 2.0.1 only, and implementation of SR
463159 which stops this verification). In this case the grace period applies for all license items
controlled by the CMS audit.
If the license server is not accessible at all (e.g. no network connection), the CMS audit is not run but
no configuration of controlled items is possible from the OmniVista 8770. Licenses are however not put
switched to inconsistent, and the grace period is not applied. The CMS raises an alarm on its inability
to reach the Flex server: Skip license Audit : Flexlm is not available.
table 9.1: License items controlled and fault consequences
Technical license Reason for Behavior during grace Behavior after grace
items inconsistency period period expiry
ICE_RELEASE License version < No restriction Predefined rights
installed software removed for all users
version
OTVM_RELEASE License version < No restriction Predefined rights
installed software removed for all users
version
ICE_GR_LOCK Not set to 2 on releases No new rights can be Predefined rights
2.0.x assigned removed for all users
ICE_OXE_ACU_USER License missing or No new user can be Deletion of "ICE OXE
license value below created ACU USER" option for
configured level randomly selected
overused users
ICE_BUSINESS_COM License missing or No new user can be Deletion of "MyIC

MUNICATION license value below created Business
configured level Communications"
option for randomly
selected overused
users
ICE_USER_DEVICE_A License missing or No association or
SSOCIATION license value below update of association of
configured level users and attached
device(s) is possible

Chapter 9 Licensing
ICE_UNIV_CLIENT License missing or No desktop or mobility Deletion desktop and
license value below option can be enabled mobility options for
configured level for any user randomly selected
overused users
ICE_DESKTOP_STD License missing or No desktop option can Deletion of desktop
license value below be enabled for any user option for randomly
configured level selected overused
users
ICE_OFF_SITE_MOB_ License missing or No mobility option can Deletion of mobility
STD license value below be enabled for any user option for randomly
users
ICE_DESKTOP_MM License missing or No desktop option can Deletion of desktop
license value below be enabled for any user option for randomly
users
ICE_OFF_SITE_MOB_ License missing or No mobility option can Deletion of mobility
MM license value below be enabled for any user option for randomly
users
ICE_MESSAGING License missing or No voice mail option Deletion of voice mail

license value below can be enabled for any option for randomly
configured level user selected overused
users
ICE_CONFERENCING License missing or No conferencing option Deletion of
license value below can be enabled for any conferencing option for
configured level user randomly selected
overused users
ICE_TELAPI_BASIC License missing or No basic telephony API Deletion of basic
license value below option can be enabled telephony API option for
configured level for any user randomly selected
overused users
ICE_TELAPI_ADVANC License missing or No advanced telephony Deletion of advanced
ED license value below API option can be telephony API option for
configured level enabled for any user randomly selected
overused users
ICE_CONFERENCEAP License missing or No conference API Deletion of conference
I license value below option can be enabled API option for randomly
configured level for any user selected overused
users
ICE_MSGAPI License missing or No messaging API Deletion of messaging
license value below option can be enabled API option for randomly
configured level for any user selected overused
users

Chapter 9 Licensing
ICE_UCAAS License missing No new right can be All predefined rights
assigned to anyone deleted for all users
Note:
During a grace period, you cannot create a user from a predefined profile containing an option marked as
inconsistent user-oriented license. For example, if the license item ICE_UNIV_CLIENT is inconsistent, you cannot
created a user from a profile allocating universal client and voice mail rights to a user.
9.3.3 Consequences of corrupted, unreadable or unaccessible licenses

A license can be corrupted, unreadable or inaccessible for example:
• In virtualized systems: when the dongle has been removed or is out of service, or there is no
network access to the central license server
• In non-virtualized systems (dongleless ALUID method): when the ALUID value is not correct
anymore, following hardware modifications
OpenTouch components implement different policies for license verifications: in some cases, licenses
are verified at startup only, in others they are verified on the fly.
Two degraded modes are implemented according to the situation:
• Panic1 refers to a case where the system started with licenses but cannot check-out any license
anymore. Typically there is no way to connect new clients, but restrictions in the capacity to
configure the system (no way to assign new rights to users or associate new users/devices). The 30
days grace period is started by the CMS at the next nightly audit, if the license server is accessible.
• Panic2 refers to a case where no license has been acquired at all since system startup. SIP and
applicative services of the system are down, devices supporting survivability switch to survivability.
Restrictions are implemented to configure the system (no way to assign new rights to users or
associate new users/devices). The 30 days grace period is started by the CMS at the audit
performed 15mn after system startup, if the license server is accessible.
System behavior differs when the problem occurs at startup, or while the system is running. In all
cases, the situation is degraded but the grace period may not start at the same time:
• Invalid licenses at startup: OpenTouch services are not started, the system goes to Panic2
Note:
Components reading licences at system startup do not support hot-plug of licenses. Consequently, a system
started without licenses must be restarted for the new valid license file to be taken into account.
• License issue while the system has already started successfully (was able to read license at last
startup):
• No immediate action is taken upon failure to verify licenses on the fly, the system remains in
Panic1 until it is manually restarted. Connected devices retain full services until they are
disconnected. Reconnected devices benefit from partial services.
• A manual system restart leads to the same consequences as invalid licenses at startup
table 9.2: Device capabilities in degraded modes
OT server events System Up System Up System Up System rebooted

Clients events Client connect Client connected Client restarted Client connected/
restarted
License file events Valid licenses License file corruption License file corrupted License file corrupted
nominal mode panic 1 panic 1 panic 2
stable state services for connected services for restarted system started without
clients clients licenses

Chapter 9 Licensing
OTC iPhone/ Basic telephony

OpenTouch
Conversation® for (dual mode) (dual mode) (private cellular mode) (private cellular mode)
Android
Adv Telephony
Collab
OT Standard Users
OmniPCX Enterprise Basic telephony
hardphone
(OXE panic mode)
VM, AA...
Collab n/a n/a n/a n/a

OTC PC Basic telephony
Adv Telephony
Collab
Anonymous users
OTC Web Reach scheduled conf
(no audio conferencing)
Legend:
: available
: available and relying on OmniPCX Enterprise
: not available
Basic Telephony: ability to place a call (dial-out 1 pcc), receive a call, call a conference bridge
Adv Telephony/UC: make ad-hoc conference, groupware, voice mail, manage routing profiles, switch
device...
Collab: IM, Presence, Access data conferences, create scheduled conference...
Note:
With a centralized license server, where the virtual CPU-ID item is stored in the OpenTouch license server, the
OmniPCX Enterprise goes to a degraded mode when the virtual CPU-ID item cannot be verified. The OmniPCX
Enterprisechecks this item every few hours, and on failure enters a degraded/panic mode.
When the system detects an inconsistency in the OPS files, it suspects illegal use, the Panic flag is set
up and the system runs in degraded mode. The steps for this degraded mode are:
• Action 1 (as soon as illegal use is detected) :
• Displays a message on the attendant set as soon as it enters idle mode, with a mandatory order
for the attendant to acknowledge this message.
• Deletes the screen of the terminal system, and displays the incident message:
Acknowledgement is mandatory.
• Stores the incident in the incidents file.
• Continuously rings an alarm set.
• Several management commands can no longer be launched and result in the following error:
Software protection error.
• Action 2 (four hours later) : Displays a predefined string on all sets with a display.

Chapter 9 Licensing
• Action 3 (eight hours later): Loops back on Actions 1 and 2.

Ot2.6 SD Generalarchitec 8AL90509USAG 1 en

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ot2.6 SD Generalarchitec 8AL90509USAG 1 en

Caricato da

Copyright:

Formati disponibili

OpenTouch Solutions

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 3/59

4.1 Use cases.......................................................................................................................................... 22

6.1 Functional API.............................................................................................................................. 36

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 4/59

8.1 Security Management............................................................................................................45

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 5/59

9.1 Non virtualized OpenTouch............................................................................................. 50

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 6/59

The OpenTouch documentation consists in separated documents, each corresponding to a specific

table 1.1: OpenTouch documentation structure

Documentation title Part number

[2] OTMS Installation Manual on a Physical Machine 8AL90512xxyy

[3] OTMS Administrator Manual 8AL90505xxyy

[4] Installation Manual on a Virtual Machine 8AL90507xxyy

[6] OpenTouch General Architecture 8AL90509xxyy

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 7/59

Documentation title Part number

[7] OpenTouch System Documentation 8AL90510xxyy

[8] OpenTouch Maintenance and Supervision 8AL90511xxyy

[11] Description of IP flows in OpenTouch solution 8AL220303381xxy

[12] OpenTouch Web Services Technical Overview 8AL90532xxyy

[15] OpenTouch Client Administration Manual 8AL90638xxyy

[16] OTMC Installation Manual 8AL90120xxyy

[17] OTMC Administrator Manual 8AL90121xxyy

[20] OpenTouch Conversation for PC User Guide 8AL90631xxyy

[30] OpenTouch Conversation for iPhone Release User Guide 8AL90884xxyy

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 8/59

Documentation title Part number

[31] OpenTouch Documentation Note 8AL90911xxyy

[34] ALE NFC Extended OXE Mobility Administration 8AL90614xxyy

[36] OpenTouch Session Border Controler Configuration Guide 8AL90065xxyy

[37] OpenTouch Suite for MLE in virtualized environment, overview TBE031

[38] Virtualization Design Guide TBE043

[39] S.O.T. 8AL90559xxyy

[40] OXE System: Dedicated Sets 8AL91024xxyy

[41] User Services 8AL91003xxyy

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 9/59

2.3 High level architecture diagram

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 10/59

OpenTouch Clients Web clients

Figure 2.1: OpenTouch sub-system overview

The Communication Infrastructure sub-system is in charge of providing all means to support

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 11/59

OTC-WEB OTC-PC OTC iPhone (dual mode)

Figure 2.2: OpenTouch components

2.4 System architecture components overview

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 12/59

OpenTouch System Components

OpenTouch Software Clients OT Web clients

8770 NMS Outlook

4059EE OXE video

Communication Infrastructure sub-sys

SIPS XS VM-SIPS AMS Email

Figure 2.3: OpenTouch system components

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 13/59

2.5 Commercial packaging using the OpenTouch

2.5.1 Bare metal packages

DCS (optional) Windows Desktop under KVM

OTMS - OpenTouch Multimedia Services

8AL90509USAG - Ed. 01 - March 2020 - General Architecture 14/59

2.5.2 Virtualization packages

table 2.2: OpenTouch Virtualized packages