Brkucc 2801

BRKUCC-2801
Enabling External
Collaboration with
Expressway
Kevin Roarty, Technical Marketing Engineer

Cisco Collaboration
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKUCC-2801
BRKUCC-2801 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
• Expressway Solution Overview - including the latest
details on services, compute platforms, licensing, and
scale
• Mobile & Remote Access including the latest Jabber, IP
Phone and TelePresence endpoint feature updates and
deployment guidance
• SIP OAuth for Jabber clients
• ICE Media Path Optimization for Mobile & Remote Access
• Expressway-E support for Let’s Encrypt CA certificates
• Single SAML SSO cluster wide agreement
Solution Overview
Cisco Expressway
Mobile & Open Video Cisco Webex WebRTC Video Call

Remote + Hybrid Services Guest Video Control &
Access IM & Presence Interop
Federation
New Features
• SIP OAuth for Jabber
New Release clients

• ICE Media Path
Optimization for MRA
X12.5 • Let’s Encrypt CA
Support
Now Available! • Single SAML SSO
Agreement
• MRA Activation Code
Onboarding
Product Line Options X8.1
VCS Expressway
“VCS Control” “VCS Expressway” “Expressway-C” “Expressway-E”

No Change No Change Or Core Or Edge
• Designed for video-centric customer • Included in Cisco UCL, CUWL, Flex,

deployments and EA Multiparty licensing
• Stand-alone licensing model requiring • $0 server software licenses
base server and session licenses • X8.9 includes feature updates to
service video-centric customer
• No recent changes to licensing model
deployments (w/o CUCM)
Expressway Local Registration Support
SIP & H.323 Video Call Control
Internal Network DMZ External Network
Internet
Expressway-C Expressway-E
H.323 Gatekeeper & SIP

Registrar providing standards-
based interop and video support
SIP signaling
for Cisco & 3rd party endpoints
H.323 signaling
Expressway-E Local Registration Support
• Beginning with X8.11 Expressway-E supports local SIP and H.323 video
registration
• Expressway-E no longer required to proxy SIP registrations
• Allows for remote H.323 registrations
• Local SIP and H.323 registrations allowed on Expressway-C since X8.9
• UCL Enhanced License enables SIP Desktop Endpoints (DX70/80,
EX60/90)
• TP Room System License required for all other systems including 3 rd party
and H.323
• Same option keys (Room System, Desktop System) used on both
Expressway C & E
Cisco Expressway and VCS
Cisco
Feature Comparison Cisco VCS
Expressway
Mobile and Remote Access Y Y

Business to Business Video (including MSFT Video Federation) Y Y
Consumer to Business with Jabber Guest Y Y
Cisco Meeting Server WebRTC (Proxy & TURN) Y Y
Video Interworking (H.323-SIP, IPv4 to IPv6, MSFT Interop) Y Y
Video / TelePresence Endpoint Registration Y Y
Cisco Webex Hybrid Service Connectors Y N
Webex Collaboration Meeting Room (CMR) Cloud/Hybrid Y Y
XMPP IM & Presence Federation Y Y
SIP IM & Presence Federation (with Skype for Business) Y Y
VCS End of Life Plans
• VCS product line has been sunset
• No further development, limited test
• No new appliances
• VCS will be EoL’d: Timing TBD
• Expressway X8.11+ release includes VCS feature set, UCM not required
• New customers: Deploy Expressway
• Existing customers: Plan migration to Expressway
• €0* migration program allows VCS customers to migrate to Expressway or CUCM (simpler
licensing model that removes guesswork!)
• Investment protection: Any customer who bought VCS since 2007 can migrate to
Expressway or CUCM for €0
*SWSS required
How Expressway Firewall Traversal Works
Enterprise Network DMZ Outside Network
UCM Internet
B
Expressway-C FW Expressway-E FW Signaling
Media
A
1. Expressway-E is the traversal server installed in DMZ. Expressway-C is the traversal client installed within the
enterprise network
2. Expressway-C connects via the firewall to a specific port on Expressway-E with secure login credentials.
3. Once the connection has been established, Expressway-C sends keep-alive packets to Expressway-E.
4. When Expressway-E receives an incoming call, it issues an incoming call request to Expressway-C.
5. Expressway C then initiates connection through CUCM to the endpoint
6. The call is established and media traverses the firewall securely
Expanded Firewall Traversal Capabilities
Expressway-C Firewall Expressway- E
Expressway delivers 3 key capabilities enabling Expressway

use cases beyond just video
• Option to proxy remote SIP registrations to Unified CM
• XCP Router for XMPP traffic
• HTTPS Reverse proxy
Compute Platforms,
Licensing
& Scale
Expressway Licensing
Business to Business Consumer to Business Interoperability Gateway

Calls Calls Calls
Firewall Traversal Calls Jabber Guest Calls i.e. intradomain MSFT

consume 1 x RMS on consume 1 x RMS on interop calls, consume 1
Expressway E Expressway E RMS on Expressway C
(includes MSFT B2B Gateway
calls)
Registered Calls (no RMS required)

Calls between endpoints registered to Cisco Call control services
Calls to Cisco conferencing infrastructure or cloud services
Cisco Meeting Server WebRTC
Expressway License & Resource Usage
• Calls from MRA endpoints or endpoints
registered locally to Expressway are
classified as Registered calls
• Calls to/from Webex cloud are

classified as CMR Cloud calls
• “Registered” & “Cloud” calls do not

consume Rich Media Session licenses,
but do count against the overall system
capacity
Expressway Compute Platform Options
Specs Based CE1200 Appliance

Virtual Machine Support
Reserved Disk
OVA Size vCPU NIC(s)
RAM Space
2 x 1.8
Small 4GB 132GB 1Gb • SKU: EXPWY-1200-K9
GHz
2 x 2.4 • Bare metal – no hypervisor
Medium 6GB 132GB 1Gb
GHz • Cisco UCS C220-M5L
8 x 3.2 • Solution for customers with security policies
Large 8GB 132GB 1Gb
GHz that do not allow VMware in the DMZ
Expressway CE1200 Appliance
• UCS-C220-M5L based appliance, bare metal (no hypervisor)
• CE1100 replacement
Now
• Expressway ONLY, no VCS option Shipping!
• Includes 10Gb SR Fiber SFPs & 1Gb Copper SFPs
• Scale improvements over CE1100, including 5K MRA registrations
• Ordering Simplification
• Single appliance SKU, EXPWY-1200-K9
• Role selection wizard allows customer to deploy as Expressway C or E
Expressway X12.5 Scalability
Server Cluster
Audio Only Audio Only

Platform Registrations Video Calls Registrations Video Calls
Calls Calls
CE1200 5,000 500 1,000 20,000 2,000 4,000
Large OVA 3,500 500 1,000 14,000 2,000 4,000
Medium OVA 2,500 100 200 10,000 400 800
Small OVA
2,000 75 150 2,000 75 150
(BE6000 M5)
Expressway Clustering, 4+2
• Cluster up to 6 Expressways for scale and
redundancy
• Clustering latency up to 80ms RTT
• Expressway E and C node types cannot be mixed in

the same cluster
• Deploy equal number of peers in Expressway C and
E clusters (this applies to most Expressway
deployments but is not critical if Expressway is
handling local registrations)
• Deploy same OVA sizes or appliances throughout
cluster
• Customers can deploy multiple clusters for the
same domain
Mobile & Remote
Access (MRA)
Mobile and Remote Access
with Cisco Expressway Jabber @Café
Private Network DMZ External Network
Internet Jabber @Home
UCM Expressway-C Expressway-E
Jabber @work
Jabber @MCO
Fixed Remote
Endpoints
Webex Room 55/70
Webex Room Kit
MRA Client & Endpoint Support Webex

Webex
Room Kit Plus
Room Kit Pro
Available Today Webex Room Kit Mini
Internal Network DMZ External Network
DX650, DX70, DX80
Internet
MX, SX, EX, C Series
TelePresence Endpoints
New!
12.1.1
required 8811, 8841, 8845, 8851, 8861, 8865
7832 & 8832 7811, 7821, 7841, 7861
Expressway & Jabber Service Discovery
DNS SRV lookup _cisco-uds._tcp.example.com
✗ Not Found
Internet DNS SRV lookup _collab-edge._tls.example.com
UCM Expressway-C Expressway-E Public DNS
✓ expwy-nyc.example.com
Jabber allows for a secondary domain to be used TLS Handshake, client authenticates
for edge service discovery. Expressway-E certificate
The “VoiceServicesDomain” can be provided in
jabber-config.xml (from TFTP or Messenger cloud), HTTPS:
or bootstrapped into client via MSI, or get_edge_config?service_name=_cisco-
ciscojabber://URL provisioning uds&service_name=_cuplogin
Split DNS SRV Record Requirements
• collab-edge record needs to be available in public DNS
• Multiple SRV records (and Expressway-E hosts) should be deployed for clusters
• A GEO DNS service can be used to provide unique DNS responses by geographic
region
_collab-edge._tls.example.com. SRV 10 10 8443 expwy1.example.com.

_collab-edge._tls.example.com. SRV 10 10 8443 expwy2.example.com.
• cisco-uds record needs to be available only in internal DNS
_cisco-uds._tcp.example.com. SRV 10 10 8443 ucm1.example.com.

_cisco-uds._tcp.example.com. SRV 10 10 8443 ucm2.example.com.
Protocol Workload Summary
Inside firewall DMZ Outside firewall

(Intranet) (Public Internet) Protocol Security Service
SIP TLS Session Establishment –
Collaboration Internet Register, Invite, etc.
Services
Media SRTP Audio, Video, Content
Share
Unified Expressway Expressway
CM C E HTTPS TLS Logon,
Provisioning/Configuration,
Unified CM IM&P Contact Search, Visual
Voicemail
Unity Connection XMPP TLS Instant Messaging,
Presence
Conferencing Resources
Hybrid Deployment - Cloud based IM&P

Services
Share
Contact Search, Visual
Webex Voicemail
Unity Connection Messenger Cloud XMPP TLS Instant Messaging,
Presence
Jabber with Team Messaging Mode New with
Jabber
12.5
Win/Mac

Services
Share
Contact Source, Visual
Cisco Voicemail
Unity Connection Webex Cloud HTTPS TLS Messaging including 1:1,
spaces, file sharing, etc.
UDS Directory Search
• All Jabber clients connecting via Expressway will use UDS for directory search (assuming Unified
CM IM&P deployment)
• TelePresence endpoints, DX series, IP Phones also use UDS directory search
• For the best contact search experience, all Enterprise Users should be imported into every
Unified CM cluster’s end user table
• Home cluster check box needs to be selected on only one cluster for each user
• Unified CM clusters support 80K end users, and can scale as high as 160K with BU approval
Media Path Summary Media Traversal
• Call between “C” and “A” on-
premise
• Expressway provides firewall
traversal for signaling & media
B • Expressway-C de-multiplexes
media and forwards toward “A”
• Media stream always SRTP
(Intranet) encrypted between “C” and
Expressway-C
Collaboration Internet • Media stream only SRTP encrypted
Services between “A” and Expressway-C
when both endpoints are
Unified Expressway Expressway C provisioned with encrypted security
CM C E profile (requires UCM mixed mode)
Media Relay
SIGNALLING • Call between “C” and “B” both off-
MEDIA premises
• Media is relayed via Expressway-C
A
• All Media streams SRTP encrypted
Mobile & Remote Access Deployment Options
Unified CM Expressway-C Expressway-E Comments
Clusters Clusters Clusters
Single Expressway deployment
1 1 1 providing remote access to a central
Unified CM cluster
Regional Expressway deployments
1 2+ 2+ providing remote access to a central
Unified CM cluster
Single Expressway deployment
2+ 1 1 providing remote access to a multiple
Unified CM clusters
Regional Expressway deployments
2+ 2+ 2+ providing remote access to multiple
Unified CM Clusters
Supporting Multiple Unified CM Clusters
Prerequisites
• Cross cluster UDS API calls are used to find a Jabber user’s home cluster
• Establishing an Intercluster Lookup Service (ILS) network between Unified

CM clusters is the easiest way to allow Unified CMs to discover one
another and get home cluster discovery working
• SIP URI replication over ILS is optional, not a requirement
• Test this yourself within a browser, substitute in UCM addresses and
username(s) specific to your deployment
https://UCM/cucm-uds/clusterUser?username=mdude
• Confirm the username lookup results always redirect to the same home
UCM cluster, no matter which UCM cluster you send the lookup request to
Designing for Multiple Expressway Clusters
Two approaches for deploying Expressway MRA at scale
Global approach - single domain (example.com) used for collab-edge DNS
SRV records
• allows all MRA clients to find any edge
• Requires all Expressway C clusters to be integrated with all CUCM + IM&P clusters
• Geo DNS load balancing can be used to help prioritize local edge resources, see
Cisco Preferred Architecture Enterprise CVD for more details
Segmented approach - subdomains (amer.example.com, emea.example.com,
apac.example.com) used for collab-edge DNS SRV records
• Allows for better capacity planning and control
• Limits the CUCM + IM&P clusters that Expressway C needs to be integrated with
• Bootstrapping service domain can be more challenging, and less obvious to end
users
MRA Client Authentication Options
SAML SSO is an option for Jabber clients providing
• The potential for stronger client authentication, dictated by Identity Provider’s
capabilities
• Alignment with the broader enterprise authentication strategy
• Expressway “SSO Exclusive” configuration option removes non-SSO MRA
authentication option
Non-SSO authentication (username + password) applies to all other MRA clients
including
• TelePresence Endpoints with TC or CE firmware
• 78xx and 88xx Cisco IP Phones
• Jabber clients when SSO is not enabled
OAuth Refresh Token Support
• OAuth 2.0 is used for token based authorization with existing MRA SSO support
• X8.10 introduces a new OAuth option for Jabber clients that applies to both SSO
and non-SSO deployments
• OAuth support includes both access tokens and a refresh token
• The refresh token reduces user authentication frequency and provides faster
reconnect to services
Additional Resources
• More details in BRKCOL-2699 - Fundamentals of Authentication and Authorization
for Collaboration Deployments
• Cisco Jabber white paper on deploying OAuth
Expressway X12.5 MRA Access Control Menu
Authentication Path selection
dictates which options are
available below
New OAuth with Refresh option

(does not require SSO)
Only applies to SAML SSO

(implicit OAuth login flow)
Required for any devices that

don’t support OAuth, or Jabber
clients not using SSO or OAuth
with Refresh
Jabber OAuth with Refresh Token Support
Minimum Software Requirements
Component MinMin Software
Software VersionProjected
Version Projected Availability
Availability
Cisco Expressway (or Cisco VCS) X8.10.1
X8.10.1 Available
Available
Unified CM 11.5(1)
11.5(1) SU3
SU3 Available
Available
Unified CM IM&P 11.5(1)
11.5(1) SU3
SU3 Available
Available
Unity Connection 11.5(1)
11.5(1) SU3
SU3 Available
Available
Jabber for Windows 11.9
11.9 Available
Available
Jabber for iPhone and iPad 11.9
11.9 Available
Available
Jabber for Mac 11.9
11.9 Available
Available
Jabber for Android 11.9
11.9 Available
Available
UCM 12.0 User Based MRA policy
• MRA End User Policy in UCM 12.0(1) - User Profile Configuration

• Allows admin to selectively disable MRA for user or groups of Jabber users
• Policy can also be used to restrict MRA users from voice/video calling services
• Requires 100% Jabber 12.0+ client population
• Expressway Access Control should be set to only allow “Authorize by OAuth token
with Refresh”
Edge Server Authentication
• Edge server authentication is always
performed by the remote device
• i.e. remote Jabber clients and remote
endpoints will always validate the
Expressway-E Server Certificate presented in
the TLS handshake
• Jabber Clients will rely on the underlying
platform trusted CA list
• Cisco Endpoints will rely on a trusted CA list
included in firmware
• No CTL option or requirement for Edge
Server certificate authentication
More
Expressway Server Certificates Details in
Appendix
• Expressway-E Server certificates should be signed by 3rd party Public CA

• Expressway-C server certificates can be signed by 3rd party Public CA or Enterprise
CA
• Expressway server certificates need to allow for both client & server authentication
X509v3 Extended Key Usage:

TLS Web Client Authentication
TLS Web Server Authentication
• Public CA signed certificates allow Jabber clients and endpoints to validate the
server certificate with platform’s default trusted CA certs
• No requirement to include Expressway certs in CTL
• Wildcard certificates not supported
Firewall Port Details
• No inbound ports required to be opened on the internal firewall
• Internal firewall needs to allow the following outbound connections from
Expressway-C to Expressway-E
• SIP: TCP 7001
• Traversal Media: UDP 2776 to 2777 (or 36000 to 36011 for large VM/appliance)
• XMPP: TCP 7400
• HTTPS (tunneled over SSH between C and E): TCP 2222
• External firewall needs to allow the following inbound connections to

Expressway
• SIP: TCP 5061
• HTTPS: TCP 8443
• XMPP: TCP 5222
• Media: UDP 36002 to 59999
High Level MRA Deployment Guidance
Start on solid ground
• Jabber service discovery needs to work on-prem
• Start on-prem and then add edge access
• Verify end user home cluster discovery in multi Unified CM cluster deployments
Don’t forget about DNS

• Understand split DNS SRV requirements, get DNS change requests in the queue
• A common DNS domain simplifies matters, but is not required
Review TCP and UDP port requirements with firewall team, and minimize UDP ports
open to Expressway-E from internet if required
Verify Expressway CA signed certs
• Confirm SANs returned in CA signed cert match what was requested in the CSR
• Verify cert includes both TLS Web Server & Client Authentication Extended Key Usage
Initial Jabber & TelePresence MRA Support
Component Min Software Version Projected Availability
Cisco Expressway (or Cisco VCS) X8.1.1 Available
Unified CM 9.1(2) SU4 Available
Unified CM IM&P 9.1 Available
Unity Connection 8.6(1) Available
Jabber for Windows 9.7 Available
Jabber for iPhone and iPad 9.6.1 Available
Jabber for Mac 9.6 Available
Jabber for Android 9.6 Available
EX/MX/SX/C Series TelePresence Endpoints TC 7.1 Available
DX70 & DX80 CE 8.2 Available
Webex Room Systems CE 9.0 Available
IP Phone Feature Set
7800/8800 Series + Expressway
7811, 7821, 7841, 7861 8811, 8841, 8845,
• Access to corporate directory (UDS) 8851, 8861, 8865
• Encrypted signaling and media (UCM mixed mode not required)
• Call Forward, Transfer, Ad-hoc & Meetme Conferencing, MWI
• Call Park, Call pickup, iDivert, Call Back, Mobile Connect, Extension Mobility
• Device management including configuration, firmware upgrades,
reset/restart/applyConfig
• Multiple line appearances
• Shared line features including Remote in Use,
Hold/Resume, Privacy, Barge/cBarge, Merge
MRA Advanced Line Support
Enabling Shared Lines & Multiple Line support
• SIP Path headers setting needs to be enabled to allow advanced line support
• CUCM 11.5(1)SU3 is recommended before enabling SIP Path Headers on
Expressway C
• This setting maps to the following auto-generated zone setting

