Preferred Architecture for

Enterprise Collaboration
Part 1: Call Control and Conferencing
Glen Lavers, Johannes Krohn, Ken Wong
BRKCOL-2420
Preferred Architecture for Enterprise Collaboration
Cisco Live Session Details
There are two Preferred Architecture for Enterprise Collaboration sessions at
Cisco Live this week:
You are » BRKCOL-2420
here Part 1: Call Control, Conferencing
Wednesday, June 10th @ 8 AM

» BRKCOL-2421
Part 2: Collaboration Edge, Core
Applications, and Sizing
Wednesday, June 10th @ 1 PM
Agenda
• What is "Preferred Architecture"? • Conferencing
• Architecture Overview
• Call Control
• Conferencing Deployment
• High-level View
• Collaboration Meeting Rooms
• Clustering
• Design Consideration
• DNS Requirements
• Certificate Management
• Base Configuration
• Call Routing, Dial Plan
• SIP Trunking
• Multi-Cluster Considerations
What is “Preferred
Architecture”?
The Preferred Architecture for
Collaboration process was created to
simplify selling and designing. It is a
design where Cisco experts make the
design decisions for you following the
80/20 rule. Its advise from the SRND you
would give your best friend if they asked
you “just tell me what I need to do”.
What does the PA aim to accomplish?
• Simplify selling and deployment
Simplify

• Allow generalists to understand collaboration deployment and what

Empower is preferred

• Reduce complexity of overall deployment choices

Clarify

• Give existing customers a reference to move their deployment

Guidance toward

• Feed simplification (and design issues) back to Development

Influence
PA Process Figure it out:
Define Collaboration
Preferred Architecture

Feedback:
Feed gaps found during Build and validate:
the “build and validate” Build it in the lab and
phase back into product validate concepts
teams

Write it down: Extend:

Document Preferred Move it into GB test
Architectures for the beds, Cisco on Cisco,
field and partners Alpha and EFT process

Define
Define additional Preferred
Architectures (Voice, Video)
Collaboration Preferred Architectures & CVDs
www.cisco.com/go/cvd/collaboration !

PA CVD Cisco Validated Design

PA Overview Cisco Validated Design Applications

Coming
Soon!!!

Pre-Sales Post-Sales Post-Sales

Process process Process
• Design Overview Document • Detailed Design and Deployment • Detailed, Deployment Guidance

• Targeted to Presales Guidance • Post Sales Design and Deployment

• What (w/ Some Why)! • Post Sales Design and Deployment • What, Why, and How!
• What, Why, and How! • Process Driven Guide
• Process Driven Guide • Plugs into the PA CVD
Mid Market PA/CVD Document Mapping !

www.cisco.com/go/cvd/collaboration
www.cisco.com/go/ucsrnd

Use Case PA Overview CVD

Voice Only PA for Midmarket Voice Unified Comm. using BE6000 CVD
Collaboration Edge Using BE6000 CVD
Standalone Video * PA for Video Video Conferencing using BE6000 CVD
Collaboration Edge Using BE6000 CVD
Full Collaboration PA for Midmarket Unified Comm. using BE6000 CVD
Collaboration Video Conferencing using BE6000 CVD
Collaboration Edge Using BE6000 CVD
Helpdesk using Cisco UCCX CVD

* Fits both Mid-Market and Enterprise

Enterprise PA/CVD Document Mapping !

www.cisco.com/go/cvd/collaboration
www.cisco.com/go/ucsrnd

Use Case PA CVD

Voice N/A N/A

Standalone Video * PA for Video Video Conferencing

using BE6000 CVD
Full Collaboration PA for Enterprise PA for Enterprise
Collaboration Collaboration CVD

* Fits both Mid-Market and Enterprise

Preferred Architecture for Collaboration
Enterprise Cisco Validated Design (CVD)

Call Control • Functions: Dial Plan (Dialing Habits,

Endpoints/ILS/GDPR), Trunking, SRST,
UCM, IM&P, ISR, CUBE CTI, DNS, Cert Mgmt, Provisioning, EM Architecture:
Component S
Role, HA,
Conferencing • Functions: Ad hoc, Rendezvous,
Security,
i
Scheduled, CMR, CMR Hybrid, Personal
UCM, Conductor, TS, TMS Multiparty Scalability z
i
• Functions: Mobile Remote Access n
Edge (MRA), B2B, IM&P Federation, PSTN Deployment:
UCM, Expressway, CUBE, ISR Access, ISDN Video Process and g
Configuration
Applications • Functions: Applications and Tools: VM
Deployment, Licensing, Voice Messaging
Ucx, PCD, PLM

• Functions: Sizing numbers for products

Sizing built on a set of calculated assumptions
Call Control
Architecture and Deployment Models: Simplification
• Recommendation: Centralized Call Processing Model (Single Call Processing Cluster)
• Full-Mesh Distributed Call Processing Deployment Model (Multiple Call Processing
clusters) may be required. This model is based on multiple iterations of the Centralized
Call Processing Deployment Model

IM&P UCM IM&P UCM IM&P UCM

Branch1 Branch2 Branch1 Branch2 Branch1 Branch2

Preferred Architectures
Benefits

• Single Collaboration Design (Voice, Video, IM&P, Conferencing, Edge)

• Collaboration-friendly dial plan which makes easy to add video to voice, IM&P
to voice and video
• Simplified: deployment model, design, dial-plan, video architecture, IM&P
integration, sizing, etc.
• Modular architectural approach for scalability
• Add additional services avoiding re-configuration costs
• Future Proof the Architecture
• Customizing the PA???  GO TO THE SRND FOR GUIDANCE
Call Control
High-level View
 Headquarters
Cisco
Unity Prime
Connection Collaboration
Expressway-E WebEx

Mobile/Teleworker
DMZ
Applications Expressway-C
Internet
Unified
Instant Message Communications
and Presence Manager Third-Party Solution
Integrated/Aggregated
Services Router
Integrated
MPLS WAN Services
Router
Collab Edge
Call Control
TelePresence Server Conductor TelePresence
Management Suite PSTN / Remote Site
ISDN

Conferencing

Endpoints

17
Call Control
Design Objectives

