Cisco Remote Expert Mobile Installation and Configuration Guide

Cisco Remote Expert Mobile Installation and Configuration Guide
 Cisco Remote Expert Mobile
Installation & Configuration Guide 10.6(1)
First Published: June 26, 2015 Cisco Systems, Inc.
www.cisco.com 1 Installation & Configuration Guide - 10.6(1) THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE
WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO
BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE
FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE
INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF
YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO
REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley
(UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the
University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS
ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES,
EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR
INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING
OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers.
Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative
purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. All printed copies and duplicate soft copies are considered un-Controlled copies and the original on-line version should be referred to for
latest version. © 2015 Cisco Systems, Inc. All rights reserved. 2 Installation & Configuration Guide - 10.6(1) Preface About this guide This document outlines the steps necessary to install and configure Cisco Remote Expert Mobile (RE Mobile) Open Virtual Appliance
(OVA). This deployment guide specifies: ▪
The VM platform requirements for Remote Expert Mobile ▪
How to load the Remote Expert Mobile .ova installation file ▪
How to install & configure Remote Expert Mobile in different topologies Prior to Install and Configuration, you should read and be familiar with “Cisco Remote Expert Mobile Design Guide 10.6”. If you require VMware infrastructure training, you must acquire the necessary knowledge and experience regarding deployment and
management of virtual machines before you deploy components on VMware virtual machines. This guide assumes that you are familiar with basic contact center and unified communications terms and concepts. This guide provides the
required DNS, NAT, reverse proxy and firewall configuration information but assumes that the network administrator has a working
knowledge of configuring these systems. This guide also assumes you have sufficient Cisco Unified Call Manager knowledge to: ▪
Configure CUCM trunks ▪
Configure routing patterns ▪
Configure SIP Normalization scripts Successful deployment of Remote Expert Mobile also requires familiarity with the information presented in the Cisco Collaboration
Systems Solution Reference Network Designs (SRND). To review IP Telephony terms and concepts, see the documentation at the preceding
link. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list
of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective
owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. Organization of This Guide This guide includes the following sections: Introduction Introduction & brief overview of Remote Expert Mobile and its SDKs,
software server components, agent integrations and key technologies. Overview of Remote Expert Mobile Deployment
Options Describes the standard Remote Expert Mobile deployment models:
single box, all-in-one deployment and highly available multi-box clustered
deployment for the RE Mobile OVA 3 Installation & Configuration Guide - 10.6(1) Before You Begin Lists Infrastructure requirements Installing RE Mobile for a Single Master Node / AllIn-One Deployment Table showing sequence of operations required to install RE Mobile
for a single node deployment. Installing the Base Multi-node HA Deployment Install and Configure the Virtual Machine(s) Configure the NTP Service Configure the HTTP Reverse Proxy Configure the Domain Name Service (DNS) Table showing sequence of operations required to install RE Mobile
for a single node deployment. Describes hardware, software and configuration requirements for
the virtual machine(s) needed to run RE Mobile Describes the procedure for configuring the NTP service Describes the configuration of the reverse proxy needed for RE
Mobile Describes the procedure for configuring the DNS service Install the Remote Expert Mobile OVA Describes the procedure for installing the REM OVA. Includes
subsections for Single- and Multi-node deployments. Configuration and use of Transport Layer Security
(TLS) in REAS Ensure successful installation of TLS certificates Operating System Describes how to gain access to the hosts’ operating systems Remote Expert Mobile Administration Console Describes how to access the REM Administration Console Expert Assist Configuration – Consumer Access
Number Regex Configuration of destination number restriction by regular expression. Expert Assist Configuration – Image Quality Scale
Factor Configuration of screen share quality using Expert Assist Post Install Verification Perform test calls and Expert Assist sessions Expert Assist Agent & Supervisor Agent Console Ensure successful RE Mobile integration with Cisco Agent Console. Restricting Application URIs via the Reverse Proxy List of the URIs that should be allowed through the Reverse Proxy Additional Information VMware specifics Configuring Cisco Unified Communications
Manager 10.5.x or later Describes the Unified Communications deployment configurations
of Remote Expert Mobile deployment solely with CUCM. Acronym List Lists some common industry and Cisco specific acronyms relevant to
Remote Expert Mobile. Obtaining Documentation and Submitting a Service Request For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional
information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html. Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation, as an RSS feed
and deliver content directly to your desktop using a reader application. The RSS feeds are a free service. Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at
www.cisco.com/go/offices. 4 Installation & Configuration Guide - 10.6(1) Documentation Feedback To provide comments about this document, send an email message to the following address: contactcenterproducts_
[email protected] We appreciate your comments. Conventions This document uses the following conventions. Convention Indication bold font Commands and keywords and user-entered text appear in bold font. italic font Document titles, new or emphasized terms, and arguments for which you supply values are in italic font. [ ] Elements in square brackets are optional. {x | y | z } Required alternative keywords are grouped in braces and separated by vertical bars. [ x | y | z ] Optional alternative keywords are grouped in brackets and separated by vertical bars. string A nonquoted set of characters. Do not use quotation marks around the string or the string will include the
quotation marks. courier font Terminal sessions and information the system displays appear in courier font. < > Nonprinting characters such as passwords are in angle brackets. [ ] Default responses to system prompts are in square brackets. !, # An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line. Introduction Cisco Remote Expert Mobile is a software solution that enables personal and actionable customer interactions within mobile & web
applications. These interactions range from simple click-to call to a complete voice, video and Expert Assist customer engagement session
interconnected to a full contact center environment. For example, Cisco Remote Expert Mobile can connect individual investors to the next
available financial advisor within a mobile trading app (B2C – Business to Consumer) or a field employee’s mobile app routing into an
internal helpdesk (B2E – Business to Employee). Features With Cisco Remote Expert Mobile developers can deliver voice, video and Expert Assist co-browse and application sharing in mobile
or web applications. Cisco Remote Expert Mobile is designed specifically for remote collaboration services provided through Cisco
Unified Communications Manager, Cisco Unified Contact Center Enterprise (Unified CCE) and / or Cisco Unified Contact Center
Express (Unified CCX). Remote Expert Mobile offers the following features and options that are pre-sized within core components.
Core component features are: ■
In-app voice & video communications (Over-the-Top WebRTC communications) —
—
High definition video and audio Bi-directional or one-way video 5 Installation & Configuration Guide - 10.6(1) ■
■
Mute audio, video or both Client side call control WebRTC to SIP gateway (trunking into Cisco Unified Border Element and Unified Communications Manager) —
—
Expert Assist —
—
—
—
—
—
—
—
■
Web co-browse Mobile app sharing Remote app control Expert form editing and completion Annotation by expert Expert document push Expert URL sharing Protect sensitive data with field and data masking Media Handling: —
—
—
—
—
—
—
—
STUN server (RFC 5389) for client external IP identification UDP port multiplexing Media encryption / decryption Bidirectional audio High definition video (H.264 or VP8 in CIF (352x288), nHD (640x360), VGA (640x480), 720p (1280x720) High definition and narrowband audio codec support (Opus, G.711 ulaw or G.711 alaw) Opus, G.711 ulaw, G.711 alaw & G.729a audio transcoding into the enterprise network H.264 & VP8 video transcoding SDKs Cisco Remote Expert Mobile includes Software Development Kits (SDKs) to provide voice over IP, video over IP and expert assist (app share &
web co-browse, annotation and document push) features within pre-existing mobile and web applications. Whether placing or receiving calls in
client web applications, RE Mobile’s Client SDK for Web supports every major browser such as: Google Chrome 33+, Mozilla Firefox 28+,
Opera 28+, Internet Explorer 11 and Apple Safari 8. With WebRTC at its core, in-app communications are enabled without the need for plugins.
Where WebRTC is yet to be supported in Internet Explorer and Safari, WebRTC plugins are provided for voice and video. Cisco Remote Expert
Mobile also delivers integrated communications in iOS 7+ and Android 4.1.2+ apps thru native libraries. 6 Installation & Configuration Guide - 10.6(1) Overview of Expert Mobile Deployment Options As detailed in Remote Expert Mobile Design Guide 10.6, the RE Mobile OVA may be used to install RE Mobile two configurations: singlenode or multi-node configuration. 1.
2.
Single Node, all-in-one deployment
▪
All services (Application Server and Media Broker) deployed to a single Virtual Machine (VM). ▪
This is ideal for development test-beds, proof of concept and small-scale deployments. Base HA Multi-node deployment
▪
This deployment model is made up of multiple VMs, each hosting either an REAS or a REMB. ▪
A multi-box topology would typically be used for production deployments. Note: It is important to note that the OVA will ALWAYS create a VM hosting both the REAS (which hosts the Web Gateway, Expert
Assist as well as the Finesse Gadgets and Expert Assist Web Consoles) and REMB. The same OVA template file is used to deploy RE
Mobile in any required topology. These deployment scenarios cover the integration of CUBE, UCCE and CUCM. This guide does not cover Remote Expert Mobile deployed
exclusively with Unified CM. Single Node, All-In-One Topology Using the OVA template, Remote Expert Mobile can easily be setup as a single master VM with both REAS and REMB service
running concurrently. 7 Installation & Configuration Guide - 10.6(1) Figure 1. Single Node Topology Internet)
DMZ)
Enterprise)
Enterprise)
Applica=on)
Server)
MediaSense)
(Op=onal))
HTTP/S)
Enterprise)
Reverse)Proxy)
RP)
Unified)CCE)
Unified)CVP)
(Op=onal))
HTTPS/WSS)
CSDK%
DTLS)/)sRTP)
RTP)
CUBE1E)
VXML)Gateway)
(Op=onal))
REAS%&%REMB%
EPs)
SIP
HTTPS/WSS
Finesse)
Media (Voice/Video) CTI
Note: Single Non-HA Master deployments should only be used for non-critical development or lab systems. The role of the reverse proxy within this deployment is described in the Functions of the HTTP Reverse Proxy section below. Multi-node, Clustered Topology Remote Expert Mobile Base HA Multi-node Deployment is a four (4) node cluster (2 REAS and 2 REMB) and can support up to 100
concurrent video, audio and expert sessions in a high availability configuration. 8 Installation & Configuration Guide - 10.6(1) Figure 2. Base HA Multi-node Deployment DMZ)
Internet)
Enterprise)
Enterprise)
Applica>on)
Server)
MediaSense)
(Op>onal))
HTTP/S)
RP)
CSDK&
Unified)CCE)
Unified)CVP)
(Op>onal))
HTTPS/WSS)
Enterprise)
Reverse)Proxy) HTTPS)
DTLS)/)sRTP)
REMB2&
REMB&
REAS&
REAS&
RTP)
CUBE5E)
VXML)Gateway)
(Op>onal))
EPs)
SIP
HTTPS/WSS
Media (Voice/Video) CTI
Finesse)
Note: Every Remote Expert Mobile Application Server cluster must consist of a single master node and any number of slave nodes.
The master node must be created prior to slave nodes being created. The role of the reverse proxy within this deployment is described in the Functions of the HTTP Reverse Proxy section below. 9 Installation & Configuration Guide - 10.6(1) Before You Begin Infrastructure Requirements Supporting infrastructure must be in place before beginning to deploy and configure RE Mobile. This infrastructure will consist of the
following: —
A suitable virtual machine —
Proper NTP configuration —
Proper HTTP Reverse Proxy configuration —
Proper DNS configuration Installing RE Mobile for a Single Master Node / All-In-One Deployment The sequence of procedures for installing RE Mobile for a Single Master Node / All-on-one deployment are shown in the table below: Sequence 1 Done? Task Notes Install and configure the virtual machine Install and
Configure the
Virtual Machine(s) 2 Configure the NTP
Service Configure NTP 3 Install and configure the HTTP Reverse Proxy Configure the
HTTP Reverse
Proxy 4 Install and configure DNS Configure the
Domain Name
Service (DNS) 10 Installation & Configuration Guide - 10.6(1) 5 Deploy the OVA for Single Master Node / All-­‐In-­‐One deployment Installing a Single
Master Node / All-InOne Deployment 6 Post Install
Verification Verify the installation. 7 Configure Transport Layer Security in REAS Configuration and
use of Transport
Layer Security
(TLS) in REAS 8 9 Log into the host’s operating system Use a browser to access the Remote Mobile Administration Console Operating System Remote Expert
Mobile
Administration
Console 10 Configure Remote Expert Assist Expert Assist
Configuration –
Consumer Access
Number Regex 11 12 Configure the Expert Assist Agent & Supervisor Agent Console Expert Assist Agent
Console Testing Finesse
Gadget Test the Agent Console 11 Installation & Configuration Guide - 10.6(1) 13 Restrict Applicaion Via the Reverse Proxy Restricting
Application URIs
via the Reverse
Proxy Installing the Base Multi-node HA Deployment The sequence of procedures for installing RE Mobile for a Single Master Node / All-on-one deployment are shown in the table below: Sequence 1 Done? Task Notes Install and configure the virtual machine Install and
Configure the
Virtual Machine(s) 2 Configure the NTP
Service Configure NTP 3 Install and configure the HTTP Reverse Proxy Configure the
HTTP Reverse
Proxy 4 Configure the
Domain Name
Service (DNS) Install and configure DNS 5 Deploy the OVA for Base Multi-node HA deployment Installing a Base
Multi-node HA
Deployment 6 Install and Configure the REMB for Base Multinode HA
deployment 12 Installing and
Configuring a REMB
(Base Multi-node HA
Installation & Configuration Guide - 10.6(1) deployment) 7 Post Install
Verification Verify the installation 8 Configure the Transport Layer Security (TLS) in REAS Configuration and
use of Transport
Layer Security
(TLS) in REAS 9 10 Log into the host’s operating system Use a browser to access the Remote Mobile
Administration Console Operating System Remote Expert
Mobile
Administration
Console 11 Expert Assist
Configuration –
Consumer Access
Number Regex Configure Remote Expert Assist 12 Configure the Expert Assist Agent $ Supervisor Agent
Consoles 13 Expert Assist Agent
Console Expert Assist
Supervisor Console Expert Assist
Agent &
Supervisor
Installation & Configuration Guide - 10.6(1) Consoles 13 Testing Finesse
Gadget Test the Agent Console Gadgets 14 Configure the Reverse Proxy to restrict the application
URIs Restricting
Application URIs
via the Reverse
Proxy Install and Configure the Virtual Machine(s) This section lists the recommended platform and specifications-based system requirements. The requirements outlined refer to the minimum
requirements for RE Mobile. The minimum requirements for future releases may differ and you should refer to the release notes or
administrator guide to ensure that pre-requisites are met. You will require a separate VMware host for each RE Mobile node you intend to provision. For an all-in-one single box deployment, you
will only require a single VMware host. For a multi-box installation, you will need multiple hosts available. Hardware and system Requirements RE Mobile requires a server platform that meets VMware’s Compatibility Guide for VMware vSphere 5.x or later. Refer to the VMware
developer documentation for additional configuration and hardware requirements. We highly recommend using the Cisco Unified
Computing System (CUCS) to simplify and maximize performance. See
http://docwiki.cisco.com/wiki/Unified_Communications_in_a_Virtualized_Environment for the current list of supported UCS tested
reference configurations and specifications for supported platforms. Each RE Mobile node is deployed as a virtual server and requires a VMware server to act its host. The server operating system is
CentOS. RE Mobile is an on-premises deployment. All services are set up, managed, and maintained on your corporate network. Ensure that: ▪
VT is enabled in the BIOS before installing VMware ESXi ▪
The VM host “Virtual Machine Startup/Shutdown” is configured to “Allow Virtual machines to start and stop automatically
with the system” Prior to installing the RE Mobile OVA, ensure that you have a suitable vCenter environment prepared. This environment will consist of a
VMware vSphere Datacenter and a VMware host. NOTE: For more information on installing and configuring VMware Sphere and hosts, see the VMware documentation at
https://www.vmware.com/support/pubs/ Remote Expert Mobile is delivered as an OVA image and deployed as described in this document. 14 Installation & Configuration Guide - 10.6(1) Configure the NTP Service Ensure that the VMware host is configured with a valid NTP server – the same NTP server that will be specified in Expressway. Procedure
Step 1 Select the host. Step 2 Go to the Configuration tab. Step 3 Select a VM. Select Time configuration. Step 4 Select Properties. Step 5 If the date and time were red on the previous page, set the date and time manually to the current time. Step 6 Click Options. Step 7 Select NTP Settings and click Add. Step 8 Enter the IP address of the NTP server and click OK. Step 9 Select Restart NTP service to apply changes check box Step 10 Click OK … and Click OK again
Configure the HTTP Reverse Proxy The HTTP Reverse Proxy must be installed in front of the REAS in the DMZ. For information on configuring HTTP Reverse Proxy, see the documentation at https://docs.trafficserver.apache.org/en/latest/admin/reverseproxy-http-redirects.en.html. Configure the Domain Name Service (DNS) RE Mobile requires DNS when installing a multi-box environment. The following is a list of the required DNS entries. ▪
An FQDN for each REAS VM (for example, server-A.example.com, server-B.example.com, etc. ▪
A cluster address (also known as a service address). This is a single FQDN that resolves to all the REAS nodes. This is the FQDN
that the cluster as a whole is contactable on. NOTE: For more information on configuring DNS, see the documentation for your particular DNS server. 15 Installation & Configuration Guide - 10.6(1) Install the Remote Expert Mobile OVA General This section will outline installation for the two RE Mobile deployment topologies. 1.
Single master node – an all-in-one deployment for testing and development use
2.
Base HA Multi-node - a clustered deployment for production use
Cisco RE Mobile software is flexible in its support of multiple deployment options. Running in a virtualized environment, enterprises can
run RE Mobile on any hardware platform that meets the specifications outlined above. This makes it easy to manage and deploy RE Mobile
within an existing data center. Along with the CentOS operating system and Oracle Java, the OVA template includes: ▪
The RE Mobile Application Server (REAS), ▪
Remote Expert Mobile Client SDKs (CSDK) ▪
Expert Assist Web Agent and Supervisor Consoles ▪
Expert Assist Agent and Supervisor Consoles ▪
Remote Expert Mobile Media Broker (REMB) Note: Before undertaking an installation of the Cisco RE Mobile OVA, please be sure to review the Cisco Remote Expert Mobile
10.6 Design Guide. Installing a Single Master Node / All-In-One Deployment The steps below describe how to deploy the simplest RE Mobile configuration. Note: Single master node deployments should only be used for non-critical development or lab systems. Interface Selection The single-node deployment has only one REAS and one REMB within its cluster. When deploying the OVA as a single box, all-in-one
topology, the simplest and recommended configuration is to define only the “External” interface. OVA Deployment Step 1: Download the RE Mobile OVA through your usual distribution channels. Note: The OVA is a large file – allow sufficient time to download the OVA prior to beginning an installation. Step 2: Launch the VMware vSphere client on your local machine and connect to your vCenter Server. Step 3: Select the VMware Datacenter containing the VMware host you intend to deploy to. Step 4: Click: File > Deploy OVF Template… Step 5: Browse to locate the RE Mobile OVA file. Click Next . Step 6: Review OVF image details and click Next to continue. 16 Installation & Configuration Guide - 10.6(1) Step 7: Click Accept for each license agreement. When all license agreements have been accepted, click Next. Step 8: Specify a name and location for the deployed template. Choose the VMware Datacenter containing the VMware host you intend to
deploy into and click Next. Note: The specific VMware host will be selected in a later step.
Note: You may change the default template name to something more descriptive if you wish.
Step 9: Select the desired hardware deployment configuration. The deployment template enables you to choose from one of two VM hardware configurations – Small Machine or Large
Machine. Note that this is different from the option of what software you wish to deploy. a.
Remote Expert Mobile – Small Machine
Requires 4 vCPU (8400 MHz reservation) & 4 GB RAM (4 GB reservation) b.
Remote Expert Mobile – Large Machine
Requires 8 vCPU (16800 MHz reservation) & 8 GB RAM (8 GB reservation) Select Remote Expert Mobile – Small Machine, and click Next.
Step 10: Select the specific VMware host to run the template. Click Next. Note: This host must have sufficient capacity to run the deployment VM configuration selected in the previous step.
Step 11: Select the desired Disk Format and click Next.
The disk format chosen determines the way in which the virtual machine will allocate disk space, and when it will claim that
space. The recommended format is Thick Provision Lazy Zeroed. Under this format, the entire disk space required by the guest
OS (Remote Expert Mobile) will be allocated by the VMware host at template deployment time. However, disk blocks in the
guest are zeroed at write time (making write operations slightly slower than the eager zeroed option). Note: For developer lab deployments – you may choose Thin Provision. For most deployments, optimal performance is required –
choose Thick Provision Eager Zeroed.
Step 12: Map the networks within the enterprise to those the template defines. The OVA template will display the 3 interfaces (External, Internal and Management) that each require mapping to a network
within the enterprise. During deployment of the OVA, it automatically detects any available networks and randomly assigns one to the External, Internal
and Management interfaces. Note: These initial Interface-to-LAN mappings can be changed as required by double-clicking in the appropriate entry in the
“Destination Networks” column.
The OVA deployment’s next configuration screen will allow you to specify IP addresses for the various interfaces that are
required. As discussed earlier, for a single node deployment, the only interface required is the “External”. As the others will not be enabled,
their associations are irrelevant. Step 13: Configure the template network details. 17 Installation & Configuration Guide - 10.6(1) a.
Node Configuration
I.
II.
III.
b.
Cluster Address - For a single node deployment, this property need not be set and therefore should be ignored.
Master Node Address - For a single node deployment, this property is irrelevant and should be ignored.
Network Name Resolution I.
Host Name - Specify the desired hostname of the VM being installed. This should be a DNS-resolvable FQDN.
II.
DNS Server 1 - This is a mandatory field. Enter the address of DNS server that the RE Mobile VM should use.
III.
c.
Node Type - For a single node deployment, there will only be one Application Server, therefore, the Node Type must
be set to Master.
DNS Server 2 - The second DNS server is an optional field.
Network Time Configuration
Configuring NTP is highly recommended, and therefore should be enabled with an appropriate NTP server address e.g.
time1.google.com d.
External Network Configuration As mentioned earlier, configuring the external network is mandatory for each RE Mobile cluster node. I.
External IP Address - Enter the IP address that will be assigned to this VM when installed.
This must be a valid and available IP address within the network associated with the ‘External’ interface selected
on the previous screen. II.
III.
External Network Mask - Enter the required network mask (e.g. 255.255.255.0) for the LAN associated with the
External interface.
External Gateway - Enter the IP address of the External interface’s default network gateway. Note that this is NOT related to the Web Gateway hosted on the REAS. e.
Internal Network Configuration
The Internal interface is not required for a single node deployment, therefore the Use Internal Network checkbox should be
left unchecked. f.
Management Network Configuration
The Management interface is not required for a single node deployment, therefore the Use Management Network checkbox
should be left unchecked. Step 14: Review the summary, check the box to power on the VM once deployment has completed, and click Finish to begin deployment.
Details shown in the summary will be written to a file as a record of the selected configuration for later reference. Step 15: OVA installation will now proceed – wait for it to complete. Step 16: Post install server access. On first boot of the newly created VM, the OS and RE Mobile applications will be configured according to the details entered
when deploying the OVA. 18 Installation & Configuration Guide - 10.6(1) As such, the first boot of the new VM will take longer than a normal boot. Note: Please do NOT use the VM until the login prompt is displayed on the console as viewed through the vSphere client.
To log into the external address of the VM, use SSH with the credentials below: Username: root Password: changeit
Note: Run the password.sh script and change the administrator password.
Step 17: Perform Post Install Verification The single node deployment is now complete.
Verify that everything is in order by performing some post install tests outlined in the Post Install Verification section below. Installing a Base Multi-node HA Deployment Base Multi-node HA Topology Overview Figure 3. Base Multi-node HA Deployment Internet)
DMZ)
Enterprise)
Enterprise)
Applica>on)
Server)
MediaSense)
(Op>onal))
HTTP/S)
RP)
CSDK&
Unified)CCE)
Unified)CVP)
(Op>onal))
HTTPS/WSS)
Enterprise)
Reverse)Proxy) HTTPS)
DTLS)/)sRTP)
REMB2&
REMB&
REAS&
REAS&
RTP)
CUBE5E)
VXML)Gateway)
(Op>onal))
EPs)
HTTPS/WSS
SIP
Media (Voice/Video) CTI
Finesse)
Prior to installation of the Base HA Multi-node model, please read the “Cisco Remote Expert Mobile Design Guide 10.6” for better
familiarity with Remote Expert Mobile pre-requisites, architecture and software components.
Note: The topology below is an example only. 19 Installation & Configuration Guide - 10.6(1) Server Type REAS-A REAS-B REMB-A REMB-B OVA Size Small Small Large Large Type of Node Master OVA Configuration Notes Slave Master Master ▪
Master: 0.0.0.0 (default) ▪
External: 10.10.10.90 ▪
Master: 10.10.10.90 ▪
External: 10.10.10.190 ▪
Master: 0.0.0.0 (default) ▪
External: 198.135.3.99 ▪
Internal(Optional): 10.10.10.95 ▪
Management (Optional): false ▪
Master: 0.0.0.0 (default) ▪
External: 198.135.3.100 ▪
Internal(Optional): 10.10.10.195 ▪
Management (Optional): false Installing and Configuring REAS (Base Multi-node HA deployment) This section outlines how to deploy a Remote Expert Mobile Application Server (REAS) within a multi-node topology. In production deployments, the REAS is installed and configured as separate VM from the REMB (Media Broker). As shown in the diagram
below, the REAS cluster is installed and configured within the enterprise’s internal “green” zone, while the REMB has been place within the
DMZ. The diagram below shows a typical multi-node deployment consisting of two REAS VMs and the REMB VMs for increased resilience and
media handling capabilities. Required REAS Interfaces The diagram below shows the recommended configuration of a multi-node topology in which the REAS VM(s) has been configured with its
“External” interface on one network subnet, and an optional “Management” interface on a different network / subnet. Note: the “Internal” interface has not been enabled on the REAS VM as it is not used by this component.
As described earlier, enabling the “Management” interface on the REAS VM is an optional security measure, which forces its administration to
be performed via a separate “Management” LAN subnet that is different to the one that the VM’s “External” interface is connected to. The diagram below also shows the recommended configuration of the REMB VM which has both “External” and “Internal” interfaces
(connected to different network subnets within the DMZ) in order to segregate the media external and internal RTP traffic it handles. In addition to the “External” and “Internal” interfaces, the “Management” interface has also been enabled on the Media Broker VM. The Web
Gateway will use this interface on the Media Broker to configure and control it. 20 Installation & Configuration Guide - 10.6(1) Note: the diagram shows the LANs within the DMZ and in the Green Zone being terminated at the firewall. It is expected that the
firewall between these distinct zones will act as a NAT router. Figure 8. High Level Logical REAS Topology: Installing the Remote Expert Mobile Application Server (REAS) Step 1: Download the RE Mobile OVA through your usual distribution channels. Note: The OVA is a large file – allow sufficient time to download the OVA prior to beginning an installation. Step 2: Launch the VMware vSphere client on your local machine and connect to your vCenter Server. Step 3: Select the VMware Datacenter containing the VMware host you intend to deploy to. Step 4: Click: File > Deploy OVF Template… Step 5: Browse to locate the RE Mobile OVA file. Click Next . Step 6: Review OVF image details and click Next to continue. Step 7: Click Accept for each license agreement. When all license agreements have been accepted, click Next. Step 8: Specify a name and location for the deployed template. Choose the VMware Datacenter containing the VMware host you intend to
deploy into and click Next. Note: The specific VMware host will be selected in a later step.
21 Installation & Configuration Guide - 10.6(1) Note: You may change the default template name to something more descriptive if you wish.
Step 9 (REAS): Select the desired hardware deployment configuration. The deployment template enables you to choose from one of two VM hardware configurations. The supported configuration is the “small
machine,” described below. Remote Expert Mobile – Small Machine Requires 4 vCPU (8400 MHz reservation) & 4 GB RAM (4 GB reservation) Select a machine configuration supported by the capacity of your VMware Host, and click Next.
Step 10 (REAS): Select the specific VMware host to run the template. Click Next. Note: This host must have sufficient capacity to run the deployment VM configuration selected in the previous step.
Step 11 (REAS): Select the desired Disk Format as Choose Thick Provision Lazy Zeroed and click Next.
The disk format chosen determines the way in which the virtual machine will allocate disk space, and when it will claim that space.
The option selected will affect the deployment speed. Thick Provision Lazy Zeroed The entire disk space required by the guest OS (Remote Expert Mobile) will be allocated by the VMware host at template deployment
time. However, disk blocks in the guest are zeroed at write time (making write operations slightly slower than the eager zeroed option). Step 12 (REAS): Map the networks within the enterprise to those the template defines. The OVA template will display the 3 interfaces (External, Internal and Management) that each require mapping to a network within the
enterprise. During deployment of the OVA, it automatically detects any available networks and randomly assigns one to the External, Internal and
Management interfaces. These initial Interface-to-LAN mappings can be changed as required by double-clicking in the appropriate
entry in the “Destination Networks” column. The OVA deployment’s next configuration screen will allow you to specify IP addresses for the various interfaces that are required. As discussed earlier, for this Application Server VM being deployed, the required interfaces are the “External” and “Management”. As
the “Internal” interface does not apply to REAS, it will not be enabled (on the next screen), therefore its association is irrelevant. Step 13 (REAS): Configure the template network details. Note: A deployment with multiple REAS nodes requires DNS entries to enable a single domain name to resolve to the external IP
addresses of the Master and Slave REAS nodes. a.
Node Configuration (REAS)
I.
Node Type - When installing the first REAS in the cluster, the Node Type must be set to Master.
Set the Note Type to Slave when installing subsequent Application Server VMs into the same cluster as the Master. II.
Cluster Address - This property defines an address in DNS that resolves to all the REAS nodes within the cluster.
As illustrated above, this is an optional property that is only applicable when deploying the Master node. If left blank, the
Master node’s “External” IP address (which is the default value) will be applied. If this value is to be set, DNS must be configured with it before continuing with this deployment ensuring that the DNS entry
resolves to only the Master node. 22 Installation & Configuration Guide - 10.6(1) By setting this value, a new self-signed HTTPS identity certificate will be generated (using this value) for the REAS cluster
during deployment. Also, if this value was set when installing the Master node, then while installing any Slave node, DNS must be updated with
a new entry for the Slave’s IP address against this Cluster Address. Note: It is important to update DNS after the Slave VM has been installed.
III.
Master Node Address - This property is only required by REAS Slave nodes to enable them to communicate with
the Master. It should therefore only be populated when a Slave REAS VM is being installed.
Network Name Resolution (REAS) b.
c.
i.
Host Name - Specify the desired hostname of the VM being installed. This should be an FQDN.
ii.
DNS Server 1 - This is a mandatory field. Enter the address of DNS server that the RE Mobile VM should
use.
iii.
DNS Server 2 - The second DNS server is an optional field.
Network Time Configuration
When installing a multi-node cluster, NTP must be configured by selecting the “Use Network Time Server?” checkbox and
specifying an appropriate NTP server address e.g. time1.google.com External Network Configuration (REAS) d.
As mentioned earlier, configuring the external network is mandatory for each VM being created. I.
External IP Address - Enter the IP address that will be assigned to this VM when installed.
This must be a valid and available IP address within the network associated with the “External” interface selected
on the previous screen. II.
External Network Mask - Enter the required network mask (e.g. 255.255.255.0) for the LAN associated
with the External interface.
III.
External Gateway - Enter the IP address of the External interface’s default network gateway.
Note that this is NOT related to the REAS. e.
Internal Network Configuration (REAS) Use Internal Network checkbox should be left unchecked for REAS. The Internal interface is not required for this REAS’s
deployment topology. It is specific to the Media Broker. f.
Management Network Configuration (REAS) As described earlier, the “Management“ interface is optional but the Application Server VM in this topology will be
configured with 2 interfaces - External and Management. In order to enable and configure the Management interface, the Use Management Network checkbox MUST be checked. 1.
Management IP Address - Enter the IP address that will be assigned to this VM’s Management interface when
installed. This must be a valid and available IP address within the network associated with the “Management” interface selected on the
previous screen. 23 Installation & Configuration Guide - 10.6(1) 2.
Management Network Mask - Enter the required network mask (e.g. 255.255.255.0) for the LAN associated with
the Management interface. 3.
Management Gateway IP Address - Enter the IP address of the Management interface’s default gateway. Note that this is NOT related to the REAS. 4.
Management Gateway Remote Network (CIDR format) - If the Application Server is expected to communicate
with entities on a different network via this interface, the IP address range (encompassing the other entities) on the other
network should be entered (in CIDR format) e.g. 10.10.10.0/24. Configuring this field will cause a static route to be added to
the VM’s network routing table. For a deployment such as the one in which this Application Server VM is being installed, its Management interface will only
be used to initiate communication with any slave Application Servers. As they will be on the same subnet, this field should
be left blank. Step 14 (REAS): Review the summary, check the box to power on the VM once deployment has completed, and click Finish to begin
deployment. Step 15 (REAS): OVA installation will now proceed – wait for it to complete. Step 16 (REAS): Post install server access. On first boot of your new VM, the OS and RE Mobile applications will be configured according to the details entered when deploying
the OVA. As such, the first boot of the new VM will take longer than a normal boot. Please do not use the VM until the login prompt is
displayed on the console as viewed through the vSphere client. To SSH into the external address of VM, use the credentials below. Username: root Password: changeit Disable the Media Broker by executing the following command: /opt/cisco/10.6.1.10000-x/CSDK/resources/disable-service.sh
Step 17 (REAS): Adding an Additional REAS Slave Node The instructions in this section can be repeated to install additional REAS VMs into the cluster. However, note that all subsequent VMs must be added as Slave nodes. Step 13 (above) describes the OVA’s configuration screen
where this is set. Step 18 (REAS): Set the cluster address By default, the RE Mobile Application Server’s cluster address will be set to the IP address of the Master node. If the cluster has more
than one REAS node, its cluster address should be changed. This can be performed during deployment, as described in Step 13 (above). If it has already been done, the following procedure is NOT
required, but may be followed if the administrator wishes to change the cluster address. Before changing the cluster address, ensure that the new cluster address has been registered with DNS, and resolves to the external IP
addresses of all the Application Server nodes in the cluster. 1.
SSH into the Master REAS VM - SSH into the Master REAS VM (see above for credentials) 2.
Change the Cluster Address and Regenerate Certificates - Execute the following command replacing
example.com with the DNS registered FQDN of the cluster. 24 Installation & Configuration Guide - 10.6(1) o
/root/change-cluster-address.sh –-regenerate-certs example.com Note: that the “–-regenerate-certs” argument will regenerate the REAS Load Balancer certificates such
that they are self-signed and contain the new cluster address. The short form of the “--regenerate-certs” script
arguments is “-r”. o
Be aware that the existing certificates will be overwritten! 3.
Restart all REAS nodes in the cluster - SSH into the external address of each REAS node in the cluster and
restart the REAS service by executing the following command. service reas restart Installing and Configuring a REMB (Base Multi-node HA deployment) The steps below outline how to install the REMB within a multi-node topology. In a typical production deployment (see diagram below), each REMB would be installed onto a VM within the DMZ, which is separate to
the REAS VM that is within the enterprise’s internal “green” zone REMB should be installed after the REAS cluster has been established.
Additional REMBs can be installed for more session capacity and as media handling needs increase. Consumer
Network
DMZ
Agent Contact Centre Network – The Green Zone
REAS Cluster
HTTPS
WSS
VP8
Agent Contact
Center
DTLS sRTP
RTP
Figure 4. Multi-Node Deployment Required Interfaces The diagram (Figure 10) below shows the recommended configuration of a multi-box topology in which the Media Broker has been
configured with both “External” and “Internal” interfaces (connected to different network subnets within the DMZ) to segregate its the
external and internal RTP traffic it handles. In addition to the “External” and “Internal” interfaces, the “Management” interface has also been enabled on the Media Broker VM. The
Web Gateway will use this interface to configure and control the Media Broker. Note: Figure 10 shows the LANs “Internal” interface of the Media Broker VM connected to LAN1. However, if required this interface
could be connected to a different LAN that is used to transport RTP between the DMZ and the internal SIP network within the DMZ
and in the Green Zone being terminated at the firewall. It is expected that the firewall between these distinct zones will act as a NAT
router. 25 Installation & Configuration Guide - 10.6(1) Figure 10. Multi-Node Multi-NIC OVA Deployment Note: As mentioned earlier, deploying the OVA will ALWAYS create a VM hosting the REAS and the Media Broker. The OVA will be deployed with a view to have the resulting VM just host the Media Broker in the DMZ. As the OVA being deployed will host just the Media Broker in this multi-node topology, post-deployment, the REAS service should be
disabled. Details of deploying a REAS are described in the Installing an Application Server section above. To install the Remote Expert Mobile Media Broker, deploy the RE Mobile OVA template as described below. Note: These instructions can be repeated to install additional Media Brokers.
Note: All nodes in an REM cluster must be on the same subnet. If they are not, they cannot communicate without an appropriate routing
infrastructure. The routing approach is strongly discouraged.
Step 1 (REMB): Use the previously downloaded RE Mobile OVA. Step 2 (REMB): Launch the VMware vSphere client on your local machine and connect to your vCenter Server. Step 3 (REMB): Select the VMware Datacenter containing the VMare host to whichyou intend to deploy. Step 4 (REMB): Click: File > Deploy OVF Template… Step 5 (REMB): Browse to locate the RE Mobile OVA file (ex. RE Mobile-10.6.1.10000-x.ova) Step 6 (REMB): Review OVF image details and click Next to continue. 26 Installation & Configuration Guide - 10.6(1) Step 7 (REMB): Click Accept for each license agreement, then click Next Step 8 (REMB): Specify a name and location for the deployed template. Choose the VMware Datacenter containing the VMware host you
intend to deploy into and click Next. The specific VMware host will be selected in a later step. Note: The default template name should be changed to something more descriptive as this is helpful when performing a multi-node
installation.
Step 9 (REMB): Select the Large Machine hardware deployment configuration. Note: Base HA Multi-node deployments always require large OVA instances for all REMB instances. Remote Expert Mobile – Large Machine Requires 8vCPU (16800 MHz reservation) & 8GB RAM (8GB reservation) Ensure the Large Machine configuration supported by the capacity of your VMware Host / physical server, and click Next.
Step 10 (REMB): Select the specific VMware host to run the template. Click Next. Note: This host must have sufficient capacity to run the deployment VM configuration selected in the previous step. Step 11 (REMB): Select the Disk Format Thick Provision Lazy Zeroed and click Next. The disk format chosen determines the way in which the virtual machine will allocate disk space, and when it will claim that space. The
preferred production format is: Thick Provision Lazy Zeroed The entire disk space required by the guest OS (Remote Expert Mobile) will be allocated by the VMware host at template deployment
time. However, disk blocks in the guest are zeroed at write time (making write operations slightly slower than the eager zeroed option). Step 12 (REMB): Map the networks within the enterprise to those the template defines. The OVA template will display the 3 interfaces (External, Internal and Management) that each require mapping to a network within the
enterprise. During deployment of the OVA, it automatically detects any available networks and randomly assigns one to the External, Internal and
Management interfaces. These initial Interface-to-LAN mappings can be changed as required by double-clicking in the appropriate
entry in the “Destination Networks” column. The OVA deployment’s next configuration screen will allow you to specify IP addresses for the various interfaces that are required. As discussed earlier, for this Media Broker VM being deployed, the required interfaces are the “External” and “Internal”. As the
“Management” interface will not be enabled (on the next screen), its association with a LAN is irrelevant. Step 13 (REMB): Configure the template network details. Note: IP addresses are assigned during installation. These addresses CANNOT be changed once assigned. If you assign an incorrect address,
or wish to change an IP address, you must re-install the node.
a.
Node Configuration (REMB)
I.
Node Type – All Media Broker VMs being created require the Node Type to be set to Master.
27 Installation & Configuration Guide - 10.6(1) Note that the Media Broker will need to be manually added into the Web Gateway cluster’s configuration. This is described
in Step 18 below - Configuring the Web Gateway Cluster with the Media Broker. b.
II.
Cluster Address - This property is only required when installing a master REAS node. As the VM being installed will host
just a Media Broker, this field should be ignored.
III.
Master Node Address - This property is only required when installing a slave REAS node. As the VM being installed will
host just a Media Broker, this field should be ignored.
Network Time Configuration (REMB)
When installing a multi-node cluster, NTP must be configured by selecting the “Use Network Time Server?” checkbox and
specifying an appropriate NTP server address e.g. time1.google.com c.
Network Name Resolution (REMB) Host Name - Specify the desired hostname of the VM being installed. This should be an FQDN. DNS Server 1 - This is a mandatory field. Enter the address of DNS server that the RE Mobile VM should use. DNS Server 2 - The second DNS server is an optional field. c.
External Network Configuration (REMB) As mentioned earlier, configuring the external network is mandatory for each VM being created. I.
External IP Address - Enter the IP address that will be assigned to this VM when installed.
This must be a valid and available IP address within the network associated with the “External” interface selected on
the previous screen. II.
External Network Mask - Enter the required network mask (e.g. 255.255.255.0) for the LAN associated with the
External interface.
III.
External Gateway - Enter the IP address of the External interface’s default network gateway.
Note that this is NOT related to the REAS. d.
Internal Network Configuration (REMB) As described earlier, the Media Broker will be configured with 2 NICs - External and Internal. In order to enable and
configure the Internal interface, the Use Internal Network checkbox MUST be checked. 1.
Internal IP Address - Enter the IP address that will be assigned to this VM’s Internal interface when installed.
This must be a valid and available IP address within the network associated with the “Internal” interface selected
on the previous screen. 2.
Internal Network Mask - Enter the required network mask (e.g. 255.255.255.0) for the LAN associated with the
Internal interface. 3.
Internal Gateway IP Address - Enter the IP address of the Management interface’s default gateway. Note that this is NOT related to the REAS. 4.
Internal Gateway Remote Network (CIDR format) - If the Application Server is expected to communicate with
entities on a different network via this interface, the IP address range (encompassing the other entities) on the other
28 Installation & Configuration Guide - 10.6(1) network should be entered (in CIDR format) e.g. 10.10.10.0/24. Configuring this field will cause a static route to be
added to the VM’s network routing table. This is not required. Therefore, this field should be left blank. e.
Management Network Configuration (REMB) The “Management“ interface is not required for a Media Broker deployment, therefore the Use Management Network
checkbox must NOT be checked. Note: It is possible to configure both internal (SIP) and external (WebRTC) interfaces to use the same IP address and ports. Typically, a SIP
configuration will take a range of ports, while WebRTC configurations will take a single port. It is important that the WebRTC port be
OUTSIDE of the SIP port range.
Step 14 (REMB): Review the summary, check the box to power on the VM once deployment has completed, and click Finish to begin
deployment. Step 15 (REMB): OVA installation will now proceed – wait for it to complete. Step 16 (REMB): Post install server access. On first boot of your new VM, the OS and RE Mobile applications will be configured according to the details entered when deploying
the OVA. As such, the first boot of the new VM will take longer than a normal boot. Please do not use the VM until the login prompt is displayed
on the console as viewed through the vSphere client. Once the VM has been installed, SSH into its external address and stop the REAS using the credentials below. Username: root Password: changeit Disable the REAS by executing the following command: /opt/cisco/ REAS-10.6.1.10000-x/REAS/resources/disable-service.sh Step 17 (REMB): Configuring the Web Gateway Cluster with the Media Broker Navigate to the Remote Expert Mobile Administration web console at: https://<reas-address>:8443/web_plugin_framework/webcontroller/mediabrokers a.
Click the “Add Record” button to add a new record for the Media Broker that has just been installed. b.
Enter the “Control Address” (as shown below) – This should be the IP address of the Media Broker’s “Internal” interface. The Web Gateway will use this address on the Media Broker to configure and control it. c.
Add a new “SIP Network” record. d.
Local Address CIDR – This is the address range the Media Broker will bind to for RTP communications on the SIP
Network. Set this to the IP address of the “Internal” interface in CIDR format i.e. <IP-Address>/32 e.
Start/Finish Port Ranges – This is the port range the Media Broker will bind to on the SIP Network e.g. 17000 – 17500 Each Media Broker will use 4 ports per call. As such, the number of ports required for the Media Broker to bind to on the SIP
side is typically calculated as follows:
29 Installation & Configuration Guide - 10.6(1) Number of concurrent calls the Media Broker is expecting to manage X 4 f.
Add a new “WebRTC Client” record – See the diagram above. g.
Source CIDR Address – This is the address range on which the REAS will receive WebRTC traffic from clients in CIDR
format e.g. all h.
Click the ‘+’ sign next to the newly added record and add entries defining the “RTP Public and Local Port” i.
Public Address & Port – This is the IP address and port that WebRTC clients must send RTP traffic to; typically the front of
a firewall e.g. 16000 j.
Local Address & Port – This is the IP address and port the Media Broker will bind to in order to receive RTP traffic from
WebRTC clients e.g. 16000 k.
As the media Broker now starts up with 5 processes it is now required that each Media Broker’s Source CIDR Address is associated with 5 ports. To configure this, repeat steps h to j. above to configure a total of 5 ports e.g. ranging from 16000 -­‐ 16004. Note: All of these ports will need to be opened on the firewall.
l.
Click the “Save” button to persist the configured Media Broker. Step 18 (REMB): Configuring Additional Media Broker Nodes The instructions in this section (Step 1 (REMB) to Step18 (REMB)) can be repeated to install additional Media Broker nodes into the
cluster. Step 19 (REMB): Post Install Verification Your cluster deployment is now complete.
Verify that everything is in order by performing some post install tests outlined in the Post Install Verification section below. 30 Installation & Configuration Guide - 10.6(1) Connection Monitoring As explained above, a Media Broker will typically be configured with multiple network interfaces. If there is more than one network
interface and the management REST interface is bound to a different network than one or more of the media-carrying interfaces (internal or
external) then it is possible for the Media Broker to process calls (via the REST interface) but be unable to send or receive media for those
calls. To ensure that the Media Broker only accepts calls over the REST interface when it is fully connected to the internal and/or external
networks you can configure connection monitoring. How it works Each Media Broker can be configured with none or more groups of addresses. A Media Broker will consider itself connected, and
therefore able to service calls, if it can “reach” to at least one of the addresses in each group. i.e. the logical operations are ORs within
each group and ANDs between each group. The Media Broker will attempt to establish the “reachability” of an address by: —
ping (ICMP echo requests) —
If that receives no response then attempt to establish a TCP connection to port 7 at that address A success with either mechanism will mark that address as reachable. If there are no groups configured then the Media Broker is considered to be connected. Example A typical network setup for Media Broker has 3 network interfaces: —
Management – The REST interface used by the Gateway is bound to this addresses —
External – external media —
Internal – internal media In this case there is no need to monitor connectivity on the management interface, as the gateway will only use the Media Broker if it
can reach it over this interface. Therefore it is sensible to monitor the external and internal interfaces. Configuration and use of Transport Layer Security (TLS) in REAS Overview of TLS and certificates By default, REAS is configured to use Transport Layer Security (TLS). Using TLS enables servers to verify the identities of both the server
and client through exchange and validation of their digital certificates, as well as encrypt information exchanged between secure servers
using public key cryptography, ensuring secure, confidential communication between two entities. Data is secured using key pairs
containing a public key and a private key. The owner encrypts the sent data using the recipient’s public key, which can then be decrypted
only with the private key in the pair. Encryption alone provides no proof of the identity of the sender of the encrypted information, however.
Certificates address this problem by also providing a digital signature, an electronic means of verifying a resource's identity. To prove its
identity, a resource requests a certificate from a Certification Authority (CA). The issued certificate is then signed with the CA's private key,
and should be added to the resource's identity certificate store. A certificate typically contains the following information: 31 Installation & Configuration Guide - 10.6(1) ▪
Owner's public key ▪
Owner's name ▪
Expiration date of the public key ▪
Name of the issuer (the CA that issued the certificate) ▪
Serial number of the certificate ▪
Digital signature of the issuer This certificate can then be sent to other resources to establish trust with that resource. The receiving resource should add the CA certificate
to their trust certificate store. For two-way trusted communication, certificates should be exchanged between resources. All REAS components within a cluster should be provisioned with certificates signed by a trusted CA. During the installation process, the
installer provisions the servers with temporary certificates, the CN (Common Name) of which reflects the cluster address that you specified
when installing each component; this defaults to the server’s IP address, but could have been changed. The temporary certificates all have a
common signer and as such it is possible for each of the servers within the cluster to communicate over TLS with other servers within the
cluster. When the installation of the cluster has been completed, the certificates should be replaced with certificates that have been signed by
a third-party Certification Authority (CA) or by a SCEP server. The CN in the updated certificates should reflect the fully-qualified DNS
names of the Server Group. If all of the cluster components share the same CN, only one signed certificate will be required for the cluster. Certificates can be managed using the Management Console, and you can manage the certificates for multiple Server Groups. The
Management Console enables you to perform the following functions: ▪
view identity certificates ▪
create and sign new identity certificates using SCEP ▪
create Certificate Signing Requests (CSRs) for third-party CAs ▪
replace existing identity certificates, for example, when they are about to expire, or the CN value has changed (host or domain
renamed) ▪
replace expired identity certificates ▪
view trust certificates ▪
import trust certificates. To work with certificates you must know the security password; the default password is changeit, however this might have been changed
during installation. Note: Certificates are initially created on the VM instance hosting the Master REAS, and are then automatically copied to all of the
REAS in the cluster. Identity and trust certificate groups An identity certificate is a certificate that can be used to identify a machine. The CN of these certificates will usually contain either: ▪
A fully-qualified name that can be resolved in DNS. This name can resolve to one or more machines. 32 Installation & Configuration Guide - 10.6(1) ▪
The IP address of the machine. Identity certificates are managed in ‘identity certificate groups’. On installation, the following identity certificate groups are created: ▪
mgmt-server-group - for the Master REAS (Domain Host Controller), that is, the server hosting the Management Console
and the License Server. ▪
main-server-group for the REAS. For example: For the REAS groups, a certificate is required for each transport type (SIPS and HTTPS) in the group, as shown in the image above. As the
Master REAS (Domain Host Controller) is only a management interface, only an HTTPS certificate is required. Trust certificates are managed in ‘trust certificate groups’. By default, a single trust certificate group is created, which can be used by all of
your Server Groups. Certificates are created and saved in identity certificate group and trust certificate group directories on the server hosting the Master REAS
(Domain Host Controller), and are then automatically copied to each REAS in the Server Group. If a new REAS is added to an existing Server Group, the certificate group directories are automatically copied to that new server. Similarly,
if a new cluster, or Server Group, is added to the enterprise, the certificate group directories are automatically copied to each REAS in the
new cluster. 33 Installation & Configuration Guide - 10.6(1) Configuring REAS with identity certificates signed by a third-party CA If you want to generate a new identity certificate to be signed by a third-party CA, you must generate a Certificate Signing Request (CSR),
send the generated CSR to the third-party CA, and then import the signed certificate (received from the CA) into the identity certificate
group. Note: Certificates can also be signed by a SCEP server. See "Configuring Load Balancers or Application Servers with identity certificates
signed by a SCEP server".
If you want to generate a new certificate with a new name, you must first generate a key pair for the new certificate, and then follow the
signing procedure using the newly generated entry in the list. Generating a keypair This step is only required if you are creating a certificate with a new name. If you just want to change the CN in the certificate, you do not
need to generate a new keypair. 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 3.
From the menu on the left, expand Subsystems > Trust Management and select ID Certificates. 4.
Select the identity certificate group that you want to work with. 5.
Click Generate Keypair. 6.
Enter a meaningful name, preferably indicating the component and transport type, for example, for a certificate for SIP traffic on
Load Balancers, it could be called something like sip-lb. 7.
Enter the DN value. The CN value in the DN should reflect that of the SIP domain. If the Load Balancers are in a different domain
to the Application Servers, use the domain applicable to the component type that the new certificate is for). For example:
CN=192.168.1.234, or CN=example.net. 8.
Enter the expiry date, in the form yyyy-mm-dd. For example: 2015-03-20. 9.
Enter the security password. 10. Click Save. A new entry with the specified name is added to the list of certificates. Generating a CSR You need to generate a Certificate Signing Request to send to the third-party CA. 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 3.
From the menu on the left, expand Subsystems > Trust Management and select ID Certificates. 4.
Select the identity certificate group that you want to work with. 34 Installation & Configuration Guide - 10.6(1) 5.
Select the certificate that you want to be signed in the list; this might be the entry for the keypair that you have just generated. 6.
Click Generate CSR. 7.
Enter the security password, and the DN for the component that you are generating a certificate for, then click Save. A dialog containing the CSR text is displayed. For example: 8.
Copy all of the displayed text, including the start and end tags, and paste it into a text editor, then save the file. 9.
Click Close Sending a certificate to the external CA for signing The procedure for getting your certificate signed by a third-party CA depends upon the requirements of that CA. See the guidance from the
CA. Importing the signed certificate When you receive the certificate back from the CA you must then import it into the identity certificate group. 1.
In the Identity Certificates dialog, select the identity certificate group that you want to work with. 2.
Select the certificate entry of the identity certificate that you requested the CSR for. You must ensure that you select the correct
entry. 3.
Click Import. 4.
Enter the name of the certificate and the security password. 5.
Open the certificate in a text editor, and copy all of the contents, including the start and end tags. 6.
In the Encoded Certificate field, paste the certificate text. 7.
Click Save. 35 Installation & Configuration Guide - 10.6(1) Once the certificate is imported, the window is updated to reflect any changed certificate details, such as the issuer DN and the
expiry date. 8.
The updated identity certificate group directory is then copied to each Application Server and Load Balancer in the Server Group.
Each server must be restarted for the changes to take effect. Configuring Load Balancers or Application Servers with identity certificates signed by a SCEP server If you want to generate a new certificate that is signed using the SCEP protocol, this is a single UI operation, which performs the CSR
generation, sending, receiving, and importing steps automatically. Before you can perform this procedure, you must configure the REAS
with the details of a server that implements the SCEP protocol, for example, an EJBCA server. Configuring REAS to use the SCEP protocol 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 3.
From the menu on the left, expand Subsystems > Trust Management and select SCEP Configuration. 4.
Click Add. 5.
Enter the required SCEP values as follows: Parameter Value Name Enter a name for this SCEP configuration URL The SCEP Server CGI URL. A typical value for an EJBCA server might be
something like: http:// ejbca.example.com:8080/scepraserver/scep/ pkiclient.exe Profile Enter the value of the SCEP profile, or identity, that you want to use Subject DN
Prefix This is the string that will be prefixed to the “CN=” value when constructing the
Subject Distinguished Name in the X509 certificate. For example, if this field is set to “C=GB,O=Cafex,OU=Test”, the subject DN
might be something like “C=GB,O=Cafex,OU=Test,CN=example.com”. 6.
Click Save. Generating a SCEP-signed certificate 1.
In the Identity Certificates dialog, select the identity certificate group that you want to work with. 2.
If you want to create a certificate with a new name, you first need to generate a keypair. See "Generating a keypair". 3.
Select the certificate entry of the identity certificate that you want to send to the SCEP server for signing. 4.
Click SCEP Sign Certificate. The CSR is generated, sent to the SCEP server, signed, returned, and imported into the identity certificate group directory. 5.
The updated identity certificate group directory is then copied automatically to each Application Server and Load Balancer in the
Server Group. 36 Installation & Configuration Guide - 10.6(1) 6.
Each server hosting an REAS must then be restarted for the changes to take effect. Configuring REAS with trust certificates To allow TLS connections to the REAS from external entities that use identity certificates signed by a CA that is not currently
recognized, a certificate from the unknown CA must be added to the trust certificate group. Importing the trust certificate 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 3.
From the menu on the left, expand Subsystems > Trust Management and select Trust Certificates. 4.
Select the trust certificate group that you want to work with. 5.
Click Import. 6.
Enter a meaningful name, preferably indicating the CA whose certificate you want to import, and the security password. 7.
Open the certificate from the unknown CA in a text editor and copy all of the contents, including the start and end tags. 8.
In the Encoded certificate field, paste the certificate text, and click Save. The certificate is imported into the trust certificate group directory and then copied to each server in the group. Configuring the Domain Host Controller and License Server with an identity certificate The Master REAS must also have an identity certificate containing the CN of that server. On installation, this server is provisioned with a
default, self-signed, identity certificate, in the management-group identity certificate group. This certificate should also be replaced with an
alternative certificate signed by a third-party Certification Authority (CA) or a SCEP server. 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the menu on the left, expand Subsystems > Trust Management and select ID Certificates. 3.
In the Identity Certificate Group area, select management-group. 4.
Do one of the following: 5.
▪
If you want the certificate to be signed by the SCEP server, click SCEP Sign Certificate. ▪
If you want the certificate to be signed by a third-party CA, generate a CSR (see "Generating a CSR"), send it to the
CA and then import the new certificate. (As this certificate is created and imported on the server that is hosting the
Domain Host Controller that you are provisioning, no file transfer is required.) Restart the server that is hosting the Domain Host Controller Replacing an identity certificate You would typically need to replace an identity certificate when it has expired. 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 37 Installation & Configuration Guide - 10.6(1) 3.
From the menu on the left, expand Subsystems > Trust Management and select ID Certificates. 4.
Select the identity certificate group that you want to work with. 5.
Select the certificate entry of the identity certificate that you want to replace. 6.
Do one of the following: ▪
If you want the certificate to be signed by the SCEP server, click SCEP Sign Certificate. ▪
If you want the certificate to be signed by a third-party CA, generate a CSR (see "Generating a CSR" on page 102),
send it to the CA and then import the new certificate. 7.
The updated identity certificate group directory is then copied automatically to each Application Server and Load Balancer in the
Server Group. 8.
Each server hosting an Application Server or Load Balancer must then be restarted for the changes to take effect Exporting an identity certificate 1.
If you want to create a backup copy of a certificate signed by a third-party CA, you can do so by exporting it. 2.
In the Management Console, from the top-right menu select Profiles. 3.
From the Profile drop-down list, select the management profile. 4.
From the menu on the left, expand Subsystems > Trust Management and select ID Certificates. 5.
Select the identity certificate group that you want to work with. 6.
Select the certificate entry of the identity certificate that you want to export. 7.
Click Export. 8.
Enter the security password. A dialog containing the certificate text is displayed. 9.
Copy the text and paste it into a text editor, then save the file. 10. Click Cancel to close the dialog. Removing a trust certificate You would typically remove a trust certificate to prevent TLS connections from machines that use identity certificates signed by a specific
CA that you no longer trust. 1.
In the Management Console, from the top-right menu select Profiles. 2.
From the Profile drop-down list, select the management profile. 3.
From the menu on the left, expand Subsystems > Trust Management and select Trust Certificates. 4.
Select the trust certificate group that you want to work with. 5.
Select the trust certificate that you want to remove. 6.
Click Remove. 38 Installation & Configuration Guide - 10.6(1) 7.
Enter the security password and click Save. 8.
The updated identity certificate group directory is then copied automatically to each Application Server and Load Balancer in the
Server Group. 9.
Each server hosting an Application Server or Load Balancer must then be restarted for the changes to take effect. Operating System When the OVA has been successfully installed, you can log in to the operating system using the following default credentials: username: root password: changeit These credentials should be changed upon install. Remote Expert Mobile Administration Console The credentials for the Remote Expert Mobile Administration Interface, available at https://<targetvm>:8443/web_plugin_framework/webcontroller are: username: admin password: admin These credentials should be changed upon install.
RE Mobile Gateway Configuration – Outbound SIP Server As SIP messages will need to be routed from REAS to the CUBE, the addresses of all the nodes within the CUBE cluster must be
configured as an Outbound Sip Servers via the Gateway à General Administration page.
The format of the Outbound Sip Server URI is: sip:<CUBE-IP-ADDRESS> (e.g. sip:10.10.10.81 as shown below)
39 Installation & Configuration Guide - 10.6(1) The meaning of these fields is as follows:
•
Rewrite outbound SIP URIs If this is set to true then REAS will update the host part of the Request URI of all outbound requests
to match the host part of the outbound SIP server address. If this is set to false then requests are sent on to the outbound SIP
server(s) without change.
•
Server Timeout The time REAS will allow a server to respond to a request before it is considered to be down before trying
another server.
•
Ping Interval The interval between successive OPTIONS messages being sent to an outbound SIP server when that server is
considered UP.
•
Dead Link Ping Interval The interval between successive OPTIONS messages being sent to an outbound SIP server when that
server is considered DOWN.
REAS will maintain a view of whether it is connected to each of the outbound servers by examining the responses to OPTIONS messages
and the responses to initial requests. The state of the Outbound SIP Server connections can be viewed in the performance log screen which
can be found at Gateway à Performance Log.
When routing a new initial outbound request the REAS will build up an ordered list of Outbound SIP Servers as follows:
•
First, all UP servers are added in a random order.
•
The remaining (DOWN) servers are appended to the list
40 Installation & Configuration Guide - 10.6(1) REAS will then route the request to the first in the list. If no response is received within the configured 'Server Timeout' period then the request
will be routed to the next server in the list and so on until a response is received or no more servers remain. In this latter case the call will fail.
41 Installation & Configuration Guide - 10.6(1) Expert Assist Configuration – Consumer Access Number Regex Remote Expert Assist can be configured to limit the URIs that the consumer can dial.
The consumer JavaScript API can specify the destination URI that it wishes to connect to. This is specified as a SIP URI and is
typically set to an address on the CVP server (e.g. sip:[email protected]). To avoid malicious users from changing this value it is possible to configure the Remote Expert Assist cluster with a regular expression
that the destination provided by the consumer’s browser must match. This configuration item is called the Consumer Access
Number Regex and by default is blank, meaning it will allow calling to any destination. The following steps outline how to lock down the range of addresses that the consumer may dial. 1.
Navigate to the Remote Expert Mobile Administration web console at:
https://<reas-address>:8443/web_plugin_framework/webcontroller 2.
Authenticate with the credentials:
Username: admin Password: admin 3.
Navigate to the Expert Assist tab and click the General Administration menu.
42 Installation & Configuration Guide - 10.6(1) 4.
Edit the Consumer Access Number Regex field with a regular expression suitable for your deployment environment. e.g. To
only allow calls to the destination: sip:[email protected], enter the regex: ^sip:[email protected]$
5.
Click Save.
To test that the Agent Console is working as required, follow the steps outlined in the Testing the Agent Console section of the Post
Install Verification chapter. Expert Assist Configuration – Image Quality Scale Factor Remote Expert Assist can be configured to configure the quality of the screen share seen within the Agent Console. This "Image Quality Scale Factor" is a configuration item of RE Mobile and can be changed via the Expert Assist Administration page on
the Web Plugin Framework web console. 1. Navigate to the Remote Expert Mobile Administration web console at: https://<reas-address>:8443/web_plugin_framework/webcontroller 43 Installation & Configuration Guide - 10.6(1) 2. Authenticate with the credentials: Username: admin Password: admin 3. Navigate to the Expert Assist tab and click the General Administration menu. The property is called "Image Quality Scale Factor" and is defined within a range of 0 to 1, with the default setting being 0.5.
Setting this to 1 will apply no scaling, however will require more bandwidth.
Expert Assist Configuration – Enabling UUI Data Remote Expert Assist can be configured to allow User-to-User Information (UUI) to be passed from the client.
The value specified will be placed in the SIP User-to-User Information header in hex-encoded form. Note that the UUI can only be used
when “Anonymous Consumer Access” is set to “trusted” mode.
The "Anonymous Consumer Access" is a configuration item of RE Mobile and can be changed via the Expert Assist Administration page on
the Web Plugin Framework web console. 1. Navigate to the Remote Expert Mobile Administration web console at: https://<reas-address>:8443/web_plugin_framework/webcontroller 2. Authenticate with the credentials: Username: admin Password: admin 3. Navigate to the Expert Assist tab and click the General Administration menu. The property is called " Anonymous Consumer Access " and should be changed from the default setting of “enabled” to “trusted”. Expert Assist Configuration – Audio and Video Hold Treatment
You can configure how hold is rendered to endpoints using the settings in the proxy.properties file on each of the REM Media Broker servers. You can find this file at /opt/cisco/<release-­‐number>/CSDK/media_broker/. You can configure several properties with the main ones listed below, whether or not audio on hold is enabled: video.hold.on
true|false
Whether or not video on hold is enabled
video.hold.image.path
44 Installation & Configuration Guide - 10.6(1) Video hold image path - image must be in PNG format
audio.hold.on
true|false
45 Installation & Configuration Guide - 10.6(1) Post Install Verification Once you have completed deployment of the RE Mobile cluster, it is recommended that you verify that the solution is properly configured.
This may be done without the use of any additional network components (such as Cisco Contact Centre or CUCM). Validating Expert Assist The Expert Assist sample application is made up of 3 components. ▪
Agent console (this is not related to Finesse) ▪
Supervisor console (this is not related to Finesse) ▪
Consumer-side web application Before a call can be established an Agent must be logged into the Agent console. For ease of testing, without the need to integrate with Call Manager or Finesse, Remote Expert Mobile pre-defines a single user with both
the Agent and Supervisor role assigned to them. ▪
Username: agent1 ▪
Password: agent1 By default, this ‘local’ user has been enabled, and as such, Remote Expert Mobile will first look to authenticate the user logging in via the
Expert Assist Agent/Supervisor Console against these credentials before authenticating against Call Manager or Finesse. Note: This locally authenticated user should only be used when testing the solution configuration, but MUST be disabled in production
deployments.
The ‘local user’ is configured via the Remote Expert Mobile Administration interface (Agent Consoles > Agent Consoles Administration
> Local User Authentication) – See above for details: 46 Installation & Configuration Guide - 10.6(1) Expert Assist Agent Console 1.
For the agent application, open an incognito browser window within Chrome from a system with a webcam
2.
Navigate to: https://<reas-address>:8443/expertassist/agent
3.
Login to the Agent Console using the configured ‘local’ Expert Assist user.
47 Installation & Configuration Guide - 10.6(1) Expert Assist Supervisor Console The Supervisor console is simply used to define the URLs and documents that Agents can push to consumers during an Expert Assist screen
sharing session. 1.
Open an incognito browser window for the agent application and navigate to:
https://<reas-address>:8443/expertassist/supervisor 2.
Login via the Expert Assist Supervisor console to define the URLs and documents that Agents can push to consumers during an Expert
Assist screen sharing session.
Note: By default, the REAS cluster is not configured to trust security certificates. This is not an issue when the remote server that
REAS is connecting to is configured to listen on HTTP. However, if the solution requires that the remote server that REAS is
connecting to use HTTPS, then ensure that one of the available options have been selected.
Expert Assist Consumer-Side Web Application 1.
Open an incognito browser window for the consumer-side application and navigate to:
https://<reas-address>:8443/assistsample/?agent=<LOCAL_EXPERT_ASSIST_USER> Update the “LOCAL_EXPERT_ASSIST_USER” in the URL above to the configured ‘local’ user with the Agent and Supervisor
roles as described above (e.g., Agent1). 48 Installation & Configuration Guide - 10.6(1) 2.
Begin an Assist session by clicking the Assist button in the upper right of the screen.
3.
Click to allow your browser access to your microphone and webcam.
49 Installation & Configuration Guide - 10.6(1) Expert Assist Agent & Supervisor Consoles The Agent Console allows screen share features between consumer and agent.
The Supervisor Console allows screen share files and links to be managed. Both Consoles are installed as part of the OVA onto the REAS (that hosts Expert Assist) but require configuration before they can be used Gadget Pre-Requisites 1.
Cisco Finesse 10.5 / 11.0
▪
This should have been installed and appropriately configured. ▪
It must be connected to a network routable from the Remote Expert Mobile cluster. 2.
One or more Agents must be configured such that they can login to the Agent Console and receive calls.
3.
At least one Supervisor must be configured in order to access the Supervisor Console.
4.
An inbound number must be defined allowing RE Mobile consumers to call into Agents.
5.
The CCE/CCX must be configured to route the configured inbound number to one more Agent-queues.
6.
Configure the Cisco Finesse Administration web application with the location of the RE Mobile cluster hosting the Agent and
Supervisor Gadgets – See the “Configuring the Agent & Supervisor Gadgets within the Finesse Server” section below for details.
7.
Configure the addresses of the machines within the Finesse server cluster via the Web Gateway’s administration console – See the “RE
Mobile Application Server Configuration – Agent & Supervisor Gadget” section below for details.
8.
Optionally, configure Expert Assist to limit URIs that the consumer can dial – See the “Expert Assist Configuration – Consumer
Access Number Regex” section below for details.
Note: Versions of Cisco Finesse before 10.6 make gadget requests using SSLv2Hello protocol. SSLv2Hello is disabled by default
within RE Mobile due to the POODLE vulnerability (October 2014).
A script has been included with the RE Mobile OVA that will enable support for SSLV2Hello. To enable legacy SSLv2Hello, invoke
the
<REAS_INSTALL_DIR>/resources/enable-sslv2.sh script on the master REAS host, and then restart the
service. Once it has been restarted, the script must be executed on all the slave nodes within the cluster e.g. [[email protected] ~]# /opt/cisco/<REAS_INSTALL_DIR>/resources/enable-sslv2.sh And to return to default behaviour, invoke the <REAS_INSTALL_DIR>/resources/disable-sslv2.sh script on each REAS
host in the cluster e.g. [[email protected] ~]# /opt/cisco/<REAS_INSTALL_DIR>/resources/disable-sslv2.sh 50 Installation & Configuration Guide - 10.6(1) Finesse Server Trust Management
To provide a secure Finesse Desktop, the HTTPS identity certificate of the cluster hosting the Expert Assist Gadgets must be added to the
Finesse Tomcat trust-store.
The following steps describe how to achieve this:
1.
Obtain the REAS certificate
Follow the “Exporting an identity certificate” section above to export the Load Balancer’s HTTPS identity certificate.
Note: Ensure to select the main-loadbalancer-group identity certificate group, and then its https identity certificate.
2.
Add the REAS certificate Finesse’s Tomcat trust-store
Refer to the “Add Certificate for HTTPS Gadget” section within the Cisco Finesse Administration Guide for details:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/finesse/finesse_1051/user/guide/CFIN_BK_C3
A9BCBC_00_cisco-finesse-administration-guide-1051.pdf
Note: The Tomcat service must be restarted on all the Finesse nodes after the certificate has been imported into Finesse.
Configuring the Agent & Supervisor Consoles within the Finesse Server The Finesse server needs to be configured with the location of the Expert Assist Agent and Supervisor Consoles. The following steps explain how to achieve this. 1. Open the Cisco Finesse Administration web console by navigating to:
https://<finesse-server>/cfadmin/container/ 2.
Enter the Administrator user’s credentials and click ‘Sign in’.
51 Installation & Configuration Guide - 10.6(1) 3.
Navigate to the Desktop Layout tab.
4.
Adding the Agent and Supervisor consoles to the Finesse console is achieved by editing its layout (defined in XML).
The Finesse console’s UI is divided into tabs. Each of these can contain one or more gadgets. The RE Mobile Agent and
Supervisor gadgets will be configured to reside in separate tabs on the Finesse console. The XML layout of the Finesse console is separated into 2 sections as shown in the diagram below: ▪
One defining the content within the tabs that all Agents have access to ▪
And another defining the content within the tabs that all Supervisors have access to Based on the diagram above, the XML required to define the Agent and Supervisor tabs in order to configure the appropriate
Console is shown below. Agent Console Definition <tab> <id>EA</id> <label>Expert Assist</label> <gadgets> <gadget>https://<reasaddress>:8443/finesse_assist_gadget/FinesseAssist.xml</gadget> </gadgets> </tab> Supervisor Console Definition <tab> 52 Installation & Configuration Guide - 10.6(1) <id>EAS</id> <label>Expert Assist Supervisor</label> <gadgets> <gadget>https://<reasaddress>:8443/finesse_assist_admin_gadget/FinesseAssistAdmin.xml</gadget> </gadgets> </tab> 5.
The XML above should be copied, edited and pasted into the appropriate section of the Desktop Layout XML.
a.
Replace the reas-address with either the IP address of the master REAS node, or the DNS resolvable REAS cluster-address.
The example above shows the URL used to access the Gadgets (hosted on the REAS cluster) being secure. This may be
changed to be insecure if required. If the URL is secure, the Finesse servers MUST be configured to trust the REAS cluster – See the “Finesse Server Trust
Management” section above. b.
Copy the Agent and Supervisor tab definitions into the appropriate section(s) of the console layout.
Note that the Agent tab definition MUST be pasted into the “Agent” role section within the XML. However, it may also be pasted into the “Supervisor” role section if all Supervisors were to require Agent functionality. c.
Click Save.
Configuring the Agent & Supervisor Consoles within the RE Mobile Application Server Prior to starting a screen share, the Agent Console will authenticate the logged in user with the Finesse Server(s) that it will interact with.
The REAS cluster must therefore be configured with the address of the Finesse Server(s) being used. The Finesse Console’s configuration is managed through the Remote Expert Mobile Administration interface: 1.
Navigate to the Remote Expert Mobile Administration web console at:
https://<reas-address>:8443/web_plugin_framework/webcontroller 2.
Authenticate with the credentials:
Username: admin Password: admin 3.
Navigate to the Agent Consoles tab and click the Agent Consoles Administration menu.
This interface allows the configuration of the following: -
Expert Assist Agent Name Label 53 Installation & Configuration Guide - 10.6(1) -
-
-
▪
Enabling the ‘Display Agent Name’ property causes the Agent’s ‘First Name’ field (configured in Cisco Call
Manager) to be displayed to the consumer when the Expert Assist call is established. ▪
If a specific label is required to be displayed to the consumer when the Expert Assist call is established in place of
the Agent’s name, the ‘Display Agent Name’ property should be disabled. Additionally, a value should be entered
in the ‘Fixed Agent Name’ field representing the required label to be used. Outbound HTTP Proxy Setting ▪
This property should only be filled in if Finesse Agents using the gadget will be sharing documents hosted
externally that require access via a HTTP proxy. Otherwise, it should be left blank. ▪
The format of this property is: http://proxyserver:port Certificates Settings ▪
The ‘Trust All Certificates’ property defines whether or not to trust ALL HTTPS certificates provided by the
remote server when making outbound connections e.g. ▪
When the Agent gadget requests access of documents over HTTPS, ▪
When Expert Assist communicates with the Cisco Call Manager via its AXL interface. ▪
The ‘Trust JDK Certificates’ property defines whether or not to trust those HTTPS certificates defined within the
default JDK trust store (i.e. those certificates signed by ‘well-known’ CAs) when making outbound connections
e.g. ▪
When the Agent gadget requests access of documents over HTTPS, ▪
When Expert Assist communicates with the Cisco Call Manager via its AXL interface. Authentication for a Local User o
This property allows a ‘local’ Expert Assist user to be defined with the Agent and/or Supervisor role – The
spelling and case sensitivity of these roles is extremely important. o
When a Finesse user logs in via the Finesse console, their login credentials are sent to the Assist Server (by the RE
Mobile Finesse Gadget(s) that they have been configured with). If these credentials match those of the configured ‘local’ Expert Assist user, the role assigned to the ‘local’ user
will determine which of the RE Mobile Finesse Gadget(s) (that the logged in user has been configured with) will be
enabled. -
A list of Finesse Servers o
The RE Mobile Finesse gadgets use this list of servers to authenticate both Agents and Supervisors. When a user initiates an action (either the Supervisor gadget loading the resources that will be shared between
agent and consumer, during its initialization process; Or the Agent gadget requesting the consumer’s permission to
start a screen-share session), the RE Mobile Finesse gadget requests permission from Expert Assist to allow that
user to perform the action. As part of this request, the gadget sends the user’s credentials to Expert Assist, which will attempt to contact the
first server in this list asking it to validate the user’s credentials. The next server in the list will only be contacted if
the current server does not respond (e.g. if the server is offline). If the current server does respond, Expert Assist
54 Installation & Configuration Guide - 10.6(1) will either give permission to the gadget to perform the user’s requested operation, or deny it permission, based on
the response received from the server. -
o
In a clustered Finesse server environment, the Gadget may be configured with many Finesse Servers and may
authenticate with any of them. o
Click the Add button and enter the HTTP(S) URL of each Finesse Server (e.g.
https://<FinesseAddress>:<Port>). ▪
As Finesse is being accessed securely, the appropriate Certificate Settings (see above) must be selected. Call Manager Settings o
4.
These settings are only required for the non-Finesse Agent Console which authenticates against the specified Call
Manager’s AXL interface. Click “Save” to persist the configuration changes to the Finesse Gadget.
The screenshot below shows the layout of the properties described above on the Remote Expert Mobile Administration interface. 55 Installation & Configuration Guide - 10.6(1) 56 Installation & Configuration Guide - 10.6(1) Testing Finesse Gadget The following steps illustrate how to test that the Finesse Gadget has been properly installed and configured: 1.
Ensure a Finesse agent is logged in to the Finesse Server.
a.
Navigate to https://<finesse-server>/desktop/container/
b.
Authenticate with the agent ID, password and phone extension.
2.
A consumer should browse to any Remote Expert Mobile Assist enabled website (this may be the sample website installed with the
product).
If using the sample website: Navigate to the website URL, providing the agent details as a URI encoded parameter. The URL should take the form: https://<rem-server-address>/assistsample/?agent=sip:<tel-number>@<CUBE_IP> e.g., if the RE Mobile server address is example.com, and the agent URI is sip:[email protected] (where 100.1.0.100 is
the IP address of the Cisco UBE): https://example.com/assistsample/?agent=sip:[email protected] 3.
The agent value, set above, should be restricted using the Consumer Access Number Regex configuration outlined in the Configure
Remote Expert Assist – Consumer Access Number Regex.
Note: The Agent and Consumer pages must be opened on separate machines, or different browsers or in incognito mode to avoid web
socket issues. These issues will only arise during testing.
Below is a typical view of the agent and consumer browsers. The agent is seeing the consumer’s screen and has chosen to highlight
an area of the screen. 57 Installation & Configuration Guide - 10.6(1) Restricting Application URIs via the Reverse Proxy The reverse proxy is installed in front of the REAS as shown in the diagram below. By only making specific REAS URIs publically visible, results in clients (in the Consumer Network) only having access to the server
resources they need, while all others are protected. The following table shows the URIs that should be allowed through the reverse proxy. Path Protocol Description /csdk-sample/* HTTP(s) Client SDK sample application. /gateway/csdk-sdk.js /gateway/csdk-presence.js /gateway/csdk-aed.js HTTP(s) Web SDK assets. HTTP(s) HTTP(s) Web SDK assets. Web SDK assets. /gateway/csdk-common.js HTTP(s) Web SDK assets. /assistserver/defaultUIResources/
* HTTP(s) Default UI used by iOS clients. /assistserver/img/* HTTP(s) Some common graphical resources. /assistserver/consumer HTTP(s) Servlet used to provide clients with a session. /assistserver/sdk/web/consumer/* HTTP(s) Web SDK assets. /assistserver/sdk/web/shared/* HTTP(s) Web SDK assets. /gateway/adapter.js /assistserver/topic HTTP(s) Web SDK assets. WebSocket WebSocket used for screen share, annotations …etc. 58 Installation & Configuration Guide - 10.6(1) /gateway/websocketcall Web Socket Web Socket used for call control. The following specifically relates to the RE Mobile consumer-side sample application URIs. Path Protocol Description /assistsample/* HTTP(s) Expert Assist sample client application. The following specifically relates to the URIs used by the RE Mobile Agent and Supervisor consoles. Path Protocol Description /expertassist/agent/* HTTP(s) HTTP(s) Expert Assist Agent console. Expert Assist Supervisor console. HTTP(s) HTTP(s) HTTP(s) HTTP(s) HTTP(s) HTTP(s) HTTP(s) Web SDK assets. Web Agent SDK assets. Web Agent SDK assets. Web SDK assets. Web SDK assets. Web SDK assets. Web Socket Web socket used by Agent to connect to a Consumer’s
screen share. /expertassist/supervisor/* /gateway/adapter.js /assistserver/sdk/web/shared/* /assistserver/sdk/web/agent/* /gateway/csdk-phone.js /gateway/csdk-aed.js /gateway/csdk-common.js /expertassist/agent/token /assistserver/topic/* 59 Servlet used to provide Agents with a session. Installation & Configuration Guide - 10.6(1) Additional Information Supported features 1.
SAN with Fibre interconnect - Use of a SAN with Fibre interconnect, rather than a NAS, is recommended in order to maximize the
transfer speed.
2.
Incremental VMware Backups - If incremental backups are to be enabled, ensure that you follow the VMware Guides on 1st & 3rd
Party Backup Solutions. Unsupported features 1.
VMware fault tolerant mode - VMware fault tolerant mode is not supported (because the Remote Expert Mobile uses multiple cores). 2.
vMotion - vMotion has not been tested with Remote Expert Mobile.
▪
NOTE: VMware snapshots are not supported and will cause performance issues Configuring the UCM Deployment Model
The Remote Expert Mobile Application server will connect to a CUCM Cluster via a SIP trunk. To define a SIP Trunk that correlates to the
REAS cluster 1.
Create a SIP trunk security profile,
i.
From the Navigation drop-down list, select Cisco Unified CM Administration, and click Go.
ii.
From the System menu, select Security > SIP Trunk Security Profile.
iii.
Click Add New.
iv.
Name a Description
v.
Ensure the incoming Transport Type is TCP+UDP
vi.
Check the box for ‘Accept Presence Subscription’, ‘Accept Out-of-Dialog REFER, ‘Accept Unsolicited Notification’
and ‘Accept Replaces Header’
2.
Create a SIP Profile for Remote Expert Mobile
3.
Create a SIP trunk
i.
From the Device menu, select Trunk.
ii.
Click Add New.
iii.
From the Trunk Type drop-down list select SIP Trunk, and click Next.
iv.
Enter the device name, for example SIPTrunk.
v.
From the Device Pool drop-down list select Default.
60 Installation & Configuration Guide - 10.6(1) vi.
Select the Media Termination Point Required check box.
vii.
Select the Redirecting Diversion header Delivery - Inbound check box.
viii.
In the Outbound Call area, select the Redirecting Diversion header Delivery – Outbound check box.
ix.
In the SIP Information area, in the destination Address field enter the IP address of REAS
x.
From the SIP Trunk Security Profile drop-down list select the security profile that you created in "Configuring a SIP
trunk security profile" on 1.
xi.
From the SIP Profile drop-down list select the SIP profile that you created in "Creating a SIP profile" on 2.
xii.
Click Save.
Create a normalization script that will be applied to the CUCM trunk. This will alter the SIP message to change the hosts part of
destination addresses to be what Remote Expert Mobile expects. The script for our example user is as follows: M = {}
function M.outbound_INVITE(msg)
local method, ruri, ver = msg:getRequestLine()
local uri = string.gsub(ruri, "@(.*):%d+", "@fcsdk.registration.domain")
msg:setRequestUri(uri)
local toheader = msg:getHeader("To")
local touri = string.gsub(toheader, "@(.*)>", "@fcsdk.registration.domain>")
msg:modifyHeader("To", touri)
end
return M Alter the script to reflect your Remote Expert Mobile registration/SIP domain. Then, 4.
Set up an End User
5.
Create a CTI Remote Device and associate it with the End User
6.
Add a Directory Number to the Device
7.
Define a Route Pattern and associate it with the SIP Trunk to the REAS cluster
8.
Add Remote Destination that matches the Route Pattern
9.
Define a new Line Group and associate it with a DN
10. Create a Hunt List and associate it with the Line Group
11. Define a Hunt Pilot and associate it with the Hunt List
61 Installation & Configuration Guide - 10.6(1) Acronym List ▪
CIDR - Classless Inter-Domain Routing ▪
CODEC – “coder-decoder" encodes a data stream or signal for transmission and decodes it for playback in voice over IP and video
conferencing applications. ▪
CSDK - Remote Expert Mobile Client SDKs. Includes three distinct SDKs for iOS, Android and Web/JavaScript developers. ▪
CUBE – Cisco Unified Border Element, a Cisco session border controller used in contact center and unified communications solutions ▪
CUCM – Cisco Unified Communications Manager or Unified CM ▪
CUCS – Cisco Unified Computing System servers ▪
CVP – Cisco Unified Voice Portal ▪
G.711 – PCMU/A 8-bit audio codec used for base telephony applications ▪
G.729a – low bit rate audio codec for VoIP applications ▪
H.264 – video codec. H.264 is the dominant video compression technology, or codec, in industry that was developed by the
International Telecommunications Union (as H.264 and MPEG-4 Part 10, Advanced Video Coding, or AVC). Cisco is open-sourcing
its H.264 codec (Open H.264) and providing a binary software module that can be downloaded for free from the Internet. Cisco will
cover MPEG LA licensing costs for this module. ▪
Opus – low bit rate, high definition audio codec for VoIP applications. Opus is unmatched for interactive speech and music
transmission over the Internet, but is also intended for storage and streaming applications. It is standardized by the Internet Engineering
Task Force (IETF) as RFC 6716 which incorporated technology from Skype's SILK codec and Xiph.Org's CELT codec (www.opuscodec.org) ▪
NACK – Negative Acknowledgement. NACK is used by the receivers of video to indicate the loss of one or more RTP packets as par
to the base mechanisms of the Real-time Transport Control Protocol (RTCP). This enables the sender to resend video packets to handle
packet loss over the Internet or poor network conditions. ▪
PCCE - Cisco Packaged Contact Center Enterprise (Packaged CCE) ▪
PLI – Packet Loss Indication is another feedback mechanism of the Real-time Transport Control Protocol (RTCP) which enables the
sender to resend keyframe packets to re-establish a full video picture when communicating over the Internet or poor network
conditions. ▪
REAS – Remote Expert Mobile Application Server ▪
REMB – Remote Expert Mobile Media Broker ▪
RTP – Real-time Transport Protocol ▪
RTCP – Real-time Transport Control Protocol ▪
UC – Unified Communications ▪
UCCE – Cisco Unified Contact Center Enterprise (Unified CCE) ▪
UCCX - Cisco Unified Contact Center Express (Unified CCX) ▪
VP8 – video codec. VP8 is a video compression format owned by Google. Google remains a staunch supporter of VP8 after buying
On2 Technologies in 2010. Google then released VP8 software under a BSD-like license as well as the VP8 bitstream specification
under an irrevocable license and free of royalties. VP8 is roughly equivalent in processor usage, bandwidth and quality as H.264. ▪
WebRTC – Web Real Time Communications for plugin-less communications 62 
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement