BRKCOL-3990 Cms On-Premises and Hybrid

BRKCOL-3990
Cisco Meeting Server,

on-premises and hybrid
large scale conferencing design
Aniello (Nello) Zanfardino,
Solution Architect
Cisco Advanced Services
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKCOL-3990
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda
Cisco Meeting Server, on-premises and hybrid
large scale conferencing design
• Introduction
• Core
• Edge
• MS Interoperability
• Hybrid Conferencing
• Conclusions
• Backup slides
Introduction
CMS - Key Capabilities
What CMS does
Cisco Meeting
Audio Browser Access
Video Conference Spaces Application MS Interoperability
Conference (WebRTC)
(Native CMA)
• Interoperability • Scalable • Enriched meeting • WebRTC browsers • PC/MAC/iOS • Native

• Scaling • Reduced costs • Virtual meeting • Users & Guests • Same • Any Lync/S4B
• Clustering • Multiple ways to rooms access functionalities and version
• Multitenancy join • Multiple VMR per • Session Controls look & feel as • On-prem and cloud
• Virtual Meeting • DTMF, IVR user (mute, drop, etc) WebRTC client • Bidirectional
Rooms • content sharing • Session handover • Better video quality content
• Built in NAT browser/video room • Seamless user
traversal experience
• Security
Cisco Meeting Server

BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6
Hardware Components
How CMS looks like – excluding legacy servers
CMS 2000 CMS1000 Spec Based

Flagship, Swiss Knife Flexibility
Highest Capacity High Capacity Medium capacity
BRKCOL-2803 Abhijit Dey Designing and deploying multiparty conferencing for telepresence video
Core CMS sizing
Platform Capacity [HD sessions per server(*)] Session Capacity
Type Multipliers
CMS 2000 500 (up to CMS 2.2)
Full-HD 0.5
CMS 1000 (****) 96 1080p30
HD (*) 1
MM410v (legacy) 64
720p30
MM400v (legacy) 32 480p30 2
Dedicated server VM (**) 2.5 per physical core Audio (***) 40
Co-resident VM 1.25 per physical core

(hyper-threading disabled)
(*) HD 720p30 video calls with 720p5 content and up to 2.5 Mbps bandwidth
(**) CPU 2.5 GHz+, 1 GB vRAM per vCPU, hyper-threading enabled, more details at:
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-meeting-server.html
(***) With G.711 codec. Max 450 participant per conference per CallBridge, max 3000 audio calls
(****) Cms1000 VM : hyper-threading enabled ,2 Virtual Sockets, 35 Core per sockets, 58 GB vRAM,100 GB HD
Max 100 WebRTC sessions per server and max 500 sessions per XMPP cluster (see edge section)
Management / Admin methods
How to interact with CMS
CLI /
API
Console
WebAdmin
SFTP
(Web GUI)
CMS - Services
CMS Key Software Components
H323 GW and
Call Bridge XMPP WebBridge Turn Server Load Balancer
SIP Edge
(core) (core) (core, edge) (edge) (edge)
(legacy)
Video Bridging core Client and WebRTC with compatible Firewall traversal for XMPP signalling H323 GW (not GK)
Call Control Inter-component browsers (Chrome, media traffic firewall traversal
Media processing signalling Firefox, Opera) (proxy) SIP firewall
Clustering transversal
IM&P Brand-able
VP8 & H.264 Equivalents services
exist in Expressway
Webadmin Recorder & Database cluster

(core) Streamer (core) (core) Services are split between
• Core Service
Web Administration Recording Database Clustering • Edge Services
meetings to depending on their placement in the network
external storage Redundancy and
Streaming Resiliency
meetings to
external server
Architecture – Core only – Single server
CMA WebRTC
Clients Clients
XMPP WEBBRIDGE
SIP
XMPP
CORE SERVER CALLBRIDGE

HTTPS / WEBRTC
Media
LDAP
AD
Although the term CMA client in documentation may refer to both native and WebRTC clients,
for simplicity, we will use the CMA name only for native clients
Architecture – core and edge (pre-Expressway WebProxy)
CMA WebRTC
Clients Clients
External
TURN
DMZ
LOADBALANCER WEBBRIDGE
EDGE SERVER
SIP
Internal XMPP
XMPP WEBBRIDGE
HTTPS / WEBRTC
CALLBRIDGE
CORE SERVER Media
AD LDAP
WebRTC
Clients
CMA
Clients
CMS Clustering
Benefits Components
• Scalability Database Clustering
• Resiliency • Spaces
• Geographic optimization: • Dial Plan
• Reduce latency using closest call • Cluster-wide configuration
bridge Call Bridge Clustering
• Minimize WAN traffic • Distributed calls
Database Clustering
Highlights
Odd number of DB servers required for reliable master election if network split
DB nodes needs to see more than half of the cluster members to be eligible as master
Max 5 DB server, recommended 3
All DB operations are directed to the master
Separate DB server improves CallBridge robustness and simplifies upgrades

(suggested with server with distribute processing (cms2000, X3) and large DBbs (>10k spaces))
Max of 8 Call Bridges per cluster.

Designs more than 8 Call Bridges in a cluster need to be validated by Cisco BU
Clustering Architecture - Call Bridge with dedicated DB
• Keepalives
Call Bridge Cluster • Call Status
• Distributed Calls
• Max 300 ms RTT
(max 100 ms RTT within CallBridgeGroup)
• Spaces
• Users Call Bridge Cluster
Database Connect • Dial-plan HTTPS + SIP
• Cluster-wide
configuration
• Max 300 ms RTT Database Connect
TLS/Postgres
• Cluster sync DB Master
• Max 200 ms RTT
Postgres Database Cluster
TCP/TLS Port : 5432 Database Cluster TLS / Postgres
DB Slave DB Slave
Clustering Architecture - Call Bridge with co-located DB
Database Cluster
• Keepalives Call Bridge Cluster
• Call Status HTTPS + SIP
Call Bridge Cluster • Distributed Calls
DB Slave
DB Slave Database Connect
TLS/Postgres
• Cluster sync • Spaces

Database Cluster
• Users TLS / Postgres
• Dial-plan
DB Master
• Cluster-wide
configuration
Other combinations of CallBridges and DataBase are also possible,

best choice may vary with customer deployment
Distributed calls
Resiliency, scale, geo-distribution
Conference 1
Conference 2
distribution links with multiple

streams for remote participants (*)
Preview in CMS 2.3 : more than 4
streams in the distribution links
(Cluster.peerlinkbitrate >= 2Mpbs)
EMEA
Americas APAC
(*) up to 4 streams using
max “peerlinkbitrate” bandwidth
(before CMS 2.3) BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 17
For reference
Distributed call Setup

Call Bridge Cluster Enpoint2
CUCM2
Enpoint1 CUCM1
Call Bridge CB1 Call Bridge CB2
DB: MySpace1
SIP: INVITE MySpace1
First call established

Dual protocol
HTTP/SIP inter- SIP: INVITE MySpace1
CallBridges trunk
Intra-cluster dialogue finds that the space is already active in in CB1
CB1: generating peer URI sip:Conf_ID@CB1 for coSpace <spaceID>

CB2: call <Call ID> now peered with conference on server CB1 (peer URI Conf_ID@CB1)
SIP
SIP: INVITE Conf_ID@CB1
HTTPS / SIP
Distributed Video Call established

Media
XMPP Clustering
Highlights
XMPP High Availability mechanism with keepalives
3 or 5 XMPP Servers
Master election similar to the database cluster
Call Bridges gets XMPP server list from DNS _xmpp-component._tcp SRV record
(use GEO DNS to optimize geographically the XMPP server selection)
Call Bridge must be configured on all XMPP servers with same credentials
(use the xmpp callbridge add once and then xmpp callbridge add-secret)
All XMPP traffic is forwarded to XMPP master
(CallBridge/loadbalacers can send message to any XMPP server)
Full mesh connectivity from LoadBalancers to XMPP servers is not required
Max 500 sessions per XMPP cluster
Max 200 msec RTT between XMPP servers

Deployment Prerequisites - DNS DNS
• Several DNS records are required for the solution to work properly
• The main DNS records are:
1. 1) DNS A records for all the servers involved (e.g. cms1-us.mycompany.com)
2. 2) DNS A records for user access to services (e.g. meet.mycompany.com)
3. 3) DNS SRV records to locate XMPP server:
4. -For clients and internal services _xmpp-client._tcp.mycompany.com port 5222
-For CallBridges to locate XMPP cluster members _xmpp-components._tcp.mycompany.com port 5223
5. A more comprehensive list is in installation docs
• Large conference design involves (discussed in the Edge section)

• GEO DNS for optimal allocation of service entry point from Internet
• Split DNS allocation of external, internal service
Deployment Prerequisites - Certificates
•WebAdmin
Certificate
•XMPP
•WebBridge types:
•Callbridge
• self-signed
Components •Loadbalancer
that need a
certificate: •Trunk
•Turn (if using TLS)
•Database Cluster • Private CA
•Recording server
•Streaming server
Signed
• Public CA Signed
Reduce Certificate Complexity
• Plan/design certificate structure before deployment
• Combined Certificates
• Certificates shared among multiple components and servers
• Use multiple FQDN entries in certificates Subject Alternative Name (SAN)
• CA-Signed
• Combined certificates have some limitations:
• database clustering (client) needs separate certificate
• Lync/S4B integration have specific requirements
• Wildcard certificates
• Supported but limitations applies too
Cisco Meeting Server 2.x, Certificate Guidelines for Scalable and Resilient Server Deployments
• Use case 1
• Call Control : traffic optimization
CMS Core Design • Bridge and DB Cluster distribution
• LDAP integration : user and space