• Call control is centralized at a single location that serves multiple remote sites
• Multiple call control systems as iterations of the centralized call control model
• Management and administration are centralized
• Common telephony features are available across voice, video endpoints and
Jabber clients
• Single call control and a unified dial plan are provided for voice, video endpoints
and Jabber clients
• Critical business applications are highly available and redundant
Call Control Functions
• User / Endpoint Identities & Status
• Endpoint Registration & Management
• Session Management
• Central “Dial Plan” Authority
• Application Integration
• Third-Party Interoperability

Unified Communications Manager is the Heart of the Architecture.

The “Glue” that binds it all together.
Call Control
What’s new/different
• All endpoints registered with Unified CM
• VCS only for third party and legacy video endpoint registration
• Single cluster for call routing and IM&P
• +E.164 based dial and numbering plan
• LDAP for user provisioning and authentication
• Expressway-Core/Edge for firewall traversal
Clustering
Unified CM with IM & Presence Cluster
Unified CM Cluster IM & Presence Cluster

DB Sync
• Two databases
• Each DB has:
DB Publisher
Publisher Subscriber • One publisher
Call Processing • Multiple subcribers
SIP

TFTP 1 CTI/QBE
• CM subcriber:
SOAP API XML
Primary Secondary
• Call processing pairs
TFTP 2 Subscriber Subscriber • TFTP pairs
Call Processing
... • IM&P publisher part
of pair
Primary Secondary
Up to 6 nodes
...
Up to 21 nodes
PA Clustering Guidelines
• Call Processing Subscribers always added in pairs
• 1:1 redundancy only
• Single TFTP Subscriber pair
• Call Processing Subscriber and IM&P pairs added to match scale requirements
• MoH function colocated with Call Processing Subscribers
DNS Requirements
DNS Requirements
• Jabber certificate validation requires DNS for UC services
• Recommendation:
• Enable DNS forward (A record) and reverse (PTR record) lookup for all UC servers
• Potentially zone per cluster:
• pub.emea-uc.example.org
• tftp1.emea-uc.example.org
• tftp2.emea-uc.example.org
• sub1a.emea-uc.example.org
• sub1b.emea-uc.example.org
• Dedicated zone for cluster simplifies configuration of cluster fully qualified domain name
(CFQDN):
• *.emea-uc.example.org
DNS for UDS Based Service Discovery
• DNS SRV records are required for Jabber service discovery
• On-prem service discovery looks for _cisco-uds._tcp.ent-pa.com
• Recommendation:
• SRV record for each Unified CM subscriber
• Best load balancing of initial UDS requests during registration

• DNS SRV load balancing only used for intial UDS request.
• Further UDS requests are load balanced by Jabber over all UDS nodes in
cluster learned from UDS
• Example:
_cisco-uds._tcp.ent-pa.com 86400 IN SRV 10 10 8443 sub1a.emea-uc.ent-pa.com
_cisco-uds._tcp.ent-pa.com 86400 IN SRV 10 10 8443 sub1b.emea-uc.ent-pa.com
_cisco-uds._tcp.ent-pa.com 86400 IN SRV 10 10 8443 sub2a.emea-uc.ent-pa.com
_cisco-uds._tcp.ent-pa.com 86400 IN SRV 10 10 8443 sub2b.emea-uc.ent-pa.com
Certificate Management
Certificate Requirements
Base Concepts
• Certificate exchange part of TLS connection setup
Serial
• Certifcate Validity: expiration date, signature valid? Signature
• Certificate Trust: is the signing entity trusted? Issuer
• Self-signed certs: import cert into trust store Subject
• Issuing CA trusted Validity
• Identity: does the certificate identity match the Subject Public Key
identity of the intended communication peer?
Jabber Certificate Validation

• Required Certificates
• Unified CM IM&P: Tomcat, XMPP
• Unified CM: Tomcat, CallManager
• Unity Connection: Tomcat
• WebEx Meetings Server: Tomcat

• Options:
• Users ignore certificate validation pop-ups and accept certs  invalidates security
concepts
• Install above certificates in the Enterprise Trust store of all clients
• Use CA (public/private) issued certificates: only trust with CA has to be established
Certificate Recommendations
• CA issued certificates simplify the deployment
• With self-signed certificates to establish trust all certificates have to be cross-imported
or deployed to clients via GPO
• Use multi-server certificates to minimize the management overhead
• Private CA avoids policy constraints of public CAs; e.g. single certificate per
FQDN
Base Configuration
FQDN Processnode References
• All nodes of a cluster are managed under “System/Server”
• Options:
• IP address
• Hostname (no domain)
• Fully Qualified Domain Name (FQDN, includes DNS domain portion)

• Processnode references exposed to external entities

• Endpoint configuration files (Unified CM groups for registration)
• UDS service discovery
• ...
FQDN Processnode References
Why not IP addresses?
• IP address processnode references are used by Jabber to build HTTPS URLs to accesss services
• Certificate validation during TLS connection setup
• Validity: validity period
• Trust: direct (imported into trust store) or indirect (certificate issued from trusted CA)
• Identity: subject of the certificate (or subject alternate name) needs to match the intended communication peer

• Final identity check fails if host connects to an IP address, because cert subjects (typically) are domain
names
• Certificates with IP address subject alternate name not an option
• CA validation of IP addresses questionable
• Incorrect treatment of IP address SANs by some browsers

• IP address processnode references cause Jabber certificate validation to fail

FQDN Processnode References
Why not hostnames?
• Exposed hostnames need to get fully qualified by clients
• Which domain should be used?
• Presence domain?
• Domain learned by client via DHCP?

• What if the customer has site with multiple DNS domains?

• domain learned by client via DHCP: nyc.ent-pa.com
• DNS domain of Unified CM cluster: uc-cluster.ent-pa.com
• Problem: client uses wrong FQDN to connect to servers
FQDN Processnode References
FQDN is the only/best solution
• Pro:
• Solves certificate validation problems
• Solves multi-domain problems

• Con:
• Creates DNS dependency
• DNS becomes critical foundation service for UC

• Recommendation: set server names (Unified CM admin GUI under

System/Server) to FQDNs!
Enterprise Parameter
• Global settings determining fundamental behaviour of Unified CM
• Identification
• Cluster ID: unique cluster identification
• Service URLs: make sure that URLs refer to FQDNs