xConfiguration Zones Zone 3 Neighbor SIP RFC3327 Enabled: "Yes"
IP Phone MRA Support
Cisco Expressway (or Cisco VCS) X8.7 Available
7811, 7821, 7841, 7861 IP Phones 11.0 Available
8811, 8841, 8845, 8851, 8861, 8865 IP Phones 11.0 Available
7832 & 8832 Conference Phones 12.1.1 Available
DX650, DX70, DX80 Collaboration Endpoints 10.2(4) SR Available
Software requirements for multiple lines and shared line features

7811, 7821, 7841, 7861 IP Phones 11.5 SR1 Available
8811, 8841, 8845, 8851, 8861, 8865 IP Phones 11.5 SR1 Available
SIP OAuth
for Jabber clients
SIP OAuth for Jabber Clients
• Objective: make it simple to deploy and support Jabber clients with
voice/video encryption
Benefits
• Simplification: Encrypted Jabber clients no longer require UCM mixed
mode, CTL, LSCs, or CAPF enrollment
• ICE Media Path Optimization for Jabber clients over MRA becomes a
possibility when all SIP signaling legs are encrypted
• Active Control (iX) can be negotiated in more call flows with CMS or
Webex conferencing
SIP OAuth Support in UCM 12.5
SN’s/SAN’s UCM
New option in Phone Security of Expwy
nodes
Device Security Modes
Profile enables encryption Encrypted
Encrypted Non-secure
(OAuth)
without LSC/CAPF, using Tomcat CM
“single” TLS + OAuth tokens mTLS
5091
5090 5061 5060

• Must be first enabled via CLI Expwy-C
(MRA)
(requires export-controlled)
TLS
mTLS TCP
• New SIP ports on UCM (+ OAuth in SIP)
(configurable)
• Automatic mTLS with Expwy-C
LSC
for MRA-registered clients
Jabber SIP OAuth Considerations
• OAuth with Refresh needs to be enabled on UCM
• Jabber client AuthN options include SAML SSO, LDAP or local end user
• Client certificates not required for secure SIP when using SIP OAuth, but
remain an option for SAML SSO AuthN
• UCM AuthZ service runs on all nodes in the cluster
Enabling Jabber for SIP OAuth
1. Upgrade Jabber client population to 12.5 or later
2. Enable SIP OAuth on UCM 12.5
3. Restart CallManager service on call processing nodes
4. Refresh UCM servers from Expressway-C
5. Apply SIP OAuth enabled Phone Security Profile to Jabber clients
Enabling SIP OAuth on UCM
• Enable SIP OAuth with a single CLI command
> utils sipOAuth-mode enable
• Then restart CallManager service on call processing nodes
SIP OAuth TCP Ports
SIP OAuth TCP ports activated

after using the cli to enable
SIP OAuth and restarting
CallManager service
TCP ports default to 5090 and

5091, but are configurable per
UCM server
Refresh UCM Servers on Expressway-C
• Refreshing the UCM server allows Expressway to discover when SIP OAuth
is enabled
Expressway-C auto-generated neighbor zones
• “CEOAuth-” zones are created after server refresh discovers SIP OAuth
enabled on the UCM cluster
SIP OAuth Neighbor Zone
SIP OAuth Search Rule
Phone Security Profile – Universal Device Template
Profile applies to all device

types, but SIP OAuth is only
supported on Jabber CSF,
TCT, BOT, TAB devices
TFTP encrypted config still requires

LSC, so it is not compatible
Leave as default,
Not used with SIP OAuth
Jabber SIP OAuth MRA Support
Unified CM 12.5(1) Available
Jabber for iPhone and iPad 12.5 Available
ICE Media Path
Optimization for MRA
MRA Media Path Summary (pre-12.5)
DMZ
Collaboration Internet
Services

CM C E
SIGNALLING
MEDIA
Express-C media encryption policy (b2bua) enforces media encryption for MRA clients
Brief Introduction to ICE
• Interactive Connectivity Establishment - RFC 5245
Internet
Expressway-E
(TURN Server)
• Provides a best effort mechanism for SIP client NAT traversal

• Allowing clients to discover network topology details and find one or more
paths by which they can communicate
• Delivering the cheapest media routing that minimizes firewall traversal and
use of centralized resources
ICE Protocols
• TURN (Traversal Using Relays around NAT) RFC 5766
• STUN (Session Traversal Utilities for NAT) RFC 5389
• Refer to Kristoff Van Coillie’s BRKCOL-2986 Cisco Live session for a
brilliant ICE, TURN, & STUN Tutorial
X12.5 MRA ICE Realities Internet
• ICE support has existed in Expressway/VCS for years, X12.5 adds ICE
passthrough support allowing MRA to be compatible with ICE
• ICE Media Path Optimization only applies to MRA to MRA calls
• Expressway traversal media path will be used initially for all calls, and an
optimized media path will kick in within seconds (when possible)
• Endpoints and Jabber clients require encrypted security profiles
• Endpoint support includes Jabber, 78xx/88xx phones (that support MRA),
and CE TelePresence Devices
Encrypted Phone Security profiles
• Expressway-C cert is used in TLS handshake with UCM on behalf of
remote endpoints with encrypted security profiles
• UCM needs to match Expressway certificate’s CN/SAN with a phone
security profile name to authorize the TLS registration on TCP 5061
• Use the Universal Device
Template type profile
• Apply to all non-jabber clients
deployed over MRA (assumes
jabber clients will use a
separate phone security
profile with oAuth enabled)
Enabling ICE and configuring TURN on UCM
• Configuration parameters are available at multiple levels
• Enterprise Phone Configuration
• Common Phone Profile
• Jabber Device Configuration
Expressway-E TURN Server Configuration
Expressway-C ICE Passthrough for UCM Cluster
• Update the UCM config on Expressway-C for each UCM cluster
Expressway-C ICE Passthrough for Traversal zone
Expressway-C ICE Passthrough call type
Expressway-C ICE Passthrough metrics
• Available on Expressway-C
• Metrics help to understand
MRA usage patterns and
identify configuration issues
• ICE metrics are summarized for
24 hour window
• Per node ICE passthrough
metrics can be exported as
CSV
Expressway-C ICE Passthrough metrics
ICE MRA Support
Component Min Software Projected Availability
Version
Cisco Expressway X12.5 Available
Jabber for Windows 12.6 Targeting March 2019
Jabber for iPhone and iPad 12.6 Targeting March 2019
Jabber for Mac 12.6 Targeting March 2019
Jabber for Android 12.6 Targeting March 2019
7811, 7821, 7832, 7841, 7861 IP Phones 12.5 Available
8811, 8832, 8841, 8845, 8851, 8861, 8865 IP Phones 12.5 Available
Cisco TelePresence Devices (DX & Room Systems) CE9.6.1 Available
Let’s Encrypt support
on Expressway-E
Let’s Encrypt Introduction
• Let’s Encrypt is a free, automated, and open Certificate Authority
• Providing X.509 certificates for TLS encryption at no charge
• Includes an automated process designed to overcome manual creation,
validation, signing, installation, and renewal of certificate
• ACME protocol (Automated Certificate Management Environment)
• More details at www.letsencrypt.org
• Let’s Encrypt signed certs are compatible with all MRA endpoints
• Compatible with both Expressway server and domain certificates
Expressway-E ACME Requirements
• TCP port 80 required to be open inbound to all Expressway-E’s from ANY
• DNS A records need to be available in public DNS for all SANs required in
Expressway-E certificate
• Admin needs to manually add Let’s Encrypt CA and Digital Signature Trust
X3 root CA certs to both Expressway C & E
• Each Expressway-E will request and maintain it’s own certificate
• The random strings required to satisfy the ACME challenges are shared
across all Expressway-E cluster peers
CSR considerations when using Let’s Encrypt
• MRA deployments should consider using the CollabEdgeDNS “format”
• collab-edge subdomain used in CSR for any configured MRA domain(s)
• This name format alternative satisfies Jabber and TelePresence endpoint
certificate requirements
• Compatible with Let’s
Encrypt DNS and HTTP
requirements
Automated Certificate Renewal and Deployment
• A new cert will be signed after 2/3 of existing certificate’s validity
• Automatic deployment of new certificate can be scheduled
• No restart of Expressway
required
• Deployment signals to
various processes to
reload the server
certificate
Single SAML Cluster
Wide Agreement
Expressway Single SAML Agreement
• Simplifies Jabber Expressway MRA SSO deployments
• Allows for SAML SSO compatibility with IDaaS vendors including Okta
• Cluster mode uses a
self-signed certificate
(with long lifetime) that
is included in the SAML
metadata and used for
signing SAML requests
Expressway Single SAML Agreement
• Single entityID
• Multiple ACS URLs for each Expressway-E node and domain
Closing Thoughts
Key Takeaways
• Expressway X12.5 release has arrived!!!
• 12.5 solution release includes a compelling feature set delivering security,
simplification, and TCO reduction
• Activation code onboarding over MRA for Cisco IP phones is coming soon,
planned for the 12.5(1)SU1 release targeting 1H CY19
• Expressway alone provides call control for video-centric customer

deployments (w/o Cisco Unified CM)
• Cisco VCS customers should plan migration to Expressway
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKUCC-2801
Complete your online
session survey
• Please complete your Online Session
Survey after each session
• Complete 4 Session Surveys & the Overall
Conference Survey (available from
Thursday) to receive your Cisco Live T-
shirt
• All surveys can be completed via the Cisco
Events Mobile App or the Communication
Stations
Don’t forget: Cisco Live sessions will be available for viewing

on demand after the event at ciscolive.cisco.com
Continue Your Education
Demos in Meet the Related

Walk-in
the Cisco engineer sessions
self-paced
Showcase labs 1:1
meetings
Thank you
A. Expressway MRA Media Traversal
B. Minimize UDP Ports open to Expressway-
E
C. XMPP IM&P Federation
D. SIP IM&P Federation
E. Open Video Federation + Skype Interop
Appendix F. Policy Protected Dial Plan for B2B

