2017/eur/pdf/BRKUCC 3001 PDF

Enabling Seamless Collaboration
with Advanced Session Routing

Architectures and Cisco Spark
Johannes Krohn, Technical Marketing Engineer

BRKUCC-3001
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 = BRKUCC-3001
5. Join the conversation!
The Spark Room will be open for 2 weeks after Cisco Live
BRKUCC-3001 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
Characteristics of Global Deployments

Reference Dial Plan
Topologies
Global Dial Plan Replication Applications
B2B Routing
Hybrid Calling with Cisco Spark
Summary
Abstract
Global Call Control Architectures involve support for global dial plans and also
multiple types of call controls including Communications Manager,
Communications Manager Session Management Edition and Expressway
complemented with Spark hybrid services. In this session we will cover design
consideration for global call control architectures that allow the implementation of
global dial plans. We will cover concepts like global +E.164 dial plans, URI dialing,
B2B routing in a number of scenarios. For architectures involving multiple
independent call controls we will discuss the pros and cons of full mesh trunk
topologies vs. hub and spoke topologies involving Communications Manager
Session Management Edition and how new concepts like ILS/GDPR can be used
to build scalable global dial plans. Finally we will discuss how the integration with
Spark hybrid services allows to build seamless integration of global collaboration
deployments with Spark.
A solid understanding of UCM dial plan fundamentals as presented in BRKUCC-
2008 and BRKUCC-3000 is a prerequisite.
Characteristics of Global
Deployments
Characteristics of Global Deployments
Scale
# of sites
# of users/devices
Global Footprint
single call control w/ global registrations
multiple call controls w/ local registrations
Regional PSTN access
Country specific requirements
numbering plan
dialing habits dialing domains
regulatory requirements
Call Control Consolidation
Consolidation of call controls drives
# of sites
# of users/devices
Operational aspects
dial plan consolidation
management consolidation improves efficiency
Scalability limitations
standard: 4 call control subscriber pairs each supporting up to 10k* devices
Megacluster**: 8 call control subscriber pairs each supporting up to 10k * devices
Other Limits
global reach (see next slides)
organizational separation
* starting with 11.5 scale beyond 10k per subscriber pair is possible but requires engineering review
**engineering review required (contact your account team)
Single Call Control w/ Global Registrations
Simplified global routing (single call control)

Forwarding Delay impact on signalling (cut-through delay)
Legal restrictions (for example data sovereignty)
Call Control sizing limitations
Reliability (WAN availability/performance)
Single Distributed Call Control w/ Local
Registrations
Clustering over the WAN (CoW) requirements
1.5 Mbps between publisher and any subscriber
1.5 Mbps between any two sites
max. 80ms RTT between any two subscribers*
*great circle RTT Delhi-Los Angeles w/ speed of light: 80ms
Simplified global routing (single call control)

Forwarding Delay impact on signalling (cut-through delay) ok for intra-region
Legal restrictions (data sovereignty) questionable
Call Control sizing limitations
Reliability (WAN availability/performance) Local survivability, but CoW requirements
need to be met
Multiple Call Controls w/ Local Registrations
More complex global routing (between call controls) options discussed later
topologies
dial plan
No Forwarding Delay impact on signalling for intra-region calls
Legal restrictions easier to manage (in-country call control)
Call Control sizing limitations less restrictive (user base distributed over call controls)
WAN availability has no impact of intra-cluster calls
Call control separation potentially also driven by organizational constraints
Management overhead? (multiple call controls)
Call Control Recommendation
Limited to single region (country): RTT, legal, ...
potentially split cluster deployment (multi DC) for redundancy
CoW requirements prohibit global deployment

local call control failover possible for limited number of sites
Not limited to single region

Flexible call control deployment decisions:
locality
organizational
legal requirements
Interconnection of independent call controls: tbd
PSTN Access
Centralized trunking vs. decentralized gateways/trunks
Centralized trunking
economy of scale; both provider and equipment cost
subject to RTT limitations discussed before
Limitations
(international) number portability
local survivability requirements
emergency calling requirements
WAN topology limitations (RTP bandwidth limitations)
Recommendation:
it depends
hybrid solution
Numbering Plan/Dial Plan
Fixed/variable length
+1: 10 digit NANP
+39, +43, +46, +49, +53, ...: variable length
NSN Length:
+1: 10 digits
+41, +61: 9 digits
+971: 8 digits
National dialing: w/ or w/o trunk access code
1: NANP (same as country code)
ITU recommended 0: Europe, +91, ...
No access code (NDC dialing): +61,
International dialing: various access codes
00: ITU recommended, Europe, +91, ...
011: NANP
0011: +61
Trunk access code: 9, 0, ...
Emergency calls: 911, 112/110, 000
Decoder ring: +39: Italy, +41: Switzerland, +43: Austria, +46: Denmark, +49: Germany, +53: Cuba, +61: Australia, +91: India, +971: United Arab Emirates
Reference: http://www.itu.int/oth/T0202.aspx?lang=en&parent=T0202
Country Specific Considerations
Single call control:
multiple national numbering plans
multiple dialing domains (users sharing same dialing habits)
Dial like the Romans do
PSTN specifics
number formats on trunks
Legal considerations
TEHO restrictions
VoIP regulations
legal intercept
emergency calling requirements
Recommendation: consult local agencies for written(!) authoritative information
Reference Dial Plan
Requirements
multiple national numbering plans
per country dialing habits (different dialing domains)
single dial plan logic for all countries
support for intra-enterprise dialing habits
abbreviated on-net (intra/inter-site)
features
services (VM, conferencing, etc.)
URI dialing
+E.164 dialing (from directories)
Forced On-Net
Thoughts
Core routing needs to be universal
Adaptability to regional dialing
Global addresses for DNs
Enterprise specific numbers (ESN) vs. +E.164
Adaptability to regional (country specific) dialing habits
Correct caller ID for all call flows
default caller ID for calls from DN: DN as provisioned
format which can be easily normalized to PSTN requirements
Reference +E.164 Dial Plan (10.x)
CSSs Partitions Route Lists Route Groups
DN urgent DNs to avoid IDT