• Call Routing
• URI Lookup Policy: RFC 3261 URI case sensitivity
• set to “Case Insensitive”
• Organisation Top Level Domain (OTLD): routing of numeric SIP URIs
• set to main domain, e.g. “ent-pa.com”
• Cluster Fully Qualified Domain Name (CFQDN): routing of numeric SIP URIs
• space separated list of all Unified CM nodes in the cluster
• Wildcarded if all cluster members are in same domain/zone (example: *.us-cluster.ent-pa.com)
 Numeric SIP Request Routing Flowchart

Is RHS the Does RHS Does RHS Match RHS

no no no
IP address of a match match against Route or block
cluster member? CFQDN? OTLD? SIP Route Pattern

yes yes yes

Does LHS no
Analyse LHS
find a match?
yes
“numeric” pattern actually
routed based on RHS and not
based on numeric dial plan
Route or block Offer call
Always Set CFQDN and OTLD

• Set OTLD to match single(!) corporate domain name

• Make sure to set the CFQDN to match host names of all cluster nodes
• DNS naming structure might help
• e.g.: *.us-cluster.ent-pa.com for pub. us-cluster.ent-pa.com, sub1. us-cluster.ent-
pa.com , …
• Keep in mind that fallback routing based on RHS is implemented for:
• Alpha URIs not found locally
• Numeric URIs with RHS = OTLD not found in numeric lookup
Call Routing
What Is a Dial Plan About?
• Mapping from dialed destinations to connected endpoints
• Concepts that are part of dial plans
• user input
• mapping of user input to routable format (transformations)
• routing / routing restrictions (class of service)
• call presentation
• numbering plans

1234
“1234”
84961234
84961234
routing
Enterprise Specific Dialing Habits
• Typically dialing habits for local, national, international calls are
given/agreed based on a given domain/country
• In addition need to agree on how to dial:
• Private numbers (on-net)
• Intra-Site
• Services (voicemail, meet-me, call park, pick-up ...); non-DIDs

• “+”-dialing also needs to be supported!

• application support
• number portability
Class of Service
• Common term to describe the permissions of users on communication systems
• COS includes
• permission to reach certain destinations
• voicemail access
• reachability from outside
• call forward restrictions

• Enterprise dial plan is the tool to implement required classes of service

• Important: make sure to start dial plan design with full view of required classes
of service
E.164 geographic numbers
Background

• ITU Recommendation E.164 describes the “Numbering Plan of the International telephone service”
• CC: Country Code
• NSN: National significant number
• NDC: National destination code
• SN: Subscriber number
• NDC+SN = NSN: National significant number

• National numbering plan left to national authorities

• documented at http://www.itu.int/oth/T0202.aspx?lang=en&parent=T0202
• US: fixed length, NSN 10 digits
• DE: variable length, NSN 4-13 digits
Enterprise Numbering Plan
(abbreviated on-net inter-site dialing)
• Why
• Overlay addressing for non-DIDs including conference rooms and other services
• Can be re-used for VM subscriber IDs
• Possibly shorter inter-site on-net dialing (if mapped to addresses of endpoints)
• Fixed length instead of possibly variable length inter-site on-net dialing

• Enterprise Significant Numbers (ESN) must not overlap with any other dialing
habit
• Steering digit for ESNs reduces the domain available for other dialing habits
• Planning and maintenance effort!
Guidelines for ESN Plan
• Typical format:
• <access code> - any digit or “*”
• <site id> - Might be a hierarchical scheme including regional attributes
• <extension> - Intra-site on-net extension

• Example: 8-496-1234
• 8 – Access code
• 496 – Site id (site 6 in Germany)
• 1234 – Local extension

• Make sure to reserve space (what if we get more than 9 sites in Germany?)
• Make it extensible (think “Shannon coding”)
• Changing an established private numbering is VERY hard
+E.164 DNs and Non-DIDs (1)
• Non-DIDs for
• Lobby phones
• Services (call park, call pick-up, VM pilot, ...)

• +E.164 DNs for “regular” phones provide

• Unique address (by definition)
• One on-net dialing habit for free (+E.164 dialing)
• Correct globalized caller ID for all call-flows originating from internal endpoints

• “pseudo” +E.164 DNs (e.g. +0....) don’t have any of the above
+E.164 DNs and Non-DIDs (2)
• Better: start with the question “how do I want my users dial these destinations?”
• ... And add the appropriate patterns as addresses directly
• Local Significance
• site specific partition with site-unique patterns
• caution with exposing non-DID inter-site

• Global Significance
• global partition with unique DNs
• need to come up with enterprise specific numbering scheme

• On egress (specifically gateways) make sure to filter non-DID caller IDs

Example Dialing Habits/Numbering
Non-DID Addressing Based on Dialing Habits
Site +E.164 Abbr. Intra-Site* Call CMR conferencing***
Park**
SFO +14085559XXX 9XXX 4XXX 88XXXXX
NYC +12125551XXX 1XXX 4XXX 88XXXXX
RTP +19195551XXX 1XXX 4XXX 88XXXXX

* site specific translation patterns in site specific partition mapping to +E.164

** single call park range in global partition or site specific call park ranges in site
specific partitions
***single dialing habit (single route pattern) in global partition
Deployment Considerations: Numeric Dial Plan
• Use +E.164 as DN addressing
• Benefit: ensure uniform phone number formatting across all enterprise contacts
• +E.164 DNs are provisioned with a leading “\”: \+1 408 555 1234

• Use XXXX abbreviated intra-site dialing

• Benefit: allow abbreviated dialing for intra-site calls

• Use sitecode based abbreviated inter-site dialing

• e.g.: 8+<site code>+<extension>
• Access code needs to be selected so that there are no overlaps with any other dialing habit
• Benefit: use a normalized approach for inter-site calls

• Non-DID addresses in line with sitecode based abbreviated inter-site dialing

• Unique addresses
• Addtl. sitecodes per site or non-overlapping extensions
 Reference +E.164 Dial Plan
CSSs Partitions Route Lists Route Groups

DN
Line CSS SJCInternational All IP Phone DNs (+E.164), urgent

All dialing normalisation is CoS

un-specific!
SJCtoE164 All normalisation patterns can be
DN
1XXX, Prefix +1408555
re-used

9.[2-9]XXXXXX, Pre-Dot, Prefix +1408