G. MRA Resources and Troubleshooting
H. Expressway Server Certificates
I. Expressway MRA with SSO
J. Jabber Guest
K. CMS WebRTC via Expressway
Appendix A
Expressway MRA Media
Traversal
Components of Expressway Media Traversal
Expressway DMZ Expressway

C Firewall E
Proxy default component used for media

traversal
A
B2BUA component used when media s Proxy
encryption policy other than “auto” is s
applied e
n B2BUA
Assent protocol is used for multiplexed t
media on Traversal server zones
(Expressway E only)
Traversal Media Port Range
Traversal Media
Port Range
Admin configures port
Expressway DMZ Expressway range on Configuration >
C Firewall E Traversal Subzone menu
on both Expressway C & E,
defaults to 36000 – 59999
A Allocated media port range

Proxy s Proxy is divided and shared
s 1st half goes to Proxy
e
2nd half goes to B2BUA
B2BUA n B2BUA
t
Assent Traversal Media Ports
Assent
Demultiplexing
Ports
Admin configures port
Expressway DMZ Expressway range on Configuration >
C Firewall E Traversal > Ports menu
on Expressway E only
A Defaults to UDP 2776-7

Proxy s Proxy
s
Large VMs, CE1100,
CE1000 require 12
e demux ports,
B2BUA n B2BUA automatically allocated
t from the beginning of the
traversal media port
range, typically UDP
36000 – 36011
Mobile & Remote Access Media Paths
• The UDP port details, expressway components, and encryption attributes are best
understood in the following categories
• Internal – media path between Expressway-C and on-prem resources
• Traversal zone – media path between Expressway-C and Expressway-E
• External – media path between Expressway-E and MRA clients
Internal Traversal Zone External
Expressway-C s
s Expressway-E
B2BUA Proxy
e
n
t
MRA Internal Media Expressway-C
B2BUA
• Includes the UDP media traffic between Expressway-C and on-prem

clients, endpoints, gateways, conference bridges, other Expressways, etc.
• Expressway-C establishes unique UDP ports from B2BUA portion of
traversal media port range to send and receive media traffic
• Voice and Video streams will only be SRTP encrypted when all conditions
are satisfied
• UCM is in mixed mode with a CTL established
• The MRA client is configured with an encrypted phone security profile
• The other end of the call (endpoint, gateway, bridge, etc.) is configured for SRTP
A
MRA Traversal Zone Media

s
Expressway-C s
B2BUA e
n
• Includes the UDP media traffic between Expressway-C & Expressway-E t
• Voice and Video streams are always SRTP encrypted

• Expressway-C sources media from B2BUA portion of traversal media port
range, always sending to the Assent demultiplexing ports of Expressway-E
• Expressway-E returns media traffic to Expressway-C using the UDP ports
established for the opposite flow
• Expressway-E assent demultiplexing ports source UDP media traffic to a
destination port within the B2BUA media port range of Expressway-C
MRA External Media Expressway-E
Proxy
• Includes UDP media traffic over the internet between MRA clients and Expressway-E
• Voice and Video streams are always SRTP encrypted
• The Expressway Proxy component is always used on the Expressway-E
• Media latching is used to handle cases where MRA clients send non-routable IP
addresses in SIP SDP (very common over the internet)
• Expressway-E establishes unique UDP ports from the Proxy portion of the traversal
media port range for each UDP port requirement in the SDP
• Expressway-E uses the source ip address of media traffic received on the unique
UDP port to route media traffic in return
• NAT bindings on the far end allow return media traffic to reach the MRA client
Appendix B
Minimize UDP Ports
open to Expressway-E
Minimize UDP Ports Open to Expressway-E
• MRA clients require a different number of UDP ports per call depending on
client/endpoint capabilities, configuration, and per call SDP negotiation
• Some video endpoints require >10 unique UDP ports per call, and this may
continue to grow
• Jabber in phone only mode, or audio only IP phones will require 2 unique
UDP ports per call
• The Expressway docs specify the port requirements, to support max scale
(500 simultaneous video calls on large VM) which is 24,000 UDP ports
• Non-large VMs & appliances can be configured with a smaller range
• Expressway-C will always require more media ports than Expressway-E
Mobile & Remote Access Media Traversal
• MRA deployments include predictable UDP media traffic paths
• The B2BUA is always engaged for forced media encryption on the
Expressway-C
• The proxy component is always used on the Expressway-E
• Traversal Media Port Range is configured on Configuration > Traversal
Subzone menu on both Expressway C & E, defaults to 36000 – 59999
• This media port range is divided and shared
» 1st half goes to Proxy
» 2nd half goes to B2BUA
MRA Media Traversal Path

C Firewall E
A
Proxy s Proxy
s
e
B2BUA n B2BUA
t
Enterprise
Resources
MRA Media Relay Path

C Firewall E
A
Proxy s Proxy
s
e
B2BUA n B2BUA
t
Reduced UDP Port Range For Audio Only MRA
Example 1
• Customer is deploying audio only MRA clients thru Expressway
• Expressways are dedicated to MRA, no B2B video or other services provided
• Standard Expressway VMs are deployed, 300 audio only calls per server is the worst case
scenario
• 300 audio only calls equates to 600 unique UDP ports (1 RTP + 1 RTCP per call) that need to be
open from the internet to Expressway-E
• Expressway-E traversal media port range configured for 1200 ports, 36000 - 37199
» 36000 - 36599 will be dedicated to the Proxy component (open this range of 600 ports on
firewall, for source ANY dest Exp-E)
» 36600 – 37199 will be dedicated to the B2BUA component (will go unused, no need to open
ports)
• Expressway-E Assent traversal port configured with default UDP 2776-7
• Expressway-C traversal media port range (default) 36000 - 59999
Reduced UDP Port Range for MRA (Including Video)
Example 2
• Customer is deploying a variety of MRA clients including Jabber, TelePresence codecs, IP
phones
• Standard Expressway VMs are deployed, 150 video calls per server is the worst case scenario
in terms of UDP port requirements
• 150 video calls can be satisfied with 1800 unique UDP ports (assumes no more than 12 UDP
ports per call) that need to be open from the internet to Expressway-E
» 36000 - 37799 will be dedicated to the Proxy component (open this range of 1800 ports on
firewall, for source ANY dest Exp-E)
» 37800 – 39599 will be dedicated to the B2BUA component (will go unused, no need to open
ports)
• Expressway-E Assent traversal port configured with default UDP 2776-7
Reduced UDP Port Range for MRA, Large VM
Example 3
• Customer is deploying a variety of MRA clients including Jabber, TelePresence codecs, IP
phones
• Large Expressway VMs are deployed, 500 video calls per server is the worst case scenario in
terms of UDP port requirements
• 500 video calls can be satisfied with 6000 unique UDP ports (assumes no more than 12 UDP
ports per call) that need to be open from the internet to Expressway-E
» 36000 – 36011 will be dedicated to Assent demultiplexing
» 36012 - 42011 will be dedicated to the Proxy component (open this 6000 port range on
firewall, source ANY dest Exp-E)
» 42012 – 48011 will be dedicated to the B2BUA component (these will go unused, no need to
open ports)
Appendix C
Cisco Jabber IM&P
XMPP Federation
XMPP Federation Solution Overview
Extending the reach of your organization's Jabber deployment
Webex
Messenger Cloud
Business Partner
with Cisco Collab
Internet
IM&P
Any standards
based XMPP Service
Expressway XMPP Federation
Design Considerations
• An Expressway XMPP Federation deployment can easily co-reside on a
Expressway C & E pair deployed for MRA
• A dedicated Expressway C & E pair could also be deployed specifically for
federation
• Only one Expressway cluster pair should be deployed for XMPP federation
• xmpp-server DNS server record(s) are required for public federation, but
not strictly required (static routes can be used)
• Contact card details are not provided to federated contacts
• SIP Federation can still be used on IM&P when Expressway is deployed for
external XMPP federation
Enabling XMPP Federation on Expressway
Configuration Steps
Prerequisites
• UCM IM&P “XMPP Federation Node Status” must be turned off
• Relies on Expressway “Unified Communications” Traversal Zone
Open TCP 5269 inbound on external firewall to Expressway-E from ANY

Publish _xmpp-server._tcp SRV record for your domain in public DNS
Expressway-C: Configure Domain(s) enabled for XMPP Federation
Expressway-E
• Enable XMPP Federation
• Optionally configure static routes or DNS lookup for Federation
• Configure XMPP Parameters (Dialback secret, TLS settings and Allow/Deny List)
Restart XCP Router Services on UCM IM&P Server(s)

XMPP Federation Policy
• Expressway provides options for either Public or Private federation
• Security mode of TLS optional is the most flexible for public xmpp federation
• Dialback secret provides proof of possession (RFC3920) for xmpp servers to
prevent address spoofing
• TLS Required and Client-
side certificates not
compatible with Webex
Messenger
• Optional privacy mode
allows for list of domains
either allowed or blocked
XMPP Federation Support
Unified CM IM&P 9.1(1) Available
Jabber for iPhone and iPad 9.6.1 Available
Federate with Webex Messenger cloud or any standards based XMPP server
Appendix D
Cisco Jabber IM&P
SIP Federation
Jabber IM&P Federation with Expressway
Now extending to organizations using Microsoft
Microsoft ®
Office 365
Organizations
with Skype™ for
Business on premises
Internet
Expressway-C Expressway-E Webex