Line CSS SJCInternational All IP Phone DNs (+E.164), urgent URIs in same partition
All dialing normalisation is CoS

SJCtoE164
DN un-specific!
1XXX, Prefix +1408555
All normalisation patterns can be
re-used
9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
UStoE164 LRG based egress GW selection

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

Site specificity only on site PSTNInternational
specific CoS (like local) USPSTNNational Local
Route
SJCPSTNLocal LOC RL Group
\+1408[2-9]XXXXXX, Urgent
2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Key UCM Features (10.0)
Urgent Directory Numbers
allows +E.164 DNs w/o inter-digit timeout due
to overlap with variable length +E.164
patterns
CSS Inheritance
TPs uses activating CSS for secondary
lookup
saves redundant TPs, partitions, CSSes
Multiple LRGs
extends UCM 7.0s LRG capabilities to
multiple classes of calls
Reference +E.164 Dial Plan (other dialing domains)
CSSs Partitions Route Lists Route Groups
DN
ESCInternational All IP Phone DNs (+E.164), urgent
ESCtoE164
DN
9XXX, Prefix +4961007739 Country specific dialing
0.[1-9]!, Pre-Dot, Prefix +496100 normalization
0.[1-9]!#, Pre-Dot, # Prefix +496100
Country (site) specific RPs

DEtoE164
000.!, Urgent, Pre-Dot, Prefix +
000.!#, Urgent, Pre-Dot, # Prefix +
00.[1-9]!, Pre-Dot, Prefix +49 XYZ RG
00.[1-9]!#, Pre-Dot #, Prefix +49
PSTNInternational
DEPSTNNational Local
Route
ESCPSTNLocal LOC RL Group
\+496100!
Reference +E.164 Dial Plan
Summary
+E.164 based routing
+E.164 addresses (DNs)
Dialing habits other than +E.164
implemented as overlay using translation
patterns with CSS inheritance
Egress gateway selection based on local
route groups
Multiple local route groups for differentiated
egress GW selection
Reference +E.164 Dial Plan
Benefits
+E.164 DNs provide AAR for free
forced on-net for free
Simple calling party handling
globalize on ingress
localize on egress
Tool: calling party transformation patterns
+E.164 core routing enables global deployment
Dialing Normalization TPs to adapt to regional
dialing habits
Topologies
Topologies with Multiple Global Call Controls
Any-to-Any connectivity becomes complex with increasing # of call controls (n 2)

hard/impossible to manage
SIP trunk topology
failover
...
SME to Simplify Topology
SME allows for simple hub and spoke topology

Leaf clusters route all off-cluster (off-net) traffic to SME
deterministic off-net descision covered later in this session
Centralized inter-cluster routing decisions (centralized dial plan)
Keeping Regional Traffic Regional
All inter-cluster signalling is tied to SME

even for call flows within region
Although media goes direct this potentially causes media path setup delays
Multiple SMEs
With regional SMEs signalling can be kept local

.. but we add another layer of SIP trunks for SME interconnect
SME of SME for really big topologies?
Single, distributed SME using Clustering over the WAN
Distributed SME has nodes in every region

Signalling kept within region
Still single point of administration
Distributed SME characteristics
500ms extended RTT between SME nodes (compared to 80ms)
only SIP trunks
Best Effort Early Offer or MTP-less Early Offer
run on all nodes
leaf clusters must accept inbound connections from all nodes
leaf clusters must have all SME nodes as peers
No endpoint registrations and CTI devices

No media resources (MTP, transcoder, ...) on SME
Reason: avoid intra-cluster signalling and media hairpinning
SIP Trunks between Leaf and SME
Leaf cluster has two upstream SIP trunks

peering with regional SME nodes
peering with remote SME nodes
All SME nodes exist as peer in at least one SIP trunk Leaf accepts inbound
sessions from all SME nodes
Both trunks typically combined by RL/RG; priority order
Alternative: selection of regional/remote trunk based on dialed destination
SIP Trunks between SME and Leaf
SME has single SIP trunk to leaf

Peering with all leaf nodes
SIP trunk (RL) based redundancy not required as UCM distributes SIP trunk
calls randomly between peers
SIP OPTION ping to determine state of SIP peers
Recommendations
Use SME to simplify SIP trunk topology
Use single distributed SME whenever possible (scale, WAN)
SIP trunks:
SIP Best Effort Early Offer
Run on all Nodes
Multiple Destination Addresses
OPTIONS ping
PRACK
Two Leaf to SME SIP trunks: regional vs. remote nodes
GDPR Applications
Problems to solve
On-Net/Off-Net decision w/ multiple call controls
912125557001
Maintained manually
+1 408 555 1XXX +12125557XXX +14085551XXX +1 212 555 7XXX

912125556001
+14045556XXX +19195557XXX
PSTN
+1 404 555 6XXX
+1 919 555 7XXX
Each call control has to take independent on-net/off-net

decisions
Requires knowledge about remote on-net addresses
+1 212 555 6001
Explicit configuration of remote address ranges or
automatic learning?
Complexity depending on number of prefixes!
Local On-Net/Off-Net w/ Centralized Dial Plan?
SME to centralize dial plan, Maintained manually
apps, PBX interconnect etc
Default routing on leaf vs. local
on/off-net decision
Really?
PSTN
912125556001
912125557001
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 212 555 7XXX +1 404 555 6XXX
GDPR to Action
GDPR learning and routing
Global Learned E.164 Numbers Global Learned E.164 Numbers
+4961007739003 nyc.route +4961007739001 sfo.route
+4961007739002 fra.route sfo.route +4961007739002 fra.route
nyc.route
+4961007739001 +4961007739003
ILS routestring: nyc.route
routestring: sfo.route Exchange
Call controls establish ILS Exchange

GDPR information flooded Global Learned E.164 Numbers
Each call control puts learned patterns/numbers +4961007739001 sfo.route
+4961007739003 nyc.route
in respective partitions and associated them with
routestring: fra.route
learned SIP route string
SIP route strings routed by SIP route patterns
+4961007739002
Routing Call to remote Number using ILS
Information
Global Leaned +E.164numbers
+4961007739003 nyc.route 2) Match on learned numeric +E.164 pattern in
+4961007739002 fra.route digit analysis leads to SIP route string fra.route
1) Alice calls +4961007739002
+4961007739001
ILS
routestring: sfo.route Exchange
3) call gets routed using SIP route pattern fra.route
routestring: fra.route
4) 4961007739002 is routeable using the trunks CSS (is a local DN) +4961007739002
Local On-Net/Off-Net w/ GDPR SIP routeE.164
Learned
E.164
string: east.route
pattern: pattern:
+14045556XXX (east.route)
+14045556XXX
+12125557XXX
Learned E.164 pattern:

SIP route string: west.route SIP route string: east.route
E.164 pattern: E.164 pattern:
+14085551XXX PSTN +14045556XXX
+19195557XXX +12125557XXX
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 404 555 6XXX +1 212 555 7XXX
Local On-Net/Off-Net w/ GDPR Learned E.164 pattern:
+14085551XXX (west.route)
Learned E.164 pattern:

+14085551XXX PSTN +14045556XXX
+19195557XXX +12125557XXX
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 404 555 6XXX +1 212 555 7XXX
SIP route string:(east.route)
west.route
+14045556XXX
E.164 pattern: (east.route)
+12125557XXX
+14085551XXX
+14085551XXX(west.route)
+19195557XXX
+19195557XXX(west.route)
Learned E.164 pattern: Learned E.164 pattern:

+14045556XXX (east.route) +14085551XXX (west.route)
+14085551XXX PSTN +14045556XXX
+19195557XXX +12125557XXX
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 404 555 6XXX +1 212 555 7XXX
+19195557XXX (westroute)

+14085551XXX PSTN +14045556XXX
+19195557XXX +12125557XXX
+1 212 555 7001
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 404 555 6XXX +1 212 555 7XXX
Digit analysis and route lookup is hop-by-hop +14085551XXX (west.route)
+19195557XXX (westroute)

+14085551XXX PSTN +14045556XXX
+19195557XXX +12125557XXX
+1 212 555 7001
+1 212 555 6001

+1 408 555 1XXX +1 919 555 7XXX +1 404 555 6XXX +1 212 555 7XXX
GDPR Design Considerations
GDPR in an Enterprise Dial Plan
Dialing learned numbers
Up to three intercluster dialing habits to reach CSSs Partitions
remote DN: DN
Enterprise (8+7) based on enterprise alternate/pattern SJCInternational All IP Phone DNs (+E.164)
+E.164 based on +E.164 alternate/pattern
URI
SJCtoE164
DN
Assuming that CoS does not depend on dialing 1XXX, Prefix +1408555
habit all remote patterns can be put into single partition 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
onNetRemote
onNetRemote
ILS learned URIs are reachable from any device (, but the SIP route All patterns/numbers
patterns potentially are not) learned via GDPR + SIP route
patterns for SIP route strings
onNetRemote added to all CSSes with CoS On-net

Also make sure to add SIP route pattern matching on SIP route strings to onNetRemote partitions
ILS Topology
Single hub
ILS hub
(Distributed) SME as ILS hub, all other UCMs as spokes

straight forward
assumption: SIP trunking and ILS topology equivalent
Why?
ILS Networking, URI Learning and Routing
Components of end-to-end bob@cisco.com ILS networking jkrohn@cisco.com
84969XXX 84953XXX
dialing/routing
ILS networking route string:
nyc.route
GDPR propagation route string:
fra.route
jkrohn@cisco.com. 84953XXX (fra.route)
GDPR propagation bob@cisco.com, 84969XXX (nyc.route)
SIP trunk
SIP Trunk
SIP route pattern route: fra.route route: nyc.route
SIP connectivity is foundation for call routing based on SIP route patterns
ILS networking is foundation for exchange or GDPR reachability information
GDPR propagation/exchange is enabled independent of ILS networking
SIP trunk and ILS topology are independent!
ILS Topology
Multiple hubs
ILS hub
Recommendation: all UCMs are ILS hubs

Limit: max 10 hubs
Benefit: easier to troubleshoot, faster convergence
ILS overhead of full-mesh is minimal (2 message per update interval)
ILS Topology
Growing the Network
ILS hub
ILS spoke
hub/spoke
relation
Start with all UCMs being ILS hubs

Keep adding ILS hubs until limit (10 hubs) is reached
continue to add UCMs as spokes and select close UCMs as their hub
ILS Topology
Growing the Network
ILS hub
ILS spoke
hub/spoke
relation
Start with all UCMs being ILS hubs

Keep adding ILS hubs until limit (10 hubs) is reached
continue to add UCMs as spokes and select close UCMs as their hub
potentially identify few (starting with one) spoke supporting hubs
PSTN Access
Centralized
Benefits:
centralized PSTN policy; think on/off-net decision w/o GDPR!
resource consolidation
BUT:
site context lost
source specific egress selection policy requires nasty workarounds
PSTN Access
Distributed
GDPR enables distributed deterministic on/off-net

decision
Enables source specific egress selection policy (LRG)
TEHO still an option
TEHO prefix advertisements as GDPR patterns
specific partition for GDPR patterns vs alternate numbers TEHO CoS possible
PSTN Access
Distributed
GDPR enables distributed deterministic on/off-net

decision
Enables source specific egress selection policy (LRG)
TEHO still an option
TEHO prefix advertisements as GDPR patterns
specific partition for GDPR patterns vs alternate numbers TEHO CoS possible
GDPR Route String Name Space
us1.route *.route
ea1.route ea2.route
us2.route
as1.route as2.route
use pseudo TLD: example *.route

name space hierarchy in line with SIP trunk topology
one-tier hub/spoke flat name space: us1.route, us2.route, ea1.route, ...
explicit SIP route patterns on SME, wildcard SIP route pattern upstream on leaf
B2B Routing
B2B Call Flow DNS
Hierarchy
Single Edge
Expressway-C
Forward SIP Invite to companyB.com

using IP address received via DNS
VCS-E
Expressway-E Sends SIP 200 OK

Calls
x.y@companyB.com Internet
VCS-C
a.b@companyA.com
x.y@companyB.com
COMPANY A
COMPANY B
B2B w/ Expressway
Single Edge
B2B peer
signalling
media
single B2B ingress & egress point

media hairpinning through Expressway-C/E
suboptimal user experience
B2B w/ Expressway
Multiple Edges, Egress Edge Selection
B2B peer
signalling
media
Egress edge selection on SME

outbound B2B traffic sent to SME by leaf clusters
site specific egress edge selection typically not required (.. and not possible due to
loosing site context on SME)
region specific egress edge selection based on upstream trunk LRG logic
single SIP route pattern on SME for outbound B2B calls
B2B w/ Expressway
Multiple Edges, Ingress Edge Selection Closest to Calling Party
B2B peer
signalling
media
B2B edge identification based on DNS SRV lookup

W/ multiple edges: use GEO DNS
DNS SRV record resolution takes location (IP address) of orginator into account
public DNS needs to provide GEO DNS service
redundancy (failover to other edges) still an option
B2B w/ Expressway
Multiple Edges, Ingress Edge Selection Alternatives?
B2B peer
signalling
media
inter-region B2B sessions on enterprise WAN
B2B w/ Expressway
Multiple Edges, Ingress Edge Selection Alternatives?
B2B peer
signalling
media
inter-region B2B sessions on enterprise WAN

Ingress edge selection based on called destination?
Internal location of called party unknown externally
called party specific ingress edge selection requires internal routing logic
B2B w/ Expressway
Multiple Edges, Ingress Edge Selection Closest to called party
B2B peer
signalling
media
Expressway searching logic allows to try alternate paths

