request for proposals 2018-005 - nlchi · 12/01/2018 · request for proposals 2018-005 telehealth...
TRANSCRIPT
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;
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.
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.
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
Internal or External
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
Internal or External
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.6 Certificate Requirements .................................................................................................... 38
7.2.7 System Time ........................................................................................................................ 39
7.2.8 Deployment Requirements ................................................................................................. 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.1.7 Deployment Requirements ................................................................................................. 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.8 Deployment Requirements ................................................................................................. 55
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.3.10 Certificate Requirements .................................................................................................... 68
8.3.11 Deployment Requirements ................................................................................................. 69
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
8.4.4 Deployment Requirements ................................................................................................. 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
9.1.4 Deployment Requirements ................................................................................................. 77
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
9.2.3 Deployment Requirements ................................................................................................. 80
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.2 Software & Licensing Requirements ................................................................................. 106
C.3.3 Network ............................................................................................................................ 106
C.4 Telepresence Management Suite & LDAP ................................................................................ 107
C.4.1 Hardware........................................................................................................................... 107
C.4.2 Software & Licensing Requirements ................................................................................. 107
C.4.3 Network ............................................................................................................................ 107
C.5 Prime Collaboration .................................................................................................................. 107
C.5.1 Hardware........................................................................................................................... 107
C.5.2 Software & Licensing Requirements ................................................................................. 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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 9
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 10
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 11
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
Purpose Server Node vCPU vRam vDisk vNIC
Unified CM ucovtscucm1 2 4 GB 80 1
IM & Presence ucovtsimp1 1 2 GB 80 2
A.2.2 Software & Licensing Requirements
Description Quantity
Unified CM 1
IM & Presence 1
UCL Enhanced License 5
A.2.3 Network
Purpose Hostname Zone IP Address Mask Bits
Unified CM ucovtscucm1 Semi-Trust TBD /28
IM & Presence ucovtsimp1 Semi-Trust TBD /28
A.3 Cisco Meeting Server
A.3.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
CMS Edge ucovtzcmse1 4 4 GB 100 1
CMS Core ucovtscmsc1 4 4 GB 100 2
A.3.2 Software & Licensing Requirements
Description Quantity
Cisco Meeting Server 1
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 12
Shared Multiparty License 1
A.3.3 Network
Purpose Hostname Zone IP Address Mask Bits
CMS Edge ucovtzcmse1
DMZ – Internal TBD /28
DMZ - External TBD /29
DMZ – Public NAT TBD /29
CMS Core ucovptcmsc1 Semi-Trust TBD /28
A.4 Telepresence Management Suite & LDAP
A.4.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
TMS ucovtstms1 2 8 GB 250 1
A.4.2 Software & Licensing Requirements
Description Quantity
Telepresence Management Suite (incl. 10 systems) 1
Microsoft Windows Server 2012 1
Microsoft SQL Server 2012 or 2014 1
A.4.3 Network
Purpose Hostname Zone IP Address Mask Bits
TMS ucovtstms1 Semi-Trust TBD /28
A.5 Prime Collaboration
A.5.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
Prime Collaboration
ucovtscpc1 1 4 GB 100 1
A.5.2 Software & Licensing Requirements
Description Quantity
Description Quantity
Cisco Prime Collaboration (license included with UCL license above) 5
A.5.3 Network
Purpose Hostname Zone IP Address Mask Bits
TMS ucovtcpc1 Semi-Trust TBD /28
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 13
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 14
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 15
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 16
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 17
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 18
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 19
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 20
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.
Module Component Description
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 21
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 22
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 23
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 24
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 25
2. DNS round-robin
On each H.323 endpoint configure the Gatekeeper Settings as:
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
On each H.323 endpoint configure the Gatekeeper Settings as:
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 26
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
LAN Extension (Circuit #118501)
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
Module Component Description
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 27
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 28
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 29
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.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
SRC Port DST Port Protocol SRC DST Description
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).
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 30
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.
SRC Port DST Port Protocol SRC DST Description
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
SRC Port DST Port Protocol SRC DST Description
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 31
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
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 32
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
SRC Port DST Port Protocol SRC DST Description
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.
SRC Port DST Port Protocol SRC DST Description
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 33
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 34
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 35
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
Server Node vCPU vRam vDisk vNIC (1Gb)
ucovpzvcse1 2 6 GB 132 2
ucavpzvcse1 2 6 GB 132 2
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 36
7.1.6.5 Licensing Requirements
Description Quantity
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
VCS-E: N/A VCS-C: Traversal
VCS-E: N/A VCS-C: Traversal
VCS-E: N/A VCS-C: Non-
Traversal
VCS-C Registered:
SIP
Both: Traversal
VCS-E: N/A VCS-C: Traversal
VCS-E: N/A VCS-C: Non-
Traversal
VCS-E: N/A VCS-C: Non-
Traversal
VCS-E: N/A VCS-C: Non-
Traversal
VCS-E: N/A VCS-C: Non-
Traversal
Jabber Internal
(SIP)
Both: Traversal
VCS-E: N/A VCS-C: Traversal
VCS-E: N/A VCS-C: Non-
Traversal
Jabber MRA (SIP)
Both: Traversal
VCS-E: N/A VCS-C: Traversal
VCS-E: N/A VCS-C: Non-
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 37
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 38
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 39
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 40
7.2.4 Turn Server - Firewall Ports
Internet
OC
IOA
lla
nd
ale
Endpoint - Firewall Traversal
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 41
7.2.5.2 Web Bridge - Required Application Ports
Internet
OC
IOA
lla
nd
ale
Endpoint - Firewall Traversal
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
7.2.6 Certificate Requirements Reference Documentation
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 42
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
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.2.8 Deployment Requirements
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
7.2.8.1 Software Version
As of this document, the current deployable version is:
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 43
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
Server Node vCPU vRam vDisk vNIC (1Gb)
ucovpzvcse1 8 8 GB 100 2
ucavpzvcse1 8 8 GB 100 2
7.2.8.3 Licensing Requirements
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 44
8 Core Services
LAN Extension (Circuit #118501)
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
LAN Extension (Circuit #118501)
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
Module Component Description
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 45
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 46
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 47
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 48
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 49
From (Sender) To (Listener) Port Description
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 50
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 51
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 52
8.1.6 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.
8.1.7 Deployment Requirements
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
8.1.7.1 Software Version
As of this document, the current deployable version is:
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
8.1.7.3 Licensing Requirements
Unified CM does not require a server license or software version license. However, individual users
require licenses to use and connect to the environment.
Description Quantity
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 53
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 54
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 55
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 56
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 57
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
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 58
8.2.8 Deployment Requirements
For IM and Presence, simplified sizing guidance covers deployments with up to 15,000 users or 15,000
logged-in Jabber endpoints.
Software Deployment Size Nodes to be Deployed
IM & Presence Less than 5,000 users or logged in
Jabber endpoints One IM & Presence Pair using the
5k-user OVA template
8.2.8.1 Software Version
As of this document, the current deployable version is:
Software Version
Unified CM IM and Presence 11.5
8.2.8.2 Hardware
IM&P will be deployed as a virtual appliance via OVA files supplied by Cisco.
Supported versions of vSphere ESXi include 5.0 U1, 5.1, 5.5, and 6.0
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.
Server Node vCPU vRam vDisk vNIC (1Gb)
ucovpsimp1 2 4 GB 2 x 80GB 1
ucavpscimp1 2 4 GB 2 x 80GB 1
8.2.8.3 Licensing Requirements
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 59
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:
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 60
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 61
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 62
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 63
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 64
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
Cisco Meeting Server
ODC_CUCM
OCIO
ODC_CMS
SIP
Tru
nk
Unified
Communications
Manager
Cisco Meeting Server
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 65
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
Source Destination Note
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 66
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 67
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 68
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 69
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 70
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 71
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
Source Destination Note
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
Source Destination Note
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
8.3.10 Certificate Requirements Reference Documentation
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 72
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
8.3.11 Deployment Requirements
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
8.3.11.1 Software Version
As of this document, the current deployable version is:
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.
Server Node vCPU vRam vDisk vNIC (1Gb)
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
8.3.11.3 Licensing Requirements
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 73
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.
Description Quantity
Shared Multiparty License 4
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 74
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 75
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 76
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
From (Sender) To (Listener) Port Description
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
8.4.4 Deployment Requirements
The Active Directory environment will co-exist with the TMS server and thus the resources are accounted for there.
8.4.4.1 Software Version
Software Version
(Minimum) Microsoft Windows Server 2012 R2
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 77
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 78
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 79
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.
9.1.2 Firewall Ports
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 80
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.
9.1.4 Deployment Requirements
For Cisco TelePresence Management Suiter (TMSXE), simplified sizing guidance covers deployments with
up to 10,000 users.
Software Deployment Size Nodes to be Deployed
Cisco TMS 500 Endpoints 2
9.1.4.1 Software Version
As of this document, the current deployable version is:
Software Version
Cisco Telepresence Management Suite (TMS) 15.5
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 81
9.1.4.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 higher17
Supported versions of vSphere ESXi include 5.0 U1, 5.1, 5.5, and 6.0
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
9.1.4.3 Licensing Requirements
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.
Description Quantity
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 82
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 83
Purpose Destination Port
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.
Purpose Destination Port
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
9.2.3 Deployment Requirements
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
Software Deployment Size Nodes to be Deployed
Cisco Prime Collaboration < 3000 Devices 1
9.2.3.1 Software Version
As of this document, the current deployable version is:
Software Version
Cisco Prime Collaboration Provisioning 12.2
9.2.3.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 higher20
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 84
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
9.2.3.3 Licensing Requirements
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 85
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)
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 86
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 87
10.2.3 Firewall Ports
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 88
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>
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 89
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 90
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/
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 91
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 92
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 93
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 94
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:
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 95
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 96
…
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 97
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’
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 98
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 99
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 100
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 101
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 102
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'"
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 103
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 104
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
Server Node Location vCPU vRam vDisk vNIC
ucovpzvcse1 OCIO 2 6 GB 132 GB 2
ucavpzvcse1 Allandale 2 6 GB 132 GB 2
A.3 Cisco Meeting Server
A.3.1 Edge Components
Server Node Location vCPU vRam vDisk vNIC
ucovpzvcse1 OCIO 8 8 GB 100 GB 2
ucavpzvcse1 Allandale 8 8 GB 100 GB 2
A.3.2 Core Components
Server Node Location vCPU vRam vDisk vNIC
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
Server Node Location vCPU vRam vDisk vNIC
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 105
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
Server Node Location vCPU vRam vDisk vNIC
ucovpcpc1 OCIO 1 2 GB 90 GB 1
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 106
Appendix B Licensing The following provides a summation of the licensing requirements of the HA Collaboration Environment.
B.1 VCS
Description Quantity
Virtual VCS Expressway 1
Virtual VCS Control 1
Traversal23 Calls 20
Non-Traversal Calls 100
Registering Endpoints 500
B.2 Cisco Meeting Server
Description Quantity
Shared Multiparty License 4
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.
Description Quantity
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 107
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.
Description Quantity
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 108
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
Purpose Server Node vCPU vRam vDisk vNIC
VCS Expressway ucovtzvcse1 2 4 GB 132 2
VCS Control ucovtzvcsc1 2 4 GB 132 2
C.1.2 Software & License Requirements
Description Quantity
Virtual VCS Expressway (incl. 5 Traversal) 1
Virtual VCS Control (incl. 100 Traversal, 10 Non-Traversal) 1
C.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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 109
Purpose Hostname Zone IP Address Mask Bits
VCS Control ucovtzvcsc1 Semi-Trust TBD /28
C.2 Unified CM and IM & Presence
C.2.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
Unified CM ucovtscucm1 2 4 GB 80 1
IM & Presence ucovtsimp1 1 2 GB 80 2
C.2.2 Software & Licensing Requirements
Description Quantity
Unified CM 1
IM & Presence 1
UCL Enhanced License 5
C.2.3 Network
Purpose Hostname Zone IP Address Mask Bits
Unified CM ucovtscucm1 Semi-Trust TBD /28
IM & Presence ucovtsimp1 Semi-Trust TBD /28
C.3 Cisco Meeting Server
C.3.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
CMS Edge ucovtzcmse1 4 4 GB 100 1
CMS Core ucovtscmsc1 4 4 GB 100 2
C.3.2 Software & Licensing Requirements
Description Quantity
Cisco Meeting Server 1
Shared Multiparty License 1
C.3.3 Network
Purpose Hostname Zone IP Address Mask Bits
CMS Edge ucovtzcmse1
DMZ – Internal TBD /28
DMZ - External TBD /29
DMZ – Public NAT TBD /29
CMS Core ucovptcmsc1 Semi-Trust TBD /28
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 110
C.4 Telepresence Management Suite & LDAP
C.4.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
TMS ucovtstms1 2 8 GB 250 1
C.4.2 Software & Licensing Requirements
Description Quantity
Telepresence Management Suite (incl. 10 systems) 1
Microsoft Windows Server 2012 1
Microsoft SQL Server 2012 or 2014 1
C.4.3 Network
Purpose Hostname Zone IP Address Mask Bits
TMS ucovtstms1 Semi-Trust TBD /28
C.5 Prime Collaboration
C.5.1 Hardware
Purpose Server Node vCPU vRam vDisk vNIC
Prime Collaboration
ucovtscpc1 1 4 GB 100 1
C.5.2 Software & Licensing Requirements
Description Quantity
Description Quantity
Cisco Prime Collaboration (license included with UCL license above) 5
C.5.3 Network
Purpose Hostname Zone IP Address Mask Bits
TMS ucovtcpc1 Semi-Trust TBD /28
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 111
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
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 112
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 113
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 114
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 115
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.
Technical Architecture Copyright © 2017 Newfoundland and Labrador Centre for Health Information Page 116
Appendix F Acronyms Term Definition
CMS Cisco Meeting Server
CUCM Unified CM
Cisco Unified Call Manager
VCS Video Communication Server