names
• Domains structure and Dial Plan
• Call Admission Control
• TMS Scheduling
Use Case 1
Large enterprise with established worldwide collaboration infrastructure
with the need of pervasive video services with global coverage
Structural requirements (*): Conferencing requirements:
• Three worldwide regions (**) • Virtual Meeting Rooms (VMR)
• Redundancy with 2 Data Centres (DC) in • Scheduled meetings with OBTP (One
each region (**) Button To Push)
• Traffic Optimization (localize the traffic to • Expected load around 2000 HD ports
regions whenever possible) evenly split between the regions
(*) Structural requirements will be the same in most of the use cases presented
(**) More regions or more DCs can be added to the same design
Use Case 1 - Architecture Summary
Sizing for use case 1 :
AD 6 x CMS-2000 : 3000 HD ports
3 x spec based VMs for DB servers
Calendar
TMS+TMSXE
Global
(**) (**) (**)
Routing &
Management
Regional
.
Call Control
. .
Conferencing
Core Core Core (CMS cluster)
Database Database Database
Americas EMEA APAC

(**) The design discussed do not depend on the use of SME, as long as
the global routing call control entity (CUCM or SME) is aware of global and regional topology
Call Control – Trunks
Global
. . . Routing &
Management
Regional
Call Control
. . .
Conferencing
(CMS cluster)
Americas EMEA APAC
Trunk the CMS cluster to global routing call control to simplify configuration
and to reflect the global reach of the CMS cluster
One CUCM trunk per CMS to leverage CUCM route advance on call error codes (see load limit slide)
BRKCOL-2614 Glen Lavers Technical Overview of Preferred Architecture for Enterprise Collaboration 11.6 release
SIP HTTPS / SIP

Traffic Optimization 1 – Localization
Localization == keep traffic in region whenever possible
Traffic from endpoints (CMS numeric pattern and CMS SIP domains) to CallBridges
is localized by leveraging CUCM “CSS/partition/RL/RG” or Local Route Groups
Global
Routing &
. . . Management
Regional
Call Control
. . .
Conferencing
(CMS cluster)
Americas EMEA APAC
Traffic back from CallBridges is localized by configuring

CallBridge (scope) specific outbound dial-plan rule (with CMS API)
Traffic optimization 2 - HA and loop avoidance
Avoid call loop when using CMS in other region as backup/overflow
Incoming CSS of trunk to other SME Incoming CSS of trunk to leaf CUCM has
can only see local CMS access to regional CMS and other SME’s
Global
Trunk_to_other_SME Trunk_to_regional_CUCM Routing &
.
IncomingCSS 
. . Incoming CSS  Management
(RP,RL,RG)  (RP,RL,RG) 
1) EMEA_CB1 1) EMEA_CB1
2) EMEA_CB2 2) EMEA_CB2 Regional
3) other SMEs Call Control
. . .
EMEA_CB2
Conferencing
Core EMEA_CB1 Core (CMS cluster)
Americas EMEA APAC
CMS 2.x White Paper : Load Balancing Calls Across Cisco Meeting Servers
Intra-region or Intra-DC distributed conferences should be
limited
Conference 1
Conference 2
Conference 3
Conference 4
Focus on one Region

EMEA EMEA
For these four conferences load balancing distribute If call legs belonging to the same conference
calls may create up to 17 call legs (9+4x2) are bound to a single CallBridge in the region,
With more CallBridges number can increase fast!! then the number of call legs is reduced to 9
(even with more CallBridges )
.
Call Bridge Group - Feature I: Grouping
• CMS 2.1 introduces the concept of CallBridge Group
• When CallBridges in the same region or DC are placed in the same CallBridge
Group, conference will not be distributed between them
• It leverages the SIP replace mechanism (supported by CUCM)
• When CUCM makes a call to a conference (space) in a CallBridge, if the conference
exists on another CallBridge in the same group, then the call is “replaced” to the correct
call Bridge
• Network Requirement : Max latency between members of a Call Bridge Group
100 ms RTT
replace query for conference YYY using server CB2 (priority: 0, load level: 0, conference is running: 1)
For reference
Call Replacement (simplified flow)

Call Bridge group EMEA
CUCM
Video EP with existing call

Space MySpace1 to MySpace1 on CB2
SIP: INVITE MySpace1 with Call_ID Supported:.. Replace
Do not forget CUCM

Rerouting CSS on replace query for conference YYY using server CB2 (priority: 0, load level: 0, conference is running: 1)
CUCM CMS trunk

and Accept replace replacing call Call_ID to conference YYY on server CB2
on SIP trunk security
profiles replacing call Call_ID from server CB1 into conference YYY
SIP: INVITE EndpointURI From spaceURI Replaces: Call_ID

SIP
SIP: INVITE EndpointURI
HTTPS / SIP SIP: CANCEL Call_ID
Video Call established on CB2 only
Media
Call Bridge Group – Feature II: Load Balance
• A mechanism is necessary to ensure load
balancing of conferences in the same EMEA_CUCM
CallBridge Group
• This is implemented by distributing conferences
3) Invite 1) Call to
based on conference_ID and bridge_ID hashing w/Replace Space 02
that generate a “priority” in the CallBridge choice to Space02
• It is totally transparent to the user

and it leverages the same replace mechanism 2) check
for call reallocation EMEA_CB1

EMEA_CB2
• Load balancing is applied from the first call to a space Space02

(priority EMEA_CB1,
then EMEA_CB2)
replace query for conference YYY using server CB2 (priority: 0, load level: 0, conference is running: 1) EMEA_CBGroup
Call Bridge Group - Feature III: LoadLimit
• Before version 2.1 the CMS carried on accepting calls
even when it was “full” by simply reducing other call
resolution to accommodate load Max load Limit
100%
• With 2.1 a max load Limit can be configured
on each CallBridge so that when a call is received
and the CMS is above a limit CMS rejects Existing Conference
Threshold 80 %
the call;
• Limit is variable according to the conference state
New Conference
Threshold 50%
• CUCM receives “SIP 488 ,Not acceptable
here”, and Dial Plan (RG, RL) can be
configured to route advance to next call bridge
• Because of this, one SIP trunk per CMS is required,
so that error handling “surface” to CUCM RG/RL level
CallBridge1 log: call XX: ending; local teardown, system participant limit reached
CallBridge2 log: replace query for conference YYY using server CB2 (priority: 0, load level: 2, conference is running: 1)
LDAP integration : user and space names
• CMS can be synchronized with LDAP to generate users and spaces
• A good mapping of AD fields into CMS objects creates a solid and flexible
naming structure
Use case 1
Active
CallBridge Database
Directory
AD
+ Space
Key parameters for mapping
User (XMPP ID & URI) Alice@meet.ucdomain.com
Username: $sAMAccountName$@meet.ucdomain.com
Space URI Alice.space@meet.ucdomain.com
Space URI user part: $sAMAccountName$.space
2nd Space URI 8884085267209@meet.ucdomain.com
Space secondary URI user part: 888$telephoneNumber$
CMS Dial plan : Inbound call processing
Stage 1 Incoming
Stage 2 Forwarding
• Is the call for this CMS ?
• For spaces, users, IVR ? Stage 3 Outgoing
• Shall the call be
• Does the call require a Lync forwarded ?
meeting resolution ? • Where to send the call ?
• With domain rewrite ?
• And how ?
In use case 1:
CUCM SIP domain ucdomain.com
CMS cluster SIP domain meet.ucdomain.com
CMS space will have dual alphanumeric and numeric URI
CMS dial plan configuration details EMEA_CUCM
ucdomain.com
Focus on configuration of one region: EMEA
EMEA Inbound dial rules for CUCM EMEA_CBGroup
EMEA_CB1 EMEA_CB2
Targets Targets Targets
Domain name Priority Targets Lync
spaces users IVRs
meet.ucdomain.com (1) 100 Yes Yes Yes No
EMEA_CB1_fqdn (2) 50 Yes Yes Yes No

meet.ucdomain.com
EMEA_CB2_fqdn (2) 50 Yes Yes Yes No

Call Bridge specific outbound dial rule (API)
EMEA Forward dial rules : none with same priority (keep traffic in EMEA)
EMEA Outbound dial rules for CUCM
Domain Local contact Trunk CallBridge
SIP proxy to use domain
Local from domain Behavior Priority(5) Encryption
type Scope
ucdomain.com EMEA_CUCM_fqdn (3) meet.ucdomain.com Standard Continue 10 <match CUCM> EMEA_CB1
ucdomain.com EMEA_CUCM_fqdn (3) meet.ucdomain.com Standard Continue 10 <match CUCM> EMEA_CB2
EMEA_CB1_IP EMEA_CB1_IP (4) Standard Continue 5 Auto All
EMEA_CB2_IP EMEA_CB2_IP (4) Standard Continue 5 Auto All
Dial transform for CMA/WebRTC numeric dial-out (1) Highest priority domain will be used in meeting request invite
(2) Assuming CUCM trunk has CMS FQDN as “destination address”
type Match exp. Transform Prior. Action (3) alternative : multiple rules for each Subscriber
(4) required by distributed calls when “default SIP route” is used
strip ($1/(.*)/) $1@ucdomain.com 10 accept (5) Same domain entries need equal priority
TMS Scheduling
From version 15.3 TMS supports CMS as scheduled bridge
CMS can be added as scheduled Bridge in TMS
CMS clusters support