Solution concept:
direct all ingress B2B traffic to master Expressway (DNS based)
B2B w/ Expressway
B2B peer
signalling
media

Solution concept:
master tries all options: inbound to SME and via other Expressways
B2B w/ Expressway
B2B peer
signalling
media

Solution concept:
master tries all options: inbound to SME and via other Expressways
SME routing logic cancels all but the desired path
How?
B2B w/ Expressway
B2B peer
CSS_B2B_US
GDPR_US signalling
GDPR_US
media
us1.route
us2.route
CSS_B2B_AS
GDPR_US GDPR_AS
as1.route
Differentiated CoS for ingress B2B trunks
as2.route
Classification based on SIP route string learned
CSS_B2B_EA
GDPR_US GDPR_EA
for dialled destination
ea1.route
Inter-region calls from edge easily prohibited ea2.route
Caveat: no ingress inter-region failover possible!

Hybrid Calling with Cisco Spark
Cisco Spark Hybrid Services
Hybrid
Message Meeting
Services Call
Communications
Manager
HCS
Connect existing Cisco calling capabilities to Delivered Services
Business Edition
Cisco Spark capabilities in the cloud Series
Connected Calling
Cisco Cisco
On-Premises & Collaboration
Partner Hosted HCS Cloud
Call Service Connect - connects Cisco Spark & the enterprise phone system so they behave as one
Your Spark app becomes an enterprise softphone

Provides voice and video interoperability between Jabber and Spark
User benefits:
Choice: use Jabber or Spark to call anyone without worrying about which you or the other person is using
One number: be reached on Spark, Jabber, or a deskphone. Choose to take the call on whichever suits you best at that moment
Reach everyone: call company extensions, PSTN numbers, Spark only users, and even video bridge numbers
Company dial plan: dial from the Spark app as you would from your deskphone - call PSTN numbers via enterprise phone system
Make the most of video assets: en-route to the office start a call on a mobile device and hand off to a room system when you arrive
Call Connect Problem Statement
Simultaneous Ring on Spark and Enterprise for:
Spark-to-Spark calls
Calls to the enterprise extension (B2B, on-net, PSTN)
B2B calls
On UCM simultaneaus ring can be achieved using Remote Destinations
But: same URIs in Spark and Enterprise
What can be used to route?
Solution: use RD based call forking on UCM with new identity:
Cloud URI
Cloud URI
alice@example.com alice@example.com
alice@example.call.ciscopark.com
Single (unique!) cloud domain defined per organisation
bob@example.com Domain is verified to be unique bob@example.com

example.com
bob@example.call.ciscospark.com
Used to create cloud URI per User (if enabled for CSC)
Cloud URI provisioned as remote destination on CTI-RD
associated with user in UCM
alice@example.org alice@example.org
alice@example-org.call.ciscospark.com example.org
Call Service Connect/Aware
Architecture
Call Service Connect/Aware Architecture
*.ciscospark.com example.com
Expressway-E Expressway-C
Communications
Manager
SIP
Expressway-C AXL/SOAP
CTIQBE
(Connectors)
REST/HTTPS
Communications
Manager
Spark clients connect
to Cisco Collaboration SIP
Cloud over-the-top (OTT) Expressway-C AXL/SOAP
CTIQBE
(Connectors)
REST/HTTPS
Communications
Manager
Standard B2B/MRA setup. Not neccessarily
needs to be dedicated to hybrid services SIP
CTIQBE
(Connectors)
REST/HTTPS
Communications
(secure) SIP trunks for B2B, MRA and Manager
CSC calls.
SIP
CTIQBE
(Connectors)
REST/HTTPS
Communications
Manager
SIP
Expressway-C as connector platform: (Connectors)
CTIQBE
Management, Calendar, Call REST/HTTPS
Call Connector
Communications
Manager
HTTPS to connect to RESTful services
(management, call state, ...)
SIP
Independent of Expressway-C/E AXL/SOAP
Expressway-C
for B2B/MRA CTIQBE
(Connectors)
REST/HTTPS
Communications
Manager
AXL/SOAP: validation and provisioning:
Users, devices, remote destinations, ... SIP
CTIQBE
(Connectors)
REST/HTTPS
CTIQBE: device monitoring
(and control)
Call Service Connect
Call Flows
Refresher: Remote Destinations in UCM
Someone calls 1
bob@example.com
Someone calls
Session routing
bob@example.call.ciscospark.com 7 numeric & URI
1 Incoming call from trunk 2

Destination matches a URI DN +49 6100 7739764
2 associated with a DN bob@example.com
Device identified the DN is
3 3
associated with 6
4 Session initiated with device 5 Someone calls
bob@example.com
Phone/Client
5 DN is also associated with 4
CTI-RD (shared line) CTI-RD
6 Session initiated to remote destination Remote destination
7 Outbound session to remote destination
UCM
Refresher: Anchoring in UCM
alice@example.call.ciscospark.com calls
bob@example.com 1
Session routing
numeric & URI
1 Incoming call from trunk 4

