2017/eur/pdf/BRKCOL 3990 PDF

Cisco Meeting Server
Large scale conferencing design
Aniello Zanfardino Solution Architect

BRKCOL-3990
Session Scope and Key Message
Session Scope
The new conferencing architecture and design with Cisco Meeting Server
Session Key Message

When planning a large conferencing infrastructure, you cannot only count on magic.
Good preparation and design allow seamless and robust deployment
Session Prerequisites
Basic knowledge of Cisco Video and UC architecture including CMS
BRKCOL-2803 Designing and deploying multiparty conferencing for telepresence video Amparan, Dey
LABCOL-1008 Cisco Meeting Server for beginners Self Paced Lab
BRKCOL-3990 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Related sessions and reference documents
BRKCOL-2803 Wed 09:00 Designing and deploying multiparty conferencing for telepresence video Amparan, Dey
BRKCOL-2018 Tue 14:15 Best Practices for Business to Business Video Collaboration Luca Pellegrini
BRKCOL-2610 Wed 11:30 Cisco Interoperability with Microsoft - Part 1, Collaboration Tobias Neumann
BRKCOL-2611 Wed 14:30 Cisco Interoperability with Microsoft - Part 2, Video Interoperability Fabio Chiesa
BRKCOL-2614 Wed 09:00 Technical Overview of Preferred Architecture for Enterprise Collaborat. Rel 11.6 Glen Lavers
BRKCOL-2616 Tue 14:15 QoS Strategies and Smart Media Techniques for Collaboration Deployments Glen Lavers
White Paper : Load Balancing Calls Across Cisco Meeting Servers

Cisco Meeting Server 2.1, Scalability and Resilience Deployment Guide
Cisco Meeting Server 2.1, Certificate Guidelines for Scalable and Resilient Server Deployments
Cisco Meeting Server 2.1 with Cisco Unified Communications Manager Deployment Guide
Cisco Meeting Server with Expressway X8.9
All these documents are available on CCO
Agenda
Introduction
Core
Core conferencing design with clustering and traffic optimization
Scheduled conference
Ad-hoc conference
MS Interoperability with focus on-premises

Edge
Conclusions
Introduction
CMS - Key Capabilities
What CMS does
Cisco Meeting
Audio Browser Access
Video Conference Spaces Application MS Interoperability
Conference (WebRTC CMA)
(Native CMA)
Interoperability Scalable Enriched meeting WebRTC browsers PC and Mobile Interop with Lync/S4B
Virtual meeting rooms Reduced costs Virtual meeting rooms Bidirectional content platforms 2010, 2013, O365
Built in NAT traversal Multiple ways to join Multiple VMR per user Users & Guests Same functionalities On-prem and cloud
Security DTMF, IVR Interoperable access and look & feel as Bidirectional content
Scaling Screen/App sharing In room controls: WebRTC CMA One user experience
Clustering - mute/disconnect Better video quality IM&P
Multitenancy - Device mobility
Hardware Components
How CMS look like
Specialized servers General purpose Legacy Appliances

CMS 1000, CMS 2000
servers with X1,X2,X3 (EOS)
MM410v, MM400v (legacy) spec based VM
CMS 1000 and CMS 2000 are the preferred HW options
CMS - Key Software Components
CMS key services
H323 GW and
Call Bridge XMPP server WebBridge Turn Server Load Balancer
SIP Edge
core core core & edge edge edge
legacy
Video Bridging core Registration & WebRTC with Media Firewall XMPP signalling H323 GW (not GK)
Call Control Authentication compatible browsers traversal firewall transversal
Media processing for CMA Clients (Chrome, Firefox, Opera) (proxy) SIP firewall
Clustering transversal
Inter-component Brand-able
signalling VP8 & H.264 Both components
have equivalents in
IM&P Expressway
Webadmin Database cluster Recording & Streaming

core core core
Web Administration Database Recording

Clustering Streaming
Management / Admin methods
How to interact with CMS
CLI / MMP WebAdmin API SFTP

ssh, (Web GUI)
console,
VM console
Architecture Core only Single server
CMA WebRTC
Clients Clients
XMPP WEBBRIDGE
SIP
XMPP
CORE SERVER CALLBRIDGE

HTTPS / WEBRTC
Media
LDAP
AD
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
Clustering
Benefits: Components:
Increased capacity Database Clustering
Spaces, Users
Geographic optimization
Dial Plan
Resilience Cluster-wide configuration
Call Bridge Clustering

Distributed calls
Clustering Components and Architecture
Keepalives
Call Bridge Cluster Call Status
Distributed Calls
Max 300 ms RTT
Spaces
Users Call Bridge Cluster
Database Connect Dial-plan HTTPS + SIP
Cluster-wide
configuration
Max 200 ms RTT Database Connect
TLS/Postgres
Cluster synch
Max 200 ms RTT
Database Cluster
Database Cluster TLS / Postgres
Clustering - Call Bridge with co-located DB
Database Cluster
Keepalives Call Bridge Cluster
Call Status HTTPS + SIP
Call Bridge Cluster Distributed Calls
Database Connect
TLS/Postgres
Cluster synch Spaces

Database Cluster
Users TLS / Postgres
Dial-plan
Cluster-wide
configuration
Other combinations are also possible
What to keep in mind:
1) Number of DB servers : odd number (for master election), max 5, recommended 3
2) Separate DB server improves CallBridge performance and simplifies upgrades
Notation used in the presentation
.means..
Fully meshed trunking
.means..
Fully meshed distributed call

Distributed calls
Resiliency, scale, geo-distribution
Conference 1
Conference 2
1.5 Mbps 1.5 Mbps
1.5 Mbps 1.5 Mbps
1.5 Mbps 1.5 Mbps
1.5 Mbps smart-cascading links

with 4 streams
EMEA
Americas APAC
Distributed call Setup
Call Bridge Cluster Enpoint2
CUCM2
Enpoint1 CUCM1
Call Bridge CB1 Call Bridge CB2
DB: MySpace1
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>

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
Deployment Prerequisites - DNS DNS
Several DNS records are required for the solution to work properly
The main DNS records are
DNS A records for all the servers involved (e.g. cms1-us.mycompany.com)
DNS A records for user access to services (e.g. join.mycompany.com)
DNS SRV record to locate XMPP server
(used by CMA and other components)
(example: _xmpp-client._tcp.mycompany.com set to port 5222)
A more comprehensive list is in installation docs
Large conference design involves GEO DNS and split (external, internal) DNS; it
will be discussed in the edge section
Deployment Prerequisites - Certificates
WebAdmin
XMPP
WebBridge Certificate
Components Callbridge types:
that need a Loadbalancer self-signed
certificate: Trunk Private CA Signed
Database Cluster Public CA Signed
Recording server
Streaming server
Reduce Certificate management 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 needs separate certificate
Lync/S4B integration have specific requirements
Wildcard certificated
Supported but limitations applies too
Cisco Meeting Server 2.1, Certificate Guidelines for Scalable and Resilient Server Deployments
BRKCOL-2018 Best Practices for Business to Business Video Collaboration Luca Pellegrini
Core
Section agenda - Design Points Covered
Sizing
Call Control : traffic optimization
Bridge and DB Cluster distribution
LDAP integration : user and space names
Domains structure and Dial Plan
Call Admission Control
TMS Scheduling
We will look at them in the context of a use case

Use Case 1
Large enterprise with established worldwide collaboration infrastructure
with the need of pervasive video services with global coverage
Structural requirements (*):

Three worldwide regions (**)
Redundancy with 2 Data Centres (DC) in each region (**)
Traffic Optimization (localize the traffic to regions whenever possible)
Conferencing requirements:
Virtual Meeting Rooms (VMR)
Scheduled meetings with OBTP (One Button To Push)
Expected load around 400 HD ports 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 with layers
AD
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
Use Case 1 - Architecture Summary with DCs
AD
Calendar TMS+TMSXE Global

DCx
Routing &
Management
. . . . . .
Regional
. .
Call Control (*)
. . . .
Core
Conferencing
Core Core Core Core Core
(CMS cluster)

DC1 DC2 DC1 DC2 DC1 DC2
Americas EMEA APAC
(*) only one regional call control cluster will be shown BRKCOL-3990 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 26
CMS sizing
Platform Capacity [HD sessions per server] Session Capacity
Type Multipliers
CMS 2000 500
Full-HD 0.5
CMS 1000 96 1080p30
HD (*) 1
410v (legacy) 64
720p30
400v (legacy) 32 480p30 2
Standalone VM (**) 2.5 per physical core Audio (***) 30
CoResident VM 1.25 per physical core Max 8 Call Bridges per cluster
Above 8 Call Bridges
(*) HD 720p30 video calls with 720p5 content and up to 2.5 Mbps bandwidth design need to be validated
(**) CPU 2.5 GHz+, 1 GB vRAM per vCPU ;use all but one of the host physical cores
(***) Max 499 participant per conference per CallBridge
Max number of webbridge session per server is 100
Sizing : Notes
Capacity figures are meant for servers with dedicated task
Do not forget to count the ports used by inter-callbridge call legs in distributed
calls (one HD port per conference, per trunk)
Capacity is per call legs while SMP/PMP licenses are per conference
While operating CMS cluster, keep an eye on hot-spots
(CMS with large load in peak business hours)
Sizing for use case 1 :
6 x CMS-1000 which gives 576 (6x96) HD ports
3 x spec based VMs for DB servers
Bridge DB Cluster - Requirements
DB node number needs to be odd (master selection)
Max number of DB nodes is 5, recommended is 3
Max latency between servers 200 ms RTT
Multiple possibilities for database and call bridge allocation
1. Dedicated database VMs, connected from with CallBridges with no DB
2. CallBridge with colocated database server
In use case 1 we opted for the first option to maximize CallBridge performances
and simplifies upgrades
Use Case 1 - Bridge DB Cluster distribution
Core Core Core Core Core