Set CMS as preferred MCU
TMS Scheduling – CMS interaction
Administrator configures a CMS meeting TMS programs a set of static meeting into CMS
number range in TMS (with a domain)
TMS reconfigures the static meeting at the

conference start time by activating it and
updating the meeting name
Use Case 1 TMS Scheduling and OBTP - Flow
TMS+TMSXE
1) Meeting
2) Send OBPT
Calendar to Endpoints Global
Routing &
. . Management
.
3) Program
meeting
on CMS
4) OBTP to 4) OBTP to
Join Join Regional
conference conference Call Control
. . .
Conferencing
(CMS cluster)
5) Distributed call
Americas EMEA APAC
SIP CMS API EP API HTTPS / SIP EWS Media

Use case 2:
Scheduled conferences with white glove
services
Use Case 2
A large traditional worldwide enterprise where employers meeting are mediated by
white gloves service from an internal video service team
• Three worldwide regions The great majority of the video conferences are
• Redundancy with 2 DC in each region (**) • Scheduled and managed by the video team
• Traffic Optimization • Connected automatically (auto-connect)
Key challenges with scheduling with white glove
services
• Challenge 1: Optimal call routing with auto-connect
• Solution:
• If video endpoints belong to different regional SIP domains,
then a single worldwide CMS cluster can still be used and call routing optimized
- TMS 15.5+ and CMS 2.2+ to enable loadBalanceOutgoingCalls in CallBridgeGroup
- configure per region CallBridgeGroup specific outbound dial rules
• If video endpoints belong to same SIP domain,
then a separate regional CMS clusters can be deployed
• Challenge 2 : TMS Conference Control Center (CCC ) does not support CMS
• Solution :
• Cisco Meeting Manager (CMM)
TMS Scheduling with auto-connect with separate endpoint SIP domain
TMS
Global
Routing &
Management
. . .
1) Create
meeting
on CMS ap.example.com
Regional
. Call Control
. us.example.com 2) Conference .
Start
CBGroup EU
Conferencing
eu.example.com
(Global
CBGroup AP
cluster)
CBGroup US 3) Distributed Conference
on global CMS cluster
EMEA
Americas APAC
HTTPS / SIP Media EWS
SIP API
TMS Scheduling with auto-connect with single endpoint SIP domain
TMS
Global
Routing &
. . Management
.
1) Create
meeting
on CMS example.com
Regional
.
2) Conference Call Control
. example.com
Start .
Conferencing
CMS
CMS 3) Conference (Regional
Cluster on regional CMS CMS
Cluster EMEA cluster example.com
cluster clusters)
Americas APAC
IPZONE Americas IPZONE EMEA IPZONE APAC
EMEA
Americas APAC
HTTPS / SIP Media EWS
SIP API
Conference Management : CMM 1.x
Update CMS 2.3, CMM 1.0, TMS 15.6,
• From TMS 15.6 Meeting owner is passed to CMM

• Note also that Scheduled meeting appear as soon as it is activated,
even if no participant has joined yet (handy in white glove environments)
• CMS 2.3 adds call type (Lync, Space, Forwarded, Ad-hoc) to API GET to /calls for CMM
User case 3 -
Ad-hoc conferencing
Use Case 2
A large and dynamic worldwide enterprise where employers communicate on the fly
and need ad-hoc conference capability
• Three worldwide regions Mainly Ad-hoc conference with participant
• Redundancy with 2 DC in each region (**) belonging to any region
• Traffic Optimization Some rendezvous conferences
CUCM ad-hoc
• CMS 2.0+ supports CUCM ad-hoc calls
and it can be configured as CUCM
Conference Bridge
(type is conductor in CUCM 11.x and CMS in CUCM 12.x)
• Configuration is two steps

• A SIP trunk (secure or not secure) between
CUCM and CMS
• Conference Bridge - API connection (always
secure/HTTPS) from CUCM to CMS (*)
• CA-Signed certificates strongly

recommended
• Recommended to use prefixes
(URI uniqueness, troubleshooting, routing)
(*) same port as Webadmin
CUCM ad-hoc Conferencing - Architecture
Direct trunk from regional CUCM clusters for ad-hoc conference
Global
. . . Routing &
Management
Regional
Call Control
. . .
Core Conferencing
Core Core (CMS cluster)
Americas EMEA APAC
SIP API HTTPS / SIP Media

CUCM ad-hoc Conferencing
Simplified call flow
. . Global
.
Routing &
Management
.
.
Regional
Call Control
.
Merge
conference
Conferencing
Core Core Core
(CMS cluster)
Americas EMEA APAC
SIP API HTTPS / SIP Media

Use cases with large number of ports
but smaller regional footage
Single region, large port number use cases
1000 SIP HD ports, 1000 HD ports
no WebRTC or CMA clients 500 WebRTC or CMA sessions
CMS 2000: CMS 2000:

- Call-Bridge - Call-Bridge
- Webbridge - Webbridge
CMS 2000: CMS 2000:

- Database - Database
CMS 1000 (*): CMS 1000 (*):

Spec based VM: - Webbridge - Webbridge
- Database - XMPP (**) - XMPP (**)
(master) - Database - Database
CMS 1000 (*):
- Webbridge
- XMPP (**)
XMPP Call Bridge Cluster Database Connect Database Cluster - Database (*) or spec based VM
HTTPS + SIP TLS/Postgres TLS / Postgres (**) require server license
Single region, large port number use cases
480 (96x5) WebRTC or CMA HD sessions
(*) Optimization via CallBridgeGroup is a must
to minimize of distributed calls
CMS 1000: CMS 1000:
- Webbridge - Webbridge
(*) Note that this is below the 500 XMPP sessions limit
CMS 1000: CMS 1000: Alternatively the same topology can host 480 SIP HD ports,
- Call-Bridge - Call-Bridge but then it is worthy considering CMS2000 that doesn’t
- Webbridge - Webbridge “waste” capacity for distributed legs
- XMPP - XMPP
- Database CMS 1000: - Database
- Call-Bridge
- Webbridge XMPP Call Bridge Cluster Database Connect Database Cluster
- XMPP HTTPS + SIP TLS/ Postgres TLS / Postgres
- Database
• WebRTC proxy with Expressway
Edge • Edge design

CMS WebProxy feature in Expressway
• First step toward the single edge
• CMS WebProxy feature in Expressway leverages expressway existing capabilities (TURN
and MRA Web-Proxy) to facilitate firewall transversal of WebRTC CMS clients
• On expressway it can coexist with MRA, B2B, Registrar, IMP federation
but not with Jabber-Guest or Expressway-MS Interop
LIMITATIONS
• CMA native clients still needs classical CMS edge
• TURN on TCP port 443
Planned for Expressway X8.11
• Load balancing is supported, but no redundancy
• Expressway TURN for native/CMA clients is not yet supported
BRKCOL-2986 Kristof Van Coillie ICE / TURN / STUN Tutorial
From legacy CMS Edge to Expressway Web-Proxy
CMS EDGE SERVER Expressway-E

TURN
LOADBALANCER Expressway Web-Proxy

WEBBRIDGE TURN
WebProxy UC transversal
XMPP
XMPP CALLBRIDGE WEBBRIDGE UC transversal

CALLBRIDGE WEBBRIDGE client
CMS CORE SERVER CMS CORE SERVER Expressway-C
XMPP HTTPS / WEBRTC Media ; TURN

Expressway proxy for WebRTC
Architecture with updated DNS requirements
DMZ Internet
Expressway-C Expressway-E WebRTC Client
Core CMS
With WebBridge
DNS
DNS
External DNS (split) resolves

Internal DNS (split) resolves: (A) meet.myDomain to Expressway-E IP
1) (A) meet.myCompany.com to Webbridge IPs
2) (SRV) _cms-web._tls. meet.myDomain to Webbridge FQDNs
3) (SRV) _xmpp-client._tcp.MyDomain to XMPP FQDN(s) Add WebBridge and Expressway
FQDNs in certificate SANs
DNS HTTPS / WEBRTC Media/TURN

Web-Proxy Some configuration screenshots
Match to Guest Client Account URI in CMS GUI
CMS Edge Design – Sizing (*)
• Maximum number of concurrent XMPP clients per XMPP cluster: 500

(include CMA and WebRTC client, users and guests)
• Maximum number of concurrent WebRTC sessions per CMS server: 100
WebRTC proxy:
• Medium Expressway : max 100 media traversal calls per node
(B2B or MRA or WebRTC, any combination)
• Large Expressway Max 500 (**) WebRTC or 500 B2B calls per node
(*) Figures referred to expressway dedicated to the service mentioned

(**) Figure may be updated in upcoming expressway version X8.11
CMS Edge Design - Sizing
• TURN server allocation limits:
• CMS TURN server: max 1000 allocations
• Medium Expressway: max 1800 TURN allocations
• Large Expressway: max 6000 TURN allocations (*)
• Notes :
• Each CallBridge will use only one TURN server of a certain type (standard or Lync)
• TURN allocation are requested for every CMA, WebRTC and distributed calls (not on
standard SIP calls), TURN allocations are kept for the call duration (as safeguard for
network connectivity problems)
• With audio, video and content streams, each with media and control, 6 allocation are
needed per TURN client, so we can size 6 TURN allocations for internal calls, 12
TURN allocation for calls over internet (CMA or WebRTC)
(*) 6000 TURN allocation using one port are planned for new expressway release
CMS Edge Design – Service Selection
• A combination of factors influence edge service selection
and hence high availability and traffic localization:
• DNS resolutions
• RTT calculation
• Configuration
• Notes
• RTT has an important role so administrators have not full control on traffic localization
• CallBridge Groups feature at edge is not a complete solution but it helps in cleaning up the selection
process by “reducing the number of choices” (e.g. excluding choice like CallBridge in EMEA via TURN in APAC)
• When more granular control is required, explicit selection of CallBridge
can be used in alternative to CBGroup (e.g. TURN in DC1 in US is bound to CB in the same DC)
Next slides detail the mechanism and how they can be used for High Availability and Traffic
localization
Multiregional architecture with CMS edges
For CMA and WebRTC clients (this is the full picture for next slide diagram)
Americas EMEA APAC
CBGroup Americas CBGroup EMEA CBGroup APAC
LB WB LB WB LB WB LB WB LB WB LB WB
TU TU TU TU TU TU
CB WB CB WB CB WB
CB WB CB WB CB WB
XM DB XM DB XM DB
DC1 DC2 DC1 DC2 DC1 DC2
LB: LoadBalancer
WB: WebBridge CallBridge Groups include CallBridges, TURN and WebBridge servers
TU: TURN server
CB: CallBridge
XM: XMPP server BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 64
CMA: Service Selection
It affects High Availability and Traffic Localization (for full picture see previous slide)
(GEO) DNS SRV “Home” selection using RTT among LB: LoadBalancer
_xmpp-client Call Bridge direct and CallBridge via TURN WB: WebBridge
(TURN/CB pairs from CBGroups) TU: TURN server
CB: CallBridge
XM: XMPP server
LB WB TU TU WB LB TU LB WB
edge edge edge

Trunk Trunk
configuration configuration
-Turn configuration
-CallBridgeGroup
-RTT
WB CB CB WB XM XM CB WB
core core core

Region1 CallBridgeGroup1 Region2 CallBridgeGroup2 (partially shown)
1) Client selects LoadBalancer (DNS SRV)

Selecting entity and criteria
2) LoadBalancer selects XMPP server (trunk config) Selected Path
3) Client selects “home” CB, CB+TURN (CBGroups, RTT) Alternative selections
4) CallBridges selects TURN (CBGroups, RTT)
Multiregional Architecture with CMS and Expressway
WebRTC only
Americas EMEA APAC
Xway-E Xway-E Xway-E Xway-E Xway-E Xway-E
Xway-C Xway-C Xway-C Xway-C

Xway-C Xway-C
CB WB CB WB CB WB CB WB
CB WB CB WB
Core CMS XM DB XM XM
Core CMS DB Core CMS DB
Core CMS Core CMS Core CMS

LB: LoadBalancer
WB: WebBridge
CallBridge Groups include CallBridges and TURN servers in Expressway
TU: TURN server
CB: CallBridge
XM: XMPP server BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 66
WebRTC proxy via Expressway: Service Selection
It affects High Availability and Traffic Localization LB: LoadBalancer
(GEO) DNS A WB: WebBridge
meet.MyDomain + TU: TURN server
Xway cookie CB: CallBridge
XM: XMPP server
Xway-E
Xway-E TURN
TURN
Xway Clusters
Transversal
Configuration
Xway-C
(GEO) DNS SRV
Xway-C _cms-web._tls
-Turn configuration “Home” selection using RTT

-CallBridgeGroup among Call Bridge direct and
-RTTs CallBridge via TURN (TURN/CB
pairs from CBGroups)
WB CB CB WB XM XM XM WB
core core
Region1 CallBridgeGroup1 Region2 CallBridgeGroup2 (partially shown)
DNR SRV
1) WebBridge (and CB) has selected XMPP (DNS SRV) Selecting entity and criteria
2) Client selects Expressway-E (DNS A) Selected Path
3) Expressway Transversal (transversal) Alternative Selections
4) Xway-C selects WebBridge (DNS SRV)
5) WebBridge selects CallBridge/TURN (CBGroups, RTT)
6) CallBridges selects TURN (CBGroups, RTT) BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 67
Multiregional Architecture with CMS and Expressway Special use case
With limitation of cross DC traffic to DMZ
Americas EMEA APAC
Xway-E Xway-E Xway-E Xway-E Xway-E Xway-E
Xway-C Xway-C Xway-C Xway-C

Xway-C Xway-C
CB WB CB WB CB WB CB WB
CB WB CB WB
Core CMS XM DB XM XM
Core CMS DB Core CMS DB
Core CMS Core CMS Core CMS

LB: LoadBalancer • TURN servers are directly mapped to callBridge in same DC, Expressways are not clustered between
WB: WebBridge
TU: TURN server
DCs, Expressway-C use the regional WebBridges (GEO DNS)
CB: CallBridge • CallBridge Groups include CallBridges only
XM: XMPP server
Load-balancing of CMA native and WebRTC calls
New in CMS 2.3, this complements the load-balance feature suite
• The same mechanism to avoid distributed call inside a CallBridgeGroup is
available for client calls CMA and WebRTC on CMS 2.3
• Inside a CallBridgeGroup, CMA calls to the same meeting will not be distributed
and they will happen on one CallBridge (as long as it has capacity left)
• Configuration steps:
1. Add a CallBridgeGroup and place the CallBridge in the group
2. In the CallBridgeGroup configure (with API) loadBalanceUserCalls
(in addition to loadBalancingEnabled for SIP call load balance)
3. Ensure that each Call Bridge in the Call Bridge Group has a connection to the XMPP cluster or
single XMPP server
• Log messages are similar to a normal “load-balanced” call
For reference
Summary of LoadBalance CallBridgeGroups parameters

/callBridgeGroup API parameter Usage
loadBalancingEnabled = true Use to LoadBalance SIP calls to spaces and to minimize distributed
call between CallBridges in the same CallBridge Group
loadBalanceOutgoingCalls = true Use to optimally allocate outgoing calls to CallBridges or
CallBridgeGroups
loadBalanceUserCalls = true Use to optimally allocate user calls (webRTC and CMA) to
CallBridges or CallBridgeGroups
loadBalanceLyncCalls = false About loadbalancing lync/S4B calls to Spaces

Keep it as false, as it is not supported
WebRTC and Meeting Apps new look and features
New in CMS 2.3 and CMA 1.10
• Lock meetings, make participant important, mute
audio or video, drop
• "Activity" "People" and "Spaces" are replaced with
"Recent activity" and "Meet"
• Multiple way of join
• management and presentation : manage the meeting, see only
audio and presentation
• use this computer
• nearby endpoint: use video endpoint via proximity
• use my video endpoint: use video endpoint via SIP
• use my phone
BRKCOL-2803 Abhijit Dey Designing and deploying multiparty conferencing for telepresence video
On-Premises MS Interoperability
MS-Interoperability with CMS
Key features
• Native capability of CallBridge
• Interoperability with most of Lync/S4B versions and video protocols (SVC, H.264UC, RTVideo )
• On-premises or cloud
• Large scale
• Bidirectional content sharing
• Drag &Drop video participant
• Lync buddy list integration
• Presence information and in meeting IM
• Native user experience with Dual Home
BRKCOL-2610 Tobias Neumann Cisco Interoperability with Microsoft - Part 1, Collaboration
BRKCOL-2611 Fabio Chiesa Cisco Interoperability with Microsoft - Part 2, Video Interoperability
Skype for Business Integration call types
Gateway : call goes across CMS for adaptation and transcoding
Rendezvous : Video and Lync Endpoints meet in a CMS space
Dual Homed conferencing – Video endpoint joins a Lync/S4B meeting via

CMS as a native participants
Dial IVR+ConferenceID Join Lync Conference Click-To-Join
Video EP CMS
LYNC SERVER
AVMCU
5 media streams
Call types: Call start and user experience comparison
Call method CMS call type End user End user
experience experience MS
video side side
Direct point to point call Gateway Good Good

Endpoints and Video Clients Rendezvous Good Better layouts;
meet into a CMS space missing
participant roster
and controls
-Dial Lync meeting via IVR Dual homed Good Lync layouts,
-Drag and drop Video EPs into a roster and limited
Lync conference controls
Video endpoint user experience
When joining a Lync/S4B (dual homed) scheduled meeting
Option1: Meeting email invitation with additional

info about how to join Lync/S4B meeting from
Video Endpoint
[Modification of Lync email invitation form]
Option 2: One Button to Push

on endpoints
[TMS/TMSXE integration
with MS-Exchange]
For reference
Comparison of TMS scheduling with CMS and OBTP

without Lync participants With Lync participant on-prem
User add Lync Meeting in invitation No Yes
In outlook invitation, Rooms only Rooms and Lync conference ID

TMSXE service user will look at
CMS Query for Lync Conference_ID No SIP SERVICE message
to resolve lync conference
Book CMS scheduled spaces Yes No
OBTP content <CMS_Scheduled_Space>@<C <Lync_Conferece_ID>@

MS_Domain> <Lync_Domain>
CMS meeting type Rendez-vous Dual homed
For reference
Dual homed call setup via IVR (*) Video EP

MS Front End & AVMCU Call Bridge
Lync client
Client creates
a Lync Meeting
Email invite with Lync Meeting ID: 969306786

SIP: INVITE IVR
Lync clients join meeting
Type meeting ID "969306786" from invitation email
Lync resolution for "969306786"

SIP: SERVICE sip:FEP-FQDN….<resolveConference> <pstn-meeting-id> 969306786
SIP: OK… <msci:conference-id>3BG9G902

