request for proposals 2018-005 - nlchi · 12/01/2018 · request for proposals 2018-005 telehealth...

REQUEST FOR PROPOSALS

2018-005 Telehealth Consultant

Issued: January 12, 2018

Background The Newfoundland and Labrador Centre for Health Information (the Centre) is a provincial crown agency governed by a Board of Directors and managed by a President and Chief Executive Officer. The Centre provides quality information to health professionals, the public, researchers and health system decision-makers. Through collaboration with the health system, the Centre supports the development of data and technical standards and provides analytic, evaluation and information management services that supports health care delivery, health system management, performance measurement and monitoring, program planning, policy and decision-making and research. The Centre’s mandate also includes the development, implementation and operation of a confidential and secure provincial electronic health record (EHR) and provincial health information systems. The Centre's vision is improved health through quality health information. For more information on the Newfoundland and Labrador Centre for Health Information, please visit www.nlchi.nl.ca.

Introduction The Centre’s mandate includes responsibility for the provincial Telehealth environment. Telehealth enables the delivery of equitable health services to patients in Newfoundland and Labrador regardless of location. Today, Telehealth is offered in 98 sites across 63 communities. Used in over 20 clinical disciplines, 18,000 patient appointments were booked last year. By reducing the need for patients, family and specialist travel, Telehealth enhances the continuity and capacity of care throughout the health care system. The Centre currently operates an existing Telehealth environment consisting of Cisco Video Communications Server Control, VCS-Expressway, Unified Communications Manager, Instant Messaging & Presence, Telepresence Server, Conductor and Telepresence Management Suite. The Centre has worked with Cisco Systems to develop an updated Telehealth Infrastructure Architecture (Appendix V below) which will replace and enhance the existing environment. The proposed architecture is designed to achieve the following business objectives:

Support all clinical Telehealth use cases;

Scalable to future capacity requirements;

High availability;

http://www.nlchi.nl.ca/

Highly Secure;

Preserve existing functionality; and

Interoperability with existing endpoints. Telehealth services currently utilize Cisco and Polycom telepresence endpoints along with the Cisco Jabber client. These services will continue to operate on the existing infrastructure until the new system is completed and certified for production. The selected vendor will then plan and assist with transitioning these existing services from the older infrastructure to the new environment. The Centre is looking to engage a qualified consultant to participate in this Telehealth Infrastructure Upgrade project. The successful candidate will work from the Centre’s offices located in St. John’s, NL. The work is scheduled to start in early February for a four month term. Statement of Work and Deliverables Below is an outline of the statement of work required for this role. Additional information is also available in the Appendices of this document. In order to respond, proponents must demonstrate that they are able to meet each one of these requirements. Proposals that do not adhere to the requirements will be rejected and not considered for evaluation.

Conduct an engagement conference call for initial data gathering and review.

Conduct a design workshop with the Centre business and technical stakeholders to gather

and confirm information required for the Unified Collaboration environment deployment.

Specific information to be covered will include, but not be limited to:

o Project Overview

o Confirmation of business requirements

o Define success criteria for the project.

o Review technical architecture which has been produced by Centre staff.

Provide project management services including, but not limited to: a well-defined scope, milestones, timeline, meetings, reporting and a project work breakdown structure.

Prepare a system documentation package.

Submit all deliverables for preliminary review and final review, complete with a design review meeting(s)

Lead the install, configuration and commissioning of the lab and production environments and provide mentorship to technical resources.

Lead the transition of existing Telehealth services to the new system.

Prepare a Site Acceptance Test (SAT) plan for review/signoff by owner prior to the execution of any system testing

Execute Site Acceptance Testing (SAT) and record all results in the Site Acceptance Test report

Ongoing knowledge transfer to Centre’s technical staff

Revise documents and submit “as built” documentation

Provide production environment Tier 2 and Tier 3 technical support (in collaboration with

the Centre staff and processes, COTS vendor) for a 12 month period post go-live.

The Successful Candidate will be responsible to submit the following deliverables:

Documentation package including but not limitied to a detailed design doc, technical

specifications and solution functionality documentation.

System Operation and Maintenance Manual

System Test Plan

System Test Report

Fully functional system that satisfies the technical and functional requirements

Installation and provisioning services for lab and production environments

Solution knowledge transfer to support staff throughout the duration of the Project, including but not limited to design review workshops outlining data flows, a review of solution functionality and key areas to note for troubleshhooting and monitoring.

Provide 24/7/365 Technical Support for 12 months post Project go-live, including: o Adherence to NLCHI Change/Incident Management procedures o Adherence to NLCHI Release Management procedures o Maintaining the solution components up to date

Qualifications

Contractor Qualifications:

Bidders shall demonstrate in their proposals that the meet the following corporate qualifications:

Cisco Premium Partner Certification or better

Authorized Cisco Meeting Server formerly Acano

Completed a minimum of 3 Cisco video conferencing systems integration within the

two years

Team Qualifications:

Team members must have implemented at least 3 Cisco Video solutions in the last 12 months.

At least one team member with Cisco Advanced Architecture Specialization

Team members must have participated in a minimum of three previous video

conferencing installations which included Cisco CMS, UCM, VCS and TMS technologies

Response Format Proposals should be a maximum of ten pages in length and consist only of the following information:

Experience of the service provider and its proposed resource(s) relevant to the RFP’s

scope, including but not limited to: o Cisco partnership level and status; o Details concerning video conferencing systems experience, including customer

name, scope, cost, technology overview and other relevant information to allow Owner to assess bidder’s capabilities;

o Roles and functions of each team member;

o Cisco certifications of each team member;

o Video conferencing experience of each team member; and

o Sample documentation package from a previous Cisco Video Conferencing project,

excluding the O&M manual. Redacted information shall use proxy information.

Resume(s) for proposed resource(s) are to be attached as an appendix to the RFP response;

Daily rate to perform the work for four (4) months;

Other information that would add value to the proposal; and

References (2) – relevant to the scope of work outlined in this document. Proposals that fail to meet these requirements in full will not be considered for further evaluation. Evaluations

The following factors will be taken into account in these evaluations:

Resource’s experience in relation to the work to be performed (65%)

Cost to perform the work for four months (25%) – using St. John’s, NL as the established base (i.e. travel expenses to be included in daily rate)

Corporate Capability - including a corporate social responsibility statement (10%) Proposal Deadline

Responses are due by 2:00 pm NT on January 26, 2018. Electronic responses are mandatory and can be directed to the RFP’s Administrator at [email protected].

Questions

Questions can be directed to the RFP’s Administrator at: [email protected]. Oral responses to questions will not be provided. Responses to written questions will be posted as addenda on the website: www.nlchi.nl.ca/index.php/procurement. It is the Respondent’s responsibility to ensure they have all relevant information by regularly checking the web site. The Centre will not disclose the source of any questions submitted by Respondents.

mailto:[email protected]

mailto:[email protected]

http://www.nlchi.nl.ca/index.php/procurement

Questions will be received until 4:00 pm Newfoundland Time on January 23, 2018. Subsequent Phases of Work Should additional work (that fits this role) be required upon expiration of this contract, the Centre reserves the right to retain the successful professional services firm who is awarded this RFP to complete this additional work under separate contract (if performance matches expectations). Terms and Conditions A comprehensive list of the Centre’s RFP terms and conditions can be found at www.nlchi.nl.ca/index.php/procurement.

http://www.nlchi.nl.ca/index.php/procurement

APPENDICES

I. Scope of Proposed Work Vendor shall deploy the following infrastructure, software and licensing on NLCHI provided infrastructure:

a. Redundant VCS-E Cluster;

i. Primary VCS-E (Virtual)

ii. Secondary VCS-E (Virtual)

iii. 20 Traversal Licenses

b. Redundant VCS-C Cluster;

i. Primary VCS-C (Virtual)

ii. Secondary VCS-C (Virtual)

iii. 100 Non-Traversal Licenses

iv. 100 Traversal Licenses

c. Redundant CMS Edge Cluster;

i. CMS Edge-1 (Web Bridge, Load Balancer, TURN server)

ii. CMS Edge-2 (Web Bridge, Load Balancer, TURN server)

d. Redundant CMS core cluster CMS1000 appliances;

i. CMS1000-1 (Call Bridge, XMPP, Database)

ii. CMS1000-2 (Call Bridge, XMPP, Database)

iii. CMS-3 (Virtual) (XMPP, Database)

iv. 4 SMP Licenses

e. Redundant CUCM;

i. Publisher (Virtual)

ii. Primary Subscriber (Virtual)

iii. Secondary Subscriber (Virtual)

iv. 250 UCL Enhanced Plus licenses

v. 250 UCL Enhanced licenses

f. Redundant TMS cluster;

i. Primary TMS (Virtual)

ii. Secondary TMS (Virtual)

iii. 500 Endpoint Licenses

iv. Microsoft Interop

g. Cisco Prime Collaboration Standard

i. Primary CPC (Virtual)

Migration to Telepresence Infrastructure

The Centre currently operates an existing Telehealth infrastructure consisting of Cisco VCS-C/E, CUCM, TMS and IM&P. Telehealth services will continue to operate on the existing Telehealth infrastructure until the new Telehealth system is completed and certified for production.

The selected vendor will assist the Centre with transitioning Telehealth services from the existing infrastructure to the new system.

Lab Environment Build

The selected vendor will provide mentoring and coaching during the build of a lab environment by Centre staff which is to simulate the production environment.

II. Site Acceptance Test Plan and Report Vendor shall prepare a Site Acceptance Test Plan and Test Report. The test plan shall be prepared during system design and the test report will be completed during commissioning and acceptance testing. The test plan shall demonstrate that the systems successfully implements the architecture and design in terms of functionality, performance, redundancy and reliability. Performance and security conformance will be measured against manufacturer’s and industry best practices. The following functional deliverables shall be used as the basis for the Site Acceptance Test (SAT) Plan.

Endpoint Registration

1. All Polycom and Cisco endpoints shall register to VCS-C using SIP or H.323

2. All Cisco Jabber endpoints shall register to CUCM using SIP

SIP URL & H.323 Dialing

1. All endpoints shall be provisioned with a consistent SIP URI

(i.e [email protected])

2. All endpoints shall be capable of dialing using SIP URI, H.323 alias@domain and dialing by

IP address.

Collaboration Edge

1. The VCS-C/E must be configured to support Mobile and Remote Access (MRA) for both

physical endpoints and Jabber soft clients connecting outside of the firewall

2. The VCS-C/E must be configured to support Automatic Service Discovery for Mobile and

Remote Access (MRA)

3. The VCS-C/E must be configured to support Business-to-Business (B2B) video

4. The VCS-C/E must be configured to support SIP-H323 interworking

CMS Edge

1. The CMS Edge must be configured to WebRTC access to the CMS Call Bridge

2. The CMS Edge must be configured to Cisco Meeting App (CMA) access to the CMS Call Bridge

Skype for Business Call Routing

1. Outbound

a. VCS-C must be configured to route Skype for Business (S4B) domains (i.e.

easternhealth.ca) through CMS.

b. CMS will be configured to transcode SIP/H.323 calls to H.264 SVC (Microsoft S4B)

and route the call to VCS

2. Inbound

a. VCS-C will be configured inspect route video calls containing the Microsoft AV &

Share SIP variant to CMS

b. CMS will be configured to transcode H.264 SVC (Microsoft S4B) to SIP/H.323 calls

and route the call back to VCS

Cisco Meeting Server (CMS)

1. CMS must be configured for all licensed call bridges.

2. Template Personal Meeting Rooms must be configured with pin codes, or other standard

security measures.

3. CMS must be configured to work with Skype for Business.

Telepresence Endpoint Management

1. TMS must be configured to manage a consist software inventory on all endpoints

2. TMS must be configured to maintain backup configurations for all supported endpoints

3. TMS will integrated with a dedicated Telehealth Active Directory

Soft Client Video

1. All Jabber soft clients will be provisioned on CUCM using Jabber Phone Only mode

2. CUCM will integrated with a dedicated Telehealth Active Directory

3. All Jabber clients shall be provisioned for Automatic Service Discovery

4. Automatic Service Discovery shall be configured to work on the Internal network and

external networks (i.e. Internet)

Platform Security

1. All infrastructure , software components and communications shall be configured using

industry best practices and manufacturer guidelines for security hardening

III. Functional Use Cases

The system must be configured to support the following use cases;

Source Destination

Internal or External

Polycom Endpoint calling

Internal Polycom endpoint

Internal Cisco endpoint

Internal Jabber

MRA Cisco endpoint

MRA Jabber client

Into CMS Space

External SIP endpoint

External H323 endpoint

Webex CMR


Cisco Endpoint or Jabber Client calling

Internal Polycom endpoint

Internal Cisco endpoint

Internal Jabber

MRA Cisco endpoint

MRA Jabber client

Into CMS Space

External SIP endpoint

External H323 endpoint

Webex CMR


Skype Client calling Into CMS Space

WebRTC client calling Into CMS Space

IV. System Documentation Package

Vendor shall prepare a documentation package composed of the following: Detailed Design Document which includes

i. Architecture Diagram ii. Logical description of interconnection of modules and components;

Operations & Maintenance (O&M) Manual: i. Theory of operation, suitable for administrators and maintainers;

ii. Detailed administrative procedures: a. Moves, Adds, Changes and Deletions (MACD) of end points; b. Call setup and flow control; c. Backups d. Database purging; e. Editing other parameters; f. Review of system logs;

iii. Maintenance procedures: a. Monthly, quarterly and annual performance checks; b. Monthly, quarterly and annual preventative maintenance procedures c. Restorative maintenance procedures d. Common troubleshooting procedures

iv. Relevant manufacturer’s manuals and drawings v. Parts lists, including model numbers

vi. Serial number of equipment (if applicable) vii. Software Licensing information

viii. Support Contract Information

Site Acceptance Test Plan o Test philosophy; o Test procedures; o Minimum performance level and pass fail criteria for each test;

Site Acceptance Test Report o Summarize results of Site Acceptance Test procedures; o Identify any deficiencies and the Consultants plans and timeline to address the

deficiencies; o Documents systems ability to deliver all functional use cases; o Documents the system’s ability to deliver the specified redundancy and reliability.

V. Proposed Architecture The Centre has worked with Cisco Systems to develop the following updated Telehealth Infrastructure Architecture.

Telehealth Collaboration

Technical Architecture

Telehealth Collaboration - V1

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page ii

Document Control

Reviewers Name Position

Andrew Roberts Manager, Security and Architecture

Kevin Hillier Technical Manager

Ashley Dinn Telehealth Program Manager Mary Slade Director, Clinical Information Programs

Distribution Copy No. Name Location

1. NLCHI 70 O’leary Avenue, St. John’s, NL

Referenced Documentation Author Document Version

Cisco http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd.html

11.6

Cisco http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-collaboration/index.html

Change Control Date Author Version Change

January 12, 2018 Tony Galway 1 Released Document

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page iii

Contents Document Control......................................................................................................................................... ii

Reviewers .................................................................................................................................................. ii

Distribution ............................................................................................................................................... ii

Referenced Documentation ...................................................................................................................... ii

Change Control ......................................................................................................................................... ii

Contents ....................................................................................................................................................... iii

1 Executive Summary ............................................................................................................................... 8

1.1 Collaboration Infrastructure ......................................................................................................... 8

1.1.1 Scheduling & Management ................................................................................................... 8

1.1.2 Call Control & Collaboration Edge ........................................................................................ 9

1.1.3 Conferencing ......................................................................................................................... 9

1.1.4 Endpoints .............................................................................................................................. 9

1.2 Scope ........................................................................................................................................... 10

2 Current Telehealth Collaboration Architecture .................................................................................. 11

3 Requirements ...................................................................................................................................... 13

3.1 Use Cases .................................................................................................................................... 13

3.2 Further Benefits .......................................................................................................................... 13

3.3 Growth ........................................................................................................................................ 13

4 Data Flow ............................................................................................................................................ 14

4.1 Traditional Telepresence Use – Inter/Intra - RHA Communications .......................................... 14

4.2 Client Service Discovery .............................................................................................................. 15

4.2.1 Client Service Discovery inside RHA Networks ................................................................... 15

4.2.2 Client Service Discovery from the Internet ......................................................................... 16

5 Components ........................................................................................................................................ 17

5.1 Future Components .................................................................................................................... 18

6 Endpoint Registration ......................................................................................................................... 19

6.1 Internal (HIN) Endpoint Registration .......................................................................................... 19

6.2 Internet Endpoint Registration ................................................................................................... 19

6.2.1 Configuring Endpoints to work with a Cluster .................................................................... 20

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page iv

7 Edge Services....................................................................................................................................... 23

7.1 Cisco Telepresence Video Communication Server - VCS ............................................................ 23

7.1.1 VCS Expressway ................................................................................................................... 23

7.1.2 VCS Control ......................................................................................................................... 27

7.1.3 Cisco VCS Cluster ................................................................................................................. 29

7.1.4 Certificate Requirements .................................................................................................... 31

7.1.5 System Time ........................................................................................................................ 32

7.1.6 Deployment Requirements ................................................................................................. 32

7.2 Cisco Meeting Server Edge.......................................................................................................... 34

7.2.1 DNS - Cisco Meeting Server Edge – A Record ..................................................................... 35

7.2.2 Load Balancer ...................................................................................................................... 35

7.2.3 TURN Server ........................................................................................................................ 36

7.2.4 Turn Server - Firewall Ports ................................................................................................. 37

7.2.5 Web Bridge .......................................................................................................................... 37


7.2.7 System Time ........................................................................................................................ 39


8 Core Services ....................................................................................................................................... 41

8.1 Cisco Unified Communications Manager (CUCM) ...................................................................... 42

8.1.1 Clustering ............................................................................................................................ 43

8.1.2 Security ............................................................................................................................... 46

8.1.3 Endpoint Hardening ............................................................................................................ 47

8.1.4 Certificates .......................................................................................................................... 48

8.1.5 DNS ...................................................................................................................................... 48

8.1.6 System Time ........................................................................................................................ 49


8.2 Instant Messaging & Presence (IM&P) ....................................................................................... 50

8.2.1 Persistent Chat .................................................................................................................... 51

8.2.2 Managed File Transfer ........................................................................................................ 52

8.2.3 IM and Presence Message Archiving and Compliance ....................................................... 52

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page v

8.2.4 Calendar Integration ........................................................................................................... 53

8.2.5 Clustering ............................................................................................................................ 53

8.2.6 DNS ...................................................................................................................................... 54

8.2.7 System Time ........................................................................................................................ 54


8.2.9 SIP Trunk ............................................................................................................................. 55

8.2.10 Compliance and Privacy ...................................................................................................... 55

8.3 Cisco Meeting Server .................................................................................................................. 56

8.3.1 Components of CMS ........................................................................................................... 57

8.3.2 Database Resiliency ............................................................................................................ 59

8.3.3 Call Bridge ........................................................................................................................... 60

8.3.4 Call Bridge - DNS ................................................................................................................. 62

8.3.5 XMPP ................................................................................................................................... 63

8.3.6 LDAP Integration ................................................................................................................. 66

8.3.7 DNS - Cisco Meeting Server – A Record .............................................................................. 66

8.3.8 Sizing ................................................................................................................................... 67

8.3.9 MMP .................................................................................................................................... 68



8.4 Active Directory Integration ........................................................................................................ 71

8.4.1 LDAP Integration Features .................................................................................................. 72

8.4.2 Unified CM to AD ................................................................................................................ 72

8.4.3 Firewall Ports ...................................................................................................................... 73


9 Management ....................................................................................................................................... 74

9.1 Telepresence Management Suite and Extensions ...................................................................... 74

9.1.1 Supported Systems ............................................................................................................. 75

9.1.2 Firewall Ports ...................................................................................................................... 76

9.1.3 Redundant Deployment ...................................................................................................... 76


Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page vi

9.2 Prime Collaboration Standard ..................................................................................................... 79

9.2.1 Features .............................................................................................................................. 79

9.2.2 Ports .................................................................................................................................... 79


10 Endpoints ........................................................................................................................................ 82

10.1 Traditional Endpoints .................................................................................................................. 82

10.2 Jabber .......................................................................................................................................... 82

10.2.1 User Identification............................................................................................................... 83

10.2.2 Discovery and DNS .............................................................................................................. 83

10.2.3 Firewall Ports ...................................................................................................................... 84