UStoE164 LRG based egress GW selection

9011.!, Urgent, Pre-Dot, Prefix +
9011.!#, Urgent, Pre-Dot, Prefix +
9.1[2-9]XX[2-9]XXXXXX, XYZ RG
Pre-Dot, Prefix +

Routing is CoS specific.

Site specificity only on site PSTNInternational
specific CoS (like “local”) USPSTNNational Local
Route
SJCPSTNLocal LOC RL Group
\+1408[2-9]XXXXXX, Urgent
URIs and Directory Integration
• Up to 5 URIs can be configured per DN
• End user’s directory URIs are assigned to
directory numbers based on enduser’s
primary extension; partition “Directory URI”
(cannot be changed/deleted)
• other URIs can be in any partition; no need to
have them in the same partition as the DN
Route Pattern/SIP Route Pattern
Load balancing and alternate path external routes Personal CMR
Analysis of dialed destination
Expressway-C
User dials numeric
destination or URI CUBE
Gateways
(SIP) Route
Pattern
Third-Parties

Route List

Choose the highest priority RG

1st Choice 2nd Choice

Route Route
Group 1 Group 2
Trunks within the Route List are
Top down or Top down or selected based on a top down or
circular circular circular rotation

SIP Trunk SIP Trunk SIP Trunk SIP Trunk

Local Route Group (LRG)
• LRG introduced with Unified CM 7.0
• Concept: move the site specific egress gateway selection policy from the route
pattern to the calling devices’ device pool
• “Standard Local Route Group” used as placeholder in route list definition
• Dynamically replaced with route group configured on calling device’s device pool when
routing the call
• Allows for site un-specific route patterns  route pattern count reduction
• Restriction pre 10.0: we only have single LRG
• What if we want to use LRG based egress GW selection, but e.g. need to
differentiate between emergency calls and ‘regular’ PSTN calls?
Example Multiple LRG use-case
• Centralized HQ PSTN resources in the HQ used V
V

for all HQ calls and international calls (also from V

V
regional offices) V

V
• Redundant PSTN resources in regional offices
used for 911 from regional office, national calls
V Branches
from regional office and PSTN calls from branches. Regional Office 1
Overflow of regional office national calls from
regional office to HQ (branches never use HQ V
V
resources) V V

HQ V
V
• Branches have small GWs for emergency (911) V

calls and as overflow for regular calls V

V
• … but we still only want to have three route V Branches
patterns: Regional Office 2
• 911  emergencyRL
• \+1XXXXXXXXXX, urgent  USNationalRL Bonus question: why does
• \+!  InternationalRL this need to be urgent?
T302 due to overlap w/ \+!
 Example Multiple LRG use-case
Device Pools LRGs (placeholders) used in route list configuration
per location

911 National National International International

Primary Secondary Primary Secondary
HQ HQ HQ - HQ -
Regional Regional Regional HQ HQ Regional Office 1
Office 1 Office 1 Office 1
Regional Regional Regional HQ HQ Regional Office 2
Office 2 Office 2 Office 2
Branch x of Branch x Regional Branch x Regional Office 1 Branch x
Regional Office 1
Office 1
Actual PSTN Resources (route groups)
Branch x of Branch x Regional Branch x Regional Office 2 Branch x
Regional Office 2
Office 2
 Multiple LRG Example: Emergency Call
Device Pool SJCPhone Route Group:
Phone in Device Pool SJCPhone RG_SJC
LRG_PSTN_1: RG_SFO
LRG_Emergency_1: RG_SJC
Standard LRG: RG_SJC

911
Different egress gateways
Route Pattern
911
Route List
RL_911
for phones in sites SJC and
Route Groups: SFO
911
LRG_Emergency_1
Standard LRG

Route Group:
Device Pool SFOPhone RG_SFO

Phone in Device Pool SFOPhone

LRG_PSTN_1: RG_SFO
LRG_Emergency_1: RG_SFO
Standard LRG: RG_SFO
 Multiple LRG Example: PSTN Call
Device Pool SJCPhone Route Group:
Phone in Device Pool SJCPhone RG_SJC
LRG_PSTN: RG_SFO
LRG_Emergency_1: RG_SJC
Standard LRG: RG_SJC

+16125551234

Route Pattern
\+!
Route List
RL_PSTN
Same egress gateways for
Route Groups:
phones in sites SJC and
+16125551234 SFO
LRG_PSTN
Standard LRG

Route Group:
Device Pool SFOPhone RG_SFO

Phone in Device Pool SFOPhone

LRG_PSTN: RG_SFO
LRG_Emergency_1: RG_SFO
Standard LRG: RG_SFO
Reference +E.164 Dial Plan
Summary
• +E.164 based routing
• +E.164 addresses (DNs)
• Dialing habits other than +E.164
implemented as overlay using translation
patterns with CSS inheritance
• Egress gateway selection based on local
route groups
• Multiple local route groups for differentiated
egress GW selection
SIP Trunking
SIP Trunking Recommendations
• Minimize number of SIP profiles
• Consider default profiles first
• avoid per-trunk SIP profiles
• provision SIP profile per group of equivalent trunks

• Recommended SIP profile settings:

• “Use Fully Qualified Domain Name in SIP Requests” set on all trunks and for video
enabled endpoints; prevents IP address of Unified CM to show up in host portion of
URIs in calling identity headers
• Enable SIP OPTION ping for real-time status monitoring

• SIP trunk redundancy achieved by provisioning

multiple peer user agents per trunk (Unity Connection,
Conductor, Expressway-C)
Fully Qualified Domain Name in SIP Requests
• Always set “Use Fully Qualified Domain Name in SIP Requests” in SIP profile
of all SIP trunks and endpoints involved:
• CUCM will relay an alphanumeric hostname of a caller to the called endpoint
as a part of the SIP header information. This enables the called endpoint to
return the call using the received or missed call list
• Mainly important for numeric IDs, but in mixed environments where numeric
and alpha URIs exist, it’s important to always have FQDNs in SIP requests for
all calls
• For endpoints registered with CUCM the FQDN in SIP requests will be set to
the OTLD configured in the enterprise parameters
Use Fully Qualified Domain Name in SIP Requests –
Example Route call cross-cluster