Core
CallBridge Cluster
Database
Database
Database
DB Connect
Americas Cluster Sync
EMEA APAC
Call Control Trunks
Global
. . . Routing &
Management
Regional
Call Control
. . .
Conferencing
(CMS cluster)
Americas EMEA APAC
Trunk the CMS cluster to the highest call control entity (CUCM or SME)
with awareness of global and regional topology; the reasons are:
1) Trunk and routing configuration simplification
2) Reflect the global reach of the CMS cluster
BRKCOL-2614 Technical Overview of Preferred Architecture for Enterprise Collaborat. Rel 11.6 Glen Lavers
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
How avoid call loop when using CMS in other region as backup/overflow
Incoming CSS of trunk to other Incoming CSS of trunk to leaf

SME can only see local CMS CUCM sees first regional CMS
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.1 White Paper : Load Balancing Calls Across Cisco Meeting Servers
Call Control - Traffic Optimization
The dilemma with multiple optimizations
There is a potential conflict between the following requirements :
Perform distributed calls
Load balancing traffic between call bridges
Minimizing the number of call legs to maximize cluster capacity
Next slides show the potential consequences
and then the solution in CMS 2.1
Call Control Traffic Optimization
Load balancing and distributed conference have several benefits But ..
Conference 1
Conference 2
1.5 Mbps 1.5 Mbps
1.5 Mbps 1.5 Mbps
1.5 Mbps 1.5 Mbps
EMEA
Americas APAC
1.5 Mbps smart-cascading links
with 4 streams
Call Control Traffic Optimization
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 )
.
CMS 2.1 Call Bridge Group Feature (part 1.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
For reference
Call Replacement (simplified flow)

Call Bridge group EMEA
CUCM
Call Bridge CB1 Call Bridge CB2
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
CMS 2.1 Call Bridge Group Feature (part 2.LoadBalance)
A mechanism is necessary to ensure load
balancing of conferences in the same CallBridge EMEA_CUCM
Group
This is implemented by distributing conferences 3) Replace
1) Call to
Space 02
based on conference_ID and bridge_ID hashing call to
Space02
It is totally transparent to the user
and it leverages the same replace mechanism 2) check Space01
4) Space02
for call reallocation activated (active)
EMEA_CB2
EMEA_CB1
EMEA_CBGroup
CMS 2.1 Call Bridge Group Feature (part 3.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
With 2.1 a max load Limit can be configured Max load Limit
100%
on each CallBridge so that when a call is received
and the CMS is above a limit CMS rejects the call;
Existing Conference
limit is variable according to the conference state Threshold 80 %
CUCM receives SIP 488 ,Not acceptable here, New Conference

Threshold 50%
and Dial Plan (RG, RL) can be configured
to route advance to next call bridge
Use case 1 Core Design with CallBridge Groups
With Call Bridge Groups we solve in one shot :
load balancing, in-region distributed call avoidance and per-CMS call limiting
CBGroup Americas CBGroup EMEA CBGroup APAC
Core Core Core Core Core Core

Americas EMEA APAC
Domains
SIP domain routing is the least common denominator in CUCM, CMS,
Expressway (and Lync/S4B),
so using separate SIP domains is the easy solution for routing
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 : 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
Is the call for Lync ? forwarded ?
With domain rewrite ? Where send the call ?
and how ?
CMS dial plan configuration details
Focus on configuration of one region: EMEA
EMEA_CUCM
CMS Dial Plan: Inbound dial rules for CUCM ucdomain.com
Targets Targets Targets Targets
Domain name Priority
spaces users IVRs Lync EMEA_CBGroup
meet.ucdomain.com 100 Yes Yes Yes No EMEA_CB1 EMEA_CB2
EMEA_CB1_fqdn (*) 50 Yes Yes Yes No
EMEA_CB2_fqdn (*) 50 Yes Yes Yes No meet.ucdomain.com
CMS Dial Plan: EMEA Outbound dial rules for CUCM

Domain Local contact Local from Trunk CallBridge
SIP proxy to use Behavior Priority Encryption
domain domain type Scope
ucdomain.com EMEA_CUCM_fqdn (**) Standard Continue 10 <match CUCM> EMEA_CB1
ucdomain.com EMEA_CUCM_fqdn (**) Standard Continue 10 <match CUCM> EMEA_CB2
CMS Dial Plan: Forward dial rules : none

Call Bridge specific outbound dial rule (API)
with same priority (keep traffic in EMEA)
(*) assuming CUCM trunk has CMS FQDN as destination address
(**) alternative : multiple rules for each Subscriber
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 (XMPPID & 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$
LDAP integration : things to watch
AD mapping create in CMS 3 dial-able URIs:
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
LDAP integration : things to watch
There is a lot of flexibility in configuring LDAP
Multiple LDAP sources and mapping can be configured
LDAP configuration on CallBridge is per server
All CallBridges in a cluster can update users and space database
But care need to be taken to avoid feeding the database
with incongruent information, for example:
Call Bridges taking same information but mapping it differently
Different AD sources not providing the same info for a user
When in doubt, use a single configuration and a single point of synchronization
For reference
Prerequisite for QoS Packet marking at CMS
CLI command Typical configuration

dscp (4|6) <traffic type> <DSCP value> dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
Where (4|6) is ipv4 vs ipv6 dscp 4 voice 0x2E
Type is dscp 4 signaling 0x1A
signaling (SIP, AS-SIP signaling) dscp 4 low-latency 0x1A
assured-voice (any audio for AS-SIP)
voice (any other audio)
assured-multimedia (video for AS-SIP)
multimedia (any other video) Typical values EF = 0x2E, AF31 = 0x1A, AF41 = 0x22
multimedia-streaming (webbridge media) Default is 0x00 (cs3=0x18)
low-latency (XMPP)
oa&m (webadmin, LDAP, SSH, SFTP)
Value can decimal or hexadecimal
Call Admission Control
By default CMS Call bridge distributed calls bypasses CUCM CAC
This behaviour can be avoided with specific CMS cluster configuration
Conferencing design needs to consider the benefit of not CAC-ing video and
leveraging adaptive video endpoint capabilities (*)
Video traffic needs to be marked appropriately
The network will drop packets when exceeding class reserved bandwidth
Video endpoint will adapt by down-speeding
More video traffic can fit into the network
In use case 1 no CAC was applied to video
(*) BRKCOL-2616 QoS Strategies and Smart Media Techniques for Collaboration Deployments Glen Lavers
Scheduling
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
TMS 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 with

the actual meeting name at start time
Use Case 1 TMS Scheduling and OBTP - Flow
TMS+TMSXE
1) Meeting
2) Send OBPT
Calendar to Endpoints Global
Routing &
Management
. . .
3) Create
meeting
on CMS
4) OBTP to
Join Regional
conference
Call Control
. . .
Conferencing
(CMS cluster)
5) Distributed call
Database Database
Database
Americas EMEA APAC