11 Backup & Disaster Recovery ........................................................................................................... 86

11.1 Pre-Requisite ............................................................................................................................... 86

11.1.1 Configure SFTP Service ........................................................................................................ 86

11.2 Backup Schedule ......................................................................................................................... 88

11.3 Cisco Disaster Recovery System (DRS) ........................................................................................ 88

11.3.1 Backup Procedures.............................................................................................................. 89

11.3.2 VCS Control & VCS Expressway ........................................................................................... 95

11.4 Cisco Telepresence Management Server .................................................................................... 98

11.4.1 Cisco Telepresence Server .................................................................................................. 98

Appendix A Server Requirements ........................................................................................................ 101

Appendix B Licensing ............................................................................................................................ 103

Appendix C Lab Environment ............................................................................................................... 105

C.1 VCS ............................................................................................................................................ 105

C.1.1 Hardware........................................................................................................................... 105

C.1.2 Software & License Requirements .................................................................................... 105

C.1.3 Network ............................................................................................................................ 105

C.2 Unified CM and IM & Presence ................................................................................................. 106

C.2.1 Hardware........................................................................................................................... 106

C.2.2 Software & Licensing Requirements ................................................................................. 106

C.2.3 Network ............................................................................................................................ 106

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page vii

C.3 Cisco Meeting Server ................................................................................................................ 106

C.3.1 Hardware........................................................................................................................... 106


C.3.3 Network ............................................................................................................................ 106

C.4 Telepresence Management Suite & LDAP ................................................................................ 107

C.4.1 Hardware........................................................................................................................... 107


C.4.3 Network ............................................................................................................................ 107

C.5 Prime Collaboration .................................................................................................................. 107

C.5.1 Hardware........................................................................................................................... 107


C.5.3 Network ............................................................................................................................ 107

Appendix D WebRTC ............................................................................................................................. 108

Appendix E Glossary ............................................................................................................................. 109

Appendix F Acronyms .......................................................................................................................... 113

Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 8

1 Executive Summary Telehealth collaboration started with the goal of providing video conferencing amongst clinicians and

between clinicians and their patients. From there the opportunity to expand the environment with

instant messaging and presence to provide further capabilities was seen, and from that further use cases

became apparent.

The architecture provided herein provides the framework for a provincial collaboration environment

that consolidates communications infrastructure, incorporates video into meetings, and permits instant

messaging, presence and content sharing, all within a highly available production ready infrastructure.

The Telehealth Collaboration architecture takes advantage of the published Cisco Preferred

Architecture1 V11.6 (February 2017) and is based on Cisco’s engineering best practices. High availability

for all deployed applications is provided by means of the underlying clustering capabilities present in

each Unified Communications application.

1.1 Collaboration Infrastructure

Figure 1 - Collaboration Infrastructure Overview

The infographic above groups the components of the collaboration infrastructure within associated

layers.

1.1.1 Scheduling & Management

Cisco Prime Collaboration: Cisco Prime Collaboration helps enable rapid installation and

maintenance of Cisco Unified Communications and Cisco TelePresence components as well as

the provisioning of users and services.

1 http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-collaboration/index.html


Cisco TelePresence Management Suite (Cisco TMS): TMS offers complete control and

management of multiparty conferencing, infrastructure, and endpoints, to centralize

management of your entire video collaboration and TelePresence network.

Active Directory: An integrated active directory enables centralized user authentication through

forwarding requests rather than individual local accounts on environment components.

1.1.2 Call Control & Collaboration Edge

Cisco Unified Communications Manager: CUCM is an IP-based communications system

integrating voice, video, data, and mobility products and applications.

Cisco Instant Messaging & Presence: IM&P supports the following high level functions;

enterprise instant messaging, text conferencing, network based presence and contact

management.

Cisco Video Communications Server Control: VCS Control provides video call and session control,

registrations, and enhanced security for Cisco TelePresence conferences. Cisco VCS enables

features such as routing, dial plans, and bandwidth usage control, while allowing organizations

to define video call-management applications that are customized to their requirements.

Cisco Video Communications Server Expressway: VCS Expressway allows video traffic to traverse

the firewall securely, enabling rich video communications with external clients.

Cisco Meeting Server Edge: CMS Edge allows video traffic to traverse the firewall for multiparty

meetings as well as Skype for Business integrations.

1.1.3 Conferencing

Cisco Meeting Server: CMS brings premises-based video, audio, and web communication

together to meet collaboration needs for multi-party communications. It works with third-party

devices and scales easily.

1.1.4 Endpoints

The endpoint layer typically includes the following types of endpoints:

Cisco Jabber

Cisco Jabber lets you access presence, instant messaging (IM), voice, video, voice messaging,

desktop sharing, and conferencing. Find the right people, see if and how they are available,

and collaborate using your preferred method.

Cisco Meeting App


The Cisco Meeting App allows anyone to create, join, and run meetings easily, from room or

desktop video systems, mobile clients, or browsers.

Collaboration endpoints with video capabilities.

Collaboration room endpoints

WebRTC2

Appendix A 2See Appendix C Lab Environment The production environment’s primary use is Telehealth and as such its availability cannot be

compromised. An identical single instance environment will be deployed with the minimum

requirements to ensure proper functioning and duplication of production.

Figure 55 - Collaboration Lab Environment

A.1 VCS

A.1.1 Hardware

Purpose Server Node vCPU vRam vDisk vNIC

VCS Expressway ucovtzvcse1 2 4 GB 132 2


VCS Control ucovtzvcsc1 2 4 GB 132 2

A.1.2 Software & License Requirements

Description Quantity

Virtual VCS Expressway (incl. 5 Traversal) 1

Virtual VCS Control (incl. 100 Traversal, 10 Non-Traversal) 1

A.1.3 Network

Purpose Hostname Zone IP Address Mask Bits

VCS Expressway

ucovtzvcse1

DMZ – Internal TBD /28

DMZ - External TBD /29

DMZ – Public NAT TBD /29

VCS Control ucovtzvcsc1 Semi-Trust TBD /28

A.2 Unified CM and IM & Presence

A.2.1 Hardware


Unified CM ucovtscucm1 2 4 GB 80 1

IM & Presence ucovtsimp1 1 2 GB 80 2

A.2.2 Software & Licensing Requirements


Unified CM 1

IM & Presence 1

UCL Enhanced License 5

A.2.3 Network


Unified CM ucovtscucm1 Semi-Trust TBD /28

IM & Presence ucovtsimp1 Semi-Trust TBD /28

A.3 Cisco Meeting Server

A.3.1 Hardware


CMS Edge ucovtzcmse1 4 4 GB 100 1

CMS Core ucovtscmsc1 4 4 GB 100 2



Cisco Meeting Server 1


Shared Multiparty License 1

A.3.3 Network


CMS Edge ucovtzcmse1




CMS Core ucovptcmsc1 Semi-Trust TBD /28

A.4 Telepresence Management Suite & LDAP

A.4.1 Hardware


TMS ucovtstms1 2 8 GB 250 1



Telepresence Management Suite (incl. 10 systems) 1

Microsoft Windows Server 2012 1

Microsoft SQL Server 2012 or 2014 1

A.4.3 Network


TMS ucovtstms1 Semi-Trust TBD /28

A.5 Prime Collaboration

A.5.1 Hardware


Prime Collaboration

ucovtscpc1 1 4 GB 100 1




Cisco Prime Collaboration (license included with UCL license above) 5

A.5.3 Network


TMS ucovtcpc1 Semi-Trust TBD /28


WebRTC is an open framework for the web that enables “Real Time Communications” in the

browser. WebRTC is currently supported on Chrome, Firefox, Opera, Android and iOS. It is

not supported by Internet Explorer.

1.2 Scope This architecture document does not extend into the components required for end use. Each Regional

Health Authority (RHA) is responsible for making sure appropriate network bandwidth is available to

support the collaboration environment. This includes connectivity to and from regionally connected

sites such as hospitals, clinics and offices.

The architecture does rely on the health of the Health Information Network (HIN) and that it will be

monitored and managed by the NLCHI. The NLCHI will be responsible for making sure appropriate

network bandwidth is available via the HIN to support video conferencing.

WebRTC


2 Current Telehealth Collaboration Architecture The Telehealth collaboration environment is currently deployed as a non-redundant environment on

single instance virtual machines for a limited number of users.

SRX3600172.16.4.5

Security Zone: prod-SemitrustNL_HIN

10.57.112.0/28

Security Zone: OutsideOutside

10.57.11.16/28

VLAN423reth2.423

VLAN449reth2.449

VLAN520reth4.520

NL-HIN10.55.112.1

Outside10.57.11.20/28

TELE_SEMITRUST10.57.0.45(transit)

NL HIN

TelehealthCollaboration Architecture

NLCHI HIN Router (CH)

CH Firewall

NLCHI HIN Router (WH)

WH Firewall

TMS10.57.3.231

pthtmsb1

Internet

NLCHI HIN Router (EH)

EH Firewall

VCS-C10.57.3.228

STHVCCA1_VCS-C

CUCM10.57.3.236 (pthcua1)

Conductor(pthcoa1)10.57.3.235 (Admin)

10.57.3.226 (Telehealth Meetings)

10.57.3.227 (Telehealth Adhoc)

vTS (410v)10.57.3.234

pthtsa1

Jabber Guest10.57.3.233 (pthjga1)

SIP

Tru

nk

SIP

Tru

nkSI

P T

runk

IM&P/Jabber10.57.3.232

pthjsa1

SIP

Tru

nk

NLCHI HIN Router

VCS-E (STHVCEA1_VCS-E)

10.57.3.212/28 (LAN1)10.57.3.196/28 (LAN2)

24.222.186.241(LAN2/NAT)

OCIO

EHR_DMZ_Internal10.57.3.208/28

OCIO

NLCHI_EHR_DMZ_EXT_PROD10.57.3.192/28 outside/

24.222.186.250/27

inside/10.57.11.17/28

Inbound (Internet) Flow:ASA(outside)

ASA(Tele-DMZEXT)ASA(Tele-DMZINT)

ASA(inside)SRX(Outside)

SRX(Tele-Semitrust)6513(Tele-Semitrust VRF)

ASA 551610.42.230.25

SIP

Tru

nk

Security Zone: prod-SemitrustEHR_HINDMZ_APP_PROD

10.57.3.224/28

Figure 2 - Current Telehealth

In addition, some of the software used is based on older Cisco technologies and procedures. As a result

of the updated Preferred Architecture (Version 11.6) there are several components that have been

consolidated into the single Cisco Meeting Server based on Cisco’s product roadmap that make a less

complicated and more robust environment.

Module Component Description

Collaboration Management

Cisco TelePresence Conductor Manages conferencing resources

Cisco TelePresence Server Provides audio and video conferencing resources

Cisco Jabber Guest CMS offers a tighter more secure integration to video conferencing with better screen sharing capabilities than Jabber Guest.

Table 1 - Components replaced by Meeting Server


Conductor

TelepresenceServer

Jabber GuestJabber Guest

Meeting Server

Table 2 - Component Consolidation

Cisco Meeting Server is a persistent, always available video conference environment that pretty much

anyone can join; whether they use Cisco’s Telepresence endpoints, Microsoft Skype for Business or even

a web browser through WebRTC3. Meeting Server is the current preferred conferencing solution

recommended by Cisco for on premises deployment.

3 WebRTC is supported on Chrome and Firefox.


3 Requirements The primary goal of the collaboration environment is to enhance the relationships amongst health care

providers and between the health care provider and their patients. As a result of a robust unified

communications environment we save time, money and IT resources. We can also limit duplication

across the RHA’s through the deployment of a consolidated communications infrastructure.

3.1 Use Cases Use Case

From traditional telehealth endpoint Connect to Jabber application (mobile or PC) throughout any RHA across the HIN.

Connect to at a client’s home, via app or mobile browser.

From PC or mobile app

Connect to traditional telehealth endpoint at RHA across the HIN.

Connect to at a client’s home, via app or mobile browser.

Connect to another Jabber Application (mobile or PC) across RHA or Internet.

3.2 Further Benefits Just some of the broad uses and value of collaboration and unified communications include:

Use Case Description

Consolidating Infrastructure Rather than each RHA support their own collaboration suite of products, a single provincial environment ensures strong interoperability amongst the RHA’s and provides savings through consolidation of hardware, software licensing and management.

Enable meetings with remote participants

The use of web conferencing permit health care providers to reach patients and family at any time and from anywhere. Multiparty participation allow stakeholders in different parts of the province to attend a meeting without the inconvenience or cost of travel.

Extend telephony with video and incorporate video into meetings

Facilitating face-to-face video communications improve relationships and sense of well-being rather than a more impersonal telephone call.

Team workspaces for collaboration

Secure virtual rooms break geographic boundaries and foster more open communications among teams.

Collaborate from within business applications

Access collaboration and conferencing directly from select business applications such as Outlook.

Support remote work Give health care providers and support staff the ability and flexibility to work from remote locations more securely and productively while keeping fully in contact with their central office.

3.3 Growth As of June 2017, after the Jabber Client Pilot, there are approximately 225 connected endpoints. This

number is anticipated to grow to up to 2000 users within two (2) years. The initial requirements include

the following license requirements:

Quantity Description

250 Cisco Unified Workspace License – Enhanced (1 User / 1 Device, 1 Prime Collaboration, Jabber)

250 Cisco Unified Workspace License – Enhanced + (1 User / 2 Device, 1 Prime Collaboration, Jabber)

500 Managed Endpoints

20 Traversal Calls - Calls between external and internal parties passing through the firewall and not registered to the collaboration environment.

100 Non-Traversal Calls – these are calls that might, for example, go from SIP to H.323

4 Conference Multiparty Licenses.


4 Data Flow

4.1 Traditional Telepresence Use – Inter/Intra - RHA Communications Telehealth provides the ability for point to point video communications using traditional telepresence

endpoints from Cisco, Polycom or other vendors.

HINVCS Control

NLCHI Parallel

Network

1

Western Health

Eastern Health

1

3

1

3

2

Step Description

1 The telepresence endpoint units register with VCS hosted by NLCHI.

2 VCS Control performs call routing between the separate telepresence endpoints.

3 Once the call is established, point-to-point communications occur between the telepresence endpoints.

Note:

Call routing is the same for inter or intra RHA communications.


4.2 Client Service Discovery Remote clients can include Jabber, Cisco Meeting App or WebRTC. For these clients, knowing where to

register the endpoint is determined by the response to the clients DNS query.

4.2.1 Client Service Discovery inside RHA Networks

DNS

VCS Control

UCM

CMSTMSConferencing /

Scheduling

IM & P

Core Services

CallControl

NLCHI Parallel Network

Endpoints

HIN

DNS

Telus EHR Network

DNS Query

DNS Forwarder

1

2

3

3

RHA Step Description

1

The client queries the local name server for the following SRV records in order of priority:

_cisco-uds Provides the location of Cisco Unified Communications Manager.

_cuplogin Provides the location of Cisco Instant Messaging & Presence Server. The _cisco_uds entry will take precedence.

_collab-edge Provides the location of Cisco VCS Expressway or Cisco Expressway-E.

2 The local RHA DNS server performs a forwarding request to the EHR DNS servers, hosted by Telus, which contain the authoritative records.

3

Based on the DNS entry, the client will either:

DNS Entry Action

_cisco-uds The jabber client detects it is inside the corporate network and connects to Cisco Unified Communications Manager.

_cuplogin The jabber client detects it is inside the corporate network and connects to Cisco IM & Presence.

_collab-edge Note:

This entry is not deployed on the internal network, but only in the internet. This makes use of VCS Expressway and Mobile and Remote Access.

None of the SRV records

The client prompts users to manually enter setup and sign-in details.


4.2.2 Client Service Discovery from the Internet

VCS Control

UCM

CMSTMS

Conferencing / Scheduling

IM & P

Core Services

CallControl

NLCHI Parallel Network

webnames.ca(External NLCHI Provider)

Internet

VCS Expressway

DMZ Services

CMS Edge

Firewall Traversal

1

Firewall Traversal1

2

3

2 2

33

Step Description

1

The application client will query the name server for the SRV records below. Note:

NLCHI use the external provider ‘webnames.ca’ for DNS services.

Jabber Client

_cisco-uds Note deployed to external DNS.

_cuplogin Note deployed to external DNS.

_ collab-edge Provides the location of Cisco VCS Expressway or Cisco Expressway-E.

Cisco Meeting App _xmpp_client_tcp The client attempts to connect to the internal network through CMS edge services to the XMPP server hosted on the Cisco Meeting Server.

If the DNS query results in none of the SRV records being found, then the client prompts users to manually enter setup information and sign-in details.

2 The client authenticates to the Cisco Unified Communications server (CUCM) utilizing firewall traversal services of VCS expressway through Mobile and Remote Access.

3 User authenticates to CMS environment through the CMS edge services which are providing firewall traversal services.


5 Components A simplified view of the collaboration environment is presented in the figure Figure 3 - Collaboration

Overviewbelow.

Figure 3 - Collaboration Overview

These components are briefly described in Table 3 - Components of Collaboration Architecture.


Endpoints IP Phones, Telepresence Video Endpoints, Jabber Enable real-time voice, video, and instant messaging for users.

Meeting Apps Skype for Business, WebRTC, Cisco Meeting App Integrates various methods for conferencing with external parties.

Call Control

Cisco Unified Communications Manager (CUCM) Provides endpoint registration, call processing and media resource management

Cisco Unified Communications Manager IM and Presence Service

Provides instant messaging and presence services

Cisco Expressway-E Supports remote endpoint registration to Cisco Unified CM and enables business-to-business communications

Conferencing Cisco Meeting Server Provides audio and video conferencing capabilities as well as conference resource management

Management Cisco TelePresence Management Suite (TMS) and Extensions

Provides scheduling, web conferencing integration, and other advanced video features

Cisco Prime Collaboration Provisioning and management for Collaboration environment.

Edge Services

Cisco VCS Expressway Enables interoperability with third-party systems and firewall traversal

Cisco Meeting Server (CMS) Edge Provides firewall traversal services for CMS integration with technologies like Skype for Business.

Table 3 - Components of Collaboration Architecture


5.1 Future Components In addition to those components that will be deployed to fulfil the initial requirements, the role of the

collaboration environment can be expanded to include voice services.

Figure 4 - Future – Voice Services

Through the introduction of an integrated services router to connect to Public Switched Telephone

Network (PSTN) and adding the unity application within the collaboration environment, full IP telephony

could be introduced.

Note: It is not necessary to re-architect the environment for the introduction of these components.


6 Endpoint Registration All telepresence endpoints must register (or connect) to use the collaboration environment. The

registration is dependent on the location of the endpoint, whether it is on the Health Information

Network (HIN) or on the internet, as well as the type of endpoint. The endpoint also helps determine the

type of license, whether it is shared on VCS Control or a named license on Call Manager.

Endpoint Type Registration Target License Requirement

Telepresence Endpoint VCS Control Shared License

Jabber Call Manager Named License

6.1 Internal (HIN) Endpoint Registration When an endpoint is located within one of the RHA’s on the HIN, they can register directly to the

registration target (either VCS Control or Unified CM both described later) since the RHA as well as the

collaboration environment are both considered semi-trusted.

Figure 5 - Registration on the HIN

6.2 Internet Endpoint Registration When an endpoint is located in the internet (see External Endpoint line in Figure 6 - Firewall Traversal

below), it does not have direct access to the semi-trusted collaboration environment, so instead has to

go through the VCS Expressway to VCS Control for call routing. This provides firewall traversal for calling,

presence, instant messaging, voicemail, and corporate directory services for Jabber and telepresence

video endpoints. VCS Expressway also enables video communications between organizations, partners

(OSI Clinic in New Brunswick for example), and vendors over the Internet.

Firewall ports are only open between VCS Expressway and VCS Control. No firewall ports are open from

the outside endpoints to the Unified Communications infrastructure or VCS Control. All communications

for the endpoints are via firewall traversal through Expressway and Control.


Figure 6 - Firewall Traversal

When located in the internet, Jabber clients (see Jabber Client line in Figure 6 - Firewall Traversal above),

register to the Call Manager via Mobile and Remote Access, a function of VCS Expressway which

provides VPN-less access to the collaboration infrastructure.

6.2.1 Configuring Endpoints to work with a Cluster Reference Documentation