INVITE bob@cisco.com
RPID: sip:alice@cisco.com
INVITE bob@cisco.com
RPID: sip:alice@cisco.com
(“Fully Qualified…” turned on)
-or-
INVITE bob@cisco.com
RPID: sip:alice@10.10.10.1
(“Fully Qualified…” turned off)

180 Ringing 180 Ringing

RPID: sip:bob@cisco.com RPID: sip:bob@cisco.com
(“Fully Qualified…” turned on)
-or-
180 Ringing
RPID: sip:bob@10.10.10.1
(“Fully Qualified…” turned off)
 Multi-Cluster
Considerations
 Multi-cluster scenario
IM&P UCM IM&P UCM IM&P UCM

Branch1 Branch2 Branch1 Branch2 Branch1 Branch2

• Recommendation: Centralized Call Processing Model (Single Call Processing Cluster)

SIP
• Full-Mesh Distributed Call Processing Deployment Model when required. This model XMPP
is based on multiple iterations of the Centralized Call Processing Deployment Model.
SME out of the PA scope.
Multi Cluster scenario
Cisco Unified CM Dial Plan
• Intercluster Lookup Service (ILS) was introduced in Cisco Unified
Communications Manager Release 9
• Provides an overlay network between UCM clusters to facilitate information exchange
• SIP URI replication was the first application for ILS
• Addresses issue of same domain multicluster URI routing

• UC Release 10 adds support for exchange of numbered call routing information

• Simplifies configuration in large deployments based on dynamic exchange of numbered
call routing information
ILS/GDPR URI Learning
Learned from ILS Learned from ILS
bob@cisco.com  nyc.route alice@cisco.com  sfo.route
jkrohn@cisco.com  fra.route sfo.route jkrohn@cisco.com  fra.route
nyc.route

alice@cisco.com bob@cisco.com
ILS routestring: nyc.route
routestring: sfo.route Exchange
• Call controls establish ILS
Exchange
• URI information flooded Learned from ILS
alice@cisco.com  sfo.route
Each call control creates table with bob@cisco.com  nyc.route
URIs and associated SIP route string routestring: fra.route

• SIP route strings routed by SIP

route patterns
jkrohn@cisco.com
GDPR Learning and Routing
Global Learned E.164 Numbers Global Learned E.164 Numbers
+4961007739003  nyc.route +4961007739001  sfo.route
+4961007739002  fra.route sfo.route +4961007739002  fra.route

nyc.route

+4961007739001 +4961007739003
ILS routestring: nyc.route
routestring: sfo.route Exchange

• Call controls establish ILS Exchange

• GDPR information flooded Global Learned E.164 Numbers
Each call control puts learned +4961007739001  sfo.route
+4961007739003  nyc.route
patterns/numbers in respective partitions
routestring: fra.route
and associated them with learned SIP route
string
• SIP route strings routed by SIP route
patterns +4961007739002
 Routing Call to remote Number using ILS
Information
Global Leaned +E.164numbers
+4961007739003  nyc.route 2) Match on learned numeric +E.164 pattern in
+4961007739002  fra.route digit analysis leads to SIP route string “fra.route”

1) Alice calls +4961007739002

+4961007739001
ILS
routestring: sfo.route Exchange

3) call gets routed using SIP route pattern “fra.route”

routestring: fra.route

4) +4961007739002 is routeable using the trunk’s CSS (is a local DN)

+4961007739002
GDPR in an Enterprise Dial Plan
Dialing learned numbers
• Up to three intercluster dialing habits to reach CSSs Partitions
remote DN: DN
• Enterprise (8+7) based on enterprise alternate/pattern SJCInternational All IP Phone DNs (+E.164)
• +E.164 based on +E.164 alternate/pattern
• URI
SJCtoE164
DN
• Assuming that CoS does not depend on dialing 1XXX, Prefix +1408555
habit all remote patterns can be put into single partition 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408

onNetRemote
onNetRemote
• ILS learned URIs are reachable from any device (, but the SIP route All patterns/numbers
patterns potentially are not) learned via GDPR + SIP route
patterns for SIP route strings

• onNetRemote added to all CSSes with CoS “On-net”

• Also make sure to add SIP route pattern matching on SIP route strings to onNetRemote partitions
Conferencing
Architecture Overview
 Headquarters
Cisco
Unity Prime
Connection Collaboration
Expressway-E WebEx

Mobile/Teleworker
DMZ
Applications Expressway-C
Internet
Unified
Instant Message Communications
and Presence Manager Third-Party Solution
Integrated/Aggregated
Services Router
Integrated
MPLS WAN Services
Router

Call Control Collab Edge

TelePresence Server Conductor TelePresence

Management Suite PSTN / Remote Site
ISDN

Conferencing

Endpoints
Conferencing
Design Objectives
• Support flexible and extendable architecture for deployment of one or more
instant, permanent and scheduled conferences
• Dynamic optimization of conference resources on TelePresence Server for
inbound calls
• Build resiliency into the video network
• Enhance the user experience for conference participants
• Deploy personal Collaboration Meeting Rooms (CMRs) for individual user more
efficiently
• Simplify the deployment of new infrastructure components
Conferencing Architecture
Unified CM
Expressway-C Expressway-E
Internet

TelePresence
Conductor Cisco TMS

Personal
Multiparty Scheduled
TelePresence TelePresence
Server Pool Server Pool

SIP Media+Content HTTP(s)

Conferencing
Deployment
Conferencing Components

Cisco TelePresence Server for audio and video

conference resources.
Cisco TelePresence Conductor for audio and video
resource management.
Cisco TelePresence Management Suite (TMS) for
conference provisioning, monitoring and scheduling.

Cisco Unified Communications Manager (CUCM) for

call control and call routing to/from conference bridges.
Multipoint Products
Products discussed in the PA
• Conductor as the orchestrator for multipoint devices
• TelePresence Server platforms chosen as multipoint devices
• MCUs still a valid approach but not included in the PA
• Architectural considerations don’t change
TelePresence Server Platforms
TelePresence Server on TelePresence
VMWare (specs based) Server on VMWare Appliances Blade

8-core
310*

1 to 10 ports at 720p
410v
1 to 12 ports at 720p 820*

1 to 54 ports at 720p 320* 1 to 60 ports at 720p

30vCPU
1 to 24 ports at 720p

1 to 20 ports at 720p