IM&P Messenger Cloud
XMPP
Standards Organizations
SIP based XMPP service with Cisco Collab
IM&P Interdomain Federation with Skype for
Business
Overview
• Expressway provides an alternative to the
Cisco ASA TLS Proxy for interdomain SIP
federation
• Expressway alone can be used for SIP IM&P only interdomain federation with
organizations using Skype for Business (additional requirements for audio and
video calling)
• SIP IM&P federation requires a named federated domain entry on IM&P
server, in contrast to the open federation capabilities when using XMPP
• No RMS licenses required for SIP IM&P only sessions
• Including federated contact in buddy list will allow for the best presence
experience
IM&P Interdomain Federation with Skype for
Business
• Publish _sipfederationtls._tcp.example.com DNS SRV record(s) in public DNS to
make your Expressway E(s) known to business partners
• Expressway E should have a public CA signed cert, and will need to trust root CA
certificates used by federated domains
• Trusted TLS peer relationship, including a neighbor zone to IM&P on Expressway C
is required
• Expressway search rules are required to handle chat invites and presence
subscriptions
• Each federated domain needs to be administratively defined on IM&P server,
including a next hop destination matching Expressway C
• Configuration details in chapter 8 of the IM&P Interdomain Federation Guide Release
11.5(1)SU2 and the Expressway guide
SIP IM&P Microsoft Federation Support
Component Min Software Version Version

Min Software Projected Availability
Projected Availability
Cisco Expressway (or Cisco VCS) X8.9.1 X8.9.1 Available
Available
Unified CM 11.5(1)SU2
11.5(1)SU2 Available
Available
Unified CM IM&P 11.5(1)SU2
11.5(1)SU2 Available
Available
Appendix E
Open Video Federation

+
Skype for Business
Video Interop
Enabling business to cloud or B2B video
Cisco
Collaboration Cloud
Internet Organizations
with Cisco Collab
Standards
based SIP/H.323
Video
Easy as a phone call or sending an email
Internet
Enterprise Suppliers, Partners, and Customers

• Enables Business to Business Video Calling, inbound and/or outbound
• No requirement for predefined peering relationship
• Provides Business to Cloud Video Calling, i.e. Webex cloud
• Multivendor interoperability through industry standards (SIP, H.323)
• Dial Plan and Call Policy Rules dictate how open video federation truly is
Expanded Open Video Federation
CMS allows for video interoperability with organizations using Microsoft
Microsoft ®
Office 365
Organizations
with Skype™ for
Private Network DMZ External Network Business on premises
Expressway-C
Internet
Expressway-E Cisco
Collaboration Cloud
Cisco
Meeting Standards
Server based SIP/H.323 Organizations
Video with Cisco Collab
Federated Video Interop with Skype for Business
Overview
• Expressway provides a fully supported alternative to the Cisco Meeting Server
SIP Edge component for interdomain SIP video federation
• Cisco Meeting Server allows video interoperability with both Office 365 (cloud)
and organizations with on-premises Skype for Business infrastructure
• BFCP ↔ RDP bidirectional content share
• Allows Jabber clients to escalate chat session to A/V calls (requires IM&P)
• Open video federation model is possible, in contrast to IM&P named federation
requirements
• Compatible with CUCM, Expressway, and VCS based call control
• RMS license + Cisco Meeting Server licensing required for audio/video/content
call with federated Skype for Business contacts
Federated Video Interop with Skype for Business
• Publish _sipfederationtls._tcp.example.com DNS SRV
record(s) in public DNS to make your Expressway E(s)
known to business partners
• Expressway E should have a public CA signed cert and will need to trust root CA
certificates used by federated domains
• Expressway C dial plan will route inbound point to point MS SIP audio/video calls
through CMS in gateway mode and then route to CUCM or local endpoints
• Expressway C dial plan routes outbound video calls to Expressway E first, and if no SIP
or H.323 SRV records are found by the DNS zone, Expressway C will try routing the
call through CMS and then route to Expressway E where the DNS zone will look for
_sipfederationtls SRV records
• Configuration details outlined in the Cisco Expressway Options with Cisco Meeting Server
and/or Microsoft Infrastructure (Expressway X8.9.2) guide
Skype for Business Video Federation Support

Cisco Meeting Server 2.1.2 Available
Appendix F
Policy Protected Dial
Plan for B2B
Protect your resources from unauthorized access
through Expressway
Consider network elements including…
• PSTN gateways
• Conference bridges
• Phone extensions
• Voice mail systems
• Security cameras
• Video kiosks
What needs to be reachable? And what needs to be blocked from calls that
Expressway receives from the internet?
Policy in Layers
Filtering Inbound Unauthenticated Video Federation Traffic
• Filter access to Expressway allowing only required TCP & UDP ports
• Call Policy Rules on Expressway protect against scanners and toll fraud
• SIP Trunk CSS provides fine grain access control to gateways/resources
SIP Trunk CPL Rules, Filtering Unauthenticated B2B
Search Rules
Inbound CSS Search Rules ACLs traffic
SIP UDP
SIP TCP
Internet
H.323 TCP
Enterprise Unified CM Expressway-C DMZ Expressway-E External

Resources Firewall Firewall
Example of Unauthorized Access Attempts
Simple Example Expressway-E Dial Plan
• calls to the local domain routed to Expressway-C
• calls to non-local domains, from authenticated sources, routed to the internet
Zone Authentication Policy
Traversal Zone
Authenticated
Expressway-
C
Internet
Expressway-E
non-authenticated
Treat as authenticated
» All messages are classified as authenticated.
» Messages with an existing P-Asserted-Identity header are passed on unchanged.
» Messages without an existing P-Asserted-Identity header have one inserted.
Do not check credentials
» Messages are not challenged for authentication.
» All messages are classified as unauthenticated. Any existing P-Asserted-Identity headers are removed.
Non-authenticated traffic can be rejected through use of CPL rules
CPL and Authentication Policy
authenticated
Internet
non-authenticated
• One rule rejects unauthenticated calls coming from the Internet (Default Zone)
• Outbound calls will be allowed
• CPLs are more effective in security configuration than search rules because search
rules don’t have an option to reject calls
Expressway Routing
Start: Expressway
receives alias
Apply Transform
Yes Does the alias
match a
Forbidden
transform?
No If “reject”
Does calling or Yes Allow/

called match a
Reject
CPL rule?
No
If “allow”
Does the alias
match a search
Next lower- rule?
priority rule until
end of rules or Yes
the alias is
found
Is the alias Place
No found?
Yes Call
2 Expressway Call Policy Approaches
Allow-based policy:
• Allow calls matching internal dialplan for users and rooms
• Allow multiparty meetings
• Deny all other inbound calls (includes access code to PSTN, Unity calls, etc.)
Deny-based policy:
• Deny calls to PSTN
• Deny calls to Unity
• Deny calls to instant meetings on Conductor
• Allow everything else matching the internal domain
• Deny all other inbound calls
CPL Rules Example #1
Deny-based policy approach
• Destination has to match the internal dial plan. A simple rule matches the domain
portion only .*@ent-pa\.com
• Calls from external to external destinations are forbidden

• Simple policy rule protects against scanners sending traffic to @ipAddress
• Calls to Unity, PSTN gateways, Conductor instant meetings are allowed
• This example is a good starting point, further restrictions can be added
• Builds on the existing call policy rules in example #1
• Adds a rule blocking PSTN gateway access from unauthenticated callers
• More rules can easily be added protect other resources

• Allow call to Directory URI and Personal CMR (i.e. user1@ent-pa.com and
user1.cmr@ent-pa.com)
Regex: ^[a-z].*@ent-pa\.com
• Allow calls to scheduled conferences (80991XXX)
Regex: 80991\d{3}@ent-pa\.com
• Allow calls to personal CMR (80044XXX, 80051XXX, 80065XXX)
Regex: 80044\d{3}@ent-pa\.com
80051\d{3}@ent-pa\.com
80065\d{3}@ent-pa\.com
• Reject everything else
• Unauthenticated callers can only access pre-defined number ranges for

conference bridges, end user URIs, and personal CMR URIs
• All other destinations are rejected
Differentiated Policy for Inbound Calls
• Neighbor Zones can be established on Expressway-E for specific business
partners, allowing for both inbound and outbound calling
• Allows inbound calls from hosts defined in neighbor zone(s) to avoid the
default zone, and instead receive differentiated treatment
• Trusted neighbor zones can use Treat as Authenticated policy, allowing
inbound calls to bypass CPL rules established for unauthenticated inbound
traffic
• Use TLS and TLS verify on neighbor zone config
• This approach can be used to provide broader access to enterprise
dialplan and resources on inbound calls from trusted partners
UCM Calling Search Space
Block access at UCM level
• UCM’s SIP trunk calling search space controls access to all dial plan resources
• Inbound trunk CSS will have access to Directory URI, Scheduled meetings, personal
CMR and permanent conferences partitions
• UCM has a more granular approach, not based on numeric ranges alone
Trunk
UCM Inbound CSS

Expressway-C DN partition
Directory URI partition
Scheduled meeting PSTN access partition
partition
Voicemail partition
Personal CMR partition
Internet B2B partition
Monitor Search History
• Monitor the Expressway Status > Search History on a regular basis
• Expressway GUI allows sorting by status and filtering
• Confirm CPL rules are rejecting unwanted calls as desired