Lync conference join
INVITE sip:LyncUser@LyncDomain .....:conf:focus:id:3BG9G902
Lync conference subscription

SIP: SUBSCRIBE sip:LyncUser@LyncDomain .. 3BG9G902
SIP: OK with Conference information.
All participant in a dual homed meeting
(*) simplified Media SIP BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 78
Use Case 4
Customer is a Large Enterprise with Cisco UC + Video and on-premises Lync/S4B
requiring full featured integration between the two worlds
• Three worldwide regions (**) • Point to point call between Video EP and
• Redundancy with 2 Data Centres (DC) in each Lync/S4B clients
region (**) • Lync/S4B clients able to join Spaces on CMS
• Traffic Optimization (localize the traffic to (rendezvous)
regions whenever possible) • Video Endpoints able to join Lync meetings via
OBTP and via IVR with full features (dual
homed)
This is an extension of use case 1; configuration is additive to the one in use case 1
Use case 4 : Architecture
Calendar
Global
. .
TMS & TMSXE
Routing &
.
Management
Regional
Call Control
. . .
Conferencing
CMS cluster
MS Lync/S4B
Front End Pool +Infra Front End Pool +Infra Front End Pool +Infra
Americas EMEA APAC

(*) DB server not shown
for simplicity
SIP HTTPS / SIP (MS) SIP
LDAP integration : User and Space names
• The simple solution is to use a different domain for CUCM, CMS and Lync/S4B
SIP domains URIs

CUCM ucdomain.com user@ucdomain.com
Lync/S4B lyncdomain.com user@lyncdomain.com
CMS Spaces meet.ucdomain.com user.space@meet.ucdomain.com
CMS users: user@meet.ucdomain.com
• This ensure that user and space URIs do not overlap with Lync/S4B URI
Use case 4 : Traffic optimization (localization)
Traffic from local EPs to Lync domain is kept local by CUCM DialPlan(*)
Global
Routing &
Traffic. from call Bridge to Lync is . Management
kept local by using CallBridge
specific outbound dial rules
Traffic from call Bridge to CUCM is
kept local by using CallBridge Regional
specific outbound dial rules Call Control
. . .
Conferencing
CMS cluster
Traffic from Lync to CallBridge is

kept local by FEP specific static
MS Lync/S4B
routes
Americas EMEA APAC
(*) interregional secondary path is possible
but pay attention to call loop
SIP HTTPS / SIP (MS) SIP
For reference
CMS configuration details ucdomain.com
Focus on Lync related configuration of one region: (*) EMEA_CBGroup