Note: For simplicity, only capacity for 720p is shown. TS is capable of many other resolutions and frame rates with differing limits on capacity.
All numbers represent remotely managed mode (Conductor required) capability. See release notes for further detail.

*TelePresence Server 300 series and 820 can run as cluster to increase capacity.
 Requirements:
Unified CM 10.5(2)

Multistreaming Conductor XC 3.0.3

TelePresence Server 4.1.2
CE 8.0

1. End-point sends multiple copies of the

same stream, at different resolutions
and frame rates, to TS
2. TS switches the streams, and sends
the appropriate stream to the end-point
based upon the request
3. End-points receive the streams from
TS, and build the layout locally
Dual Screen Experience with Multistreaming

Without Multistreaming With Multistreaming

Dual Screen Endpoints will have video on both screens when not
sharing content. Support on MX 700, MX800 Dual and SX80
Single Screen Experience with Multistreaming

Without Multistreaming With Multistreaming

Single Screen endpoints will have an individual view of each

participant in sharing content mode (no filmstrip in PIP).
Support on SX20, SX80, MX200G2, MX300G2 and MX800
What does TelePresence Conductor do?
What does this mean? What does this mean?
Resource
Management/
Conference Virtualization Conference Bridge
Selection
• Knows all the available
• Consistent User
and used ports and
Experience
optimizes resources.
• Whether using Instant
• Intelligent Bridge selection
or Permanent or
Scheduled Conferences • Automatic cascading of
MCUs
What does this mean?
Centralized Conference
Provisioning and
Administration
• Single configuration
applied to any
conferencing resource
• Instant, permanent and
scheduled Conference
support
Conductor Platforms
Variant Conductor Clustering Capacity TAC Support

Free TelePresence
Conductor [Essentials]
(VM only)
 1 x standalone TS
NO
(Use communities & forums)

Mid-Market TelePresence 30 x standalone or clustered

Conductor [Select]
(VM only)
 (up to 2) TS
(50 Call sessions)
YES

Full TelePresence 30 x standalone or clustered

Conductor
(VM only)
(up to 3) TS
(2400 Call sessions)
YES

• Ability to upgrade from Free Conductor -> Midmarket Conductor -> Full Conductor
• Same software shared across all variants. Option keys used to differentiate types of Conductor.
Conductor and Unified CM
How does the model change?
• Emulates MCU API, looks
Conference Bridge in UCM configuration like MCU to UCM
• Utilizes B2BUA
• Accepts SIP Signaling
Uses Multiple IP addresses (65 Max.)
• Management IP
• Location specific IPs
• IP address for Instant Meetings
• IP address for Personal CMR

Added Conductor

Individual
SIP trunk in UCM configuration
bridges
Instant Conference Call Flow
TelePresence
Endpoint creates TelePresence
Unified CM initiates Unified CM routes Conductor routes
an instant Conductor creates
an instant the call(s) to the call(s) to the
conference the conference on
conference on TelePresence TelePresence
requesting to join a TelePresence
Conductor Conductor Server hosting the
three participants Server
relevant conference

Other
Participants

Unified CM TelePresence Server

Host (UCM) Conductor (TS)

Instant conference Instant conference initiated Conductor creates

request by UCM conference on TS

UCM routes call(s) to Conductor routes call(s)

Conductor to TS
Permanent Conference Call Flow
TelePresence
Unified CM routes TelePresence
Endpoint dials a Unified CM matches Conductor matches
the call to Conductor routes
permanent the dialed string to a the called number
TelePresence the call to the
conference alias (SIP) route pattern to an alias and
Conductor via SIP TelePresence
(URI or DN) or route string creates a
trunk Server
conference on TS

Unified CM TelePresence Server

Host Conductor
(UCM) (TS)

Alias matched Alias matched on Conductor

Dial conference alias UCM routes call to Conductor creates conference on TS

(URI or DN) Conductor
Participants
Conductor routes call to TS

Dial conference alias UCM routes call to Conductor routes call to TS

Conductor

Dial conference alias UCM routes call to Conductor routes call to TS

Conductor
Scheduled Conference Call Flow
Unified CM routes
User schedules
TMS uses APIs to Conductor uses call to Conductor
conference using User dials the alias
create a conference APIs to create a (dial-in, OBTP) or
Smart Scheduler. or Conductor dials
on Conductor at the conference on the Conductor dials out
User is notified of out to the user
time requested chosen TS to the user via
the meeting details
Unified CM
 Conductor
Configuration Concepts

Conductor Virtual IP Address

Location

Conference Alias (not needed for instant conferences)

Conductor Unified CM

Conf. Alias Route Pattern Conference Template

Service Route List/MRGL
Preference Service Preference (can be used in multiple Conference Templates)

Conf. Bridge Route Group/MRG

Pool #1 Pool TS TS
(can be used in
Conf. Bridge Conference Bridge multiple SP’s)
TS TS
Prioritized
#2 Pool TS TS
Instant Conference Configuration
Unified CM Conductor

Template

Service
Preference
MRGL

Pool
MRG

Endpoint Media Telepresence

Location Telepresence
Bridge Server
Servers
Permanent Conference Configuration
SIP
Unified CM Conductor
Route Alias
Pattern

Route
Pattern

Route
Template
List

Route Service
Group Preference

SIP Pool
Location
Trunk
Endpoint

Telepresence
Telepresence
Server
Servers
 Conductor Clustering
Unified CM Instant Conductor
Media Resource Group
Conductor 1
Media Bridge1 10.1.1.1 10.1.1.1

Media Bridge2 10.1.2.1

10.1.1.2 • 65 IP addresses per
Conductor server
• Up to 3 nodes in a cluster
Permanent
Conductor 2
Trunk • Up to 30 bridges per cluster
10.1.2.1
Trunk IP1 10.1.1.2 • Max RTT of 30 ms between
cluster nodes
Trunk IP2 10.1.2.2 10.1.2.2
Conductor Location Setup
Unified CM
Media Resource Group “Video”
Conductor
Media Bridge1 192.168.2.10
Instant
Media Resource Group “Voice”
Location Voice Location Video

Media Bridge2 192.168.1.10 192.168.1.10 192.168.2.10

Trunk for Voice

Permanent Trunk IP 192.168.1.11 192.168.1.10 192.168.2.11