• Confirm CPL rules are not rejecting legitimate calls
Monitoring Logs and Call Detailed records
• Consider enabling Expressway remote syslog
• Consider enabling Expressway Call Detail Records
• Continue monitoring UCM Call Detailed Records on a regular basis
Appendix G
MRA Resources and
Troubleshooting
Relevant Deployment Guides
Expressway Configuration Guides
• Start with the “Expressway Mobile & Remote Access Deployment Guide”
• For guidance on traversal connection between C & E, consult the
“Expressway Basic Configuration Deployment Guide” to establish
• For assistance with certificates, consult the “Cisco Expressway Certificate
Creation and Use Deployment Guide”
Cisco Jabber Planning and Deployment Guides
• Start with the “Planning Guide for Cisco Jabber”
Starting Point for Troubleshooting
Verify Expressway Traversal Connections
• The SIP connection between Expressway C and E needs to be established
first
• If you don’t have an active SIP traversal connection verify DNS, NTP, SSL
certificates, and the trusted CA certificates on both C and E, also check firewall for
drops
• SIP messaging over the traversal zone from C to E will provide the mobile
remote access configuration details established on the C to the E
• SSH connection from C to E on TCP 2222 will follow
• XCP connection from C to E on TCP 7400 will follow only if on-prem IM&P servers
have been discovered (doesn’t apply to Webex cloud IM&P)
Expressway-C Unified Communications Status
Status > Unified Communications Menu
View Provisioning Sessions on Expressway-C
192.168.10.14
192.168.10.14 This is the UCM server used for
192.168.10.14 UDS provisioning and
When an entry exists on this page, the
192.168.10.14 authentication. It does not reflect
user has been able to connect192.168.10.14
through
192.168.10.14 where the SIP registration will be
Expressway E &C, and successfully
192.168.10.14 sent
authenticate against UCM.192.168.10.14
192.168.10.14
However, it doesn’t indicate the client is
192.168.10.14
functional yet! 192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
192.168.10.14
Expressway-E DNS
• Note: Expressway-E servers will often
have multiple DNS aliases, especially in
dual-nic deployments
• The Expressway-E system hostname and
domain (defined under System > DNS) are
combined to form the Expressway-E
FQDN
<edgeConfig>
<sipEdgeServer>
• Expressway-E FQDN is embedded in the <server>
edge xml config served to remote clients, <address>expwy1.example.com</address>
and needs to resolve in public DNS <tlsPort>5061</tlsPort>
</server>
<server>
<address>expwy2.example.com</address>
<tlsPort>5061</tlsPort>
</server>
</sipEdgeServer>
…
Reverse Proxy Usage
Initial get_edge_config and internal SRV record request
(decrypted)
GET /dWNkZW1vbGFiLmNvbQ/get_edge_config?service_name=_cisco-uds&service_name=_cuplogin HTTP/1.1
Authorization: Basic bWR1ZGU6dGhpc3Bhc3N3ZHdpbGxiZXJlc2V0
Host: collabedge1e.ucdemolab.com:8443 Base64 encoded
Accept: */*
User-Agent: Jabber-Win-472 Base64 decode = ucdemolab.com credentials
Subsequent home cluster discovery request (decrypted)

GET /dWNkZW1vbGFiLmNvbS9odHRwcy9jdWNtLXB1Yi51Y2RlbW9sYWIuY29tLzg0NDM/cucm-
uds/clusterUser?username=mdude HTTP/1.1
Host: collabedge1e.ucdemolab.com:8443
Accept: */*
Cookie: X-Auth=7f501814-e61f-483a-8620-ed0b5d3792db
User-Agent: Jabber-Win-472 X-Auth token
Base64 decode = ucdemolab.com/https/cucm-pub.ucdemolab.com/8443
Not a general purpose reverse proxy, intended for Cisco clients only!
Home Cluster Discovery
Expressway-C will use the following UDS API to determine a user’s home cluster
https://<UCM>/cucm-uds/clusterUser?username=<USERNAME>
Unified CM
9.1.2
Unified CM
10.0
Request Edge Config In Your Browser
• Build an edge config HTTPS request that Jabber will use in the initial request
• Destination is your Expressway-E = https://exp-e01.ucdemolab.com:8443/
• Base64 encode your service discovery domain
• base64(ucdemolab.com) = dWNkZW1vbGFiLmNvbQ==
• Include the get_edge_config resource and internal DNS SRV records
• By default jabber will request both _cisco-uds and _cuplogin (_cuplogin isn’t required!)
• /get_edge_config?service_name=_cisco-uds&service_name=_cuplogin
• Put it all together in your browser’s address bar
https://exp-e01.ucdemolab.com:8443/dWNkZW1vbGFiLmNvbQ==/
get_edge_config?service_name=_cisco-uds
• Authenticate with UCM end user’s username and password when prompted by your
browser
Edge Config & Services (1 of 4)
serviceConfig details returned here are a

result of Expressway-C DNS SRV lookups
and user’s home cluster information
One or more _cisco-uds DNS SRV
records are required in internal DNS for
Jabber
The tftpServer entry is not based on a

DNS SRV record. Tftp server addresses
is mapped to the available TFTP servers
in the user’s home cluster
Required for IP Phones over MRA
Up to 4 members of the Expressway-E

cluster will be returned as a sipEdgeServer
One sipRequest “route string” is provided to

clients for each Expressway-C in the cluster
(up to 4)
Up to 4 members of the
Expressway-E cluster will be
returned as a xmppEdgeServer
Up to 4 members of the
Expressway-E cluster will be
returned as a httpEdgeServer
The userUdsServer entry will include a UCM

server that belongs to the end user’s home
cluster. This may be a different cluster than
where the _cisco-uds SRV record points
Cisco Jabber Client Initialization
Jabber provisioning & registration sequence
• Jabber service discovery DNS SRV lookups are followed by several HTTPS
requests
• Jabber will then establish an XMPP connection and authenticate (PLAIN
SASL) after receiving a one time password over the HTTPS connection
• The Jabber client is not functional without an XMPP connection (unless
using phone only mode)
• The Jabber SIP registration is one of the last steps
• Jabber will also establish an HTTPS connection for visual voicemail if that
service is provisioned on Unity Connection, provided the Unity Connection
server has been added to the allow list on Expressway C
HTTPS in the Network Log
• Monitor the HTTPS requests in the Network Log from the GUI
• Under the Status > Logs > Network Log, start by filtering on “trafficserver”
• Most recent logs are at the top

• Default INFO level logging is usually sufficient
• You can use this on both Expressway E & C
Diagnostic Logging
Maintenance > Diagnostics > Diagnostic logging Menu
• Use the diagnostic logging feature when you want to capture network and event
logs in the same file and download for analysis
• Optionally include tcpdump to download and analyze in Wireshark
Expressway Mobile & Remote Access
from Unified CM perspective
• Remote access provided by Expressway is (for the most part) transparent
to Unified CM
• MRA Integration is established on Expressway-C
• Think SIP line integration rather than SIP trunk integration
• No requirement to provision a SIP trunk on Unified CM for Expressway-C
• No requirement to make dial plan changes
• No remote access policy mechanism to limit edge access to certain Jabber
users or devices
• Remote Jabber clients or endpoints registering to Unified CM through
Expressway will appear to Unified CM as Expressway-C IP address
Interaction with SIP trunk • SIP trunk not required between
Expressway-C and Unified CM
for Mobile & Remote Access
SIP Trunk can interfere
with remote registrations • However, if Unified CM
includes a SIP trunk for other
(Intranet) (Public Internet)
integrations, Unified CM will
reject any SIP registration
attempts from remote Jabber
or TP endpoints, as the
Collaboration Internet register method is not
Services accepted on Unified CM SIP
Unified trunk interface
CM
• Update Unified CM SIP trunk
security profile to listen on
ports other than TCP 5060 or
5061 (you could use 5560,
SIP Video 5561, etc.)
Endpoints
SIP 405 will be returned to • Port change allows for SIP
SIP Register request if there trunk integration AND mobile &
is SIP trunk port conflict remote access
Parallel Traversal Zones
• One Traversal Zone used for Open Video Federation
• Provides SIP, and optionally H.323
• Media Encryption Mode = Auto or Best Effort
Expressway Firewall Expressway

C E
• Unified Communications Traversal Zone used for Mobile & Remote Access, Jabber
Guest, XMPP Federation
• Provides SIP, XMPP, HTTP
• Media Encryption Mode = Forced
MRA Client Authentication (non-SSO)
1 of 2
• MRA clients/devices need to be associated with an end user in the Unified CM
database
• This association allows the Unified CM end user’s credentials to be used for client
authentication when connecting through Expressway
• The end user’s device establishes an initial HTTP TLS session with the Expressway-
E server, and the Expressway-E challenges all unauthenticated requests
• The Expressway-E server relays authentication attempts to the Expressway-C
• Expressway-C utilizes the Unified CM UDS API to locate an end user’s home
cluster, and subsequently authenticate users against Unified CM
• Unified CM authentication can be based on the local database or optionally
configured to authenticate end users against an LDAP directory
MRA Client Authentication (non-SSO)
2 of 2
• Upon successful authentication, the Expressway-C relays an X-Auth token to the
remote client through the Expressway-E
• X-Auth token can be used for subsequent authentication purposes up until the
expiration time, default of 8 hours
• SIP digest authentication is used for client authentication for clients connecting to
Expressway-E on TCP 5061, the X-auth token is reused as for digest authentication
• The client authentication for XMPP connections is based on the PLAIN SASL
standard, RFC 4616
• In practice the Cisco client first connects on TCP 8443 to Expressway-E and
requests a one-time password or token from the IM&P server over the secured
HTTPS connection
• Once the token is acquired, the client establishes a new TLS connection to TCP
5222 and supplies the token in the XMPP Plain SASL authentication attempt
Enabling MRA “service mode” on 7800/8800
phones
• Service mode introduced to differentiate between UCM, Cloud, and Expressway
• MRA can be enabled on networks serving DHCP option 150
• Enter Service Domain used to lookup collab-edge DNS SRV record, followed by username and
password
Enabling Expressway MRA Mode on DX (1 of 2)
• DNS is required
• Reset network settings from Settings App
• If DHCP option 150 is served on local network, uncheck the “enable automatic local telephony
service discovery”
Enabling Expressway MRA Mode on DX (2 of 2)
Service domain entry will be used to lookup collab-edge DNS SRV record
Persistent User Credentials
Applies to DX series, 7800 & 8800 phones
• New product specific option introduced on UCM device configuration page
• Enabled via device pack COP file
• Defaults to Disabled, requiring the user to re-enter password on a re-