EMEA_CB2
EMEA_CB1
meet.ucdomain.com
SIP Domains
CUCM ucdomain.com
CMS meet.ucdomain.com
lyncdomain.com
Lync lyncdomain.com
Call Bridge specific outbound dial rule (API),
same priority
EMEA_FEP
CMS Dial Plan: EMEA Outbound dial rules for Lync (CUCM rules omitted)
Domain Local contact Local from Trunk CallBridge
SIP proxy to use Behavior Priority Encryption
domain domain type Scope
lyncdomain.com EMEA_FEP_fqdn EMEA_CB1_fqdn ucdomain.com Lync Continue 10 Encrypted EMEA_CB1
lyncdomain.com EMEA_FEP_fqdn EMEA_CB2_fqdn ucdomain.com Lync Continue 10 Encrypted EMEA_CB2
CMS Dial Plan: (additional) Inbound dial rules for Lync CMS Dial Plan: Forward dial rules
Targets Targets Targets Targets
Domain name Priority Forward both ucdomain.com and lyncdomain.com
spaces users IVRs Lync
with no changes
lyncdomain.com 20 No No No Yes
CMS FQDN(s) 10 Yes Yes Yes Yes Direct numeric call from CUCM to Lync Meeting (optional
(*) to be ©added
BRKCOL-3990 toand/or
2018 Cisco configuration
its affiliates. All rightsfor useCisco
reserved. casePublic1 83
For reference
Lync configuration details ucdomain.com
Focus on one region: EMEA EMEA_CBGroup

EMEA_CB1 EMEA_CB2
meet.ucdomain.com
SIP Domains
CUCM ucdomain.com
CMS meet.ucdomain.com EMEA shared CMS Certificate
lyncdomain.com
Lync lyncdomain.com CN: EMEA_CBGroup_fqdn
SAN: EMEA_CB1_fqdn, EMEA_CB2_fqdn
EMEA_FEP
New-CsTrustedApplicationPool -Identity EMEA_CBGroup_fqdn -ComputerFqdn EMEA_CB1_fqdn -Registrar EMEA_FEP_fqdn -site 1 -

RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
FEP specific application pool
New-CsTrustedApplicationComputer –Identity EMEA_CB2_fqdn –Pool EMEA_CBGroup_fqdn
New-CsTrustedApplication -ApplicationId EMEA-CMS-Group -TrustedApplicationPoolFqdn EMEA_CBGroup_fqdn -Port 5061
$Route1 = New-CsStaticRoute -TLSRoute -Destination EMEA_CBGroup_fqdn -MatchUri ucdomain.com -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity “Service:Registrar:EMEA_FEP_ID” -Route @{Add=$Route1}
$Route2 = New-CsStaticRoute -TLSRoute -Destination EMEA_CBGroup_fqdn -MatchUri meet.ucdomain.com -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity “Service:Registrar:EMEA_FEP_ID” -Route @{Add=$Route2}
1. EMEA_FEP_ID from Get-CsStaticRoutingConfiguration
2. Moving from routing global to “FEP specific” requires full re-config !! FEP specific static routes
CMS 2.3 S4B meeting optimization: dualHomeCluster mode
default and pre-2.3 behaviour
(MS) SIP
SIP Audio/Video
XMPP
Lync
proxy Distributed
HTTPS / SIP leg call leg
Media
Lync proxy leg
dualHomeCluster (*): Behaviour as in previous versions. Conferences on callbridges have distribution and Lync
proxy calls between them. All calls to S4B meeting from one callbridge. CMS participants video mixed by CMS.
Use this mode when a single cascading point per S4B dual homed conference is preferable
(*) lyncConferenceMode in /callProfiles/

SIP HTTPS / SIP
CMS 2.3 S4B meeting optimization: dualHomeCallbridge mode
No distribution between callbridges
(MS) SIP
SIP Audio/Video
XMPP
HTTPS / SIP
Media Conference & Participants info
Lync proxy leg Audio/Video
dualHomeCallBridge: No distribution between callbridges. Separate conference on every callbridge, each with
calls out to S4B meeting. A/V mixed by S4B AVMCU.
Use this mode when a independent cascading points to S4B conference on each CMS are preferred
A typical use is when conference participants are mostly belonging to the same region and you want to avoid that when the conference is
opened by a participant in the region with few participants, traffic is anchored on this region CMS and then clearly suboptimal
SIP HTTPS / SIP

CMS 2.3 S4B meeting optimization: gateway mode
CMS creates legs for each endpoint
(MS) SIP
SIP Audio/Video
XMPP
HTTPS / SIP
Media Conference & Participants info
Lync proxy leg Audio/Video
gateway: No distribution between callbridges. Each SIP participant in its own conference with associated
calls out to S4B meeting. A/V mixed by S4B AVMCU.
Use this mode when separate and independent “gateway” call legs for each endpoint are needed
with the purpose of giving the “full control” of the meeting to the S4B AVMCU
(note that this is still a dual homed call because S4B meeting need to be resolved)
SIP HTTPS / SIP
MS interoperability off-premises
MS interop off-premises - Use Case 5
Customer is a Large Enterprise with Cisco UC and without on-prem MS infrastructure
requiring integration and federation with external organizations using MS and
standard SIP
Structural requirements : Conferencing requirements:
• Three worldwide regions • Video calls with external organizations using
• Redundancy with 2 Data Centres (DC) in each standard SIP
region • Video calls with external organizations with own
• Traffic Optimization MS infrastructure or using O365
• Join meetings (spaces) hosted on this
organization CMS cluster with any client
TECCOL-2225 Davide Preti, Fabio Chiesa Cisco Collaboration and Microsoft Skype for Business - Best Practices for a successful coexistence and migration
CMS with Expressway Edge: Basic Architecture
Expressway advanced search rule filtering options : any part of URI ,SIP variant, SIP content (AV/Share or IM&P)
All traffic that needs smart SIP analysis will be sent to expressway
When required, Expressway hairpins the call leg to CMS for the adaptation and transcoding for MS-interop
Points of attention and limitations
Points of attention and limitations
Expressway do not support yet load balance with CMS (callBridgeGroup)
Hair-pinning traffic to CMS from Expressway require a relatively complex dial plan
Because of that for large deployments, it is simpler to have one separate “adaptation” CMS
per region – separate from the interregional MS cluster
Regional Global Routing Global Conferencing Edge External
Call control with core CMS cluster with adaptation CMS Users
Other SIP domains
Organization with
MS infrastructure
Americas
O365 Clients
B2B standard SIP

EMEA
APAC
SIP HTTPS / WebRTC (MS) SIP
O365 OBTP Dual Homed experience
• Office 365 users join skype meeting (o365 cloud same organization)
from Video Endpoints with OBTP and with Dual Homed Experience
• Prerequisites: CMS 2.2, TMS 15.5, TMSXE 5.5, X8.10.2+
• Operation (see next slide) :
• TMSXE monitors the room mailboxes
• When it sees a meeting it gets the skype alphanumeric URL value fetched from MAPI property
• TMSXE appends the cisco meeting server domain name (a sort of dummy/routing domain)
• TMS saves the appointment in TMS as “Externally Hosted” conference
(no resource local reserved)
• When meeting start and OBTP is pressed, CMS resolves the Lync Simple Meet URL
(requires both connectivity to internet and permission to resolve)
• Then CMS sends an INVITE to join the resolved meeting
O365 OBTP Dual Homed experience
TMS/TMSXE Video EP CMS Expressway-C Expressway-E
O365 client
O365 client books a meeting adding room participants
Fetch meeting info, including “join Lync” URL
Program OBTP with Simple_URI @cms_domain
INVITE Simple_URI @cms_domain
https Resolve Simple URI
Meeting URI and id
INVITE user@LyncDomain;gruu;.......:id:<Lync MeetingID>
ICE Negotiation
MS SIP SIP EP API HTTPS / EWS ICE Media

O365 OBTP Dual Homed: Configuration screenshots (*)
TMSXE: Define CMS domain + Skype support for Multiple Domains
CMS: Define CMS domain + Target Lync SimpleJoin
ExpresswayC: call hairpinning to and from CMS for SIP MS variant adaptation + reach O365 via transversal
(*) SIP domains used in the example

• sthlab.onmicrosoft.com : 0365
• Meet.lync.com : CMS domain for 0365 OBTP
• sthlab.net : CUCM
O365 OBTP Dual Homed: Some operational screenshots
Lync/Touch: See combined participant list
…….But controls affect only one side
TMS: Meeting confirmation email
EP: OBTP with Simple URI
B2B SIP Microsoft AV calls to O365

on Expressway C and E
For reference
Comparison of TMS scheduling with CMS and OBTP

without Lync participants Lync on-prem O365 Dual homed
experience
User add Lync Meeting in No Yes Yes
invitation
In outlook invitation, Rooms only Rooms and Lync Conference ID Rooms and Conference URL
TMSXE service user will look at
CMS Query for Lync No SIP SERVICE message https conference resolution
Conference_ID to resolve lync conference
Book CMS scheduled spaces Yes No No
OBTP content <CMS_Scheduled_Space>@ <Lync_Conferece_ID>@ <Lync_Simple_URI>@

<CMS_Domain> <Lync_Domain> <CMS_Domain_for_interop>
CMS meeting type Rendez-vous Dual homed Dual homed experience
Hybrid Conferencing
How apply large scale design principles to cloud/hybrid conferencing
Hybrid Media Node Highlights
• HMN is an on-prem extension of the Webex/Spark cloud

• Runs on CMS-1000 (or MM410v or spec based VM)
• Improve media quality by reducing latency and bandwidth consumption
• Automatic overflow. Controllable automatic upgrade
• In Phase II, HMN supports spark clients, spark rooms and SIP video endpoints
• Management via the spark admin with resource monitoring and usage metrics
• HMN can be installed in core or in DMZ
• It requires minimal number of Firewall ports to be opened
BRKCOL-2607 Louis Pratt Understanding Cloud and Hybrid Cloud Collaboration Deployment
BRKCOL-1120 Richard Murphy Cisco Spark Hybrid Media Node
BRKCOL-2202 Luca Pellegrini Cisco Spark Hybrid Call Services Architecture and Design
BRKCOL-2030 Anthony Mulchrone Cisco Spark - Cloud and On Premise Security explained
Conferencing Architecture with Hybrid Media Node in core
PSTN
Webex
Overflow client
CUCM
Expway-C Expway-E Traffic
WebEx/Spark
SIP Video
Endpoints
HMN
Spark
Clients
Spark Video
Endpoints
Webex
clients B2B partner
HTTPS Webex session

SIP REST/API Other Signaling/media Audio Video HMN Video
Media
Signaling
Conferencing Architecture with Hybrid Media Node in DMZ
PSTN
Webex
Overflow client
CUCM
Expway-C Expway-E Traffic
WebEx/Spark
SIP Video
Endpoints
HMN
Spark
Clients
Spark Video
Endpoints
Webex B2B partner

clients
900
WX media
HTTPS WX session 9000 udp
SIP REST/API Signaling 443 tcp Audio Video HMN Video
Media
Signaling
Use case 5 : Hybrid Conferencing with large hub site
Large Enterprise with Cisco UC and video looking for cloud web conferencing
• Large hub site with two DC Webex Meetings
• Redundancy Personal Meeting Rooms
• Maximize Local (on-premises) Media Scheduled Meetings
Termination
• Traffic Optimization
Design Notes
HMN placed in core
• Local media stays in core
• Minimal number of port opened on internal firewall
• Avoid traffic between DMZs in different DCs
(caused by HMN inter-cluster signalling and media)
HMN placed in DMZ
• Security policies may prefer this:
the “extension of the cloud” devices is confined to DMZ
Use case 5 Architecture with Hybrid Media Node in core
Minimization of ports to be opened on internal FW and of traffic between DMZs in different DCs
DC 1
SIP Video CUCM Expway-C Expway-E (*)

Endpoints
Spark
Clients HMN WebEx/Spark
Cluster HMNs
Spark Video
Endpoints
DC 2
WX
clients HMNs
CUCM Expway-C Expway-E (*)

(*) Expressways are clustered inside a DCs, not between DCs
HTTPS Webex session

SIP REST/API Other Signaling/media Audio Video HMN Video
Media
Signaling
Use case 5 Architecture with Hybrid Media Node in DMZs
The “extension of the cloud” device (HMN) is confined to DMZ but more inter-DMZ traffics and more opened ports on internal FW
DC 1 Expway-C (*) Expway-E (*)
SIP Video CUCM

Endpoints
Spark
Clients WebEx/Spark
Spark Video
Endpoints
DC 2
WX
clients HMN Cluster
CUCM Expway-C (*) Expway-E (*)

(*) also Expressways are clustered between DCs
HTTPS Webex session Expway

Media SIP REST/API Other Signaling/media Cluster Video HMN Video
Signaling
Design Notes
CUCM SIP trunk(s) to HMN

• Cloud allocates HMN within cluster (CUCM is informed by SDP)
=> HMNs in same cluster can be assigned to same CUCM SIP trunk
(One trunk with multiple HMN IPs for each HMN cluster)
• CUCM Route Groups/Lists are needed for

1. Traffic overflow via Expressway
(route advance on SIP error 488)
2. Routing to multiple HMN clusters
Cloud Allocation of HMN within HMN cluster
How CUCM is informed about the HMN to use
Video Endpoint CUCM HMN
Cloud Allocation of HMN within HMN cluster
There is not much benefit in leveraging CUCM route advance within an HMN cluster
Video Endpoint CUCM HMN1 HMN2
Design Notes – Bandwidth utilization
Device Behavior Typical bandwidth with 720p resolution
HMN Switch media whenever possible Send up to 6 streams between HMNs

(on-prem and cloud) Transcode media when required including roster participants using original
participant stream resolution
Spark devices Receive multiple streams with participants to 1 Mbps to 2.5 Mbps
(rooms and clients) compose in local layout
SIP Video Receive pre-composed stream with layout 1 Mbps to 2.5 Mbps
Endpoints (traditionally coming from a transcoding video bridge)
Webex Client Receive multiple streams with participants to Up to 2Mbps

compose in local layout ;
only main participant is at full resolution
BRKCOL-1120 Richard Murphy Cisco Spark Hybrid Media Node
Design Notes – Bandwidth utilization - Examples
SIP + Webex clients (average bandwidths)
Webex
client (on cloud)
2 Mbps 2 Mbps (max)
SIP Video
Endpoints
WebEx/Spark
SIP Video
Endpoints
HMN
SIP Video
Endpoints
SIP Video
Endpoints
Webex
clients
(on prem)
(*) Two participant streams but only one sent with 720p
Webex session
media Audio Video HMN Video
SIP + Webex + Spark clients
Webex
client (on cloud)
2 Mbps 2 Mbps
SIP Video
Endpoints
WebEx/Spark
SIP Video
Endpoints
HMN
SIP Video
Endpoints
Spark Video
Endpoints
Webex
clients
(on prem)
Spark Video
B2B partner
Endpoints
(*) 4 participant streams but only 3 with 720p

Webex session
Attention to unbalanced conferences
6 streams 1 stream
vs.
1 stream 1 stream
Remote Video Remote Video
Endpoint Endpoint
Webex session
Use case 6 : Hybrid Conferencing with multiple regions
Large Enterprise with Cisco UC and video looking to migrate from a legacy
conferencing infrastructure to cloud web conferencing
• Three worldwide regions Webex Meetings
• Redundancy with 2 DC in each region Personal Meeting Rooms
• Maximize Local (on-premises) Media Scheduled Meetings
Only SIP Endpoints and Webex clients
Termination
• Traffic Optimization
Additional Design Notes
CUCM SIP trunk(s) to HMN HMN selection (SIP devices)
• CUCM trunks to different HMN • HMN cluster used for the call is
regional clusters need be separate chosen by CUCM
HMN traffic • HMN server inside a cluster is chosen
by the cloud based on HMN inputs
• HMN intra-cluster traffic stays within (latency, load)
enterprise network
HMN selection (Spark clients/rooms)
• HMN inter-cluster traffic use cloud
• HMN is chosen by cloud based on
reachability info provided by client
(STUN RTT) with preference for on-
premises HMN
Additional Design Notes
Want to keep media on-premises Approach to limit HMN inter-cluster traffic for
SIP devices: CUCM Time Of Day Routing
• Do not close port 5004,
1. Prefer a regional HMN cluster at a certain time of the
this will cause split meetings !! day,
• Traffic via cloud can be reduced but not 2. with alternate route to the other HMN regional
avoided, the following traffic types go clusters for High Availability and Overflow
anyway via cloud 3. and to cloud via Expressway for overflow
• Spark/HMN signaling • TOD time switch should avoid meeting start time
• Webex signalling and media :00, :30 (:45 may be a good choice)
• HMN Inter-cluster signalling and media
Limitations
• Spark clients and rooms (not covered by this use case)
do not follow CUCM allocation.
• Strategy applies only to dial in to Webex/HMN
Future HMN dial out feature may not fit this approach
Endpoint SIP Call control On premises Hybrid conferencing layer Regional Edges Webex/Spark
cloud
During US business hours

1) HMN cluster Americas
2) HMN cluster EMEA, APAC
HMN cluster Americas
3) Overflow to cloud via US Expressway
Americas
During EMEA business hours