SIP CMS API EP API HTTPS / SIP EWS Media
TMS Scheduling
Resource reservation
Conference scheduling traditionally is linked to bridge resource reservation
Original CMS implementation change the limited resource paradigm by carrying on
accepting calls when resource limit is passed and reducing conference resolution
CMS 2.1 introduce a more classical behaviour where CMS can be configured to not
accept call above a certain limit
In any case (logical limitation), if scheduled resource preservation is required,
the only possibility is to dedicate a CMS cluster to scheduled call
For use case 1 the approach was to share all CMS callbridges among all
different call types and monitor utilization to plan resource upgrade
Use Case1 implemented with legacy Architecture
For comparison only
AD
Global
Calendar TMSXE TMS + TMSPE Routing &
Management
. .
.
Regional
Call Control
Conductor
Conductor Conductor
Conferencing
Guaranteed Best Effort pools Guaranteed Best Effort pools Guaranteed Best Effort pools
(Scheduled) (ad-hoc, rendez-vous, (Scheduled) (ad-hoc, rendez-vous, (Scheduled) (ad-hoc, rendez-vous,
Personal, scheduled) Personal, scheduled) Personal, scheduled)
Americas EMEA APAC

Use Case 2
A large traditional worldwide enterprise where employers meeting are mediated
by white gloves service from an internal video service team
Structural requirements:
Three worldwide regions
Redundancy with 2 DC in each region
Traffic Optimization
The great majority of the video conferences are
Scheduled by the video team
Connected automatically
TMS Scheduling with auto-connect
Points of attention
CMS cluster in TMS has a single IP Zone
CMS redundancy in TMS is implemented via alternate IP:
Main and alternate_IP are used both by conference creation and for dial-out( TMS 15.3)
Only one Alternate IP configuration is allowed
For Automatic-Connect, these points may lead to suboptimal routing in
geographically separated CMS clusters
but (design question)
if we use automatic connect, do we really need geographical CMS clustering ?
In use case 2 we will propose regional clustering (not global clustering)
Use case 2: TMS Scheduling with auto-connect
TMS
Global
Routing &
. .
Management
.
1) Create
meeting
on CMS Regional
.
2) Conference Call Control
. Start .
Conferencing
CMS Cluster 3) Conference (Regional
CMS Cluster on regional CMS CMS cluster
Americas EMEA clusters)
cluster APAC
IPZONE Americas IPZONE EMEA IPZONE APAC
EMEA
Americas APAC
HTTPS / SIP Media EWS
SIP API
Auto-Connect with TMS 15.4
TMS 15.4 uses a different approach for CMS auto-connect (dial-out)
that is not limited by the main/alternate IP mechanism
used by TMS to connect to CMS
With the new approach,