Cisco TelePresence VCS Cluster Creation and Maintenance January 2017

https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-9/Cisco-VCS-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-9-1.pdf

When VCS is configured as part of a cluster, endpoints registered to one side of the cluster need to be

able to reach the other peer(s) if their primary Cisco VCS becomes unavailable. The H.3234 protocol

supports this failover re-registration process automatically, but SIP5 does not.

The way in which you should configure your endpoints and DNS records depends on the protocol and

the functionality supported by your endpoints.

Initial registration process

In order of preference, for providing resilience of connectivity of endpoints to a cluster of Cisco VCSs,

you are recommended to use the following registration methods for SIP and H.323 endpoints:

SIP endpoints

1. SIP Outbound (SIP only)

SIP outbound allows an endpoint to be configured to register to two (2) or more VCS peers

simultaneously. The benefit of this is that if the connection between one peer and the endpoint

gets broken, then a connection from the endpoint to the other peer remains. With the endpoint

4 H.323, from the ITU, defines audio-visual communications on a packet network. 5 SIP – Session Initiation Protocol, a standard by the IETF, is used for signalling and controlling multimedia communications sessions; Cisco

recommends SIP over H.323.


registering to both peers simultaneously, there is no break in service while the endpoint realizes

that its registration has failed, before it registers to a different peer. Thus, at no time is the

endpoint unreachable.

Configuration of SIP outbound is endpoint specific.

2. DNS SRV records

If the endpoint supports DNS SRV, set up a DNS SRV record for the DNS name of the cluster,

giving each cluster peer an equal weighting and priority. The endpoint should be configured with

the DNS name of the cluster. On startup the endpoint issues a DNS SRV request and receives

back the addresses of each cluster peer. It will then try and register with each peer in turn until

it can register with a VCS.

The endpoint will continue to use the first VCS that it registered to for re-registrations and for

calls. If it ever loses connection to its VCS, it will use the DNS SRV entry to find a new VCS to

register to, starting at the highest priority.

3. DNS round-robin

If the endpoint does not support DNS SRV, set up a DNS A-record for the DNS name of the

cluster and configure it to supply a round-robin list of IP addresses for each cluster peer. The

endpoint should be configured with the DNS name of the cluster. On startup the endpoint

performs a DNS A-record lookup and receives back an address of a peer taken from the round-

robin list. The endpoint will try and register with that peer. If that peer is not available, the

endpoint performs another DNS lookup and the server will respond with the next peer in the

list. This is repeated until the endpoint registers with a Cisco VCS.

4. Static IP address (Least Preferred)

Possible, but since our cluster will have a DNS name, this will not be used.

H.323 endpoints

1. DNS SRV records

On each H.323 endpoint configure the Gatekeeper Settings as:

o Discovery = Manual

o IP Address = DNS name of the VCS cluster

If the endpoint supports DNS SRV, then the DNS SRV record for the name of the VCS cluster

defines an equal weighting and priority for each cluster peer. VCS responds with an H.323

“Alternate Gatekeepers” list containing the addresses of Cisco VCS cluster peer members. If the

endpoint loses connection with the Cisco VCS it will select another peer from the “Alternate

Gatekeepers” list and try to re-register with that Cisco VCS.


2. DNS round-robin


a. Discovery = Manual

b. IP Address = DNS name of the VCS cluster

If the endpoint does not support DNS SRV, set up a DNS A-record for the DNS name of the

cluster and configure it to supply a round-robin list of IP addresses for each cluster peer. The

endpoint should be configured with the DNS name of the cluster. On startup the endpoint

performs a DNS A-record lookup and receives back an address of a peer taken from the round-

robin list. The endpoint will try and register with that peer.

On registering VCS will respond with the H.323 ‘Alternate Gatekeepers’ list containing the list of

VCS cluster peer members. The endpoint will continue to use the first VCS that it registered to

for re-registrations and for calls. If it ever loses connection then it will select an “Alternate

Gatekeeper” from the list it was supplied with.

If that peer is not available, the endpoint performs another DNS lookup and the server will

respond with the next peer in the list. This is repeated until the endpoint registers with a Cisco

VCS.

3. Static IP


a. Discovery = Manual

b. IP Address = IP Address of a VCS Peer

On startup the endpoint will try and register with the VCS at the specified IP address. If that is

not available, then the endpoint will continue trying at regular intervals. This will be repeated

until the endpoint can register with the VCS.

On registering VCS will respond with the H.323 “Alternate Gatekeepers” list containing the list of VCS

cluster peer members. The endpoint will continue to use the first VCS that it registered to for re-

registrations and for calls. If it ever loses connection then it will select an “Alternate Gatekeeper” from

the list it was supplied with.


7 Edge Services