3
2 Caller ID matches a remote destination DN +49 6100 7739765 DN +49 6100 7739764
alice@example.com bob@example.com
3 Call treated as if it originated
from CTI-RD 5
Destination matches a URI
2
4 associated with a DN 3 alice@example.com calls
bob@example.com
Phone/Client
5 Device identified the DN is 6
associated with CTI-RD
6 Session initiated with device Remote destination
alice@example.call.ciscospark.com
UCM
Refresher: Anchoring w/ RD on Target
alice@example.call.ciscospark.com calls
bob@example.com 1
Session routing
alice@example.com calls
9 numeric & URI
4
3
1 ... 6 Same as before DN +49 6100 7739764
DN +49 6100 7739765
alice@example.com bob@example.com
7 DN is also associated with
CTI-RD (shared line) 2 5
8 Session initiated to remote destination 8 7
3 alice@example.com calls
bob@example.com
Phone/Client
9 Outbound session to remote destination 6
CTI-RD CTI-RD
Remote destination Remote destination
alice@example.call.ciscospark.com bob@example.call.ciscospark.com
UCM
Call Flow (Spark to Spark, Intra-Enterprise)
Call initiated by entering a

URI in the calls tab or by
selecting entry in recents
bob@example.com calls list bob@example.com
example.com
DNS
_sip._tcp.example.com.
_sip._tcp.example.org.
example.org
Spark user identified via URI match

If call was initiated by pressing call button
bob@example.com in space or for Spark user in recents list bob@example.com
then Spark user is identified directly example.com
DNS
example.org
Call presented to Spark User

bob@example.com bob@example.com
example.com
DNS
example.org
bob@example.com Call is forked to the callers enterprise bob@example.com

(caller is enabled for CSC) example.com
Destination is bobs enterprise URI (only

DNS is enabled for CSC)
exists if destination
Caller _sip._tcp.example.com.
ID is callers Spark SIP address:
alice@example.call.ciscospark.com
alice@example.org Expressway-E identified by SIP destination alice@example.org
configuration in Spark organisation example.org
Expressway-E/C routes
example.com
call to UCM cluster
DNS
example.org
Call example.com
anchored on
CTI-
RD of caller
DNS (alice@example.com)
_sip._tcp.example.com. UCM routes to endpoint
example.org
UCM example.com
routes to endpoint
... and CTI-RD of Bob
DNS and forks call to Bobs
_sip._tcp.example.com. Spark SIP address
_sip._tcp.example.org. (remote destination)
example.org
example.com
Expressway-C/E routes
to cloud based on cloud
DNS domain:
_sip._tcp.example.com. *.ciscospark.com
example.org
bob@example.com Loop is detected bob@example.com

in cloud example.com
DNS
example.org
Call Flow (Spark to Spark, Inter-Enterprise)
Call initiated as before but

between Orgs
(URI, 1:1 room, ...)
example.com
DNS
example.org
Call presented to Spark User

and forked call to calling example.com
users enterprise (calling and
called user enabled for CSC)
DNS
example.org
Call example.com
anchored on
CTI-
RD of caller
DNS (alice@example.com)
_sip._tcp.example.com. UCM routes to called
_sip._tcp.example.org. URI (SIP route pattern)
example.org
example.com
Expressway routesto
target based on SRV
DNS
example.org
example.com
DNS
example.org
Expressway-E/C routes
call to UCM cluster
example.com
UCM routes call to endpoint
DNS
example.org
example.com
UCM routes call to endpoint
DNS ... and CTI-RD with Spark
SIP address as remote
destination
example.org
Loop is detected
bob@example.com by cloud bob@example.com
example.com
DNS
example.org
Spark Call Forking
For calls initiated from Spark a call is always forked to the calling users
enterprise if the calling user is enabled for CSC
Reason:
this makes sure that Spark initiated calls are subject to the same policies and can use
the same dialing habits as calls initiated within the enterprise (CTI-RD CSS used)
anchoring makes sure that the caller ID is set to the enterprise URI of the calling user
For calls initiated from Spark a call is forked to the called users enterprise if only
the called user is enabled for CSC
in this case the caller ID is the callers Spark SIP address
CSC Forking for Spark 1:1 Calls
Calling user Called user Call forked to Called Address
Enabled for CSC enabled for CSC
Yes Yes Calling users Enterprise URI
enterprise
Yes No n.a. n.a.
No Yes Called users Enterprise URI

enterprise
No No n.a. n.a.
Closing
References
Solution Reference Network Design: http://www.cisco.com/go/ucsrnd
Collaboration Preferred Architecture Guides:
http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-collaboration/index.html
National Numbering Plan Collection:
http://www.itu.int/oth/T0202.aspx?lang=en&parent=T0202
Getting Started with Cisco Spark Hybrid Services: https://help.webex.com/docs/DOC-6433
Deploying Cisco Spark Hybrid Services (CVD Guide):
http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-collaboration/index.html
EMEA Country specific numbering plan information: https://goo.gl/3FCcBw
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
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
Appendix: Hybrid Calling
Configuration Details
General Requirements
UCM must run 10.5(2) SU3 or later
If cloud services URIs are greater than 48 characters then you want to upgrade to a release (ES) which
also has the fix for CSCux74780
Expressway-C connector must run X8.7.1 or later
Codecs supported by Collaboration Cloud:
Audio: G.711u, AAC-LD, Opus
VideoH.264
URI routing configured on UCM