if Video Endpoints are in separate regional SIP domains,
then it is possible to chose the Call Bridge used for dial-out
by leveraging CMS dial plan
Ad-hoc conferencing
Use Case 3
A large and dynamic worldwide enterprise where employers
communicate on the fly and need ad-hoc conference capability
Mainly Ad-hoc conference with participant belonging to any region
Some rendez-vous conferences
CUCM ad-hoc
CMS 2.0+ supports CUCM ad-hoc
calls and it can be configured as
CUCM Conference Bridge
Configuration is two steps
A SIP trunk (secure or not secure)
between CUCM and CMS
An API (always secure/HTTPS) connection
from CUCM to CMS (*)
CA-Signed certificates are required

Recommended to use prefixes
(URI uniqueness, troubleshooting, routing)
(*) same port as Webadmin
Use Case 3 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)
Database Database
Database
EMEA
Americas APAC
SIP API HTTPS / SIP Media
Use Case 3 CUCM ad-hoc Conferencing
Simplified call flow
. . Global
.
Routing &
Management
.
.
Regional
Call Control
.
Merge
conference
Conferencing
Core Core Core
(CMS cluster)
Database Database
Database
EMEA
Americas APAC
SIP API HTTPS / SIP Media
Audio Conference
CMS as an Audio conferences bridge
Very basic functionality : bridge + IVR

Max 499 participant per conference per CallBridge
(it can be increased with clustering)
Even more than with video,
it is important to limit the intra-region distributed calls
On-Premises MS interop
S4B/Lync Integration
Key features
Interoperability with any Lync/Skype versions
On-premises or cloud
Native capability of CallBridge
Large scale
Bidirectional content sharing
Lync buddy list integration
Native user experience with Dual Home
Native Support
SVC/H.264UC (Lync 2013) IM & Presence
RTVideo (Lync 2010) Multi-party conferencing
Direct federation to O365 Drag & drop
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 via CMS a Lync/S4B

meeting as a full featured participants (picture in the next slides)
Call types: call start and user experience comparison
Call method CMS call End user End user
type experience experience
video side MS side
Direct point to point call Gateway Good Good

Endpoints and Video Clients Rendezvous Good Better layouts;
meet into a CMS space missing
controls
-Dial Lync meeting via IVR Dual homed Good Standard

-Drag and drop Video EPs layout and
into a Lync conference controls
Dual homed sample screenshot Lync side
In meeting control Immersive endpoints
of video endpoints
Video Endpoint
participants in roaster
Video endpoints
presenting
Call types: Dual Homed
Dial IVR+ConferenceID Join Lync Conference Click-To-Join
Video EP CMS
LYNC SERVER
AVMCU
5 media streams+IM&P
Native experience preserved on both VC and Lync/S4B sides without the drawbacks of classical cascading
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 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 72
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 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 73
Section Sub Agenda:
Design Points to Keep in Mind
Same approach as core design for: Aspects to look at for MS Interop

Sizing Domains structure and Dial Plan
Bridge and DB Cluster distribution LDAP integration : user and space names
Call Admission Control Traffic optimization : Core
We will look at them in the