1) HMN cluster EMEA
2) HMN cluster Americas, APAC
3) Overflow to cloud via EMEA Expressway
HMN cluster EMEA WebEx/Spark
EMEA
During APAC business hours

1) HMN cluster APAC
2) HMN cluster Americas, EMEA
3) Overflow to cloud via APAC Expressway HMN cluster APAC
APAC
Conclusions
When planning a large conferencing infrastructure, you cannot “count on magic”.
Good planning and design enables a seamless and robust deployment.

Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKCOL-3990
• Please complete your Online Complete Your Online
Session Evaluations after each
session
Session Evaluation
• Complete 4 Session Evaluations
& the Overall Conference
Evaluation (available from
Thursday) to receive your Cisco
Live T-shirt
• All surveys can be completed via
the Cisco Live Mobile App or the
Communication Stations
Don’t forget: Cisco Live sessions will be available
for viewing on-demand after the event at
www.ciscolive.com/global/on-demand-library/.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Tech Circle
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you
BACKUP SLIDES
Cisco Advanced Services
Cisco Advanced Services Portfolio
Implement Services
ADVISE IMPLEMENT • Integrate new solutions with existing

technology
• Migrate from your current state to
Advise Services future-state solution
• Develop a strategy to align your • Validate that the solution meets your
people, process, and technology business and technical needs
• Assess your network, infrastructure,
security, and readiness for change
• Design sustainable architectures and
tech-enabled business processes
Optimize Services
• Recommend best practices for
maintaining your solutions
OPTIMIZE • Remediate solution-related issues
• Analyze solution value and recommend
adjustments or improvements
Cisco Meeting Server Services
Advise and Implement
• Highly scalable video and audio conferencing design Cisco
TelePresence
Cisco MCU
• Interoperability with Microsoft Lync/Skype for Business and WebRTC Server
• Extensible to new user video experiences and business interactions

• Migration from legacy MCUs and/or TelePresence Servers
• Flexible, global on premise deployment model Migrate
Cisco
Meeting
Optimize Server
• Ongoing capability, functionality, and capacity evolution

• Escalation support for critical or service impacting incidents/ problems Interoperate
• Security alerts and risk mitigation

• Enterprise wide change management and architectural integrity
• Knowledge transfer - architecture and design changes, migration testing
Other relevant AS value added services are available: NPA, MNRA, Adoption.
Please contact AS Global BDM team for Advanced Services scoping & quotes.
Value Added Services
Proposed AS Value Added Services
Customer Issues
• When installing Cisco Meeting Servers in new data centers Network Path Assessment (NPA)
• When installing Cisco Meeting Servers that have more capacity than the
existing MCUs / TelePresence Servers -- or –
• New video customers deploying video bridges for the first time
• Migration from third party video bridges / services (on-premises or cloud) Media Network Readiness
• Customer environment has known video quality issues Assessment (MNRA)
• Customer's needing assistance with an end-user communication plan

• Customer's needing assistance with educating end-users on any Adoption Services
experience changes after the deployment
* Contact AS Global BDM team to determine which service is appropriate
CMS configuration quick start
For reference
Configuration quick start - basic

• Configure IP • Certificate command (transfer with sftp)
• ipv4 a add <CMS_IP>/<mask> <def_GW> • Pki list
• Hostname <CMS_name> • Pki match <key> <cert>
• Pki inspect <cert>
• 2nd admin and an API user
• user add admin2 admin • License (transfer with sftp file cms.lic)
• user add apiuser api • License
• Ntp server • Webadmin
• Ntp server add <NTP_IP> • Webadmin listen a 8443
• Timezone <timezone> • Webadmin certs <key> <cert> <rootbundle>
• Webadmin enable
• DNS add and verify
• Dns add forwardzone <DNS_IP> • CallBridge
• Dns lookup a <address to lookup> • callbridge listen a
• Dns lookup SRV _xmpp-client._tcp.xxx • callbridge certs <key> <cert> <rootbundle>
• callbridge restart
For reference
Configuration quick start - Spaces

• Add IVR
• GUI->configuration->General
• Add static Rendezvous meeting

• GUI->configuration->Spaces
• Active Directory (example)
• Base DN :OU=Training,DC=EXAMPLE,DC=com
• FILTER: (&(objectCategory=person)(objectClass=user)(!(cn=Administrator))(!(cn=Guest))(!(cn=krbtgt)))
• Display name: $cn$
• Username: $sAMAccountName$@meet.example.com
• Space Name $sAMAccountName$.space
• Space URI $sAMAccountName$.space
• Secondary Space URI 15$telephoneNumber$
For reference
Configuration quick start – XMPP & WebBridge

• XMPP • Webbridge
• xmpp listen a • Webbridge listen a
• xmpp certs <key> <cert> <rootbundle> • Webbridge certs <key> <cert> <rootbundle>
• xmpp domain meet.example.com • Webbridge trust <callBridge_cert>
• xmpp enable • Webbridge enable
• Add callbridges (CLI on xmpp server) • Webbridge Web GUI config (or API)
• xmpp callbridge add core1
• xmpp callbridge add core2
• Xmpp callbridge list
• Connect CallBridge to XMPP (GUI or API)
• CMS Dial Plan – see core section
Core
For reference
CMS cluster operation during outages

If connection to DB is lost, operation stop or it is severely degraded
Operation Status Condition Features available
All read and write queries are always directed to current

DB Master, wherever it is. It is not possible to perform any
READ/WRITE CallBridge is fully featured
WRITE operation to a database which is not elected as
current Master.
inbound/forwarding/outgoing calls
If CallBridge server has local, collocated database, it can
possible, TMS scheduled conferences
READ-ONLY only read from local database when Master DB is not
will not work, dual home conferencing
accessible.
may not work
If CallBridge is a standalone - no local database on the
NO OPERATION CallBridge “death”,
same server, it can't do read access to any node except
POSSIBLE only outgoing calls may work
the Master DB.
For reference
Distributed call Setup

Call Bridge Cluster Enpoint2
CUCM2
Enpoint1 CUCM1
DB: MySpace1
First call established
Intra-cluster dialogue finds that the space is already active in in CB1
CB1: generating peer URI sip:Conf_ID@CB1 for coSpace <spaceID>

CB2: call <Call ID> now peered with conference on server CB1 (peer URI Conf_ID@CB1)
SIP
SIP: INVITE Conf_ID@CB1
HTTPS / SIP
Distributed Video Call established

Media
For reference
Call Replacement (simplified flow)

Call Bridge group EMEA
CUCM
Video EP with existing call

Space MySpace1 to MySpace1 on CB2
SIP: INVITE MySpace1 with Call_ID Supported:.. Replace
replace query for conference YYY using server CB2 (priority: 0, load level: 0, conference is running: 1)
replacing call Call_ID to conference YYY on server CB2
replacing call Call_ID from server CB1 into conference YYY
SIP: INVITE EndpointURI From spaceURI Replaces: Call_ID

SIP
SIP: INVITE EndpointURI
HTTPS / SIP SIP: CANCEL Call_ID
Video Call established on CB2 only
Media
LDAP integration : things to watch
• AD mapping creates 3 dial-able URIs in CMS :
Primary and Secondary Space URI and User URI
=> None of them should overlap with other URI in the network
• Dual mapping with alphanumeric and numeric URI for spaces provides a
flexible way to join spaces
• Sizing : If more than 30000 users need to be imported from AD, the design
should be validated by Cisco
• There is a lot of flexibility in configuring LDAP
• Multiple LDAP sources and mapping can be configured
• LDAP configuration on CallBridge is per server when configured using GUI
• All CallBridges in a cluster can update users and space database
• For a clustered environment, it is best to configure LDAP integration using API
But case should be take to to avoid feeding CMS with incongruent information
For reference
CMS 2.2 – Load balancing of outbound SIP calls

Operation:
• When CMS receive an API request to make an outbound call,
it finds the highest priority outbound dial plan rule that matches the SIP domain,
• if this applies to a local Call Bridge, then balance the call within the local Call Bridge Group.
• if this only applies to remote Call Bridges, then load balance the call within the Call Bridge
Group to which the Call Bridge is a member
As a consequence, traffic can be optimized as long as video endpoints belong to

different regional SIP domains
Recording and Streaming
Recording and streaming basic architecture
RECORDING
xmpp client
NFS/mp4
CallBridge + NFS server Video
Recorder Management Viewing
XMPP server Clients
Server
STREAMING
xmpp client
RTMP/H264
CallBridge + Streamer Streaming
XMPP server Server Streaming
Clients
Third party
BRKCOL-2544 Terry French Enterprise Webcasting and Recording Architecture with VBrick Rev
XMPP Media Media (NFS) Media (RTMP)