occurring basis
• When Enabled, the endpoint will cache the end user credentials (encrypted
on device) and the user will not be prompted to authenticate again
Problem Report Tool (PRT)
• End users can send Problem Reports (PRT) through Expressway
• Deploy web server for collecting PRTs on internal network
• Sample PRT HTTP post script
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/dx/series/rel-
notes/1023/DX00_BK_RB889E3E_00_release-notes-dx-series-
1023.html#DX00_RF_PF35EC13_00
• Assign PRT URL under common phone profile or at the device level
• Add the PRT web server FQDN to the Expressway-C HTTP server allow list
AnyConnect & Expressway Coexistence
• Customers that have deployed AnyConnect can also deploy Expressway Mobile &
Remote Access feature
• For the best end user experience, prevent all Jabber traffic from using the
AnyConnect tunnel
•  Active calls going though Expressway may be dropped if AnyConnect tunnel is established
mid-call
• Requirements to keep Jabber traffic going through Expressway

1. AnyConnect split tunnel providing connectivity to internal enterprise network only (not
including Expressway-E)
2. Deny access (ASA DNS inspection) to the internal DNS SRV records (_cisco-uds &
_cuplogin) to AnyConnect clients
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Acce
ss/BYOD_Design_Guide/BYOD_CollabEdge.html
Contact Search Considerations (Cloud Based
IM&P)
• Jabber allows for multiple
contact source integrations
Inside firewall DMZ Outside firewall • LDAP Directory sync
(Intranet) (Public Internet) provides corporate
directory to Unified CM
Services
• Corporate directory is also
exported to Webex
Messenger cloud
CM C E
• All Jabber clients will use
Webex Webex Messenger cloud
Messenger Cloud as a contact source for
contact search
LDAP
Contact Search Considerations (On-premise
IM&P)
• Jabber allows for multiple contact
source integrations
Inside firewall DMZ Outside firewall • LDAP Directory sync provides

(Intranet) (Public Internet) corporate directory to Unified CM
• User Data Services (UDS) is a

Unified CM RESTful API allowing for
Collaboration Internet contact search, among other things
Services
• Jabber clients can use LDAP
(EDI/BDI) or UDS for directory
Unified Expressway Expressway search when on-prem or connected
CM C E via VPN
• All Jabber clients will automatically

use UDS for directory search when
connecting via Expressway
• Sync entire corporate directory to

LDAP every Unified CM cluster for best
contact search experience
UDS to LDAP Proxy - Contact Search
(on-premise IM&P)
Enable UDS to
LDAP Proxy • UCM 11.5 option to forward
Search Inside firewall DMZ Outside firewall
(Intranet) (Public Internet)
all UDS directory searches
Unified to LDAP v3 compliant
CM server
Services
• Allows Organizations to
scale beyond 160,000 user
limit
Expressway Expressway
C E • New UCM 11.5 menu
LDAP> LDAP Search
• Provides same attributes as
classic UDS operation
LDAP • Requires Jabber 11.7
Appendix H
Expressway Server
Certificates
Subject Alternative Name (SAN) Requirements
Expressway-E Server Certificate
• The domain(s) used to discover the collab-edge service record
are required to be included as a DNS SAN in all Expressway-E
server certificates
• Service discovery domain in this case is ucdemolab.com
DNS X509v3 Subject Alternative Name: DNS:ucdemolab.com
• This domain is used for SRV lookups, extracted from here

• Or in some environments this will be Jabber’s
VoiceServicesDomain (not exposed to end user)
• This is a security measure that allows clients to verify
connections to edge servers authoritative for their domain (RFC
6125)
Expressway-E Certificate Requirements
DX, 78XX, 88XX specific requirements
• Trust model based on broadly trusted
Public Certificate Authorities DX650, DX70, DX80
• Endpoint firmware includes trusted public

root CA certificates
• No option to import and trust other root CA
certificates on these endpoints 8811, 8841, 8845,
• Expressway-E certificate needs to be 8851, 8861, 8865
signed by trusted public CA chain
• Latest Certificate Authority trust list posted
on cisco.com 7811, 7821, 7841, 7861
Unified CM Mixed Mode & Expressway-C SANs
1 of 2
• Expressway-C Server Certificate Generation CSR page has the option to
include Unified CM phone security profile names as additional SANs
DNS X509v3 Subject Alternative Name: DNS:secure-udt.ucdemolab.com
• This is only required in deployments that include encrypted phone security

profiles (requires Unified CM to be in mixed mode with CTL deployed)
• The Expressway-C server certificate will be presented to Unified CM during
the TLS handshake on behalf of remote endpoints with encrypted security
profiles
• Unified CM needs to find a match between the Expressway certificate’s CN
or SAN and the phone security profile name to authorize the TLS registration
on TCP 5061
Unified CM Mixed Mode & Expressway-C SANs
2 of 2
• A single phone security profile of
type Universal Device Template can
be associated with multiple device
types in UCM
• Optionally name the profile to match
an existing name in Expressway-C
certificate
• This approach is not as obvious as
dedicating a SAN for security profile
names, but minimizes Expressway-C
certificate SANs and allows you to
add encrypted MRA endpoints
without having to update the
Expressway-C certificate
Optional SANs for XMPP Federation
Applies to on-prem IM&P customers only
• The Expressway Server Certificate Generate CSR page will also insert
“IM&P chat node aliases” as SANs
• These specific SANS will allow for TLS XMPP federation
X509v3 Subject Alternative Name: conference-1-ucdemolabIMP1.ucdemolab.com
• There will be 1 chat node alias per deployed Unified CM IM&P server
• Expressway XMPP federation is an optional deployment that builds largely
on the same configuration used for Mobile & Remote Access
Expressway-C Certificate Signing Request
Only required for XMPP

federation
Only required when

using encrypted
devices with UCM
in mixed mode
Expressway-E Certificate Signing Request
Include the Unified Communications

domain configured on the Expressway-
C
Use DNS
SAN format
Copy Chat Node Aliases from the

Expressway-C CSR (XMPP
federation)
Expressway Trusted CA Certificates
• X8 software does not include the default trusted CA certificate list
• VCS customers upgrading from X7 or prior should consider purging this list
• Don’t upload more than one certificate with the same Common Name
Expressway Trusted CA Certificates
Certificate Type Expressway-C Expressway-E Comments
Trusted CA Trusted CA
Public CA cert chain used to Required to establish Traversal Zone MTLS
sign Expressway-E
certificate
  connections
Public (or Enterprise) CA Required to establish Traversal Zone MTLS

cert chain used to sign
Expressway-C certificate
  connections
Only required when Expressway-C configured

Unified CM Tomcat
certificates or CA cert chain   to use TLS Verify mode on Unified CM
discovery
Only required when Unified CM is in mixed
mode for end to end TLS. CallManager and
Unified CM CallManager CA
cert chain   Tomcat certs need to be signed in this case
so Expressway-C can validate the same
common name on multiple certificates
Only required when Expressway-C configured
Unified CM IM&P Tomcat
certificates or CA cert chain   to use TLS Verify mode on IM&P discovery
Appendix I
Expressway MRA with
SSO
(Implicit Grant Flow)
Why Single Sign-On?
• Security & Compliance: align with the broader enterprise authentication
strategy
• Simplify end user login
• Simplify user provisioning and deprovisioning for admin
• Integral to a common identity architecture - providing users with a single
identity across cloud and on-prem services
• Mobile devices drive need for externally reachable identity and access
management systems
• Potential for stronger client authentication
What’s Involved with SSO and Edge?
• Security Assertion Markup Language (SAML) v2 – open standards based
protocols for user authentication
• Identity Provider (IdP) – Responsible for User Authentication
• OAuth - open standards based protocol for token based authorization
• Tokens & Cookies
• Export & import metadata to form trust relationships between IdP,
Expressway, Unified CM, Unity Connection
Jabber + Expressway SSO Solution
SAML Solution Network Elements Assertion Domain
Consumer Name
Service System
Directory Private Network DMZ External Network

Browser
LDAP DNS
EXPWY-C EXPWY-E
Identity Internet
Infrastructure
UCM Jabber 10.6+

Service
Provider IdP SAML
Request
Collaboration Services IdP
Proxy
Unified CM
SAML
Unified CM IM&P Identity Assertion
Unity Connection Provider Proxy
Jabber + Expressway SSO Support
Unified CM IM&P 10.5(2) Available
Unity Connection 10.5(2) Available
Jabber for iPhone and iPad 10.6 Available
Your SAML v2.0 IdP must be reachable from