All domains used in enterprise URIs need to verified and registered on Cisco Collaboration Cloud org
Expressway-E certificate:
signed by public CA
SAN for all Expressway-E hosts
SANs need to belong to the domains registered on the Cisco Collaboration Cloud organization
Connector Configuration
UCM clusters
Each UCM cluster needs to be provisioned on call connector
User needs to be an application user with:
Standard AXL API Access
Standard CTI Allow Control of All Devices
Standard CTI Enabled
Standard CTI Allow Control of Phones supporting Connected Xfer and conf
Standard CTI Allow Control of Phones supporting Rollover Mode
On each UCM cluster the CFQDN has to be set to a unique
value (see preloaded header discussion later)
If multiple CFQDNs are configured then the 1 st
is considered; no wildcards allowed
Call Service Connect End-to-End
Enterprise Settings
DNS zone
A single SIP URI Domain name is defined per
Organization
SIP URI Domain has to be unique (validated)
This is used to build the Spark SIP address Traversal zone
for each user
Domain can only be defined ONCE
Suffix call.ciscospark.com for all Spark SIP
addresses
UCM neighbor
Example zone
SIP URI Domain Name: example
Host portion of Spark SIP addresses:
example.call.ciscospark.com
Enable Users for Call Service
DNS zone
Users must be entitled for Call
Service Aware
Cloud Collaboration Management
Portal is used to change user Traversal zone
entitlements
Call connector for all enabled users
populates enterprise URI and Spark
SIP address UCM neighbor
zone
Spark to Expressway
DNS zone
SIP Destination per Org is configured in
Cloud Collaboration Management
Configured destination can be IP, host,
or DNS SRV
Traversal zone
Expressway-E certificate must match

configured host/SRV
Mutual TLS (MTLS) authentication is
required for CSC
UCM neighbor
zone
MTLS can not be used on port 5061 if
Expressway-E is used for MRA
Use different port instead (5062)
MTLS on Expressway-E
Dedicated DNS zone
If Expressway-E is dedicated to
CSC then default port 5061 can be
configured for MTLS
Traversal zone
Shared
If also used for MRA then enable

MTLS on dedicated port (5062)
UCM neighbor
Mutual TLS mode = On: enable zone
additional MTLS port
Neighbor Zone to Spark
DNS zone
Challenges:
Peer definition based on IP addresses not suitable for cloud solution
DNS zone (prior to X8.6.1) allows flexible outbound routing, ...
... but we also need to be able to validate inbound connections Traversal zone
Solution:
Starting with X8.6.1 allows to configure mutual TLS authentication
Classification of inbound connections based on TLS peer certificate
DNS Zone selected based on identity in TLS certificate UCM neighbor
zone
Enables:
Dynamic outbound routing to cloud entities (DNS lookup)
Inbound authentication of dynamic cloud entities (based on certificate)
Neighbor Zone (DNS) to Spark
DNS zone
Enable MTLS classification
TLS verify mode: On
TLS verify subject name: populated
TLS verify inbound mapping: On
Both of the above flags need to be set to on to Traversal zone

enable inbound classification against the zone
TLS verify subject name needs to match the peer
certificate presented by Spark during TLS setup
fixed value: callservice.ciscospark.com
UCM neighbor
Preloaded SIP routes support required for source zone
based routing (discussed later)
Calls to Spark are bound to a fixed Domain
DNS SRV requests for a fixed domain
Home Cluster Routing Bob: ucm-eu.example.com
Alice: ucm-us.example.com DNS zone
Multiple UCM clusters inside an enterprise
Challenge: send incoming forked CSC session

to correct UCM cluster (calling users cluster)
Solution: call connector populates home clusters

CFQDN in Spark per user ucm-eu.example.com
?
CSC calls have a SIP route header carrying
this attribute
Expressway-C routes to home cluster based on this Preloaded SIP Route

ucm-us.example.com
By default Expressway rejects calls with preloaded SIP Routes
UCM neighbor
zone
Preloaded SIP Routes need to be enabled on DNS zone and traversal zones for CSC
Source based routing based on SIP route header not possible on SME
Traversal Server on Expressway-E
DNS zone
Taversal zone for CSC can be
dedicated or shared
Dedicated allows for differentiated
call treatment
If addtl. port on firewall is a problem
then existing traversal zone can be
reused; impact on search rule
configuration UCM neighbor
zone
Preloaded SIP routes support
required for home cluster routing
Traversal Client on Expressway-C
DNS zone
Preloaded SIP routes support
required for Home Cluster Routing
UCM neighbor
zone
Search Rules on Expressway-E
DNS zone
To UCM:
Route everything from the MTLS
authenticated DNS zone to the
traversal zone
No further matching required
From UCM:
With dedicated CSC traversal zone UCM neighbor
route everything from traversal zone to zone
DNS zone
Search Rules on Expressway-E
DNS zone
To UCM:
Route everything from the MTLS
authenticated DNS zone to the
traversal zone
No further matching required
From UCM:
With dedicated CSC traversal zone UCM neighbor
route everything from traversal zone to zone
DNS zone
Shared traversal zone requires more
specific treatment:
.*@.*\.ciscospark.com
Differentiated CoS per User
DNS zone
For calls anchored on a CTI-RD the CTI-RD
device CSS and line CSS are used to route
the call
This makes sure that for all CSC calls