Sizing
Virtual Machine
• Recording and Streaming needs separate VM with minimum 4 vCPUs
• Streaming: 1 vCPU and 1GB of memory per 6 concurrent streams (max 6 VM)
Recording: 1 vCPU and 0.5GB of memory per concurrent recording (max 8 VM)
Network
• Stream media is H264 at 720p30 (2Mbps)
Disk
• The size of 720p30 recordings ranges from 300MB to 800MB for 1 hour
• Presentation is captured in the main recording stream, not separately
Scaling Streaming and Recording
Call Bridge Groups allow optimal allocation of resources
Edge
• WebRTC proxy with Expressway
• Edge design
For reference
CMA Sign-in and Join a space (simplified)
CMA
client LoadBalancer XMPP Server TURN CallBridge(s)
DNS
DNS SRV lookup _xmpp-client._tcp.MyDomain
Sign-in + userID, password

Validate credential
AD
list of CB and CB via TURN
CMA Client: Evaluate RTT among CB and CB via TURN, Choose CB
Welcome CMA Screen
Join Space
Call Request
Port Allocation Request[UDP 3478]

Answer
Answer with TURN address and port to use
Port Allocation Request[UDP 3478 or TCP 443]
UDP or TCP UDP
DNS XMPP HTTPS / WEBRTC Media/TURN BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 145
For reference
WebRTC Sign-in and Join a space (simplified)
Web
XMPP via CallBridge
client WebBridge TURN
LoadBalancer
DNS
DNS A lookup meet.MyDomain
Sign-in + userID, password
DNS SRV lookup _xmpp-client._tcp.MyDomain
Authenticate Validate credential

AD
list of CB and CB via TURN
WB:Evaluate RTT among CB and CB via TURN, Choose CB
Welcome CMA Screen
Join Space Call Request

Answer
UDP or TCP UDP
For reference
WebRTC Guest joins a Space (simplified)
Web
DNS XMPP via CallBridge
client WebBridge TURN
LoadBalancer
DNS A lookup meet.MyDomain
Join a meeting + Meeting_ID & passwd
DNS SRV lookup _xmpp-client._tcp.domain
Validate Meeting_ID & passwd

Enter Name + Join
Request guest credentials
Authenticate
Validate credentials
TBV list of CB and CB via TURN
TBV WB Evaluate RTT among CB and CB via TURN, Choose CB, Call Request

Answer
UDP or TCP UDP
For reference
CMA: Traffic Localization and High Availability Tools

Selecting entity Service / Server Section method Localization High Availability
Client LoadBalancer DNS SRV GEO DNS Multiple LB SRV records

and/or smart DNS
Load Balancer XMPPserver Trunks configuration Local Trunk Multiple trunks from
LoadBalancer to XMPP
servers
CMA client (via CallBridge (CB) CMA Client estimation - TURN according to Multiple CallBridges
XMPPserver) RTT among CB and CB CBgroups
via TURN ( sticky result, - RTT favours regional
selected CB will be servers
“homeCB” )
CallBridge (CB) TURN Server CB RTT estimation + RTT and CBgroup Multiple TURN choices
CallBridgeGroup (same as above) per CB
CMA Client TURN server at CMA Received by CB after CB Decided in previous step Multiple TURN servers
client side turn allocation
TURN protocol and Try fist UDP.3478, then Decided in previous step Multiple TURN servers
port at CMA client TCP.443
side
For reference
WebRTC: Traffic Localization and High Availability Tools

Client WebBridge (WB) DNS A (need that client sticks GEO DNS Multiple WB A records
with one WebBridge IP) and/or smart DNS
WebBridge LoadBalancer DNS SRV GEO DNS Multiple SRV records and/or
smart DNS
Load Balancer XMPPserver Trunks configuration Local Trunk Multiple trunks from
LoadBalancer to XMPP
servers
WebBridge (via CallBridge (CB) WebBridge estimation - TURN according to Multiple CallBridges
XMPPserver) RTT among CB and CBgroups
CB+TURN (TBVerified) - RTT favour regional
( sticky result -> “home CB”) servers
WebBridge XMPP server DNS SRV record GEO DNS XMPP clustering
CallBridge (CB) TURN Server CB RTT estimation + RTT and CBgroup Multiple TURN choices per
CallBridgeGroup (same as above) CB
WebBridge Client TURN server at Received by CB after Decided in previous step Multiple TURN servers
client side CallBridge TURN allocation
TURN protocol & Try fist UDP.3478, then Decided in previous step Multiple TURN servers
port at client side TCP.443
For reference
WebRTC Expressway Proxy : Localization and HA Tools

Client Expressway-E DNS A (Xway sticks the GEO DNS Multiple Xway-E A records
session with a cookie) and/or smart DNS
Expressway-E Expressway-C Transversal Zone Config. Regional Xway Cluster, Clustering, transversal
Configuration zone configuration
Expressway-C WebBridge DNS SRV record GEO DNS Multiple SRV records
and/or smart DNS
WebBridge (via CallBridge (CB) WebBridge estimation - TURN according to Multiple CallBridges
XMPPserver) RTT among CB and CBgroups
(WebBridge CB+TURN (TBVerified) - RTT favour regional
located in core) ( sticky result ) TURN servers
WebBridge XMPP server DNS SRV record GEO DNS XMPP clustering
CallBridge (CB) TURN Server CB RTT estimation + RTT and CBgroup Multiple TURN choices per
CallBridgeGroup (same as above) CB
WebBridge Client TURN server at Received by CB after Decided in previous Multiple TURN servers
client side CallBridge TURN allocation step
TURN protocol Try fist UDP.3478, then Decided in previous Multiple TURN servers
and port at client TCP.443 step
side BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 150
On-Premises MS Interoperability
For reference
Dual homed call setup via drag and drop (*)

Lync client Lync client MS Front End Call Bridge
& AVMCU Video EP
Lync clients in meeting
SIP: INVITE VideoEP
SIP: (re)INVITE VideoEP with conf:focus:id:R6KHVK2Y
escalating Lync conversation …. To Lync Conference
SIP: INVITE sip:LyncUser@LyncDomain…. conf:focus:id:R6KHVK2Y

drag and drop Video EP to the meeting
Lync conference subscription
SIP: SUBSCRIBE sip:LyncUser@LyncDomain .. conf:focus:id:R6KHVK2Y
SIP: OK with Conference information.
All participant in a dual homed meeting

(*) simplified Media SIP BRKCOL-3990 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 152

BRKCOL-3990 Cms On-Premises and Hybrid

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKCOL-3990 Cms On-Premises and Hybrid

Uploaded by

Copyright:

Available Formats

BRKCOL-3990

Cisco Meeting Server,

• Interoperability • Scalable • Enriched meeting • WebRTC browsers • PC/MAC/iOS • Native

Cisco Meeting Server

CMS 2000 CMS1000 Spec Based

Co-resident VM 1.25 per physical core

Webadmin Recorder & Database cluster

CORE SERVER CALLBRIDGE

Max 5 DB server, recommended 3

All DB operations are directed to the master

Separate DB server improves CallBridge robustness and simplifies upgrades

Max of 8 Call Bridges per cluster.

• Cluster sync • Spaces

Other combinations of CallBridges and DataBase are also possible,

distribution links with multiple

Distributed call Setup

SIP: INVITE MySpace1

First call established

Intra-cluster dialogue finds that the space is already active in in CB1

CB1: generating peer URI sip:Conf_ID@CB1 for coSpace <spaceID>

Distributed Video Call established

Master election similar to the database cluster

Max 500 sessions per XMPP cluster

Max 200 msec RTT between XMPP servers

• Large conference design involves (discussed in the Edge section)

• Call Control : traffic optimization

CMS Core Design • Bridge and DB Cluster distribution

• LDAP integration : user and space

• Call Admission Control

Americas EMEA APAC

SIP HTTPS / SIP

Traffic back from CallBridges is localized by configuring

Focus on one Region

Call Replacement (simplified flow)

Video EP with existing call

SIP: INVITE MySpace1

SIP: INVITE MySpace1 with Call_ID Supported:.. Replace

Do not forget CUCM

CUCM CMS trunk

SIP: INVITE EndpointURI From spaceURI Replaces: Call_ID

• It is totally transparent to the user

for call reallocation EMEA_CB1

• Load balancing is applied from the first call to a space Space02

EMEA_CB1_fqdn (2) 50 Yes Yes Yes No

EMEA_CB2_fqdn (2) 50 Yes Yes Yes No

ucdomain.com EMEA_CUCM_fqdn (3) meet.ucdomain.com Standard Continue 10 <match CUCM> EMEA_CB2

EMEA_CB1_IP EMEA_CB1_IP (4) Standard Continue 5 Auto All

EMEA_CB2_IP EMEA_CB2_IP (4) Standard Continue 5 Auto All

CMS can be added as scheduled Bridge in TMS

CMS clusters support

TMS reconfigures the static meeting at the

Americas EMEA APAC

SIP CMS API EP API HTTPS / SIP EWS Media

IPZONE Americas IPZONE EMEA IPZONE APAC

• From TMS 15.6 Meeting owner is passed to CMM

• Configuration is two steps

• CA-Signed certificates strongly

Americas EMEA APAC

SIP API HTTPS / SIP Media

Americas EMEA APAC

SIP API HTTPS / SIP Media

CMS 2000: CMS 2000:

CMS 2000: CMS 2000:

CMS 1000 (): CMS 1000 ():