LAN Extension (Circuit #118501)

Outside10.57.11.20/28

NL-HIN (vlan 423)10.55.112.1

NL HIN

ucovpzvcse110.57.3.130/28 (LAN1)10.57.3.146/28 (LAN2)

24.222.186.?(LAN2/NAT)

VLAN 1000reth0.1000

Western RHA

Central RHA

Eastern / Lab Grenfell RHA

VLAN423reth2.423

SRX3600

172.16.4.5

VCS Expressway

Inside

10.57.11.17 / 28

ASA 5516

10.42.230.25


OutsideTBD/28

NL-HIN (vlan 423)TBD

Cluster

SRX3600

TBD

Inside

x.x.x.x/xx

Outside

24.222.186.250/27

Allandale

Internet

OCIO

ucavpzvcse110.57.3.131/28 (LAN1)10.57.3.147/28 (LAN2)

24.222.186.?(LAN2/NAT)

VCS Expressway

ASA 5516

x.x.x.x/xx

Clus

ter

VLAN423reth2.423

UC_SemiTrust

UC_SemiTrust

LA

N E

xte

nsio

n (E

as

tlink C

ircu

it ID#

118

50

1)

ucavpzcmse110.57.3.133/28 (LAN1)10.57.3.149/28 (LAN2)

24.222.186.?(LAN2/NAT)

Meeting Server Edge

DMZEXT-UC

x.x.x.x/28

ucovpzcmse110.57.3.132/24 (LAN1)10.57.3.148/28 (LAN2)

24.222.186.?(LAN2/NAT)

Meeting Server Edge

DMZINT-UC

10.57.3.129/28

DMZEXT-UC

10.57.3.145/28

DMZINT-UC

x.x.x.x/28

VLAN 1000reth0.1000

ucovpzvcsc110.57.255.2/27

VCS Control

ucavpzvcsc110.57.255.3/27

VCS Control

Figure 7 - Collaboration Edge Deployment


Edge Services

VCS Control Enables interoperability with third-party systems and firewall traversal

VCS Expressway Supports remote endpoint registration to Cisco Unified CM and enables business-to-business communications

Meeting Server Edge Enables firewall traversal to the Cisco Meeting Server.

7.1 Cisco Telepresence Video Communication Server - VCS

7.1.1 VCS Expressway

For availability and redundancy, Cisco VCS Expressway is deployed with at minimum two (2) nodes,

within the DMZ and is paired with a two (2) node VCS Control cluster which is deployed inside the Semi-

Trust network providing the ability for firewall traversal.


Figure 8 - VCS Expressway – Conceptual and Detail

VCS Expressway is a SIP Registrar & Proxy and H.323 Gatekeeper for devices which are located outside

the internal network (for example, home users and mobile users registering across the internet and 3rd

party businesses making calls to, or receiving calls from the network).

The VCS Expressway has a public network domain name and is configured with a traversal server zone to

receive communications from VCS Control in order to allow inbound and outbound calls to traverse the

NAT or firewall device.

Expressway is reachable directly from an untrusted external network (the internet) and is thus placed in

the DMZ for security. Through Mobile and Remote Access functionality it allows endpoints such as Cisco

Jabber to have their registration, call control, provisioning, messaging and presence services provided by

Cisco Unified Communications Manager (Unified CM) when the endpoint is not within the enterprise

network. Expressway provides secure firewall traversal and line-side support for Unified CM

registrations.

Expressway can support multiple domains, so it is possible to host ‘telehealth.healthenl.ca’ as well as

‘nlchi.nl.ca’ and other RHA domains. Through this functionality, users can have their Jabber ID the same

as their email address.

7.1.1.1 VCS Expressway - DNS

The VCS Expressway server DNS entries have to be configured for both the internal and external (public)

DNS servers. The public DNS must be configured with _collab-edge._tls.<domain> SRV records so that

endpoints can discover the VCS Expressways to use for Mobile and Remote Access. SIP service records

are also required for a cluster of two (2) VCS Expressway systems.

7.1.1.1.1 Expressway – A Record

The A record must be resolvable both internally and externally.

Record ucovpzvcse1.uc.healthenl.ca. 600 IN A TBD

ucavpzvcse1.uc.healthenl.ca. 600 IN A TBD

Type A


Resolves To IP addresses of VCS Expressway Servers

Resilience Considerations One A and/or AAAA record per VCS Expressway Server. The decision on which Expressway is used is normally random.

Description This record is not used directly, but is forwarded by the _collab and _sip records. There is no restriction or requirement on the format of this record.

7.1.1.1.2 _collab-edge – External DNS Only

The _collab-edge record should be available to public DNS servers; multiple SRV records should be

deployed for HA environments. If available, a GEO DNS service could be used to provide unique DNS

responses by region.

Record

_collab-edge._tls.uc.healthenl.ca 86400 IN SRV 10 10 8443 ucovpzvcse1.uc.healthenl.ca _collab-edge._tls.uc.healthenl.ca 86400 IN SRV 10 10 8443 ucavpzvcse1.uc.healthenl.ca Alternatively _collab-edge._tls.nlchi.nl.ca 86400 IN SRV 10 10 8443 ucovpzvcse1.uc.healthenl.ca _collab-edge._tls.nlchi.nl.ca 86400 IN SRV 10 10 8443 ucavpzvcse1.uc.healthenl.ca

Type SRV

Resolves To IP address of Video Communication Server Cluster edge servers deployed in the DMZ. Usually this is port 8443.

Resilience Considerations One SRV record can be created for each VCS-E server such that multiple results are returned in response to a DNS lookup. Clients choose a destination for VCS-E traffic based on the priority and weight information

Description Used by clients to login. The SRV record must correspond to the domain used in your usernames. Records for multiple domains can refer to the same VCS Expressway environment.

7.1.1.1.3 _sips, _h323cs – External DNS Only

In order to for SIP and H.323 clients to know they are outside the firewall and must go through VCS

Expressway, the _sips._tcp and _h323cs._tcp records are required. It is possible to also defined

_sips._udp, however this is NOT recommended for video traffic.

Record

_sips._tcp.uc.healthenl.ca 86400 IN SRV 10 10 5061 ucovpzvcse1.uc.healthenl.ca _sips._tcp.uc.healthenl.ca 86400 IN SRV 10 10 5061 ucavpzvcse1.uc.healthenl.ca _h323cs._tcp.uc.healthenl.ca 86400 IN SRV 10 10 1720 ucovpzvcse1.uc.healthenl.ca _h323cs._tcp.uc.healthenl.ca 86400 IN SRV 10 10 1720 ucavpzvcse1.uc.healthenl.ca Alternatively (Example) _sips._tcp.nlchi.nl.ca 86400 IN SRV 10 10 5061 ucovpzvcse1.uc.healthenl.ca _sips._tcp.nlchi.nl.ca 86400 IN SRV 10 10 5061 ucavpzvcse1.uc.healthenl.ca _h323cs._tcp.nlchi.nl.ca 86400 IN SRV 10 10 1720 ucovpzvcse1.uc.healthenl.ca _h323cs._tcp. nlchi.nl.ca 86400 IN SRV 10 10 1720 ucavpzvcse1.uc.healthenl.ca

Type SRV (*)

Resolves To The A record is for the Expressway edge servers deployed in the DMZ. Usually this is port 5061 for SIP with TLS, and 1720 for H.323.

Resilience Considerations One SRV record can be created for each VCS Expressway server such that multiple results are returned in response to a DNS lookup. Clients choose a destination for traffic based on the priority and weight information



7.1.1.2 VCS Expressway - Firewall Requirements

DMZ

Internet

Semi-TrustO

CIO

Alla

nd

ale

Call

Ma

nag

er

/ IM

& P

VC

S C

on

tro

l

VCS Expressway

Endpoint - Firewall Traversal

MRA

Figure 9 - Endpoint Registrations

I. Internet DMZ

SRC Port DST Port Protocol SRC DST Description

H.323 Endpoint Registration with Assent6 >=1024 1719 UDP Internet VCS-E RAS / RAS Assent

>=1024 2776 TCP Internet VCS-E Q.931/H.225 and H.245

>=1024 36000 UDP Internet VCS-E RTP Assent

>=1024 36001 UDP Internet VCS-E RTCP Assent

H.323 Endpoint Registration with Public IP

1719 1719 UDP Internet VCS-E RAS

>=1024 1720 TCP Internet VCS-E Q.931/H.225

>=1024 15000 - 19999 TCP Internet VCS-E H.245

>=1024 36002 - 59999 UDP Internet VCS-E RTP & RTCP

SIP endpoints registering using UDP / TCP or TLS >=1024 5060 TCP Internet VCS-E SIP TCP

>=1024 5060 UDP Internet VCS-E SIP UDP

>=1024 5061 TCP Internet VCS-E SIP TLS

>=1024 36002 – 59999 UDP Internet VCS-E RTP & RTCP

>=1024 3478 UDP Internet VCS-E TURN server control

>=1024 24000 - 29999 UDP Internet VCS-E TURN server media

Mobile & Remote Access

>=1024 8443 TLS Internet VCS-E UDS Phonebook and provisioning

>=1024 5222 TCP Internet VCS-E XMPP (IM & Presence)

II. DMZ Internet


H.323 Endpoint Registration with Public IP

>=1024 1719 UDP VCS-E Internet RAS

15000 - 19999 1720 TCP VCS-E Internet Q.931/H.225

6 Assent is a Cisco proprietary protocol which presents a solution for NAT (and firewall) traversal for H.323 and SIP communications (both

signaling and media).


15000 - 19999 >=1024 TCP VCS-E Internet H.245

36002 - 59999 >=1024 UDP VCS-E Internet RTP & RTCP

SIP endpoints registering using UDP / TCP or TLS

25000 – 29999 >=1024 TCP VCS-E Internet SIP TCP

5060 >=1024 UDP VCS-E Internet SIP UDP

36000 – 59999 >=1024 TCP VCS-E Internet SIP TLS

24000 – 29999 >=1024 UDP VCS-E Internet RTP & RTCP

III. Internal Networks DMZ

Only management servers ever need access the VCS-E server from the internal networks.


Management & Monitoring

22 22 TCP NLCHI VCS-E SSH

443 443 TCP NLCHI VCS-E HTTPS

>=1024 161 UDP NLCHI VCS-E SNMP Monitoring

IV. DMZ Internal Networks


Management & Monitoring

30000 - 35999 514 UDP VCS-E Syslog Server Logging

>= 1024 80 / 443 TCP VCS-E Cisco TMS Server Management

30000 - 35999 389 / 636 TCP VCS-E LDAP Server LDAP

123 123 UDP VCS-E NTP Server NTP

>= 1024 53 UDP VCS-E DNS Server DNS

7.1.2 VCS Control

For availability and redundancy, Cisco VCS Control is deployed with at minimum two (2) nodes, within

the Semi-Trust network and is paired with a two (2) node VCS Expressway cluster which is deployed

inside the DMZ network providing the ability for firewall traversal.

Figure 10 - VCS Control Conceptual & Detail


Located in the semi-trust network inside the organization, VCS Control is a SIP Registrar & Proxy and

H.323 Gatekeeper for devices which are located on the internal network and provides:

Function as a traversal client to establish a secure connection to VCS Expressway through the

firewall.

Establish connection to Cisco Unified CM.

Integrate with an existing internal video network that uses H.323.

Enable mobile and remote access capabilities and call signaling for Cisco supported endpoints,

directing them to Unified CM for SIP registration and/or the IM and Presence Service

7.1.2.1 VCS Control – DNS

7.1.2.1.1 Control – A Record

The A record must be resolvable both internally and externally.

Record ucovpzvcsc1.uc.healthenl.ca. 600 IN A TBD

ucavpzvcsc1.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP addresses of VCS Control Servers

Resilience Considerations One A and/or AAAA record per VCS Control Server. The decision on which Control is used is normally random.

Description This record is not used directly, but is forwarded by _sip records. There is no restriction or requirement on the format of this record.

7.1.2.1.2 _sips, _h323cs – Internal DNS Only

In order to for SIP and H.323 clients to know where they should register, the _sips._tcp and

_h323cs._tcp records are required.

Record

_sips._tcp.uc.healthenl.ca 86400 IN SRV 10 10 5061 ucovpzvcsc1.uc.healthenl.ca _sips._tcp.uc.healthenl.ca 86400 IN SRV 10 10 5061 ucavpzvcsc1.uc.healthenl.ca _h323cs._tcp.uc.healthenl.ca 86400 IN SRV 10 10 1720 ucovpzvcsc1.uc.healthenl.ca _h323cs._tcp.uc.healthenl.ca 86400 IN SRV 10 10 1720 ucavpzvcsc1.uc.healthenl.ca Alternatively (Example) _sips._tcp.nlchi.nl.ca 86400 IN SRV 10 10 5061 ucovpzvcsc1.uc.healthenl.ca _sips._tcp.nlchi.nl.ca 86400 IN SRV 10 10 5061 ucavpzvcsc1.uc.healthenl.ca _h323cs._tcp.nlchi.nl.ca 86400 IN SRV 10 10 1720 ucovpzvcsc1.uc.healthenl.ca _h323cs._tcp. nlchi.nl.ca 86400 IN SRV 10 10 1720 ucavpzvcsc1.uc.healthenl.ca

Type SRV (*)

Resolves To The A record is for the Expressway edge servers deployed in the DMZ. Usually this is port 5061 for SIP with TLS, and 1720 for H.323.

Resilience Considerations One SRV record can be created for each VCS Expressway server such that multiple results are returned in response to a DNS lookup. Clients choose a destination for traffic based on the priority and weight information



7.1.2.2 VCS Control - Firewall Requirements

The VCS Control server connects directly to the VCS Expressway server to provide firewall traversal

services. This allows external endpoints the ability to connect into the collaboration environment using

VCS basically as a proxy.

I. Internal Networks DMZ


H.323 Endpoint Registration with AssentError! Bookmark not defined. 1719 6001 UDP VCS-C VCS-E RAS Assent

15000 – 19999 2776 TCP VCS-C VCS-E Q.931/H.225 and H.245

36002 - 59999 36000 UDP VCS-C VCS-E RTP Assent

36002 - 59999 36001 UDP VCS-C VCS-E RTCP Assent

SIP Traversal Calls

25000 – 29999 Traversal Zone Ports TCP VCS-C VCS-E SIP Signaling TCP/TLS

36002 - 59999 36000 UDP VCS-C VCS-E RTP Assent

36002 - 59999 36001 TCP VCS-C VCS-E RTCP Assent

>=1024 36002 – 59999 UDP VCS-C VCS-E RTP & RTCP

>=1024 3478 UDP VCS-C VCS-E TURN server control

>=1024 24000 - 29999 UDP VCS-C VCS-E TURN server media

Mobile & Remote Access

30000-35999 2222 TLS VCS-C VCS-E SSH Tunnels

30000-35999 7400 TCP VCS-C VCS-E XMPP – IM & Presence

I. VCS Control Internal Applications

These are the connections from VCS Control to internal applications. Firewall rules are not required since

they will live on the same network.


Connections to internal applications – No firewall is in place, but they could live on different networks. 25000-29999 5060/5061 TCP VCS-C Unified CM SIP Signaling (TCP)

5060/5061 25000-29999 TCP Unified CM VCS-C SIP Signaling (TCP)

25000-29999 5061 TLS VCS-C Unified CM SIP Signaling (TLS)

5061 25000-29999 TLS Unified CM VCS-C SIP Signaling (TLS)

30000-35999 6972 TLS VCS-C Unified CM Jabber File Download

30000-35999 443 or 8443 TLS VCS-C Unified CM HTTP for UDS

30000-35999 7400 TLS VCS-C IM & P XMPP

30000-35999 8443 TLS VCS-C IM & P HTTPS SOAP

30000-35999 7336 TLS VCS-C IM & P File Transfer

7.1.3 Cisco VCS Cluster

VCS Clusters are designed to extend resilience and capacity. VCS peers share bandwidth, routing, zone

and other configuration items amongst themselves. Endpoints can register to any peer within the cluster

and if they lose their connections to their initial peer, they can re-register to another peer in the cluster.


Licensing is shared among peers of the cluster with any capacity licenses available for use by any other

peer.

Figure 11 - VCS Cluster Port Reference

Both VCS Expressway and control will be deployed in a resilient and redundant manner across the OCIO

and Allandale data centers.

SRC Port DST Port Protocol SRC DST Purpose

Cluster Recovery & Communications

30000 - 35999 4371 TCP Current Peer Other Peers Cluster Recovery

30000 – 35999 4372 TLS Current Peer Other Peers Cluster Communication

1719 1719 UDP Current Peer Other Peers Bandwidth Management Table 4 - Cluster Communications

7.1.3.1 Cluster Notes

VCS can support up to six (6) nodes per cluster.

Expressway and Control cluster separately; Expressway can only cluster with other Expressway

nodes, and Control with other Control nodes.


Peers should be deployed in equal numbers across the cluster; a three node VCS-E cluster

should be paired with a three node VCS-C cluster.

7.1.4 Certificate Requirements Reference Documentation

Cisco VCS Certificate Creation and Use Deployment Guide December 2016

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-9/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-9.pdf

VCS requires certificates for:

Secure HTTP with TLS (HTTPS) connectivity.

TLS connectivity for SIP signaling, endpoints and neighbor zones.

Connections to other systems such as Unified CM, Cisco TMS, LDAP servers and syslog servers.

7.1.4.1 VCS Expressway

Since VCS will be clustered, Subject Alternative Name (SAN) certificates will need to be used; VCS does not support wildcard certificates. Included in the X.509 subject will be the FQDN of VCS and FQDN of the cluster.

Figure 12 – Sample - VCS-E Subject Alternative Name

The Unified CM registration domains used in the VCS Expressway certificate are used by Mobile and Remote access clients to lookup _collab-edge DNS SRV record during service discovery.

7.1.4.2 VCS Control

All of the domains which are configured on the VCS Control for Unified CM registration are required as elements of the subject alternative name. Also, IM and Presence chat node aliases (federated group chat): the Chat Node Aliases (e.g. chatroom1.example.com) that are configured on the IM and Presence servers.


7.1.5 System Time

It is recommended that the Unified CM publisher node be configured as the sole NTP server. This means

that all subsequent nodes in the cluster will set the time from the Unified CM server.

Time Server ucovpscucm1.uc.healthenl.ca

7.1.6 Deployment Requirements

VCS deployment is based on the following capacity requirements

Software Description (Concurrent) Quantity (Per Node)

VCS Expressway VCS Control

Registrations (per Node) 2500

Video Calls (per Node) 100

Audio-Only Calls (per Node) 200

Assumptions:

All Video calls are encrypted with an average call rate of 768kbps

All Audio calls are encrypted with an average call rate of 64kbps.

7.1.6.1 Software Version

As of this document, the current deployable version is:

Software Version

Cisco TelePresence Video Communication Server Expressway X8.10

Cisco TelePresence Video Communication Server Control X8.10

7.1.6.2 Hardware

VCS will be deployed as a virtual appliance via OVA files supplied by Cisco.

Supported versions of vSphere ESXi include 5.5, 6.0 and 6.5

This deployment is based on a ‘Medium’ OVA (the difference in Medium and Small is an

additional 2GB of RAM memory.

7.1.6.3 VCS Expressway

Server Node vCPU vRam vDisk vNIC (1Gb)

ucovpzvcse1 2 6 GB 132 2

ucavpzvcse1 2 6 GB 132 2

7.1.6.4 VCS Control





7.1.6.5 Licensing Requirements


Virtual VCS Expressway 1

Virtual VCS Control 1

Traversal7 Calls 20

Non-Traversal Calls 100

Registering Endpoints 500

Notes.

1. Licenses for the VCS Expressway are shared amongst the VCS-E cluster.

2. Licenses for the VCS Control are shared amongst the VCS-C cluster.

3. A traversal call will consume a license on both VCS-C and VCS-E.

The table below provides information on when a traversal or non-traversal license is used on VCS

Expressway and VCS Control.

Destination

Sou

rce

Third Party

SIP/H.323

VCS-C Registered: H.323

VCS-C Registered: SIP

Jabber Internal (SIP)

Jabber MRA (SIP)

CMS (SIP/H.323)

Third Party SIP/H.323

Both: Traversal

Both: Traversal Both: Traversal Both: Traversal Both: Traversal Both: Traversal

VCS-C Registered:

H.323

Both: Traversal

VCS-E: N/A VCS-C: Non-

Traversal

VCS-E: N/A VCS-C: Traversal




Traversal

VCS-C Registered:

SIP

Both: Traversal



Traversal


Traversal


Traversal


Traversal

Jabber Internal

(SIP)

Both: Traversal



Traversal

Jabber MRA (SIP)

Both: Traversal



Traversal

Table 5 - Non-Traversal / Traversal License Usage

7 A traversal call is one that ‘traverses’ or travels through the firewall from, for example, inside the network to outside the network.


7.2 Cisco Meeting Server Edge

Figure 13 - Cisco Meeting Server Edge

In addition to Jabber access through MRA shown previously; Cisco Meeting App, WebRTC and Skype

users that require access to multiparty meetings hosted on the CMS environment (see Meeting Server

line in Figure 6 - Firewall Traversal above) also use DMZ services through components deployed on

instances of Cisco Meeting Server.

Figure 14 - CMS Edge - Split Server Deployment

To enable DMZ edge services, the Cisco Meeting Server will be configured using the split server

deployment model. In split server deployment, the TURN server, Load Balancer, Web Bridge and SIP

Edge components are split from the core services (discussed in section 8 below) and deployed in the


DMZ. These interact with the Call Bridge (8.3.3 below) and the XMPP (8.3.5 below) service deployed in

the core systems.

For the Cisco Meeting App, the TURN (7.2.3 below), XMPP and Load Balancer (7.2.2 below) components

are required; for WebRTC, Web Bridge (7.2.5 below) and XMPP are required, and TURN and SIP Edge are

used by Skype clients participating in video conferences.

7.2.1 DNS - Cisco Meeting Server Edge – A Record

Record ucovpzcmse1.uc.healthenl.ca. 600 IN A TBD

ucavpzcmse1.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP address of CMS edge servers.

Resilience Considerations One A record per server.

Description Used by clients to login.

7.2.2 Load Balancer

In a split configuration, the Load Balancer component, while deployed on CMS edge, is only used to

connect Cisco Meeting Apps to the XMPP server, so please refer to section 8.3.5 below for more

complete details.

Figure 15 – Traffic flow for Load Balancer

Destination Port

Traffic Type

Traffic Direction

Source Destination

Between Semi-Trust and DMZ

4999 TCP Outgoing XMPP Server Load Balancer

Between DMZ and Internet

5222 TCP Bidirectional Cisco Meeting App Load Balancer


7.2.3 TURN Server

To connect to Meeting Server from external Cisco Meeting Apps or SIP endpoints you need to enable

the TURN server. The TURN (Traversal Using Relays around Nat) server provides firewall traversal

technology, allowing the Meeting Server to be deployed behind a firewall or NAT.

Cisco Meeting Apps are always monitoring TURN servers in the background via their connections to an

XMPP server. When a call starts, the client is sent a list of available TURN servers but will have already

chosen the best TURN server for each interface: therefore, when joining a call there is no additional

delay in choosing a TURN server.

The TURN servers are configured by hostname (with one host resolving to multiple servers via DNS).

7.2.3.1 TURN DNS

The TURN servers can be configured either by hostname (with one hostname resolving to potentially

multiple servers via DNS) or by IP address. This configuration is stored in the shared database.

Record turnserver.uc.healthenl.ca. 600 IN A TBD

turnserver.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP addresses of Turn Servers

Resilience Considerations One A and/or AAAA record per Web Bridge. The decision on which Web Bridge your browser uses is made by your web browser. Normally the choice is random

Description This record is not used by the Meeting Server directly; however, it is common practice to provide an end user with an FQDN to type into the browser which resolves to the Web Bridge. There is no restriction or requirement on the format of this record.


7.2.4 Turn Server - Firewall Ports

Internet

OC

IOA

lla

nd

ale


CMS - Edge

Me

eti

ng

Serv

er

TURN

Call

Bridge

Destination Port

Traffic Type

Traffic Direction

Source Destination

443

UDP (STUN) TCP (STUN)

Incoming Turn Server Call Bridge & Remote Devices

3478 UDP (STUN) TCP (STUN)

Incoming Turn Server Call Bridge & Remote Devices

32768-65535 Media UDP (STUN RDP) Media TCP (STUN RDP)

Bi-directional Turn Server Call Bridge & Remote Devices

7.2.5 Web Bridge

The Web Bridge is required to use WebRTC. The Web Bridge services will be configured to have a single

external DNS A record. However, when configuring the Web Bridges on the Call Bridge(s) there must be

a unique hostname or IP address for each Web Bridge configured on the Call Bridge(s). This enables,

each Web Bridge to be uniquely identifiable by every Call Bridge.

7.2.5.1 Web Bridge DNS

The Web Bridge services can be configured to have a single DNS A record externally. However, when

configuring the Web Bridges on the Call Bridge(s) there must be a unique hostname or IP address for

each Web Bridge configured on the Call Bridge(s). This enables, each Web Bridge to be uniquely

identifiable by every Call Bridge. This configuration is stored in the shared database.

Record webbridge.uc.healthenl.ca. 600 IN A TBD

webbridge.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP addresses of Web Bridge

Resilience Considerations One A and/or AAAA record per Web Bridge. The decision on which Web Bridge your browser uses is made by your web browser. Normally the choice is random

Description This record is not used by the Meeting Server directly; however, it is common practice to provide an end user with an FQDN to type into the browser which resolves to the Web Bridge. There is no restriction or requirement on the format of this record.


7.2.5.2 Web Bridge - Required Application Ports

Internet

OC

IOA

lla

nd

ale


CMS - Edge

Me

eti

ng

Serv

er

XMPPWeb Bridge

Call

Bridge

Destination Port

Traffic Type

Traffic Direction

Source Destination

53 TCP or UDP Outgoing Web Bridge DNS Server

443 TCP Outgoing Call Bridge Web Bridge

WebRTC Clients

80 TCP (HTTP) Incoming Web Bridge WebRTC Clients

443 TCP (HTTPS) Incoming Web Bridge WebRTC Clients


Certificate Guidelines for Scalable and Resilient Server Deployments June 16, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-0/Certificate-Guidelines-Scalable-and-Resilient-Deployments.pdf

To deploy CMS Edge in a scalable and resilient manner, individual components will require the certificates shown below.

7.2.6.1 Public CA signed certificates

Component Reason

Web Bridge WebRTC clients require a public CA signed certificate from the Web Bridge in order to trust the connection.

TURN server

If you configure TLS on your TURN server, then the TURN server will require a certificate/key pair similar to that created for the Web Bridge, so that the WebRTC client trusts the connection. The certificate should be signed by the same Certificate Authority as used for the Web Bridge certificate

7.2.6.2 Internal CA signed certificates Component Reason

Load Balancer

If native Cisco Meeting Apps are deployed then the trunk between the Core and Edge servers needs to authenticate (trust the certificate) presented by the Load Balancer.


Note: The external native Cisco Meeting Apps do not check the Load Balancer certificate.

Trunk If native Cisco Meeting Apps are deployed then the Load Balancer in the Edge server needs to authenticate (trust the certificate) presented by the trunk.

7.2.7 System Time





Note

Edge VMs that connect to a single Meeting Server Call Bridge use 4 vCPUs and 4 GB vRAM. In other cases, use 8 vCPU and 8 GB vRAM. This deployment will use only a single Call Bridge, however if at a later date the environment is expanded for multiple clients with their own Call Bridges, then the resource allocations will have to be re-addressed.

While CMS will support a resolution and frame rate of up to 1080p at 60fps for main video and 1080p at

30fps for content, the following guidelines were used in sizing the environment.

Software Description (Concurrent) Concurrent Calls

Cisco Meeting Server

HD calls (assuming 720p5 content, up to 2.5 Mbps bandwidth)

36

SD calls (448p30 - up to .9 Mbps bandwidth)

100

Audio-Only Calls 1000



Software Version

Cisco Meeting Server 2.2

7.2.8.2 Hardware

7.2.8.2.1 Edge VM

A VM configured to provide edge services should be configured with a minimum of 8 virtual CPUs and 8

GB RAM. A VM providing edge services to a single Core VM should be configured with a minimum of 4


virtual CPUs and 4 GB RAM.

CMS will be deployed as a virtual appliance via OVA files supplied by Cisco.

Supported versions of vSphere ESXi include 5.1 U2, 5.5 U1 and 6.0





There are no separately licensable components for edge services of CMS.

An XMPP license is required on the core server for each server running XMPP(and this license will be

accounted for in core CMS deployment requirements), however the XMPP license is included in the

Cisco Meeting Server software.


8 Core Services


UC_SemiTrust

NL-HIN (vlan 423)10.55.112.1

NL HIN

Western RHA

Central RHA

Eastern / Lab Grenfell RHA

VLAN423reth2.423

SRX3600

172.16.4.5


UC_SemiTrust

NL-HIN (vlan 423)TBD

SRX3600

TBD

VLAN423reth2.423

OutsideTBD/28

Outside10.57.11.20/28

LA

N E

xte

nsio

n (E

as

tlink C

ircu

it ID#

118

50

1)

Allandale

OCIO

ucovpscmsc110.57.255.4/28

Meeting Server

ucovpscmsc210.57.255.5/28

Meeting Server

ucavpscmsc110.57.255.6/28

Meeting Server

ucovpsvcsc110.57.255.2/27

VCS Control

ucavpsvcsc110.57.255.3/27

VCS Control

ucovpscucm110.57.255.7/28

Unified CM

ucavpscucm110.57.255.9/28

Unified CM

ucovpscucm210.57.255.8/28

Unified CM

ucavpsimp110.57.255.11/28

IM & Presence

ucovpsimp110.57.255.10/28

IM & Presence

ucovpstms110.57.255.12/28

TMS / LDAP

ucavpstms110.57.255.13/28

TMS / LDAP

ucovpscpc110.57.255.14/28

Prime Collaboration

VLAN 1000reth0.1000

VLAN 1000reth0.1000

Figure 16 - Collaboration Core Deployment


Call Control

Cisco Unified Communications Manager (CUCM) Provides endpoint registration, call processing and media resource management

Cisco Unified Communications Manager IM and Presence Service

Provides instant messaging and presence services

Collaboration Cisco Meeting Server Provides audio and video conferencing capabilities as well as conference resource management

Authentication Microsoft Active Directory Provide use authentication services.

There are no firewalls deployed between components in the core environment, even when components

are deployed across the two data centers at OCIO and Allandale, since there is a LAN extension in place

which places both environments on the same network regardless of their location.


8.1 Cisco Unified Communications Manager (CUCM) Reference Documentation

Installation Guide for Cisco Unified Communications Manager and IM and Presence Service Release 11.5(1) June 07, 2016

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/11_5_1/cucm_b_installation-guide-cucm-imp-1151.pdf

Cisco Unified Communications Manager is the call control platform for the collaboration environment. It

provides endpoint registration, call processing, and call admission control. In particular, it is to the Call

Manager that Jabber endpoints register and it is the Call Manager that provides signaling for calls

between Jabber and other telepresence endpoints.

Figure 17 - Unified Call Manager

The Call Manager is used during the initiation of a call. Once it has been setup, if the server were to be

disconnected, the users would not notice unless they attempted to use a different feature of the

telephony device. CUCM is involved only in call setup, teardown and features.

Unified Communications Manager provides, amongst others, the following primary functions:

Call Processing

This refers to the complete process of originating, routing and terminating calls.

Signaling and Device Control

CUCM sets up all the signaling connections between call endpoints and directs devices such as

phones, gateways and conference bridges to establish and tear down streaming connections.

Dial Plan Administration

The dial plan is a set of configurable lists that CUCM uses to perform call routing.

Phone Feature Administration


CUCM extends services such as hold, transfer, conference, and other features to IP phones and

gateways.

Directory Services

CUCM uses its own database to store user information, however this can be authenticated

locally or against an external directory. In our implementation, authentication will be through

federation with active directory across the RHAs.

Backup and Restore

CUCM provides a Disaster Recovery System (DRS) to backup and restore the CUCM

configuration database. The DRS system also backups up call details records (CDR), call

management records (CMR) and the CDR Analysis and Reporting (CAR) database.

8.1.1 Clustering

Unified CM fully supports the concept of clustering. The architecture enables a group of server nodes to

work together as a single call processing entity. The nodes will be hosted across data centers at OCIO

and Allandale.

Note:

There is no limitation on the location of the Unified CM nodes and therefore further

geographical redundancy is also an option with nodes possibly hosted anywhere in NL.

Within a Unified CM cluster, server nodes can provide unique services or these services can coexist with

others on the same node. For example, in a small system it is possible to have a single server node

providing database services, call processing services, and media resource services. As the scale and

performance requirements of the cluster increase, many of these services should be moved to

dedicated server nodes.

Figure 18 - Unified CM Node Services

For redundancy and scalability, our Unified CM cluster environment will consist of three nodes, one (1)

publisher, and two (2) subscribers.


8.1.1.1 Publisher Node

The publisher is a required server node in all clusters and there can be only one publisher per cluster8.

This is the first node to be installed and provides the database services to subscribers in the cluster. The

publisher is the only server node that has full read and write access to the configuration database.

Cisco recommends that on systems with more than 1250 users, a dedicated publisher be used to

prevent administrative operations from affecting the telephony services. This node will not provide call

processing or TFTP services, instead relying on subscribers for this purpose. Since our environment is

being built based on 2,000 users within 2 years, the cluster will have a dedicated publisher node.

8.1.1.2 Subscriber Nodes

The subscriber nodes subscribe to the publisher to obtain a copy of the database and use this to reduce

initialization time for startup. These subscribers rely on the publisher or other subscriber nodes to keep

the local copy of the database updated. Subscriber nodes will include services for Call Processing, TFTP

and Media Resource.

8.1.1.2.1 Call Processing Subscriber

The call processing subscriber has the ‘Cisco CallManager Service’ enabled. This will allow the node to

perform call processing functions such as registering and making calls to other servers with the service

enabled. Unified CM supports up to eight (8) call processing subscriber nodes.

8.1.1.2.2 TFTP Subscriber

The TFTP subscriber performs two main functions. First is the serving of files for services, including

configuration files such as the jabber-config.xml file, for phones and gateways, security files, and binary

files to upgrade devices. Second, is the generation of security and config files for download to devices.

In clusters with more than 1250 users, other services might be impacted by configuration changes that

can cause the TFTP service to regenerate configuration files. Therefore, Cisco recommends that you

dedicate a specific subscriber node to the TFTP Service.

In this implementation, TFTP service will be enabled on both subscriber nodes, but as the environment

grows, a third subscriber for TFTP specific services may be required.

8.1.1.2.3 Media Resource Subscriber

The media resource subscriber provides services such as conferencing and music on hold to endpoints

and gateways.

8.1.1.2.4 CTI Manager

The CTI manager acts as a broker between the Call Manager service and TAPI or JTAPI integrated

applications such as Jabber.

8 http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd/control.html#pgfId-1066684


8.1.1.3 Cluster Communications

Figure 19 - Intra-Cluster Communications

There are primarily two types of intra-cluster communication. First is database replication of the

configuration database which basically contains all static information on how devices are configured,

and the second is intra-cluster communication signaling which replicates run-time data such as device

registration, locations, etc. which is used to ensure optimum routing of calls.

8.1.1.3.1 Application Ports

Since all Unified CM nodes will be on the same network (via LAN extension) individual firewall rules are

not required, these ports are documented to understand data flow between nodes of the cluster.

From (Sender) To (Listener) Port Description

UCM RMT

TCP/1090 TCP/1091

Cisco AMC Service for RTMT performance monitors, data collection, logging, and alerting

DB DB

TCP/1500 TCP/1501

Database connection (1501 / TCP is the secondary connection)

DB DB TCP/1510

CAR IDS DB. CAR IDS engine listens on waiting for connection requests from the clients.

DB DB TCP/1511

CAR IDS DB. An alternate port used to bring up a second instance of CAR IDS during upgrade.

DB DB TCP/1515 Database replication between nodes during installation

Cisco Extended Functions

(QRT) DB TCP/2552

Allows subscribers to receive Cisco Unified Communications Manager database change notification

UCM UCM TCP/2551

Intra-cluster communication between Cisco Extended Services for Active/Backup determination

RIS RIS TCP/2555 Real-time Information Services (RIS) database server

RTMT / AMC / SOAP

RIS TCP/2556 Real-time Information Services (RIS) database client for Cisco RIS

DRS DRS TCP/4040 DRS Master Agent

Tomcat SOAP TCP/5001

This port is used by SOAP monitor for Real Time Monitoring Service.

Tomcat SOAP TCP/5002

This port is used by SOAP monitor for Performance Monitor Service.

Tomcat SOAP TCP/5003 This port is used by SOAP monitor for Control Center Service.

Tomcat SOAP TCP/5004 This port is used by SOAP monitor for Log Collection Service.

Tomcat SOAP TCP/5007 SOAP Monitor



RTMT TCTC TCP/32768 -

61000 Cisco Trace Collection Tool Service (TCTS) -- the back end service

for RTMT Trace and Log Central (TLC)

Tomcat TCTS

TCP/7000 TCP/7001 TCP/7002

This port is used for communication between Cisco Trace Collection Tool Service and Cisco Trace Collection servlet.

DB CDLM TCP/8001 Client database change notification

SDL SDL TCP/8002 Intra-cluster communication service

SDL SDL TCP/8003 Intra-cluster communication service to CTI

UCM CMI Manager TCP/8004

Intra-cluster communication between Cisco Unified Communications Manager and CMI Manager

Tomcat Tomcat TCP/8005 Internal listening port used by Tomcat shutdown scripts

Tomcat Tomcat TCP/8080 Communication between servers used for diagnostic tests

UCM Gateway TCP/8090 HTTP Port for communication between CuCM and GW

IPSec IPSec

TCP/8500 UDP/8500

Intra-cluster replication of system data by IPSec Cluster Manager

RIS RIS

TCP/8888 TCP/8889

RIS Service Manager status request and reply

LBM LBM TCP/9004

Intra-cluster communication between Location Bandwidth Managers

Table 6 – Intra-cluster Ports between Unified Communications Manager Servers

8.1.2 Security

Unified CM system uses a multilayered approach to call security, from the transport layer to the

application layer. The transport layer security includes TLS and IPSec for signaling authentication and

encryption to control and prevent access to the voice domain. SRTP9 adds media authentication and

encryption to secure privacy and confidentiality for voice conversation and other media.

Security Feature Line Side Trunk Side

Transport / Connection / Integrity Secure TLS Port IPSec Associations

Device Authentication TLS Certificate exchange IPSec certificate exchange or pre-shared key

Signaling Authentication/Encryption TLS Mode: authenticated or

encrypted IPSec10

Media Encryption SRTP SRTP

Authorization Presence requests Presence requests

Figure 20 - SCCP Call Security Features

The following table summarizes the authentication and encryption during a SIP call session. Security Feature Line Side Trunk Side

Transport / Connection / Integrity Secure TLS Port Secure TLS port

Device Authentication TLS Certificate exchange IPSec certificate exchange or pre-shared key

Digest Authentication Each SIP device uses unique

digest user credentials. SIP trunk user agents use unique digest

credentials.

Signaling Authentication/Encryption TLS Mode: authenticated or

encrypted TLS Mode: authenticated or encrypted mode

Media Encryption SRTP SRTP

Authorization Presence requests Presence requests Method list

Figure 21 - SIP Call Security Features

9 Secure Real-Time Transport Protocol that secures voice conversation in the network and provides protection against replay attacks. 10 Transport that provides secure H.225, H.245, and RAS signaling channels for end-to-end security.


8.1.3 Endpoint Hardening

To use secure phone capabilities, you must configure the Unified CM security mode using the Cisco

Certificate Trust List (CTL) Client. You cannot use secure phone capabilities with the non-secure security

mode. At a minimum, you must use mixed mode security.

Mixed mode security:

Allows authenticated, encrypted, and non-secure phones to register with Cisco Unified

Communications Manager.

Cisco Unified Communications Manager supports both RTP and SRTP media.

Authenticated and encrypted devices use secure port 5061 to connect to Cisco Unified

Communications Manager.

Secure Connections

If you enable secure phone capabilities, then SIP connections between Client Services Devices (CSF

devices) and Cisco Unified Communications Manager are over TLS.

If you select Authenticated as the value for the Device Security Mode field on the phone security

profile, the SIP connection is over TLS using NULL-SHA encryption.

If you select Encrypted as the value for the Device Security Mode field on the phone security

profile, the SIP connection is over TLS using AES 128/SHA encryption.

Mutual TLS ensures that only CSF devices with the correct certificates can register to Cisco Unified

Communications Manager. Likewise, CSF devices can register only to CUCM instances that provide the

correct certificate.

If you enable secure phone capabilities for users, their CSF device connections to Unified CM are secure.

If the other end point also has a secure connection to Unified CM, then the call can be secure. However,

if the other end point does not have a secure connection to Call Manager, then the call is not secure.

8.1.3.1 Transport Layer Security (TLS) and IPSec

Using TLS and IPSec Unified CM provides secure data transfer between systems and device by using

secure ports and certificate exchange. TLS secures connections among Unified CM controlled systems,

devices, and processes to prevent access to the voice domain. Unified CM uses TLS to secure SCCP calls

to phones that are running SCCP and SIP calls to phones or trunks that are running SIP.

IP Security (IPSec) provides secure and reliable data transfer between the Call Manager and gateways.

IPSec implements signaling authentication and encryption to Cisco IOS MGCP and H.323 gateways.


8.1.3.2 Cluster Security

Every node in the cluster runs an internal firewall protecting ports by source IP filtering. The firewall

opens ports only to authenticated or trusted server nodes. All nodes are authenticated before they can

access the publisher’s database via a pre-shared key authentication mechanism.

8.1.4 Certificates

Certificates secure client and server identities and required for the following components of the Unified

CM environment, which are

Component Purpose

CallManager A self-signed root certificate automatically installs when you install Unified Communications Manager on the server.

CAPF The system copies this root certificate, which gets generated during installation, to your server or to all servers in the cluster after you complete the Cisco CTL client configuration.

HTTPS A self-signed root certificate gets generated during the installation for the HTTPS (Tomcat) server.

IPSec A self-signed root certificate gets generated during installation for IPSec connections with MGCP and H.323 gateways.

SRST

When you configure a secure SRST reference in Unified CM Administration, Unified CM retrieves the SRST-enabled gateway certificate from the gateway and stores it in the database. After you reset the devices, the certificate gets added to the phone configuration file. Because the certificate is stored in the database, you cannot manage this certificate with the certificate management tool.

TVS These are self-signed certificates that support the Trust Verification Service (TVS).

Cisco Unified Communications Manager supports only PEM (.pem) and DER (.der) formatted certificates.

8.1.5 DNS

Cisco does not support mixed-mode deployments. Both Unified Communications Manager and IM and

Presence must either use or not use DNS, there cannot be a mix of DNS with static IP nodes. Also, all

environments deployed in the Collaboration environment should use the same DNS servers. If you use

different DNS servers, it is likely to cause abnormal system behavior.

8.1.5.1 DNS A-Records

Record ucovpscucm1.uc.healthenl.ca. 600 IN A TBD

ucovpscucm2.uc.healthenl.ca. 600 IN A TBD

ucavpscucm1.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP addresses of Call Manager nodes.

Resilience Considerations One A and/or AAAA record per CUCM Server.

Description This record is used by other nodes of the cluster.


8.1.6 System Time




For Cisco Unified Communications Manager (CUCM), simplified sizing guidance covers deployments with

up to 10,000 users.

Software Deployment Size Nodes to be Deployed

Cisco Unified CM 2,500 Users 3



Software Version

Cisco Unified Communications Manager (CUCM) 11.5

8.1.7.2 Hardware

IM&P will be deployed as a virtual appliance via OVA files supplied by Cisco.

CPU model must have physical core speed 2.5GHz or higher11

Supported versions of vSphere ESXi include 5.0 U1, 5.1, 5.5, and 6.0

This deployment is based on a ‘2500 User’12 OVA

Server Node vCPU13 vRam vDisk vNIC (1Gb)

ucovpscucm1 2 6 GB 1 x 80GB 1

ucovpscucm2 2 6 GB 1 x 80GB 1

ucavpscucm1 2 6 GB 1 x 80GB 1


Unified CM does not require a server license or software version license. However, individual users

require licenses to use and connect to the environment.


User Connect Licensing Enhanced 250

User Connect Licensing Enhanced+ 250

11 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-

hardware.html#processor 12 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-communications-

manager.html 13 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-communications-

manager.html#2500userVM


8.2 Instant Messaging & Presence (IM&P) Reference Documentation

Installation Guide for Cisco Unified Communications Manager and IM and Presence Service Release 11.5(1) June 07, 2016

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/11_5_1/cucm_b_installation-guide-cucm-imp-1151.pdf

Database Setup for IM and Presence Service on Cisco Unified Communications Manager Release 11.5

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/database_setup/11_5_1/cup0_b_database-setup-guide-imp-115.html

Instant Messaging Compliance for IM and Presence Service on Cisco Unified Communications Manager Release 11.5

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/im_compliance/11_5_1/cup0_b_imp-im-compliance-115.html

Microsoft Exchange for IM and Presence Service on Cisco Unified Communications Manager Release 11.5

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/exchange_integration/11_5_1/cup0_b_ms-exchange-integration-115.html

The IM and Presence Service provides instant messaging, network-based presence, and federation for

third-party chat servers, and it enables the use of Cisco Jabber for instant messaging, presence, web

collaboration and audio and video communications.

Figure 22 - IM and Presence

The aggregated user information captured by the Cisco IM and Presence Service enables Cisco Jabber,

Cisco Unified Communications Manager applications, and third-party applications to increase user

productivity. These applications help connect colleagues more efficiently by determining the most

effective form of communication.


Note:

1. IM and Presence is a service of Unified Communications Manager and is therefore tightly

integrated with Unified CM.

2. The IM and Presence and Unified CM software versions must match. For two software

versions to match, they must have the same major and minor release number

Just some of the features available through IM & Presence include message archiving, contact lists,

multiple device messaging and file transfers. IM & P can interface with Microsoft Exchange, Cisco

WebEx, Google Talk as well as Microsoft Skype for Business.

8.2.1 Persistent Chat

Ad hoc chat rooms are IM sessions that remain in existence only as long as one person is still connected

to the chat room, and they are deleted from the system when the last user leaves the room. Records of

the IM conversation are not maintained permanently.

Persistent chat rooms are group chat sessions that remain in existence even when all users have left the

room, and they do not terminate like ad hoc group chat sessions. The intent is that users can return to

persistent chat rooms over time to collaborate and share knowledge of a specific topic, search through

archives of what was said on that topic, and then participate in the discussion of that topic in real-time.

For persistent chat you must have 1:1 mapping of the external database instance for each of the nodes

in the cluster. The size of the database should be taken into consideration. Archiving messages is

optional, and it increases the traffic on the node to which the external database instance its attached. In

large deployments, disk space is a concern because it can be filled very quickly, so you must ensure that

your database is large enough to handle the volume of information being logged.

If persistent chat is enabled, an external database must be associated with the Cisco XCP Text

Conference Manager service, and the database must be active and reachable otherwise the Text

Conference Manager service will not start. If the connection with the external database fails after the

Text Conference Manager service has started, the Text Conference Manager service will remain active

and functional; however, messages will no longer be written to the database, and new persistent chat

rooms cannot be created until the connection recovers.

8.2.1.1 Deployment Considerations for Persistent Chat

Persistent chat can be deployed on one or more nodes in a cluster.

Each node that supports persistent chat must be assigned to a dedicated database instance.

An external database server may support multiple database instances.

Persistent chat is a cluster-wide setting.

At least one node in the cluster must be assigned to an external database.

The Cisco XCP Text Conference Manager service will not run on a node that is not assigned to an

external database.


Pure instant (ad hoc) conferencing does not require any external database.

Figure 23 - TCM for Persistent Chat

Number of Maximum

Persistent chat rooms per node 1,500

Total rooms per node (ad hoc and persistent) 16,500

Occupants per room 1,000

8.2.2 Managed File Transfer

Managed file transfer (MFT) allows an IM and Presence Service client such as Cisco Jabber to transfer

files to other users, ad hoc group chat rooms, and persistent chat rooms. The files are stored in a

repository on an external file server, and the transaction is logged to an external database.

Figure 24 - IM&P External File Transfer Server

8.2.3 IM and Presence Message Archiving and Compliance

As part of the architecture, IM and Presence Service contains a Message Archiver component that allows

for logging of point-to-point, text conferencing, federated, and inter-cluster messages into an external

database for non-blocking14 compliance. IM and Presence Service message archival requires an external

database (PostgreSQL, Microsoft SQL, or Oracle) instance per cluster.

14 Blocking vs non-blocking indicates if messages are or are not blocked from being sent.


Figure 25 - IM Compliance Database

A blocking third-party compliance solution, which not only allows logging of messages but also applies

policy to message delivery and message content, requires the use of a third-party compliance server

solution.

8.2.4 Calendar Integration

IM&P has the ability to retrieve calendar state and aggregate it into a presence status via the calendar

module interface with Microsoft Exchange. Exchange makes the calendar data available from the server

through Exchange Web Services (EWS), which allows submitting requests and receiving notifications

from Microsoft Exchange. The integration with Exchange is done through a separate Presence Gateway

configuration for calendar applications. Once the administrator configures a Presence Gateway for

Outlook, the user has the ability to enable or disable the aggregation of calendar information into their

presence status.

8.2.5 Clustering

The first IM and Presence node installed is the IM and Presence publisher. Any other IM and Presence

node(s) are the IM and Presence subscriber(s), and they obtain a copy of their database from the IM and

Presence publisher. The IM and Presence publisher communicates with the Unified CM publisher and

most of the IM and Presence configuration is actually done through the Unified CM publisher (for

instance, the CUCM users, the services available to presence users, and the service activation). Hence,

all IM and Presence nodes, including the IM and Presence publisher, are considered subscribers of the

larger Unified CM and IM and Presence Service cluster.


Figure 26 - Expanded Unified CM Cluster

For redundancy and scalability, the Unified IM and Presence cluster environment will consist of two

nodes, one (1) publisher, and one (1) subscriber2. Since IM&P is an application of Unified CM, it joins in

the larger Unified CM cluster.

8.2.6 DNS

IM and Presence must either use or not use DNS, there cannot be a mix of DNS with static IP nodes.

Also, all environments deployed in the Collaboration environment should use the same DNS servers. If

you use different DNS servers, it is likely to cause abnormal system behavior.

8.2.6.1 DNS A-Records

Record ucovpsimp1.uc.healthenl.ca. 600 IN A TBD

ucavpsimp1.uc.healthenl.ca. 600 IN A TBD

Type A

Resolves To IP addresses of Call Manager nodes.

Resilience Considerations One A and/or AAAA record per CUCM Server.

Description This record is used by other nodes of the cluster.

8.2.7 System Time






For IM and Presence, simplified sizing guidance covers deployments with up to 15,000 users or 15,000

logged-in Jabber endpoints.


IM & Presence Less than 5,000 users or logged in

Jabber endpoints One IM & Presence Pair using the

5k-user OVA template



Software Version

Unified CM IM and Presence 11.5

8.2.8.2 Hardware



This deployment is based on a ‘5000 User’15 OVA

The two IM and Presence nodes are deployed as a pair in order to provide redundancy if one of

the nodes fails.


ucovpsimp1 2 4 GB 2 x 80GB 1

ucavpscimp1 2 4 GB 2 x 80GB 1


The IM and Presence Service does not require a server license or software version license. However, you

must assign users and enable the IM and Presence Service for each assigned user.

8.2.9 SIP Trunk

After you configure Unified CM as a Presence Gateway, you must configure a SIP PUBLISH trunk on

Unified CM and the enable SIP Publish on the IM&P servers.

8.2.10 Compliance and Privacy

Security & Compliance

Many of the features of Instant Message and Presence, features used with the Jabber client, provide the ability to track and store conversations, files and potentially, PHI. These are features enabled at the server layer. It will be the responsibility of the Security, Compliance and Privacy officers to prepare a policy and statement around privacy and the use of IM & P.

15 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-ucm-im-

presence.html#5000userVM


Some of the features that need to be examined around Security and Privacy include:

1. Compliance servers that enable the system to log and archive all instant messaging traffic.

2. File transfer capabilities to move files across users of the IM & P environment.

3. Persistent chat capabilities that provide the ability to archive all room messages.

8.3 Cisco Meeting Server Reference Documentation

Installation Guide for Virtualized Deployments January 06, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Installation/Cisco-Meeting-Server-2-0-Installation-Guide-for-Virtualized-Deployments.pdf

Deployment Planning and Preparation Guide February 16, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-1/Cisco-Meeting-Server-Deployment-Planning-and-Preparation-Guide.pdf

Scalability & Resilience Server Deployment Guide May 05, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-1/Cisco-Meeting-Server-2-1-Scalable-and-Resilient-Deployments.pdf

Load Balancing Calls Across Cisco Meeting Servers 09 May 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/White_papers/Load-balancing-calls-across-Meeting-Servers-white-paper.pdf

H.323 Gateway Deployment Guide December 23, 2016

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-0/Cisco-Meeting-Server-2-0-H323-Gateway-Deployment-Guide.pdf

Cisco Meeting Server Release 2.2 with Cisco Unified Communications Manager Deployment Guide May 09, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-2/Cisco-Meeting-Server-2-2-Deployments-with-CUCM.pdf

Figure 27 - Cisco Meeting Server

Cisco Meeting Server (CMS) is a conference collaboration software that enables users to use Cisco video

room technology for multiparty conferencing and integration with third-party solutions such as Skype

for Business, Polycom, Avaya, mobile clients and WebRTC (Web Real Time Communication) video.

It enables:


Meeting experiences that incorporate video, audio, and content-sharing capabilities.

The ability for anyone to join a meeting easily, whether from a room system, desktop system, or

mobile device via app or browser.

Scalability so that IT managers can meet existing needs and extend as business needs grow, as

simple as scaling the environment out.

When integrated with Unified Communications Manager (CUCM) it introduces the ability to

escalate a 1:1 call to a multiparty conference which can be easily connected to via Jabber.

Through integration with Telepresence Management Suite, it includes support for “one-button-

to-push” conferences.

The core of the Meeting Server is a ‘Space’ which is a personal and persistent, always available video

conference that pretty much anyone can join, whether they use Cisco telepresence endpoints, Jabber,

Cisco Meeting App, Microsoft Skype for Business or even a web browser.

Cisco Meeting Server is a scalable software platform for voice, video and web content, which integrates

with a wide variety of third-party applications from Microsoft, Avaya and other vendors. With the

Meeting Server, people connect regardless of location, device, or technology.

8.3.1 Components of CMS

To enhance scalability and resilience, the Meeting Server will be deployed in a split configuration where

core and edge services exist on separate servers.

The implementation ensures scalability along with location and application resilience, ensuring single

node failures do not impact the overall solution.

Figure 28 – Cisco Meeting Server – Split Server Deployment


There are two layers of CMS; the platform and the applications.

The Platform is configured through the Mainboard Management Processor (MMP) which is available to

all servers.

i. MMP

The MMP is the administrative interface used for low level bootstrapping, and configuration

via its command line interface. For example, the MMP is used to enable components.

The applications run on this managed platform with configuration interfaces of their own. The following

applications are deployed on two (2) CMS Core servers and a third CMS server is deployed for quorum

services for the Database and XMPP components

Figure 29 - CMS Resilient Deployment

ii. Call Bridge

The component that bridges the conference connections together into a single conference.

Call Bridges will be clustered allowing them to operating as a single entity and scale beyond

the capacity of a single Call Bridge.

iii. Database

The Call Bridge reads from and writes to the database storing the space information, for

example the members of spaces, chat messages and recent activity. Based on a postgres

database, multiple instances can be clustered together to provide resiliency in the

deployment.

iv. Support for Lync clients

You can use Skype for Business clients, and Lync 2010 and 2013 clients connected to a

Skype for Business server, Lync 2010 or 2013 server.

The Meeting Server uses:

- RTV codec transcoding up to 1080p with the 2010 Lync Windows client and 2011

Lync Mac clients

- H.264 codec with the 2013 Lync Windows client and Skype for Business client.


The Meeting Server transcodes the content from native Lync RDP into the video format used

by other participants in the meeting and sends it as a separate stream.

v. Recording Meetings (Not to be deployed at this time)

Meeting Server has the capability of recording meetings and saving the recordings to a

document storage such as a network file system (NFS). Recording is controlled by license

keys, where one license allows one simultaneous recording. The license is applied to the

server hosting the Call Bridge (core server) which connects to the Recorder, not the server

hosting the Recorder

Recommendation

The recommended deployment for production usage of the Recorder is to run it on a dedicated VM with a minimum of 4 physical cores and 4GB. In such a deployment, the Recorder should support 2 simultaneous recordings per physical core, so a maximum of 8 simultaneous recordings.

vi. Streaming Meetings (Not to be deployed at this time)

The Streamer component adds the capability of streaming meetings held in a space to the

URI configured on the space. An external streaming server needs to be configured to be

listening on this URI. The external streaming server can then offer live streaming to users, or

it can record the live stream for later playback.

8.3.2 Database Resiliency

Databases in a cluster have one master server and several slaves. The Call Bridge needs to communicate

with the master server and will continuously assess which database instance is the Master.

Table 7 - CMS Database Replication

If a master server stops working or is disconnected, another database server can promote itself to

master. However, a database server will only promote itself, if it can see more than half of the database

servers in the cluster, and if no other database server is a master.

Cisco Recommendation


Do not create a database cluster of 2 nodes, as it reduces resilience rather than increases it. Using an odd number of nodes aids resiliency in the case of network partitions, and Cisco recommends running at least 3 database nodes

In Figure 29 - CMS Resilient Deployment above, the CMS Redundancy node is shown hosting a separate

database instance and XMPP instance. Ideally, this database instance would be at a third site allowing

total outage of either site to be handled, however in a simplified deployment, it will be housed at the

primary location (OCIO).

The table below provide the minimum Cisco recommended requirements for the external database

server.

Component Description

CPU Four (4) vCPU Sandy Bridge (or later) Intel Processors

Memory 8GB Ram

Storage 100GB Data Store and the data store must reside on the same vdisk as the OS

For the external database server, deploy the Meeting Server image on to each of the external database

host servers. An empty database is set up automatically. These host servers will require certificates.

8.3.2.1 Database - Required Resiliency Ports

Resiliency ports enable communications across Cisco Meeting Servers and are required to be open in a

scalable and resilient multi-server deployment.

Destination Port

Traffic Type

Traffic Direction

Source Destination Note

5432 TCP Bi-directional Call Bridge 2 Database 1

(Master)

5432 TCP Bi-directional

Database 1 (Master)

Database 2 Database 3

(Slaves)

Cluster & Replication Ports

8.3.3 Call Bridge Reference Documentation

Load Balancing Calls Across Cisco Meeting Servers 09 May 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/White_papers/Load-balancing-calls-across-Meeting-Servers-white-paper.pdf

For scalability and resilience of the conferencing service, Call Bridges will be configured in a cluster. This

permits load balancing incoming and outbound calls on the Meeting Servers to avoid overloading

individual Meeting Servers in the cluster.

By using Call Bridge Groups, the Meeting Server cluster can load balance calls across Call Bridges. The

decision making behind where a call ends up is handled by the Meeting Servers with the call control


system, Cisco Unified Communications Manager (CUCM), handling the SIP messages from the Meeting

Servers.

Call Bridges can be configured in the cluster to link peer-to-peer, or via call control devices.

Linking Call Bridges peer-to-peer

Reduces call complexity as the call will go from Call Bridge A to Call Bridge B directly, with

nothing in the middle to interfere with the routing of the call.

Reduces load on the call control device, and frees up resources to handle calls that need to

route through the call control device. This may be important if the call control device is licensed

on a per call basis.

Routing via call control device(s):

Creates a consistent call flow for your Meeting Server and Local SIP devices. This can make

network configuration a little simpler, particularly if there are firewalls between networks with

fixed “allow rules” which only allow calls routed through call control devices.

Unified

Communications

Manager


ODC_CUCM

OCIO

ODC_CMS

SIP

Tru

nk

Unified

Communications

Manager


ADC_CUCM

Allandale

ADC_CMSS

IP T

runk

Figure 30 - Deployment for Load Balancing Incoming Calls

Notes:

1. Two Call Bridges, being clustered, are aware of the enabled components on the other host server

and also connect to the database cluster to read from and write to it.

2. Each Call Bridge provides Caller Detail Records (CDRs) for the call legs that it is hosting. Each CDR

identifies the space ID so you can identify the same meeting on different Call Bridges by collecting

together calls with the same space ID.

3. While a non-secure trunk can be used, it is recommended that a Secure SIP trunk be configured

between CMS and CUCM. The API requires HTTPS communications, so certificates will be required.


8.3.3.1 Call Bridge - Required Application Ports

Destination Port

Traffic Type

Traffic Direction

Source Destination

53 TCP or UDP Outgoing Call Bridge DNS Server

SIP & Call Control

5060

UDP (SIP) TCP (SIP)

Bi-directional Call Bridge Internal registered SIP endpoint or voice call control

5061 TCP (SIP TLS) Bi-directional Call Bridge Internal registered SIP endpoint or voice call control

32768-65535 UDP (STUN RTP, BFCP) Incoming Call Bridge Internal registered SIP endpoint or voice call control

Lync Clients

1024-65535

UDP (STUN RTP) TCP (RDP)

Outgoing Call Bridge Lync Client Note: Port range depends on Lync Server

32768-65535 UDP (STUN RTP)

TCP (RDP) Incoming Call Bridge Lync Client

443 TCP Outgoing Call Bridge Lync Edge Server

3478 UDP Outgoing Call Bridge Lync Edge Server

5061 TCP (SIP TLS) Bi-directional Call Bridge Lync FE Server

32768-65535 UDP (STUN RTP) Incoming Call Bridge Lync Edge Server

Cisco Meeting Apps

1024-65535 UDP (STUN RTP) Outgoing Call Bridge

Internal native Cisco Meeting Apps. Port range depends on client side.

32768-65535 UDP (STUN RTP) Incoming Call Bridge

Internal native Cisco Meeting Apps.

8.3.3.2 Call Bridge - Required Resiliency Ports

Resiliency ports enable communications across Cisco Meeting Servers and are required to be open in a

scalable and resilient multi-server deployment.

Destination Port

Traffic Type

Traffic Direction


443 TCP Bi-directional Call Bridge 1 Call Bridge 2

5060

TCP (SIP) UDP (SIP)

Bi-directional Call Bridge 1 Call Bridge 2

5061 TCP (SIP TLS) Bi-directional Call Bridge 1 Call Bridge 2

1024-65535

UDP (SIP) BFCP

Outgoing Call Bridge 1 Call Bridge 2

32768-65535

UDP (SIP) BFCP

Incoming Call Bridge 1 Call Bridge 2

5223 TCP Outgoing Call Bridge 1

XMPP Server 2 XMPP Server 3

5432 TCP Bi-directional Call Bridge 1 Call Bridge 2

Database Cluster & Replication

8.3.4 Call Bridge - DNS

Record callbridge01.uc.healthenl.ca. 600 IN A 10.X.X.X callbridge02.uc.healthenl.ca. 600 IN A 10.X.X.X

Type A

Resolves To IP address of Call Bridge


Resilience Considerations One record per Call Bridge. Each Call Bridge must have a unique FQDN

8.3.5 XMPP

Figure 31 - CMS - XMPP Component Deployment

The XMPP server handles the signaling to and from Cisco Meeting App and WebRTC. XMPP does not

work as a shared application, but instead provides fail-over protection. XMPP servers in resilient mode

are loaded with the same configuration and know the location of each other. XMPP messages can be

sent to any server, but these messages are then forward to the master XMPP server. In the event of a

failure of the master, the remaining servers elect a new master and forward messages to that node.

In a resilient deployment, the XMPP server that a Call Bridges connects to is controlled via DNS. This choice is based on the DNS priority and weight given. A Call Bridge only connects to one XMPP server at a time. There is no requirement for all Call Bridges to connect to the same XMPP server since all traffic is forwarded to the master. If a network problem results in the Call Bridge losing connection to the XMPP server, the Call Bridge will attempt to reconnect to another XMPP server.

Note

Deployments with only two XMPP servers will not benefit from resiliency, and if one fails it will cause an outage, effectively doubling the risk of failure versus stand-alone mode. This is due to the failover algorithm requiring more than half of the nodes to be available in order for the system to make good decisions about which XMPP server is the master.

8.3.5.1 XMPP DNS

DNS SRV records are required for any location in which it is desired to access the XMPP service. These

addresses will generally be fronted by a load balancer. SRV records essentially allow transparent DNS-

level redirects of XMPP services to another domain or port. A simple example is when you want users to

have addresses like “[email protected]”, but your XMPP server is really installed on

“xmpp.uc.healthenl.ca”. In principle they work the same way as MX records do for email.


XMPP has two different types of SRV records, those for clients to use (client-to-server), and those for

other XMPP servers to use when they look up your domain (server-to-server).

Examples:

_xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 60 5222 ucovpzcmse1.uc.healthenl.ca. _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5222 ucavpzcmse1.uc.healthenl.ca. _xmpp-server._tcp.uc.healthenl.ca 86400 IN SRV 10 60 5269 ucovpzcmse1.uc.healthenl.ca. _xmpp-server._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5269 ucavpzcmse1.uc.healthenl.ca.

In the example above, the target domain must be an existing DNS A record for the target server, it cannot be an IP and it cannot be a CNAME. The ’10 60’ and ’10 20’ are the records priority and weight which allow multiple targets to have different priorities; lower priorities are tried first. Weight is used to bias resolvers towards certain targets if the priorities tie. The ‘5222’ and ‘5269’ indicate the port on which the service is running. Clients typically connect to 5222, and servers to 5269. These can be changed, for example, if you want to run multiple XMPP servers on the same machine.

8.3.5.1.1 xmpp – A Record

Record External DNS: xmpp1.uc.healthenl.ca. 600 IN A 24.222.186.xx – TBD xmpp2.uc.healthenl.ca. 600 IN A 24.222.186.xx – TBD

Type A

Resolves To IP address of either the XMPP server or a load balancer which is configured to trunk to the XMPP server.

Resilience Considerations One A record per XMPP load balancer (or server).

Description Used by clients to login. The SRV record must correspond to the domain used in your XMPP usernames

8.3.5.1.2 _xmpp-client

In order to enable client connections, including use of a WebRTC client the _xmpp-client._tcp record is

required. Where it is not possible to route directly to the core server, XMPP traffic should instead be

handled by the Load Balancer

Record

External DNS: _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 60 5222 xmpp1.uc.healthenl.ca. _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5222 xmpp2.uc.healthenl.ca. Internal DNS: _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 60 5222 ucovpscmsc1.uc.healthenl.ca. _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5222 ucovpscmsc2.uc.healthenl.ca. _xmpp-client._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5222 ucavpscmsc1.uc.healthenl.ca.

Type SRV (*)

Resolves To The A record for the CMS edge servers deployed in the DMZ. . Usually this is port 5222.


Resilience Considerations One SRV record can be created for each XMPP server/Load Balancer such that multiple results are returned in response to a DNS lookup. Clients choose a destination for XMPP traffic based on the priority and weight information

Description Used by clients to login. The SRV record must correspond to the domain used in your XMPP usernames

8.3.5.1.3 _xmpp-server

The XMPP service can federate with any other standards-compliant XMPP service. In order to enable

this, create the _xmpp-server._tcp SRV record, usually resolving to port 5269. Because XMPP federation

will usually be across the Internet, typically these records are only required to point to servers available

in the DMZ.

Record External DNS: _xmpp-server._tcp.uc.healthenl.ca 86400 IN SRV 10 60 5269 xmpp1.uc.healthenl.ca _xmpp-server._tcp.uc.healthenl.ca 86400 IN SRV 10 20 5269 xmpp2.uc.healthenl.ca

Type SRV (*)

Resolves To The A record for the CMS edge servers deployed in the DMZ. Usually this is port 5269.

Resilience Considerations One SRV record can be created for each XMPP server/Load Balancer such that multiple results are returned in response to a DNS lookup. Clients choose a destination for XMPP traffic based on the priority and weight information

Description Used to federate between XMPP servers. The SRV record must correspond to the domain used in your XMPP usernames

8.3.5.2 XMPP – Firewall Ports

Figure 32 – Traffic flow for XMPP Server

XMPP application traffic flows from the core Meeting Server to Load Balancer and Web Bridge in the

DMZ and directly to any Cisco Meeting Apps deployed to the HIN.


Destination Port

Traffic Type

Traffic Direction

Source Destination

Between Semi-Trust and DMZ

4999 TCP Outgoing XMPP Server Load Balancer

5222 TCP Bidirectional XMPP Server Web Bridge

Between Semi-Trust and HIN

5222 TCP Bidirectional XMPP Server

Internal (HIN) Cisco Meeting Apps

Between DMZ and Internet

443 TCP Bidirectional WebRTC Web Bridge

5222 TCP Bidirectional Cisco Meeting App Load Balancer

In a split configuration, the single point of contact for Cisco Meeting apps is the load balancer which

then communicates with the XMPP server.

8.3.6 LDAP Integration

For users to utilize the Cisco Meeting Apps to connect to the Meeting Server, then you must have an

LDAP server (currently Microsoft Active Directory or OpenLDAP). The Meeting Server imports the User

accounts from the LDAP server.

You can create user names by importing fields from LDAP. The passwords are not cached on the

Meeting Server, instead a call is made to the LDAP server when a Cisco Meeting App authenticates, and

therefore passwords are managed centrally and securely on the LDAP server.

Benefits of utilizing the LDAP server include the ability to separate users into groups. For example:

Everyone at Western Health

Everyone in a specific department

Everyone with a specific job title.

Meeting Server supports secure LDAP, normally run on port 636 however this can be changed if

required.

8.3.6.1 LDAP - Required Application Ports

Destination Port

Traffic Type

Traffic Direction

Source Destination

Note: If a ports is highlighted with a ‘*’ it is configurable. LDAP

389 / 636* TCP (SIP TLS) Outgoing

Call Bridge 1 Call Bridge 2

LDAP (Active Directory)

8.3.7 DNS - Cisco Meeting Server – A Record

Record ucovpzcmsc1.uc.healthenl.ca. 600 IN A TBD

ucaopzcmsc2.uc.healthenl.ca. 600 IN A TBD ucavpzcmsc2.uc.healthenl.ca. 600 IN A TBD


Type A

Resolves To IP address of CMS core servers.

Resilience Considerations One A record per server.

8.3.8 Sizing

When a VM is configured to run one or more Meeting Server components, Cisco recommends that the

entire host is dedicated to the VM. This provides best performance for real time media applications and

ensures high quality end user experience. The sizing of VMs depends on the components being used.

8.3.8.1 Call Bridge VM

The Call Bridge carries out the media transcoding for the Meeting Server. This component has the

highest requirements of any of the components. Each physical core of an Intel Xeon 2600 series (or

later) CPU, running at 2.5GHz, is capable of approximately 2.5 720p30 H.264 call legs when hyper

threading is enabled. Capacity scales linearly with number of CPU cores and frequency, so a two socket

E5-2680v2 system, which has 20 physical cores, can handle 50 concurrent 720p30 H.264 call legs.

720p30 Participants (Call Legs) CPU Configuration Ram Configuration

50 Dual Intel E5-2680v2 32 GB

40 Dual Intel E5-2650v2 32 GB

25 Single Intel E5-2680v2 16 GB

15 Single Intel E5-2640v2 8 GB

Table 8 - Sample Requirements for HD Call Legs

The VM should be configured to use all but one of the host physical cores. When hyper threading is

enabled the number of available logical cores is double the number of physical cores, so in the dual E5-

2680v2 system above, there are 40 virtual CPUs, of which 38 should be allocated to the VM. If an option

is available to choose both number of sockets and number of cores per socket, a single socket should be

configured with all the virtual CPU cores.

Over-subscription of the host can cause scheduling delays and result in degraded media quality. A

correctly configured VM, according to Cisco recommendations, will degrade gracefully by dropping

frame rate and/or resolution if pushed over capacity.

1GB RAM for each underlying physical CPU core should be allocated to the VM. For the system above,

the VM should be configured with 19GB corresponding to the 19 physical CPU cores inuse.

Notes:

1. Hyperthreading should be enabled where available; without it there is capacity reduction.

2. vCPU’s assigned to the CMS must be dedicated for its use.

8.3.8.2 Database VM

The host server for a database has modest CPU requirements, but requires large storage and memory.


Four vCPUs, 8GB RAM and 100GB data store.

Sandy Bridge (or later) class Intel processors (e.g. E5-2670 or E5-2680 v2).

The data store should reside on either a high IO per second SAN or local SSD storage.

The data must reside on the same vdisk as the OS.

8.3.9 MMP

For administrative configuration access to the MMP will be available via SSH and HTTPS.

8.3.9.1 MMP - Required Access Ports

Destination Port

Traffic Type

Traffic Direction


22 TCP Incoming

NLCHI Administrators

MMP Secure Login to MMP

443 TCP (HTTPS) Incoming

NLCHI Administrators

MMP Secure Web Admin

8.3.9.2 MMP – Service Access

The following ports are required to connect normal services to the Meeting App.

Destination Port

Traffic Type

Traffic Direction


53 TCP or UDP Outgoing MMP DNS Server

123 TCP or UDP Outgoing MMP NTP Server

514 TCP Outgoing MMP Syslog Server

161 UDP Incoming MMP SNMP Server

162 TCP or UDP Outgoing MMP SNMP Trap


Certificate Guidelines for Single Combined Server Deployments May 10, 2017

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-2/Certificate-Guidelines-Single-Combined-Server-Deployment-2-2.pdf

Public CA certificates and a certificate bundle are required for:

Application Reason

XMPP Server Native Cisco Meeting App require a public CA signed certificate from the XMPP server in order to trust the connection.

Call Bridge Lync Edge server requires a public CA signed certificate from the Call Bridge if doing direct federation.

The remaining applications, can be signed with an internally signed CA certificate.

Application Reason

Web Admin

The Meeting Server only allows HTTPS connection, so a certificate is required for the Web Admin. Note: The Meeting Server API is routed through the Web Admin Interface, so a certificate is required even if you configure the Call Bridge through the API rather than the Web Admin.


OPTIONAL

Recorder If you enable a Recorder or Streamer on the Meeting Server, the Call Bridge requires a signed certificate from the Recorder, and the Recorder requires and needs to trust a certificate from the Call Bridge Streamer


While CMS will support a resolution and frame rate of up to 1080p at 60fps for main video and 1080p at

30fps for content, the following guidelines were used in sizing the environment.

Software Description (Concurrent) Concurrent Calls


HD calls (assuming 720p5 content, up to 2.5 Mbps bandwidth)

36

SD calls (448p30 - up to .9 Mbps bandwidth)

100

Audio-Only Calls 1000



Software Version

Cisco Meeting Server 2.2

8.3.11.2 Hardware16

CMS will be deployed as a virtual appliance via OVA files supplied by Cisco.

Supported versions of vSphere ESXi include 5.1 U2, 5.5 U1 and 6.0.

vCPU: The number of required vCPU is a base 4vCPU for normal components such as database,

xmpp server ,etc. and then add 1 vCPU for every 1.25 HD call. We assume 36 calls in our sizing.

vRAM: The amount of vRAM required is a base of 4GB, and then 1GB for each additional core.


ucovpzvcsc1 18 22 GB 100 1

ucovpzvcsc2 6 10 GB 100 1

ucavpzvcsc1 18 22 GB 100 1

Total (supporting 36 calls) 42 54 GB


Call multiparty licensing is the primary licensing model used for Cisco Meeting Server. Multiparty

licensing is available in two variations: Personal Multiparty Plus (PMP Plus) licensing, which offers a

16 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-meeting-server.html


named host license, and Shared Multiparty Plus (SMP Plus) licensing, which offers a shared host license.

Both Personal Multiparty Plus and Shared Multiparty Plus licenses can be used on the same server.



The following activation keys are required to use the Cisco Meeting Server and are included with the

software.

Component Note

Call Bridge If you are deploying a cluster of Call Bridges you require a license file for each Call Bridge in the cluster.

XMPP License Activation Key – included in the software.

Note

In a cluster of Call Bridges, each Call Bridge requires its own PMP Plus/SMP Plus licenses, licenses cannot be shared between Call Bridges. For example, if you have two Call Bridges you need to purchase separate licenses for each Call Bridge.

8.3.11.3.1 Personal Multiparty plus licensing

Personal Multiparty Plus (PMP Plus) provides a named host license assigned to each specific user who

frequently hosts video meetings. Personal Multiparty Plus is an all-in-one licensing offer for video

conferencing. It allows users to host conferences of any size (within the limits of the Cisco Meeting

Server hardware deployed). Anyone can join a meeting from any endpoint, and the license supports up

to full HD 1080p60 quality video, audio, and content sharing.

8.3.11.3.2 Shared Multiparty Plus licensing

Shared Multiparty Plus (SMP Plus) provides a concurrent license that is shared by multiple users who

host video meetings infrequently. This licensing is ideal for environments that have room systems

deployed that are shared among many users. Users can host a meeting with their space, initiate an ad-

hoc meeting or schedule a future one. Each shared host license supports one concurrent video meeting

of any size (within the limits of the hardware deployed). Each Shared Multiparty Plus license includes

one Rich Media Session (RMS) license for the Cisco Expressway, which can be used to enable business-

to–business (B2B) video conferencing.


8.4 Active Directory Integration Reference Documentation

Directory Integration and Identity Management http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/directry.html?bookSearch=true

Figure 33 - Active Directory for Federated Trust

Integration with Microsoft Active Directory will provide users with a single sign-on through their

individual RHA domain accounts. Using a unidirectional authentication (one-way trust) path between

the RHA domain controllers and the AD controllers deployed in the UC environments users of the UC

environment will use their own RHA credentials when accessing resources.

Figure 34 - Trust Direction


Each of the collaboration applications will forward authentication requests to the Local Active directory,

which in turn through its federated trust, forward account authentication back to the RHA of the

originating user. This ensures that if a user changes their local AD credentials, for example, then the new

password will automatically be used in the Collaboration environment.

The configuration of the AD Trust is not included in this document, but is a straight forward process as

documented by Microsoft (https://technet.microsoft.com/en-us/library/cc816738(v=ws.10).aspx)

8.4.1 LDAP Integration Features

Full integration with LDAP (Active Directory) provides more features than just user authentication.

Provisioning

When directory integration occurs, Unified CM can automatically add, remove and modify user

information each time a change occurs back at the LDAP.

User Lookup

Lookups to the LDAP can be enabled to allow Jabber or Cisco Meeting App, or third party XMPP

clients to search for clients in the LDAP directory.

Group Integration

Jabber users can search for groups in AD and add them to their contact lists.

8.4.2 Unified CM to AD

Note:

As with the entire Collaboration environment, DNS is integral, without a properly configured

DNS, integration will fail.

For integration between CM and AD, the AD administrator will create a username for the Unified CM

connection to the LDAP server which will have read rights to the directory.

AD User Notes

UCM_AD_Admin AD Read rights to the directory.

When the user is set, determine the fully distinguished name of the location where it was created; this

should include the CN of the name, the OU(s) that the name falls into (if there’s more than one OU, get

their correct order) and the DCs (also in the correct order).

Export a DER encoded binary X.509 Windows certificate from the Domain Controller that contains the

global catalog and upload that certificate to Unified CM as a ‘tomcat-trust’ onto the Publisher and all

subscribers and then restart the DirSync service and Tomcat services.


At this point, the CUCM servers are ready for secure connections to AD and a synchronization should be

performed as a final test of the connection. It’s good to remember, however, that this can eat up a lot of

bandwidth. If possible, schedule the sync to be performed during off hours.

8.4.3 Firewall Ports

The following application ports are used between Unified CM and Active Directory


UCM AD

TCP/389 TCP/636

TCP/3268 TCP/3269

Lightweight Directory Access Protocol (LDAP) query to external directory

AD UCM Ephemeral

These ports are used between the Collaboration Active Directories and the RHA and NLCHI AD Servers.

Destination Port

Traffic Type

Traffic Direction

Source Destination

Between Semi-Trust and HIN

636 TCP Bidirectional Collaboration

AD Servers

Eastern Health AD Servers Central Health AD Servers

Western Health AD Servers Lab-Grenfell AD Servers

NLCH AD Servers


The Active Directory environment will co-exist with the TMS server and thus the resources are accounted for there.


Software Version

(Minimum) Microsoft Windows Server 2012 R2


9 Management Module Component Description

Management

Cisco TelePresence Management Suite and Extensions

Provides scheduling, web conferencing integration, and other advanced video features

Cisco Prime Collaboration

Figure 35 - Management Environment

The management environment includes Telepresence Management Suite and Prime Collaboration.

9.1 Telepresence Management Suite and Extensions Reference Documentation

Cisco TelePresence Management Suite Administrator Guide July 2017

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/tms/admin_guide/Cisco-TMS-Admin-Guide-15-5.pdf

Cisco TelePresence Management Suite Installation and Upgrade Guide May 2017

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/tms/install_guide/Cisco-TMS-install-guide-15-5.pdf

Cisco TelePresence Management Suite Extension for Microsoft Exchange Deployment Guide Version 4.0

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/tmsxe/install_guide/Cisco-TMSXE-Deployment-Guide-4-0.pdf

The Telepresence Management Suite (TMS) provides control and management of telepresence

conferencing and media services infrastructure and endpoints. With TMS, you can schedule

conferences, integrate phone books from external information sources and existing AD directories, and

provision and management endpoints.


Figure 36 - Telepresence Management Suite

TMS also delivers usage and activity reports to aid decisions and view how the environment is being

used. TMS also provides a portal front end for management purposes to provide a quick view on current

conference activity and end point issues.

Figure 37 - TMS Portal

9.1.1 Supported Systems

All systems in the telepresence deployment can be added to TMS:

Telepresence Endpoints

Cisco VCS

Telepresence Servers


Unified CM

Meeting Server

Etc.

Endpoints not directly supported by TMS (such as Polycom devices) can be added as unmanaged

endpoints. TMS will have no control over these unmanaged endpoints, but by integrating, they are

available for booking.


The following ports are used by TMS and must be enabled through the firewall to all telepresence

endpoints.

Purpose Destination Port

Traffic Type

Traffic Direction

Source Destination

FTP 20,21 TCP Out TMS Endpoints

HTTP / HTTPS 80,443 TCP Bidirectional TMS Endpoints

HTTPS to Unified CM 8443 TCP Out TMS Unified CM

LDAP / LDAPS 389, 636 TCP Out TMS AD

Polycom GAB 3601 TCP In TMS Polycom

SMTP 25 TCP Out TMS SMTP Server

SNMP 161 UDP Out TMS SNMP Server

SNMP Traps 162 UDP Bidirectional TMS SNMP Server

SSH 22 TCP Out TMS Endpoints

Telnet 23 TCP Out TMS Endpoints

Telnet Challenge 57 TCP Out TMS Endpoints

Telnet Polycom 24 TCP Out TMS Endpoints

9.1.3 Redundant Deployment

For a fully redundant TMS deployment with automatic failover, TMS servers must be fronted with a

network load balancer and a shared SQL server database.

For this installation, we will be configuring TMS using the hot standby model. This requires manual

intervention if there is a failure on the primary TMS server, and is therefore a switchover solution rather

than a failover solution. The hot standby redundancy model requires the TMSNG database to be located

on an external SQL server, and that the two TMS servers must be in the same Windows domain.

One Cisco TMS server is active at any given time with this redundancy model. The hot standby server

must be kept up to date with security patches and other upgrades so that it is ready for activation within

a few minutes if the primary server fails.

Deploying two servers will increase availability, but will not increase TMS scalability.


9.1.3.1 Database

TMS relies heavily on its SQL database, in which it stores all of its configuration data. So a fully resilient

TMS solution requires a highly available SQL server database. The database is to be installed on two

servers and configured in a hot-standby mode. The hot-standby database will also be used for backup

and recovery of user information.

Figure 38 – Database Replication

The standby database will be co-located with TMS and LDAP.

The primary database will be perform log shipping to the standby (secondary) database on a defined

schedule. The standby database will be set to either RECOVERING or STANDBY (standby allows limited

read only access).

Using standard SQL server processes, the primary server will back up the transaction log and copy it to

the standby instance. The standby instance will then run a job to apply (restore) this transaction log to

its SQL database instance.

Note:

With a standby database configured in this fashion, there will always be a small delta between

the primary and secondary SQL server databases. This delta will be the equal to the time delay

between transaction log shipping.


For Cisco TelePresence Management Suiter (TMSXE), simplified sizing guidance covers deployments with

up to 10,000 users.


Cisco TMS 500 Endpoints 2



Software Version

Cisco Telepresence Management Suite (TMS) 15.5


9.1.4.2 Hardware




This deployment is based on a Regular Deployment OVA plus SQL Server

Server Node vCPU18 vRam vDisk vNIC (1Gb)

ucovpstms1 6 24 GB 300GB 1

ucavpstms1 6 24 GB 300GB 1


Only one live database can be used in a redundant implementation therefore both servers will use the

same TMS serial number and the same set of release and option keys.


Cisco Telepresence Management Suite 1

Microsoft SQL Server 2012 or later 2

Microsoft Windows Server 2012 or later 2

17 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-

hardware.html#processor 18 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-telepresence-management-

suite.html


9.2 Prime Collaboration Standard Reference Documentation

Cisco Prime Collaboration Provisioning Install and Upgrade Guide 12.1

http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/collaboration/12-1/provisioning/install_upgrade/guide/cpco_b_cisco_prime_collaboration_provisioning_install_and_upgrade_guide_12_1.html

Prime Collaboration is included with Unified Workspace Licensing (UWL) and User Connect Licensing

(UCL) for Cisco Unified Communications. It provides simplified, unified management across voice and

video collaboration networks. It offers automated provisioning, real-time monitoring, and proactive

troubleshooting, plus long-term trending and analytics.

A more feature rich advanced product, Prime Collaboration Advanced which includes three separate

modules: Provisioning, Assurance, and Analytics is available, however included with licensing is the

Standard version.

Prime Collaboration Standard, includes a subset of the features available in the Provisioning and

Assurance modules.

Figure 39 – Prime Collaboration

9.2.1 Features

Some of the primary features of Prime Collaboration Standard include:

Fault and performance monitoring of core Unified CM and TelePresence systems.

Performance dashboards to monitor short-term performance metric trends.

Real-time dashboards for cluster status and alarm browser to display faults.

Ability to provision devices telepresence devices including Jabber.

9.2.2 Ports

The following tables lists the required ports for the Prime Collaboration Provisioning server to

communicate with the devices and applications.



Source Destination

HTTP/Apache Web Server TCP/80 Prime Collaboration Unified CM Cluster

HTTPS TCP/8443 Prime Collaboration Unified CM Cluster

SSH TCP/22 Prime Collaboration Unified CM Cluster

Telnet TCP/23 Prime Collaboration Unified CM Cluster

The following ports are used by the Prime Collaboration Provisioning servers to communicate either

with the client machine.


Source Destination

To communicate with the client machine over HTTP. TCP/80 Client Browser Prime Collaboration

To connect to the Provisioning server from the client machine over HTTPS.

TCP/443 Client Browser

Prime Collaboration

To connect to the Provisioning server from the client machine over SSH.

TCP/22 Client

Prime Collaboration


Since Prime Collaboration is a management utility, there is no expectation that the environment will be

redundant, a single instance will be deployed.

For Cisco Prime Collaboration Provisioning, simplified sizing guidance covers deployments with up to

150,000 devices, we will be deploy based on an environment size of less than 3000 devices (Small) and

less than 5,000 users.19


Cisco Prime Collaboration < 3000 Devices 1



Software Version

Cisco Prime Collaboration Provisioning 12.2

9.2.3.2 Hardware



Supported versions of vSphere ESXi include 4.x, 5.x, 6.x

19 http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/collaboration/system_capacity/System_Capacity_for_Cisco_Prime_Collaboration_Provisioning_12_1.html 20 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-

hardware.html#processor


This deployment is based on the Small21 deployment model (3000 or less devices)

Server Node vCPU vRam vDisk vNIC

ucovpcpc1 1 2 GB 90 GB 1


Cisco Prime Collaboration Standard does not require a license, it is included with Unified Workspace

Licensing (UWL) and User Connect Licensing (UCL) for Cisco Unified Communications.

21 http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-prime-collaboration-

provisioning.html


10 Endpoints Module Component Description

Endpoints IP Phones, Telepresence Video Endpoints, Jabber Enable real-time voice, video, and instant messaging for users.

IP Phones, Jabber clients, and TelePresence video endpoints use SIP to register directly to Cisco Unified

CM. The Unified CM cluster’s failover mechanism provides endpoint registration redundancy.

Just a small list of representative end points include:

Endpoint Description

IP Phone Physical of Soft IP Phones

Cisco Endpoints Variety of Telepresence and Video endpoints

Jabber Soft client with integrated voice, video, voicemail, instant messaging and presence.

10.1 Traditional Endpoints Traditional endpoints include telepresence systems such as the Cisco DX80 or Polycom devices. These

endpoints must be configured to take advantage of the redundant TFTP nodes configured within the

Unified CM environment. When configuring TFTP options using DHCP or statically, define a TFTP

subscriber node IP address array containing the IP addresses of both TFTP subscriber nodes.

When configuring these options (DHCP scope or manually configuring endpoints) assign half of the

endpoint devices to use the first TFTP subscriber (ucovpscucm2 – CUCM Subscriber at OCIO) as the

primary, and the other TFTP subscriber (ucavpscucm1 – CUCM subscriber at Allandale) as the secondary,

and then reverse the other half. In addition to providing redundancy, this will also distribute endpoints

across the TFTP subscribers providing a level of load balancing.

10.2 Jabber Reference Documentation

Planning Guide for Cisco Jabber 11.8 http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_8/cjab_b_planning-guide-jabber-118.html

Cisco Jabber is personal telepresence for mobile, remote, and extended teams and allows you to find

people, see if and how they are available, and chat and collaborate using your preferred method. Jabber

can be deployed on Windows, iPhone and Android devices.

Cisco Jabber lets you access presence, instant messaging (IM), voice, video, voice messaging, desktop

sharing, and conferencing from wherever you need to work — the airport, hotel, coffee shop, or home

office. It keeps you connected with your entire telepresence community, no matter where you are.

Jabber features include:

Instant Messaging (IM)

Presence - Allows you to see if a contact is available via Jabber, on the phone or in a meeting.

Video Conferencing - Video phone integrated with CDU video conferencing systems (compatible

to all standards based video conferencing systems anywhere on the internet)


Desktop sharing - Allow your colleagues to see what you are seeing on your computer and allow

them to interact with what they are seeing.

File Sharing

10.2.1 User Identification

Figure 40 - Jabber ID

Users are identified by their Jabber ID or JID. This is a combination of their

User ID as defined in the Cisco Unified Communications Manager, and the

domain.

If the Jabber ID is the same as their email address then the Jabber Client will automatically provide

presence information to the Outlook client in the form of colour coding: Green, they are online, Yellow,

a meeting, etc.

10.2.2 Discovery and DNS

DNS is particularly important for the proper functioning of Jabber. When the client is started, and you

enter your JID, then Jabber will use the domain portion of the address to resolve the service type,

whether it be on the local corporate network or via the internet.

When a client queries a name server, it sends separate, simultaneous requests to the name server for

the following SRV records in the order presented below:

1. _cisco-uds

2. _cuplogin

3. _collab-edge

Based on what the name server returns, the client will connect to the following:

Name Server Returns Client’s Response

_cisco-uds Detects it is inside the corporate network and connects to Cisco Unified Communications Manager

_cuplogin Detects it is inside the corporate network and connects to Cisco Unified Presence

_collab-edge Client attempts to connect to the internal network through Expressway Mobile and Remote Access

Once the service discovery has completed, then Jabber will cache the information and use that for

future logon. If at a later time, the login fails, then service discovery will be triggered again.



Port

Application Layer Protocol

Transport Layer Protocol

Description

Configuration 53 DNS UDP Hostname resolution.

3804 CAPF TCP

Issues Locally Significant Certificates (LSC) to IP phones. This port is the listening port for Cisco Unified Communications Manager Certificate Authority Proxy Function (CAPF) enrollment.

6970 HTTP TCP Connect to the TFTP server to download client configuration files.

6972 HTTPS TCP Connects to the TFTP server to download client configuration files securely for Cisco Unified Communications Manager release 11.0 and later.

8191 SOAP TCP Connects to local port to provide Simple Object Access Protocol (SOAP) web services.

8443 HTTPS TCP Traffic to Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence Service.

Communication Manager Signaling 2748 CTI TCP

Computer Telephony Interface (CTI) used for desk phone control.

5060 SIP TCP Provides Session Initiation Protocol (SIP) call signaling.

5061 SIP over TLS TCP SIP over TCP Provides secure SIP call signaling. (Used if Secure SIP is enabled for device.)

5070-6070 BFCP UDP Binary Floor Control Protocol (BFCP) for video screen sharing capabilities.

30000-39999 FECC UDP Far end camera control (FECC).

Instant Messaging and Presence

443 XMPP TCP

XMPP traffic to the WebEx Messenger service. The client sends XMPP through this port in cloud-based deployments only. If port 443 is blocked, the client falls back to port 5222.

5222 XMPP TCP

Connects to Cisco Unified Communications Manager IM and Presence Service for instant messaging and presence.

7336 HTTPS TCP MFT File transfer (On-Premises only).

37200 SOCKS5

Bytestream

TCP Peer to Peer file transfer, In on-premises deployments, the client also uses this port to send screen captures.

Voice or Video Media Exchange

16384-32766 RTP/SRTP UDP Cisco Unified Communications Manager media port range used for audio, video, and BFCP video desktop share.

45130-45230 see 10.2.3.1 below

(49152-65535) RDP TCP

IM-only desktop share. Applies to Cisco Jabber for Windows only.


10.2.3.1 Port Range Limits

The default range of ports for screen and file sharing within the Jabber client is defined system wide and

includes all ports from 49152 to 65535.

From a security standpoint, this is a large range to open up through firewalls, so the security groups

have requested that the port range be limited. This port range can be limited via the parameters defined

in the table below.

Parameter Definition

SharePortRangeStart

This parameter is used with SharePortRangeSize to specify a port range to use when users share their screen from a chat window. If you do not configure these parameters, then the client uses the default port range for IM screen share, 49152 to 65535. For more information on default port ranges, see the topic on Ports and Protocols in the Cisco Jabber Planning Guide. The value you enter specifies the start of the port range. The minimum value is 1024. The value cannot exceed 65535 minus the SharePortRangeSize.

SharePortRangeSize Specifies the size of the port range, when used with the SharePortRangeStart parameter. The minimum value is 40. The value when added to the SharePortRangeStart parameter cannot exceed 65535

Add the following to the jabber-config.xml file.

<Policies>

<SharePortRangeStart>45130</SharePortRangeStart>

<SharePortRangeSize>1000</SharePortRangeSize>

</Policies>


11 Backup & Disaster Recovery Since the environment is being architected in a redundant fashion across two data centers with network

links by two providers, availability should be assured. Even so, it is prudent to ensure the environment is

backed up on a regular basis in the event of a failure.

With no central Cisco backup solution, different backup methods must be used for different portions of

the environment.

Purpose Backup Procedure

CUCM Backup Schedule Much of the environment configurations are static and backup procedures require manual intervention, so for this reason, backups will be performed for portions of this environment in an ad-hoc manner after configuration changes have been performed.

Purpose Backup Schedule

Unified Communications Manager Daily

Instant Messaging & Precence

VCS Control Ad-hoc: As required after configuration changes VCS Expressway

Telepresence Management Server

Daily

Cisco Disaster Recovery System (DRS)

IM & P

VCS Control Error! Reference source not found.

VCS Expressway

Telepresence Management Server Cisco Telepresence Management Server

Cisco Meeting Server TBD – Procedure will be added once environment is available

Cisco Prime Collaboration TBD – Procedure will be added once environment is available

11.1 Pre-Requisite

An SFTP is required as a destination for the backups from the Cisco Disaster Recovery System (DRS).

Cisco allows you to use any SFTP server product with applications that require SFTP access but

recommends SFTP products that are certified with Cisco through the Cisco Technology Developer

Partner program (CTDP).

In our configuration, we will host the SFTP service on the Telepresence Management Server (pthtmsb1)

which will be backed up on a regular schedule using the corporate backup service.


11.1.1 Configure SFTP Service

For the NLCHI Cisco UCM environment we are using the application ‘freeFTPd22’, which is a product

installed previously by a visiting consultant.

Once the software is running, configure the ‘SFTP’ server’s listening address and root destination

directory.

Parameter Value

Listen Address TBD

Port 22

SFTP Root Directory C:\UC-Backups

Table 9 - freeFTPd SFTP Settings

Figure 41 - freeFTPd: Configure SFTP Settings

Then create a user that CUCM will use for delivering the backup configuration files.

Parameter Value

Login uc-backup

Authorization Password stored as SHA1 hash

Password <Enter Password>

Home directory C:\UC-Backups

User can access SFTP Server

Table 10 - freeFTPd Configuration Parameters

22 http://www.freesshd.com/


11.2 Backup Schedule Much of the environment configurations are static and backup procedures require manual intervention,

so for this reason, backups will be performed for portions of this environment in an ad-hoc manner after

configuration changes have been performed.

Purpose Backup Schedule

Unified Communications Manager Daily

Instant Messaging & Precence

VCS Control Ad-hoc: As required after configuration changes

VCS Expressway

Telepresence Management Server Daily

11.3 Cisco Disaster Recovery System (DRS) DRS provides full data backup and restore capabilities for servers in a Cisco Unified Communications

Manager (CUCM) cluster. DRS allows you to perform regularly scheduled automatic or user-invoked data

backups. DRS performs a cluster-level backup, which means that it collects backups for all servers in a

CUCM cluster to a central location and archives the backup data to physical storage device or a secure

FTP server (shown configured above).

The table below show the systems backed up by the DRS system.

Component Host

Unified Communications Manager ucovpscucm1 ucovpscucm2 ucavpscucm1

Instant Messaging & Presence ucovpsimp1


ucavpscimp1

Table 11 - DRS Managed Servers

Caution: 1. DRS only supports matching versions of Cisco Unified Communications Manager for restore. The

version of the backup must match the new server on which you will be restoring.

2. Before you restore Cisco Unified Communications Manager, ensure that the hostname, IP address, DNS configuration, version, and deployment type of the restore matches the hostname, IP address, DNS configuration, version, and deployment type of the backup file that you want to restore.

Log in to the Disaster Recovery System with the same administrator username and password that you

use for Cisco Unified OS Administration or IM and Presence OS Administration.

11.3.1 Backup Procedures

The backup procedures provided in this section apply to the following components:

Host Purpose IP

ucovpscucm1 Unified Communications Manager TBD

ucovpscucm2 Unified Communications Manager TBD

ucavpscucm1 Unified Communications Manager TBD

ucovpsimp1 Instant Messaging & Presence TBD

ucavpsimp1 Instant Messaging & Presence TBD


11.3.1.1 DRS Menu

The DRS menu provides the ability to Backup or Restore a copy of the Cisco UCS environment. In a new

environment, the first task is to configure the backup device and once that has completed, next would

be to schedule regular backups.

11.3.1.2 Configure Backup Device

With no previous backup device configured, create a new Backup Device. From the Backup Device List

page, select ‘Add New’:

Figure 42 - DRS: Add New Backup Device

Use the parameters as shown in the table below. The host, user name and password are the same as

were configured in Error! Reference source not found. Error! Reference source not found..

Parameter Value

Backup Device Name sFTP-Backup

Host name/IP address TBD

Path name /cucm

User name uc-backup

Password <Enter Password>

C:\UC-Backups


Table 12 - DRS Backup Device Configuration Parameters

The configured backup device will then look the same as Figure 43 - DRS: Backup Device below. In this

instance, we are using an IP address because the DNS entries have yet to be created, however when the

system is in full production, a fully resolvable DNS entry will be used rather than an IP.

Figure 43 - DRS: Backup Device

When the Backup Device has been created then it will be listed in the ‘Backup Device List’ and can be

edited if necessary.

11.3.1.3 Schedule Regular Backups

Next, create the backup schedules, of which there can be up to fourteen backup. Each backup schedule

has its own set of properties, including a schedule for automatic backups, the set of features to back up,

and a storage location.

From the scheduler window the features available to backup are:


Figure 44 - DRS Scheduler Selectable Features

These meaning of these features are below in Table 13 - DRS: Scheduler Features.

UCM Unified Communications Manager

CDR_CAR Call Detail Records

PLM Prime License Manager

IM_AND_PRESENCE Instant Messaging & Presence

Table 13 - DRS: Scheduler Features

To create a new schedule click ‘Add New’:

Figure 45 - Schedule List: Add New

A long scheduler window will be brought up as shown below, though for brevity some of the registered

components have been removed as these are selectable only through the ‘Select Features’ section.


…

11.3.1.3.1 Daily Backups

To create a daily backup schedule for the environment, enter the values from Table 14 - DRS: Daily

Backup Schedule into the Scheduler window.

Parameter Value


Schedule Name Daily

Device Name sFTP-Backup

Select Features <Select all features>

Start Backup at <Indicate a time for backups to start, eg. 1-May-2017 at 2330>

Frequency Daily

Table 14 - DRS: Daily Backup Schedule

Save and Enable the schedule to complete, and it will be then available in the ‘Schedule List’ window

showing the status as ‘Enabled’


Figure 46 - DRS: Schedule List

11.3.1.4 Backup History

Once backups have been scheduled and have run, you can verify they have run successfully from

‘History’ :

This will bring up a log file of when the last backups were completed and the Result.

Figure 47 - DRS: Backup History

11.3.2 VCS Control & VCS Expressway

The same procedure is used for each of Cisco Telepresence Video Communication Server Control and

Telepresence Video Communication Server Expressway.

The data included in the backup are:

system configuration settings

clustering configuration


security certificates

administrator account details

Log files are not included in the backup files

First navigate, via web browser to the server using its IP address from the table below and log in as the

‘admin’ user.

Server Telepresence Component IP Address

ucovpzvcse1 VCS Expressway TBD

ucavpzvcse1 VCS Expressway TBD

ucovpsvcsc1 VCS Control TBD

ucavpsvcsc1 VCS Control TBD

Figure 48 - Telepresence Login

Navigate to ‘Maintenance -> Backup and restore’

Figure 49 - Backup and Restore

Then under ‘Backup and restore’ select ‘Create system backup file’. The encryption password is optional

and in our deployment we will not use this option. The screen scrapes below show the current Software

Version of the deployed software.


Figure 50 - VCS Control: Backup

Figure 51 - VCS Expressway: Backup

Save the resulting file to the secure location located on the Backup Repository server:

Telepresence Component File Location

Video Communication Server Control C:\UC-Backups\Cisco Telepresence VCS Control

Video Communication Server Expressway C:\UC-Backups\Cisco Telepresence VCS Expressway

Figure 52 - Backup Locations


11.4 Cisco Telepresence Management Server

11.4.1 Cisco Telepresence Server

Server Telepresence Component IP Address

ucovpstms1 Telepresence Management Suite TBD

ucavpstms1 Telepresence Management Suite TBD

First navigate, via web browser to the primary TMS server using its IP address from the table above and

log in as the ‘admin’ user.

Then navigate to the Systems -> Configuration Backup -> Perform Backup menu item.

Figure 53 - TMS Configuration Backup

Next, select what needs to be backed up – normally, this will be via the ‘All Systems’ folder view.


Figure 54 - TMS Perform Backup

Select ‘All Systems’ and click on ‘Make Backup’ and it will back up the TMS data within the TMSNG SQL

database. Once this is complete, dump the database to a file using ‘sqlcmd’ so it can be backed up with

the corporate backup service.

The destination provided should have sufficient space for the backup. Execute the commands from the

TMS server command prompt:

Backup Commands:

C:\UC-Backups\Cisco Telepresence Management Suite>sqlcmd -S

(local)\SQLEXPRESS -E -Q "BACKUP DATABASE tmsng TO DISK='C:\UC-

Backups\Cisco Telepresence Management Suite\tmsng.bak'"


C:\UC-Backups\Cisco Telepresence Management Suite>sqlcmd -S

(local)\SQLEXPRESS -E -Q "BACKUP DATABASE tmspe TO DISK='C:\UC-

Backups\Cisco Telepresence Management Suite\tmspe.bak'"

Once executed, you will be presented with a message indicating the success (or failure) of the backup,

and the files will be located in the indicated directory and ready for normal server backup.


Appendix A Server Requirements The following provides a summation of the server requirements of the HA Collaboration Environment.

A.1 VCS Expressway

Server Node Location vCPU vRam vDisk vNIC

ucovpzvcse1 OCIO 2 6 GB 132 GB 2

ucavpzvcse1 Allandale 2 6 GB 132 GB 2

A.2 VCS Control




A.3 Cisco Meeting Server

A.3.1 Edge Components




A.3.2 Core Components


ucovpzvcsc1 OCIO 18 22 GB 100 GB 1

ucovpzvcsc2 OCIO 6 10 GB 100 GB 1

ucavpzvcsc1 Allandale 18 22 GB 100 GB 1

A.4 Cisco Unified Communications Manager


ucovpscucm1 OCIO 2 6 GB 80 GB 1

ucovpscucm2 OCIO 2 6 GB 80 GB 1

ucavpscucm1 Allandale 2 6 GB 80 GB 1

A.5 Cisco Instant Messaging & Presence

Server Node Location vCPU vRam vDisk vNIC (1Gb)

ucovpsimp1 OCIO 2 4 GB 2 x 80 GB 1

ucavpscimp1 Allandale 2 4 GB 2 x 80 GB 1


A.6 Cisco Telepresence Management Suite

Server Node Location vCPU vRam vDisk vNIC (1Gb)

ucovpstms1 OCIO 6 24 GB 300 GB 1

ucavpstms1 Allandale 6 24 GB 300 GB 1

A.7 Cisco Prime Collaboration


ucovpcpc1 OCIO 1 2 GB 90 GB 1


Appendix B Licensing The following provides a summation of the licensing requirements of the HA Collaboration Environment.

B.1 VCS


Virtual VCS Expressway 1

Virtual VCS Control 1

Traversal23 Calls 20

Non-Traversal Calls 100

Registering Endpoints 500

B.2 Cisco Meeting Server



The following activation keys are required to use the Cisco Meeting Server and are included with

the software.

Component Note

Call Bridge If you are deploying a cluster of Call Bridges you require a license file for each Call Bridge in the cluster.

XMPP License Activation Key – included in the software.

B.3 Cisco Unified Communications Manager

Unified CM does not require a server license or software version license. However, individual users

require licenses to use and connect to the environment.


User Connect Licensing Enhanced 250

User Connect Licensing Enhanced+ 250

B.4 Cisco IM & Presence

The IM and Presence Service does not require a server license or software version license. However,

you must assign users and enable the IM and Presence Service for each assigned user.

23 A traversal call is one that ‘traverses’ or travels through the firewall from, for example, inside the network to outside the network.


B.5 Cisco Telepresence Management Suite

Only one live database can be used in a redundant implementation therefore both servers will use

the same TMS serial number and the same set of release and option keys.


Cisco Telepresence Management Suite 1

Microsoft Windows Server 2012 or later 2

Microsoft SQL Server 2012 or later 2

B.6 Cisco Prime Collaboration

Cisco Prime Collaboration Standard does not require a license, it is included with Unified Workspace

Licensing (UWL) and User Connect Licensing (UCL) for Cisco Unified Communications.


Appendix C Lab Environment The production environment’s primary use is Telehealth and as such its availability cannot be

compromised. An identical single instance environment will be deployed with the minimum

requirements to ensure proper functioning and duplication of production.

Figure 55 - Collaboration Lab Environment

C.1 VCS

C.1.1 Hardware


VCS Expressway ucovtzvcse1 2 4 GB 132 2

VCS Control ucovtzvcsc1 2 4 GB 132 2

C.1.2 Software & License Requirements


Virtual VCS Expressway (incl. 5 Traversal) 1

Virtual VCS Control (incl. 100 Traversal, 10 Non-Traversal) 1

C.1.3 Network


VCS Expressway

ucovtzvcse1






VCS Control ucovtzvcsc1 Semi-Trust TBD /28

C.2 Unified CM and IM & Presence

C.2.1 Hardware


Unified CM ucovtscucm1 2 4 GB 80 1

IM & Presence ucovtsimp1 1 2 GB 80 2

C.2.2 Software & Licensing Requirements


Unified CM 1

IM & Presence 1

UCL Enhanced License 5

C.2.3 Network


Unified CM ucovtscucm1 Semi-Trust TBD /28

IM & Presence ucovtsimp1 Semi-Trust TBD /28

C.3 Cisco Meeting Server

C.3.1 Hardware


CMS Edge ucovtzcmse1 4 4 GB 100 1

CMS Core ucovtscmsc1 4 4 GB 100 2



Cisco Meeting Server 1


C.3.3 Network


CMS Edge ucovtzcmse1




CMS Core ucovptcmsc1 Semi-Trust TBD /28


C.4 Telepresence Management Suite & LDAP

C.4.1 Hardware


TMS ucovtstms1 2 8 GB 250 1



Telepresence Management Suite (incl. 10 systems) 1

Microsoft Windows Server 2012 1

Microsoft SQL Server 2012 or 2014 1

C.4.3 Network


TMS ucovtstms1 Semi-Trust TBD /28

C.5 Prime Collaboration

C.5.1 Hardware


Prime Collaboration

ucovtscpc1 1 4 GB 100 1




Cisco Prime Collaboration (license included with UCL license above) 5

C.5.3 Network


TMS ucovtcpc1 Semi-Trust TBD /28


Appendix D WebRTC WebRTC is an open project (https://webrtc.org/) that provides browsers and mobile applications with

Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been

optimized to enable rich, high-quality RTC applications to be developed for the browser, mobile

platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others. This page is

maintained by the Google Chrome team.

Cisco Meeting Server Support:

Browser Version Notes

Chrome >= 28 >= 33 is required for screen sharing

>= 37 screen sharing is disabled by default, but Cisco has an extension to enable it.

Firefox >= 25.0.1

Opera Not Officially Supported

Internet Explorer

NOT SUPPORTED

https://webrtc.org/


Appendix E Glossary Term Definition

Access Control List (ACL) List that defines rights and permissions to access system functions and resources. See Method List.

Authentication Process that verifies the identity of the communicating entity.

Authorization

Process that specifies whether an authenticated user, service, or application has the necessary permissions to perform a requested action; in Cisco Unified Communications Manager, the security process that restricts certain trunk-side SIP requests to authorized users.

Authorization Header A SIP user agent response to a challenge.

Certificate

A message that contains the certificate holder name, the public key, and the digital signature of the certificate authority that is issuing the certificate.

Certificate Authority (CA) Trusted entity that issues certificates: Cisco or a third-party entity.

Certificate Authority Proxy Function (CAPF)

Process by which supported devices can request locally significant certificates by using Cisco Unified Communications Manager Administration.

Certificate Trust List (CTL)

A file, which is created either with the CLI command set utils cli or with the CTL Client and signed by the Cisco Site Administrator Security Token (security token), that contains a list of certificates for servers that the phone is to trust.

Challenge In digest authentication, a request to a SIP user agent to authenticate its identity.

Cisco Site Administrator Security Token (security token; etoken)

A portable hardware security module that contains a private key and an X.509v3 certificate that the Cisco Certificate Authority signs; used for file authentication, it may be used to sign the CTL file.

Device Authentication Process that validates the identity of the device and ensures that the entity is what it claims to be before a connection is made.

Digest Authentication

A form of device authentication where an MD5 hash of a shared password (among other things) gets used to establish the identity of a SIP user agent.

Digest User User name that is included in an authorization request that phones that are running SIP or SIP trunks send.


Digital Signature

Value that is generated by hashing the message and then encrypting the message with the private key of the signer; the recipient decrypts the message and the hash with the signer public key, produces another hash with the same hash function, then compares the two hashes to ensure that the messages match and the content is intact.

Endpoint An endpoint is the device the user interacts with, it can be IP phones to web, mobile, and desktop clients.

File Authentication

Process that validates digitally signed files that the phone downloads. The phone validates the signature to make sure that file tampering did not occur after the file creation.

H.323 An internet standard that defines a common set of codecs, call setup and negotiating procedures, and basic data transport methods.

Image Authentication Process whereby a phone validates the integrity and source of a binary image prior to loading it on the phone.

Integrity Process that ensures that data tampering did not occur between entities.

IPSec Transport that provides secure H.225, H.245, and RAS signaling channels for end-to-end security.

Locally Significant Certificate (LSC)

A digital X.509v3 certificate that CAPF issues; installed on the phone or JTAPI/TAPI/CTI application.

Manufacture Installed Certificate (MIC)

A digital X.509v3 certificate that is signed by the Cisco Certificate Authority and installed in supported phones by Cisco Manufacturing; used as the authentication mechanism to CAPF when LSCs are installed in phones.

Man-in-the-Middle Attacks Process that allows an attacker to observe and modify the information flow between Cisco Unified Communications Manager and the phone.

Multipoint Control Unit (MCU)

A flexible system to connect multiple H.323 endpoints and allow multiple users to participate in IP-based video conferences.

MD5 A hash function that is used with encryption.

Media Encryption

Process whereby the confidentiality of the media is protected with cryptographic procedures. Media encryption uses Secure Real-Time Protocol (SRTP) as defined in IETF RFC 3711.

Message/Data Tampering Event when an attacker attempts to alter messages in transit, including ending a call prematurely.


Mixed Mode

Cisco Unified Communications Manager security mode that you configure to allow devices with secure/nonsecure profiles and RTP/ SRTP media to connect to Cisco Unified Communications Manager.

Nonce A unique, random number that the server generates for each digest authentication request; used to generate an MD5 hash.

Nonsecure Mode

Cisco Unified Communications Manager security mode that you configure to allow devices with nonsecure profiles and RTP media to connect to Cisco Unified Communications Manager.

Nonsecure Call Call in which at least one device is not authenticated or encrypted.

Nonsecure Device Device that uses UDP or TCP signaling and nonsecure media.

PKI

Public key infrastructure, which comprises the set of elements that is needed for public key encryption, including secure public key distribution, certificates, and certificate authorities.

Public / Private key

Keys that are used in encryption. Public keys are widely available, but private keys are held by their respective owners. Asymmetrical encryption combines both types.

Replay Attack

Event when an attacker captures information that identifies a phone or proxy server and replays information while pretending to be the actual device; for example, by impersonating the proxy server private key.

RTP Real-Time Transport Protocol

Simple Certificate Enrollment Protocol (SCEP)

A protocol that is used to communicate with a certificate authority that issues X.509 certificates.

Secure Call Call in which all devices are authenticated, signaling is encrypted, and the media (voice stream) is encrypted.

Signaling Authentication TLS process that validates that no tampering occurred to signaling packets during transmission.

Signaling Encryption

Process that uses cryptographic methods to protect the confidentiality of all signaling messages that are sent between the device and the Cisco Unified Communications Manager server.

SIP Realm A string (name) that Cisco Unified Communications Manager uses to respond to a challenge.

SRTP Secure Real-Time Transport Protocol that secures voice conversation in the network and provides protection against replay attacks.


SSL A cryptographic protocol that secures data communications such as e-mail on the Internet; equivalent to TLS, its successor.

Transport Layer Security (TLS)

A cryptographic protocol that secures data communications such as e-mail on the Internet; functionally equivalent to SSL.

Trust List Certificate list without digital signatures.

Trust Store A repository of X.509 certificates that an application, such as Cisco Unified Communications Manager, explicitly trusts.

X.509 An ITU-T cryptographic standard for importing PKI certificates, which includes certificate formats.


Appendix F Acronyms Term Definition

CMS Cisco Meeting Server

CUCM Unified CM

Cisco Unified Call Manager

VCS Video Communication Server