Trunk for Video

Trunk IP 192.168.2.11
Cisco TelePresence Management Suite
Unified Service Orchestration and Control
Cisco TelePresence Management Suite Extensions

TelePresence Management Suite

Core Platform (TMS)

TelePresence Management
Suite Provisioning Extension
Cisco
(TMSPE)
TMS Core  Smart Scheduler
 Personal CMR portal
Platform
TelePresence Management Suite
Extension for Microsoft Exchange
(TMSXE)
 Cisco TelePresence Management Suite Architecture
Active Nodes
TMSXE TMS/TMSPE

• TMS in active/passive mode

Network Load
Balancer • External SQL Server used by
Scheduling Single virtual
request both TMS nodes
Active IP address
Exchange
address for
Servers SQL Directory
management
• TMSPE is co-resident with TMS
• TMSXE must be deployed
separately

TMSXE TMS/TMSPE

Passive Nodes
Collaboration Meeting
Rooms
Collaboration Meeting Rooms (CMR) Concept
• Always available, personal meeting room that’s virtualized
• Ability to support voice, video, and content sharing
• Any standards based endpoint supported including Jabber
• Seamless integration with WebEx, allowing ability to join via WebEx in their browser or
from any mobile WebEx client
Collaboration Meeting Rooms Deployment Options
CMR Premise
• Integration between Conductor and TMSPE
Unified CM
– Require Conductor, TMS and TMSPE

• Utilize Conductor provisioning API for conference setup

and configuration

TMS and TMSPE installed • Easy provisioning and configuration of personal meeting
On same server rooms for up to 100,000 users
Conductor TMS – TMSPE uses AD groups to assign Conductor template
configuration to users
TMSPE
• Setup and customize personal CMR from the user’s portal

• Each personal CMR has an associated video address (DN

or URI) that is integrated into Unified CM’s dial plan

• Integrate with CMR Hybrid to create instant WebEx

meeting
Bridge Resources Pool
Personal CMR Provisioning
CMR Template Configuration on TMS
This template will be
created on Conductor
by TMS

Service Preference on
Conductor for this
template
Alias generated from
AD username

Number generated
from AD telephone
number

Note: CMR Template

configuration cannot be
modified from Conductor UI.
Setup CMR at User’s Portal
Unified Communications Self Care Portal
TelePresence Conference Meeting Room and Scheduling

This tab provided by TelePresence

Management Suite (TMS)
Provisioning Extension (TMSPE)

Your scheduled TelePresence

meetings, including WebEx-
enabled TelePresence, One
Button to Push, etc.

Your Collaboration Meeting

Room (CMR)

Your favorites and

account settings
CMR Hybrid
• Integrate on-premise video with
WebEx participants
Unified CM

• Require a certificate signed by a

trusted Root Certificate Authority on
Expressway-C Expressway-E
Expressway-E
Conductor
Internet
• User who wants to schedule CMR
Hybrid meeting must have a host
account with WebEx
Cisco TMS
• Decide on the audio options (WebEx
or PSTN or TSP)
TelePresence
Server Pool • Support scheduled or non-
scheduled
SIP Media+Content HTTP(s)

Cisco Collaboration Meeting Rooms (CMR) Hybrid Configuration Guide

 • Prefer OpEx over CapEx. Conference
CMR Cloud resource and infrastructure reside in
WebEx Cloud

• Require on-premise Unified CM for call

Unified CM control and Expressway for B2B calls

• Add-on to existing WebEx MC subscription

Expressway-C Expressway-E

Internet • Users join via video endpoint or WebEx.

On video, users join by dialing URI

• Maximum of 25 standard-based video

endpoints and up to 500 video-enabled and
500 audio-only WebEx users

• Users have his own room for personal

meeting. Each room has an associated
URL and video URI
SIP Media+Content
• Meeting can be scheduled or non-
scheduled
Cisco Collaboration Meeting Rooms (CMR) Cloud Enterprise Deployment Guide
• Support WebEx, PSTN or TSP audio
options
Design Considerations
 Requirements:

Scheduled Conferences TMS 14.6+

TS 4.1+
WebEx
Conductor XC3.0+
Collaboration Meeting Rooms Premises Release 4
Unified Communications
Manager
Expressway-C Expressway-E

Internet
B2B, B2C,
Cloud Services

TMS
• Configure TS in Remotely Managed Mode
Conductor
• Conference placement is done at conference start
time
• Bridge resources for scheduling can be either
Shared Pool of TS Resources Dedicated or Shared
Conferences Scheduling with Conductor
Deployment Options

Dedicated Resources Shared Resources

Conductor TMS Conductor TMS

Instant and Permanent Scheduled

Instant, Permanent, and Scheduled

• Similar to previous TMS deployment with directly

managed TelePresence Servers.
• Simplest deployment, TelePresence Servers are
• Single TS, in single Bridge Pool, in single Service dynamically allocated for any type of conference.
Preference. TMS can have multiple Service Preferences
• If utilization is high, additional TelePresence Servers
in a prioritized list.
can be deployed.
• IP Zones based on Conductor IP Zone, so possible loss of
• Takes advantage of Optimized Conferencing.
conference placement intelligence if already using IP
Zones with directly managed bridges.
Conferences Scheduling with Conductor
Conductor Redundancy
• TMS does not support Conductor cluster
• More than one node from a Conductor can be added to TMS, but manual
intervention is required to have TMS fallback to one of these secondary
Conductor nodes.
Conductor
Cluster

TMS
 Conductor TMS

Conferences Scheduling with Conductor Service Preference 1

Scheduled Pool

Deployment Option – Example 1

Dedicated bridge for scheduled conferences
• Configuration
• Single pool with a single conference bridge
• Pool is marked for scheduling in Conductor
• Pool is reported to TMS in capacity information

• Advantages
• Conference availability guaranteed
• Maximizes resources as TMS will book ports until the bridge is full

• Disadvantages
• Uses one conference bridge exclusively for scheduling
 Conductor TMS

Conferences Scheduling with Conductor Service Preference 2

Primary Scheduled Pool Backup Scheduled Pool

Deployment Option – Example 2

Dedicated bridge for scheduled conferences with dedicated backup bridge
• Configuration
• Two pools with a single conference bridge in each
• Second pool is used as backup if the highest priority bridge fails
• Only first pool is marked for scheduling in Conductor’s Service Preference and reported to TMS