context of another use case
Use case 4 : On-premises MS interop
Customer is a Large Enterprise with Cisco UC+Video and on-prem Lync/S4B
requiring full featured integration between the two worlds
Point to point call between Video EP and Lync/S4B clients
Lync/S4B clients able to join Spaces on CMS
Video Endpoints able to join Lync meetings via OBTP and via IVR with full features
Refer to BRKCOL-2610 Cisco Interoperability with Microsoft - Part 1, Collaboration Tobias Neumann
Refer to BRKCOL-2611 Cisco Interoperability with Microsoft - Part 2, Video Interoperability Fabio Chiesa
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
Device routing
capability
Lync/S4B and CMS CUCM can route Expressway can route

can only route on on numbers on any part of a URI
SIP domains or SIP domains and even more
In addition SIP domain routing,

a numeric Meeting ID simplifies conference join
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: meet.ucdomain.com user@meet.ucdomain.com
User and space URI should not overlap with Lync/S4B URI
(pay attention to CMS user XMPP_ID)
Video endpoint user experience
When joining a Lync/S4B 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]
TMS scheduled OBTP Lync conferences
Requires TMS 15.3+
When TMS/TMSXE is integrated with MS exchange,
it monitors Video Room mailboxes
When it sees an invitation for a Lync/S4B meeting, instead of booking local bridge
resources, it simply programs endpoint OBTP for:
<Lync_Conference_ID>@LyncDomain
Video Room join triggers a call from EP to Lync Conference via CMS
In term of design, same principles apply
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_CB1 EMEA_CB2
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

Targets Targets Targets Targets
CMS Dial Plan: Forward dial rules
Domain name Priority
spaces users IVRs Lync Forward both ucdomain.com and lyncdomain.com,
lyncdomain.com 20 No No No Yes according to dial plan and with no changes
CMS_FQDN(s) 30 Yes Yes Yes Yes Direct numeric call from CUCM to Lync Meeting (optional)
(*) to be added to configuration for use case 1 BRKCOL-3990 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 82
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 CMS Certificates
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}
(*) EMEA_FEP_ID from Get-CsStaticRoutingConfiguration

FEP specific static routes (*)
Use case 5 : MS interop to external organization
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
Video calls with external organizations using standard SIP
Video calls with external organizations with own MS infrastructure or using O365
Join meetings (spaces) hosted on this organization CMS cluster with any client
Refer to BRKCOL-2611 Cisco Interoperability with Microsoft - Part 2, Video Interoperability Fabio Chiesa
CMS + Expressway edge Architecture: features used
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
On-premises conferencing traffic can still go directly from CUCM to CMS so all
the scaling capability discussed earlier can still be used
CMS with Expressway edge Architecture: basic blocs
More info CCO: Cisco Meeting Server with Expressway X8.9
Use case 5 : Architecture
Regional Global Routing Global Conferencing Edge External
Call control with core CMS cluster with adaptation CMS Users
Unknown SIP domains
Organization with
MS infrastructure
Americas
O365 Clients
EMEA
B2B standard SIP

APAC
SIP HTTPS / WebRTC (MS) SIP SIP SIMPLE
Edge
Edge Section Agenda
Introduction
Post-CMS 2.1 Design CallBridge Groups with Edge
Preview Expressway proxy for WebRTC
CMS Architecture with split core and edge
(pre-Expressway WebProxy)
CMA WebRTC
Clients Clients
External
LOADBALANCER TURN
DMZ WEBBRIDGE
EDGE SERVER
SIP
Internal XMPP
HTTPS / WEBRTC
XMPP CALLBRIDGE WEBBRIDGE
CORE SERVER Media ; TURN
AD LDAP
WebRTC
Clients
CMA
Clients
DNS design - CMA Native Client
1) Query (SRV) External Native Client
_xmpp-client._tcp.MyDomain 1. DNS SRV Lookup for _xmpp-client._ tcp.MyDomain Loadbalancer
External Load-Balancer 2. Connect to the a CallBridge via the load balancer,
DNS
CallBridge sends a list of TURN servers
3. The CMA Client queries the set of possible TURN servers
and chooses one based on availability, location and TURN server load
Requirements
GEO DNS Edge Edge Edge
for correct regional allocation
Split DNS
for internal/external separation
Core Core Core
Americas EMEA APAC
a) Query (SRV) Internal Native CMA client

_xmpp-client._tcp.MyDomain a) DNS SRV lookup for _xmpp-client._ tcp.MyDomain XMPP server
Internal XMPP Server b) A call bridge is chosen and used for the session
DNS
DNS XMPP
DNS design - WebRTC Client
1) Query (A) Join.MyDomain
External WebBridges
External Web Client
External 1. (A) DNS Lookup for JOIN.MyDomain -> WebBridge(External)
DNS 2. Get WebBridge IP and connect
3. Webbridge queries _xmpp-client._tcp.MyDomain -> Loadbalancer
Requirements
GEO DNS
Edge Edge Edge for correct regional allocation
Split DNS
for internal/external separation
Core Core Core

