Professional Documents
Culture Documents
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
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
Define
Define additional Preferred
Architectures (Voice, Video)
Collaboration Preferred Architectures & CVDs
www.cisco.com/go/cvd/collaboration !
Coming
Soon!!!
• 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
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
www.cisco.com/go/cvd/collaboration
www.cisco.com/go/ucsrnd
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
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)
• 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
• Con:
• Creates DNS dependency
• DNS becomes critical foundation service for UC
• 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
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
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
• 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
• 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, ...)
• “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
DN
Line CSS SJCInternational All IP Phone DNs (+E.164), urgent
Route List
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
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
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
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
+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
INVITE bob@cisco.com
INVITE bob@cisco.com RPID: sip:alice@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)
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
nyc.route
+4961007739001 +4961007739003
ILS routestring: nyc.route
routestring: sfo.route Exchange
+4961007739001
ILS
routestring: sfo.route Exchange
routestring: fra.route
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
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
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
8-core
310*
1 to 10 ports at 720p
410v
1 to 12 ports at 720p 820*
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)
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
Free TelePresence
Conductor [Essentials]
(VM only)
1 x standalone TS
NO
(Use communities & forums)
• 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 Uses Multiple IP addresses (65 Max.)
Conference Bridge in UCM configuration like MCU to UCM • Management IP
• Utilizes B2BUA • Location specific IPs
• Accepts SIP Signaling • 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
Location
Template
Service
Preference
MRGL
Pool
MRG
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
Trunk IP 192.168.2.11
Cisco TelePresence Management Suite
Unified Service Orchestration and Control
Cisco TelePresence Management Suite Extensions
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
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
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
Service Preference on
Conductor for this
template
Alias generated from
AD username
Number generated
from AD telephone
number
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
TMS
Conductor TMS
• 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
• 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
• 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
• 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
Refer to Cisco TelePresence Conductor` with Cisco TMS Deployment Guide for more detail.
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