• Advantages
• Conference availability guaranteed
Enabled
• Maximizes resources as TMS will book ports until the bridge is full
Disabled
• Fallback bridge in case of bridge failure

• Disadvantages
• Uses two conference bridge exclusively for scheduling
• Consumes backup resources
 Conductor TMS

Conferences Scheduling with Conductor Service Preference 3

Primary Scheduled Pool Shared Use Pool

Deployment Option – Example 3

Dedicated bridge for scheduled conferences with shared use backup bridge
Pool shared with other
Service Preferences
• Configuration
• Two or more pools with the highest priority pool having a single bridge for scheduling
• Other pool(s) contain bridges for both scheduled (as a backup) and non scheduled conferences.

• Advantages
• Conference availability guaranteed
• Maximizes resources as TMS will book ports until the bridge is full
• Fallback bridge in case of bridge failure subject to capacity availability in other pools

• Disadvantages
• Uses one conference bridge exclusively for scheduling
 Conductor TMS

Conferences Scheduling with Conductor Service Preference 4

Shared Use Pool

Deployment Option – Example 4

Shared use bridges for scheduled and non-scheduled conferences
• Configuration
• One or more pools with one or more bridges shared for scheduling and non scheduling
• All pools are marked for scheduling in Conductor’s service preference and report to TMS

• Advantages
• Most efficient use of TelePresence Server resources
• All conference types can take advantage of Optimized Conferencing
• Disadvantages
• Resource availability for scheduled conferences is not guaranteed
• Non scheduled conferences could be using the resources
• Limit this possibility by decreasing the resources on the Capacity Adjustment feature of the service preference
Conferences Scheduling with Conductor
Caveats
• Auto-Dialed Participants (ADPs)
• ADPs can be used in TMS scheduled
meeting but are configured in and out-
dialed by Conductor
• TMS has no knowledge about existence
of and resources consumed by ADPs
• Call Detail Records (CDRs)
• Conductor does not feedback a
conference CDRs
• TMS can gain CDR information directly
from the bridges if they are in TMS
Refer to Cisco TelePresence Conductor` with Cisco TMS Deployment Guide for more detail.
• Scheduling options not supported
• Media Port Reservation – do not enable on
MCUs
• TMS Conference Templates
• TMS Participant Templates
• Lecture conferences on Conductor, only
meeting type conferences are supported
• Some information (e.g. video resolution,
snapshots) in Conference Control Center
(CCC) are unavailable but full CCC
functionality remains unchanged
Multi Cluster Deployment
Site 1 Site 2
Unified CM Unified CM
Expressway-C Expressway-E Expressway-E Expressway-C
Internet

TelePresence TelePresenc
Conductor Cisco TMS e Conductor

MPLS WAN
Personal Scheduled Scheduled Personal
Multiparty TelePresence TelePresence Multiparty
TelePresence Server Pool Server Pool TelePresence
Server Pool SIP HTTP(s) Server Pool
Multi Cluster Deployment

• Multiple Unified CM clusters might share a single Conductor cluster with

separate pools for the Telepresence Servers
• However, if the Unified CM clusters are dispersed worldwide, it is best to
dedicate a Conductor cluster per Unified CM cluster to avoid relying on
international connection for local calls
• Use ILS between different clusters if alphanumeric SIP aliases and a single SIP
domain are used
• Deploy a single TMS instance to provide conference monitoring, provisioning
and scheduling for the entire organization
Conferencing Deployment Recommendations
• Utilize Conductor to manage TS for all conference types
• All TS within the same pool should have identical capacity
• Enable “Best Effort Early Offer” on all SIP trunks
• Use the same Unified CM SIP trunk to Conductor for both scheduled and
personal CMR
• Deploy components in cluster for redundancy if possible
• Configure a host PIN for all personal CMR
• Ensure “Optimize Resources” and “Active Control” are turned on (they are
enabled by default)
Closing
Additional Information
• Cisco Collaboration Solutions Design Guidance:
http://www.cisco.com/go/ucsrnd
» Cisco Collaboration Systems 10.x Solution Reference Network Designs (SRND)
» COMING SOON: Cisco Collaboration Systems 11.0 Solution Reference
Network Designs (SRND)

• Cisco Enterprise Preferred Architecture:

http://www.cisco.com/go/cvd/collaboration
» Cisco Preferred Architecture for Enterprise Collaboration, Design Overview
» Cisco Preferred Architecture for Enterprise Collaboration, CVD

• To continuously improve the Preferred Architecture Documentation, we

need your feedback. For questions, suggestions and clarifications please
send email to pa-team@external.cisco.com
Cisco Customer Connection Program 17,000+
Members
Connect with Cisco & Peers
• Influence Collaboration product direction
• Access to early adopter & beta trials
• Contribute to advisory groups
• Monthly technical & roadmap briefings
• Exclusive perks at Cisco Live
– Collaboration Cloud Fusion: Vision &
Architecture (speaker: Jonathan Rosenberg, Visit the Customer Connection Program -
VP/CTO CTG) Collaboration zone in the Cisco Campus
– 5 NDA Roadmap Sessions + Microsoft Interop  Join the Customer Connection program
 Explore the Collaboration community
– Q&A Open Forum with Product Management
 New CCP members get a thank-you gift
– Reserved seats at Work Human Innovation Talk
(Wed. 3:30 – 4:30)
Continue the Conversation using Cisco Spark
• Sign up free for Cisco Spark at http://www.ciscospark.com/
• Download the application from iOS App Store, Google Play Store, or from
http://download.ciscospark.com/
• Visit the World of Solutions Cisco Spark area for demos
• Use Cisco Spark to continue the conversation or ask any additional questions
with the speaker for this session. The room name is BRKCOL-2420
• How to get added to the Cisco Spark room for this session
• To opt in, send an email to spark-at-ciscolive@cisco.com with the message “Please
add me to the BRKCOL-2420 room”
Complete Your Online Session Evaluation
• Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner
will receive a $750 Amazon
gift card.
• Complete your session surveys
though the Cisco Live mobile
app or your computer on
Cisco Live Connect.
Don’t forget: Cisco Live sessions will be available
for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Table Topics
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you