Americas EMEA APAC
Internal Web Client

a) DNS Lookup for JOIN. MyDomain-> WebBridge (Internal)
Internal a) Query (A) Join.MyDomain b) WebBridge queries _xmpp-client._tcp.MyDomain -> XMPP server
DNS Internal WebBridges
DNS HTTPS
For reference
WebRTC Sign-in and Join a space (simplified)
Web
XMPP via CallBridge
client WebBridge TURN
LoadBalancer
DNS
DNS A lookup Join.MyDomain
Sign-in + userID, password
DNS SRV lookup _xmpp-client._tcp.MyDomain
Authenticate
Validate credential
Welcome 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 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 93
For reference
WebRTC Guest joins a Space (simplified)
Web
XMPP via CallBridge
client WebBridge TURN
LoadBalancer
DNS
DNS A lookup Join.MyDomain
Join a meeting + Meeting_ID & passwd
Validate Meeting_ID & passwd
Enter Name + Join

Request guest credentials
DNS SRV lookup _xmpp-client._tcp.domain
Authenticate
Validate credentials
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 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 94
Issue 1: full mesh of services (*)
LOADBALANCER TURN WEB_BRIDGE LOADBALANCER TURN WEB_BRIDGE LOADBALANCER TURN WEB_BRIDGE
Edge Edge Edge
CALLBRIDGE XMPP CALLBRIDGE CALLBRIDGE

Core Core Core
Core
Location A Location B Location C
In classical CMS design, the full mesh of service ensures redundancy but increase complexity
Traffic is optimized by internal mechanisms but there is no control to force the traffic localization
XMPP Media/TURN WebBridge Mapping (*) some XMPP links are not drawn for simplicity
Issue 2: multiple edges when implementing full architecture
Calendar
Global
. .
TMS
.
Routing &
Management
Conferencing
Xway-C Xway-C Xway-C

Regional
Call Control
S4B
Lync/S4B
S4B FE S4B FE
FE
Edge
S4B Edge CMS-Edge S4B Edge S4B Edge
Xway-E CMS-Edge Xway-E CMS-Edge Xway-E
Americas EMEA APAC Internet
Post-CMS 2.1 Design
CallBridge Groups in Edge
CMS 2.1 Call Bridge Groups feature with Edge services
The CMS 2.1 CallBridge feature applies also to edge services (WebBridge,
TURN) to allows localization
WebBridge and TURN servers can be assigned to a
CallBridge Group
CallBridge
so their services will be used only by the associated CallBridge or CallBridge
Group
Example Edge service distribution w/CallBridgeGroups
LOADBALANCER TURN WEB_BRIDGE LOADBALANCER TURN WEB_BRIDGE LOADBALANCER TURN WEB_BRIDGE
Edge Edge Edge
CALLBRIDGE XMPP CALLBRIDGE CALLBRIDGE

Core Core Core
Core
DC1 Region1 DC2 Region1 DC3 Region2
Region 1 - CBridge Group 1 Region 2 - CBridge Group 2
XMPP WebBridge Mapping Media/TURN

Edge Service Design with multiple regions and DCs
CBGroup Americas CBGroup EMEA CBGroup APAC
Edge
Edge Edge Edge Edge Edge Edge

Core

Americas EMEA APAC
CallBridge Groups include CallBridges, TURN and WebBridge servers
How to limit inter-DC Core/DMZ traffic
(2) (2) (2) (2) (2) (2)
Edge
Edge Edge Edge Edge Edge Edge

CBGroup Americas Core
CBGroup EMEA CBGroup APAC
(1) (1) (1)

Americas EMEA APAC
(1) CallBridge Groups include CallBridges

(2) Direct Mapping between edge services (TURN, Webbridge) and CallBridge in same DC
Preview
Expressway proxy for WebRTC
Cisco Meeting Server Web Proxy Preview
ATTENTION even if configurable, Cisco Meeting Server Web Proxy
is not supported in current Expressway X8.9 release
CMS WebProxy feature in Expressway allows to leverage 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 MS Interop
CMA native clients still need classical CMS edge
Expressway TURN doesnt support TCP 443 as TURN port
From legacy CMS Edge to Expressway Web-Proxy
Available when Expressway WebProxy is released
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
Available when Expressway WebProxy is released
DMZ Internet
Expressway-C Expressway-E WebRTC Client
Core CMS
DNS
DNS
External DNS (split) resolves

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