internet
Cisco has tested the most popular IdPs → OpenAM
Jabber iOS SSO Authentication Enhancement
• Allowing Safari browser enables iOS client
certificate–based SSO
• Requires Apple iOS 9+, SSO, UCM 11.5,
Expressway X8.9, Jabber 11.8, and a client
certificate enrollment mechanism
• Authentication method remains between
client and IdP
Mobile and Remote Access X8.9 Enhancement
• Embedded Safari for Jabber iOS
• If “Allow Jabber iOS clients to use embedded Safari browser" is set to “Yes” on the
Expressway-E,
then the get_edge_sso response will contain
<allowEmbeddedSafari>true</allowEmbeddedSafari>
HTTPS: GET /get_edge_sso
HTTPMSG:
HTTP/1.1 200 OK
<?xml version='1.0' encoding='UTF-8'?>
<SSOResult version="1.0">
<Response>
<SingleSignOn>
<Status enabled="true"/>
<Token reuse="false"/>
<allowEmbeddedSafari>true</allowEmbeddedSafari>
<Uri>https:// edge1.ciscotp.com:8443/#(domain)/authorize</Uri>
</SingleSignOn>
</Response>
</SSOResult>
• Admins are recommended to use the same setting on the Expressway as the CUCM,
otherwise the users will get an inconsistent experience
Cookies and Access Token
• IDP Cookie: Set by the IDP in the Browser when Assertion is provided. This
could be of type “Session” or “Permanent”. This is the core of the Single
Sign On Experience.
• SP Session Cookie: this is set by SP (CUCM) on the Browser when the
Resource access is granted.
• Access Token: the OAuth Access token is provided when the browser is
redirected to the target Resource.
• Cookies and OAuth Access Token depends on Timers that are set by
Admins
SSO Edge Transitions
EDGE to ON-PREM  Seamless reconnection
• Tokens issued through Expressway are valid for direct connections
to Unified CM and Unity Connection
ON-PREM to EDGE  Jabber will need to re-authenticate, which
may be transparent to the user depending upon IdP cookie expiration
• Tokens issued directly by Unified CM and Unity Connection will not
be valid for connections through Expressway
• If the IdP cookie has expired, the user will be prompted via the
standard re-establish SSO session pop-up
Edge SSO Tokens
• Jabber receives three tokens via two different calls to the Expressway
authorize API
• In the first request to Expressway Jabber retrieves the CUCM OAuth Token
which is used to authenticate all HTTP (including UDS) and XMPP traffic
traversing the edge.
• This same request also provides Jabber with a Expressways SIP Token
which is required for SIP traffic to traverse the edge. This token can have
longer lifetime than the CUCM token.
• In the subsequent request to Expressway Jabber retrieves the Unity OAuth
Token for use by Voicemail HTTP traffic. (/authorize with service=
base64(domain/protocol/address/port)
Edge SSO Timers (Implicit Grant Flow)
A) IdP Session timeout D) SIP REGISTER expiry refresh
• Configured on the IdP (e.g. ADFS2, Configurable on CUCM (various
OpenAM, Ping, etc.) settings depending on device type)
• Default depends on IDP For mobile device types, register
• Typically expect 8 – 10 hours expires typically = 10 to 12 minutes
With 12 minute register expiry, sip stack
B) OAuth Token expiry attempts to refresh register 10 minutes
• Configured on CUCM/Unity - Default 60 after last successful one
minutes For all other devices (including CSF)
register expires = 2 minutes –
C) SIP Token Extra TTL
SIP stack attempts to refresh
• Configured on EXP-C (or VCS-C) register 1 minute 55 seconds after last
• Value is added onto OAuth Token expiry successful one
to get SIP Token Expiry
• Default 0 - Max 48 hours
Appendix J
Consumer to Business
Video
with Jabber Guest
Jabber Guest Consumer to Business Video
Extending the reach of your organization's video deployment
Expressway-C
Internet
UCM Expressway-E
HTTP SIP
Jabber Guest
Why Jabber Guest?
• Enhance customer interactions with click to call video links embedded in
email and on your website
• Make experts easy to find and consult with on video
• HR Interviews: Video Recruiting and Interviews
• Jabber Guest 11 introduces guest content share
• Voice, video and content streams SRTP encrypted over the internet
• Ideal for customers that haven’t transitioned to, or invested in Cisco
Meeting Server
• Jabber Guest api available for link creation and management
Jabber Guest 11 (Random String) Link Config
Jabber Guest
• Jabber Guest cannot co-reside on an Expressway C & E pair deployed for MRA
• Jabber Guest requires one rich media session license per call (Expressway E)
• Include Jabber Guest link domain name in Expressway E certificate as SAN
• External firewall required to map inbound TCP 443 to TCP 9443 of Expressway E
(allowing for links without needing to include TCP port numbers)
• Expressway E network design trade offs
• Dual NIC Expressway E deployments allow for assent media traversal between C & E, but
requires TCP 5061 open between Expressway-E and Jabber Guest
• Single NIC Expressway E deployments do not allow for assent media traversal and require UDP
ports open between E & C, but no requirement for TCP 5061 between Expressway E and
Jabber Guest Server
Jabber Guest Support
Jabber Guest 10.5 Available
Mozilla Firefox 10 Available
Google Chrome 18 Available
Apple Safari 5 Available
Microsoft Internet Explorer 8 Available
iOS (mobile app) 7 Available
Android (mobile app) 5 Available
Appendix K
Cisco Meeting Server
WebRTC via
Expressway
WebRTC Access to Cisco Meeting Server Spaces
Internet
Cisco Expressway-C Expressway-E

Meeting
Server
Expressway + CMS WebRTC
Overview
• Expressway E&C pair provides firewall traversal for
WebRTC clients, including https reverse proxy &
TURN server
• Does not replace Web Bridge! The CMS Web
Bridge, Call Bridge, XMPP, and database
components are all required
• Allows for guest access to Cisco Meeting Server
spaces, end user access (with login) too
• No RMS license required for CMS WebRTC calls
• Bidirectional content (chrome extension required
when sharing from WebRTC side)
Expressway WebRTC Proxy
DNS & Certificate Considerations
• Choose meaningful FQDN for WebRTC access and configure this FQDN as “guest account client
URI” on both CMS and Expressway, and in CMS as the Web Bridge URI
• Split DNS A records allow easy internal & external WebRTC access
• Externally the FQDN name resolves to Expressway E public IP address
• Internally FQDN name resolves to CMS (Web Bridge)
• Include the FQDN in Expressway E and CMS Web Bridge certificate as SAN
Expressway WebRTC Proxy
Opening HTTPS port and protecting admin web interfaces
• External firewall needs to allow TCP 443 and
80 from internet (TCP 80 is optional, and only
used to redirect end users to TCP 443)
• Move the Expressway web admin listening
port off TCP 443 to TCP 7443, 445, or 9000
• External firewall should block Expressway E
web admin TCP port from internet
• CMS web admin should also be configured to listen on non-standard HTTPS port, i.e.
TCP 7443 (webadmin listen a 7443)
• Admins: don’t forget to update your web admin browser bookmark(s) to include the
non-standard HTTPS port!
TURN Server Configuration • Add Expressway E TURN server details to
Dual NIC + Static NAT Expressway E CMS via API, do not add via CMS web gui
• Optionally define TURN server with IP address
• Expressway E TURN server not required, CMS
TURN server is an option
Expressway E LAN2 Static NAT
X8.11 Improved CMS WebRTC Support
• WebRTC Proxy service and TURN service can share TCP 443 on a single
Expressway-E
• Improved CMS redundancy for CMS Web bridges
• CMA client TURN Server on Expressway (feature preview)
• Still no CMA (XMPP) traversal support through Expressway
Internet
Cisco Expressway-C Expressway-E

Meeting
Server
Expressway CMS WebRTC Proxy

Cisco Meeting Server 2.1.4 Available

Brkucc 2801

Uploaded by

Copyright:

Available Formats

Brkucc 2801

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

Brkucc 2801

Uploaded by

Copyright:

Available Formats

BRKUCC-2801

Kevin Roarty, Technical Marketing Engineer

Mobile & Open Video Cisco Webex WebRTC Video Call

New Release clients

“VCS Control” “VCS Expressway” “Expressway-C” “Expressway-E”

• Designed for video-centric customer • Included in Cisco UCL, CUWL, Flex,

Internal Network DMZ External Network

H.323 Gatekeeper & SIP

Mobile and Remote Access Y Y

5. Expressway C then initiates connection through CUCM to the endpoint

6. The call is established and media traverses the firewall securely

Expressway-C Firewall Expressway- E

Expressway delivers 3 key capabilities enabling Expressway

Business to Business Consumer to Business Interoperability Gateway

Firewall Traversal Calls Jabber Guest Calls i.e. intradomain MSFT

Registered Calls (no RMS required)

• Calls to/from Webex cloud are

• “Registered” & “Cloud” calls do not

Specs Based CE1200 Appliance

Audio Only Audio Only

CE1200 5,000 500 1,000 20,000 2,000 4,000

Large OVA 3,500 500 1,000 14,000 2,000 4,000

Medium OVA 2,500 100 200 10,000 400 800

• Expressway E and C node types cannot be mixed in

Private Network DMZ External Network

Internet Jabber @Home

UCM Expressway-C Expressway-E

MRA Client & Endpoint Support Webex

Internal Network DMZ External Network

DX650, DX70, DX80

7832 & 8832 7811, 7821, 7841, 7861

DNS SRV lookup _cisco-uds._tcp.example.com

Private Network DMZ External Network

UCM Expressway-C Expressway-E Public DNS

_collab-edge._tls.example.com. SRV 10 10 8443 expwy1.example.com.

• cisco-uds record needs to be available only in internal DNS

_cisco-uds._tcp.example.com. SRV 10 10 8443 ucm1.example.com.

Inside firewall DMZ Outside firewall

Inside firewall DMZ Outside firewall

Inside firewall DMZ Outside firewall

• Establishing an Intercluster Lookup Service (ILS) network between Unified

New OAuth with Refresh option

Only applies to SAML SSO

Required for any devices that

• MRA End User Policy in UCM 12.0(1) - User Profile Configuration

• Expressway-E Server certificates should be signed by 3rd party Public CA

X509v3 Extended Key Usage:

• External firewall needs to allow the following inbound connections to

Don’t forget about DNS

• This setting maps to the following auto-generated zone setting

7811, 7821, 7841, 7861 IP Phones 11.0 Available

8811, 8841, 8845, 8851, 8861, 8865 IP Phones 11.0 Available

7832 & 8832 Conference Phones 12.1.1 Available

DX650, DX70, DX80 Collaboration Endpoints 10.2(4) SR Available

Software requirements for multiple lines and shared line features

Unified CM 11.5(1) SU3 Available

7811, 7821, 7841, 7861 IP Phones 11.5 SR1 Available

5090 5061 5060

• Then restart CallManager service on call processing nodes