originating from CSC enabled users (caller ID
is cloud services URI) per user CoS is Traversal zone
enforced
alice bigboss
bob
X
UCM neighbor
zone
UCM neighbor zones/UCM trunks
DNS zone
Multiple inbound trunks on UCM require multiple UCM neighbor
zones on Expressway-C
Dedicated zones for CSC per UCM
Dont re-use zones defined for B2B Traversal zone
(see CoS discussion)

Use listening port numbers on UCM to
multiplex trunks
Listening port on UCM defined by SIP UCM neighbor
zone
Security profile
Expressway-C Search Rules
DNS zone
To UCM
One search rule per UCM cluster
Match on CFQDN in SIP route header
(CFQDN pushed into cloud by
call connector) Traversal zone
From UCM
With dedicated Spark traversal zone
create Spark specific search rule UCM neighbor
Else calls to spark are subset of B2B rule on zone
Expressway-C
UCM User
DNS zone
Enduser requirements in UCM
Mail ID
Telephone Number
Home cluster attribute
Enabled for Mobility Traversal zone
Primary Extension
Enterprise URI provisoned on users primary extension (DN)
UCM neighbor
zone
CTI-RD, remote Destinations
DNS zone
CTI Remote Device needs to be provisioned
Users primary extension as DN (shared line)
Rerouting CSS has to have access to route to Spark Traversal zone
CSS only used if per user CoS is enabled (see before)

CTI-RD to be added to users list of controlled devices
Call connector uses this to select CTI-RD for remote destination
provisioning UCM neighbor
zone
Cloud services URI automatically provisioned as remote
destination by call connector
Note: the above is subject to change (more automation)

2017/eur/pdf/BRKUCC 3001 PDF

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

2017/eur/pdf/BRKUCC 3001 PDF

Uploaded by

Copyright:

Available Formats

Enabling Seamless Collaboration

with Advanced Session Routing

Johannes Krohn, Technical Marketing Engineer

Use Cisco Spark to communicate with the Speaker and fellow

Download the Cisco Spark app from iTunes or Google Play

Characteristics of Global Deployments

Simplified global routing (single call control)

Simplified global routing (single call control)

CoW requirements prohibit global deployment

Not limited to single region

Interconnection of independent call controls: tbd

DN urgent DNs to avoid IDT

All dialing normalisation is CoS

UStoE164 LRG based egress GW selection

Routing is CoS specific.

Country (site) specific RPs

Any-to-Any connectivity becomes complex with increasing # of call controls (n 2)

SME allows for simple hub and spoke topology

All inter-cluster signalling is tied to SME

With regional SMEs signalling can be kept local

Distributed SME has nodes in every region

No endpoint registrations and CTI devices

Leaf cluster has two upstream SIP trunks

SME has single SIP trunk to leaf

+1 408 555 1XXX +12125557XXX +14085551XXX +1 212 555 7XXX

Each call control has to take independent on-net/off-net

+1 212 555 6001

Call controls establish ILS Exchange

1) Alice calls +4961007739002

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

Learned E.164 pattern:

+1 212 555 6001

Learned E.164 pattern:

+1 212 555 6001

Learned E.164 pattern: Learned E.164 pattern:

+1 212 555 6001

Learned E.164 pattern: Learned E.164 pattern:

+1 212 555 7001

+1 212 555 6001

Learned E.164 pattern: Learned E.164 pattern:

+1 212 555 7001

+1 212 555 6001

onNetRemote added to all CSSes with CoS On-net

(Distributed) SME as ILS hub, all other UCMs as spokes

Recommendation: all UCMs are ILS hubs

Start with all UCMs being ILS hubs

Start with all UCMs being ILS hubs

GDPR enables distributed deterministic on/off-net

GDPR enables distributed deterministic on/off-net

use pseudo TLD: example *.route

Forward SIP Invite to companyB.com

Expressway-E Sends SIP 200 OK

single B2B ingress & egress point

Egress edge selection on SME

B2B edge identification based on DNS SRV lookup

inter-region B2B sessions on enterprise WAN

inter-region B2B sessions on enterprise WAN

Expressway searching logic allows to try alternate paths

Expressway searching logic allows to try alternate paths

Expressway searching logic allows to try alternate paths

Caveat: no ingress inter-region failover possible!

Your Spark app becomes an enterprise softphone

Single (unique!) cloud domain defined per organisation