DNS design - Web Client with Expressway
1) Query (A) Join.MyDomain External CMA Web Clients:
Expressway-E 1. A DNS Lookup for JOIN.MyDomain to get Expressway-E IP
External
DNS 2. Connect to Expressway-E which supplies address of TURN server
3. Expway-C queries(SRV) _cms-web._tls.Join.MyDomain for Internal WebBridges
4. Webbridge queries (SRV) _xmpp-client._tcp.MyDomain for XMPP server
2)
Expway-E 2) Expway-E Expway-E
3)
Expway-C Expway-C Core Core Expway-C

Core Americas EMEA APAC
Internal Web Client (no changes)

DNS Lookup for JOIN. MyDomain which return Internal WebBridge
Internal Query (A) Join.MyDomain WebBridge queries _xmpp-client._tcp.MyDomain to get XMPP server
DNS Internal WebBridges
DNS
GEO DNS for correct regional allocation
HTTPS
Split DNS for internal/external separation
Web-Proxy Some configuration screenshots
Web-Proxy some operational screenshots
Recording & 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
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
Recording: 1 vCPU and 0.5GB of memory per concurrent recording
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, again, allow optimal allocation of resources
Agenda
Introduction
Core
Core conferencing design with clustering and traffic optimization
Scheduled conference
Ad-hoc conference
MS Interoperability with focus on-premises

Edge
Conclusions
Conclusions
When planning a large conferencing
infrastructure, you cannot only
count on magic.
Good preparation and design allow
seamless and robust deployment.
Complete Your Online Session Evaluation
Please complete your Online
Session Evaluations after each
session
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
Dont forget: Cisco Live sessions will be available
Communication Stations for viewing on-demand after the event at
CiscoLive.com/Online
Cisco Spark
Ask Questions, Get Answers, Continue the Experience
Use Cisco Spark to communicate with the Speaker and fellow

participants after the session
Download the Cisco Spark app from iTunes or Google Play

1. Go to the Cisco Live Berlin 2017 Mobile app
2. Find this session
3. Click the Spark button under Speakers in the session description
4. Enter the room, room name = BRKCOL-3990
5. Join the conversation!
The Spark Room will be open for 2 weeks after Cisco Live
Continue Your Education
Demos in the Cisco campus
Walk-in Self-Paced Labs
Lunch & Learn
Meet the Engineer 1:1 meetings
Related sessions
Q&A
Thank You

2017/eur/pdf/BRKCOL 3990 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2017/eur/pdf/BRKCOL 3990 PDF

Загружено:

Авторское право:

Доступные форматы

Cisco Meeting Server

Large scale conferencing design

Aniello Zanfardino Solution Architect

Session Key Message

LABCOL-1008 Cisco Meeting Server for beginners Self Paced Lab

White Paper : Load Balancing Calls Across Cisco Meeting Servers

MS Interoperability with focus on-premises

Specialized servers General purpose Legacy Appliances

Webadmin Database cluster Recording & Streaming

Web Administration Database Recording

CLI / MMP WebAdmin API SFTP

CORE SERVER CALLBRIDGE

Call Bridge Clustering

Cluster synch Spaces

Fully meshed trunking

Fully meshed distributed call

1.5 Mbps 1.5 Mbps

1.5 Mbps 1.5 Mbps

1.5 Mbps 1.5 Mbps

1.5 Mbps smart-cascading links

SIP: INVITE MySpace1

First call established

SIP: INVITE MySpace1

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

We will look at them in the context of a use case

Structural requirements (*):

Database Database Database

Americas EMEA APAC

Calendar TMS+TMSXE Global

Database Database Database

Core Core Core Core Core

Traffic back from CallBridges is localized by configuring

Incoming CSS of trunk to other Incoming CSS of trunk to leaf

Next slides show the potential consequences

and then the solution in CMS 2.1

1.5 Mbps 1.5 Mbps

1.5 Mbps 1.5 Mbps

1.5 Mbps 1.5 Mbps

Focus on one Region

Call Replacement (simplified flow)

Video EP with existing call

SIP: INVITE MySpace1

SIP: INVITE MySpace1 with Call_ID Supported:.. Replace

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

CUCM receives SIP 488 ,Not acceptable here, New Conference

CBGroup Americas CBGroup EMEA CBGroup APAC

Core Core Core Core Core Core

Database Database Database

Americas EMEA APAC

EMEA_CB1_fqdn (*) 50 Yes Yes Yes No

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

CMS Dial Plan: EMEA Outbound dial rules for CUCM

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

CMS Dial Plan: Forward dial rules : none

Key parameters for mapping

Prerequisite for QoS Packet marking at CMS

CLI command Typical configuration

Value can decimal or hexadecimal

In use case 1 no CAC was applied to video