collaboration architecture-2013 cisco live local

Local Edition

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public

Local Edition

Collaboration Architecture Pete DePalma Collaboration CSE


Prerequisites

•  You have a basic understanding of networking concepts

•  LAN, WAN, IOS, CLI, SNMP, SYSLOG, etc.

•  You have a good understanding of CUCM •  You have a solid understanding of following core Cisco UC components

and what they do

•  CUBE, CUCM IM/P, Unity Connection, VCS-C/E

•  You have a basic understanding of base UC protocols or standards

•  SIP, XMPP, H.323, DNS •  You are familiar with Cisco video infrastructure and its components


Agenda

•  Core Components with Clustering over the WAN and Dual DC

•  SIP Trunking and Gateway TIPs

•  Dial Plan (URI)

•  CUCM + Video Architecture

•  Collaboration on the Edge

•  Medianet


Local Edition

Clustering Over The WAN or Dual Data Center Architecture


CUCM Clustering Over The WAN Network Requirements

•  Delay (Latency) 80ms Maximum Round Trip Time (RTT) between any two servers (increased in v6.1) Measure Delay from IOS next to VoS you are testing

•  Jitter No certain restriction, however IP Precedence 3 ICCS traffic should be minimized using Quality of Service (QoS) features. (CBWFQ)

•  Error Rate No Loss; Although Unified CM will tolerate random errors, they could result in impaired performance of the cluster High Quality point-to-point circuit recommended (w/ SLA)

CSACSE-R2#ping Protocol [ip]: Target IP address: 10.89.178.1 Repeat count [5]: Datagram size [100]: 500 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: 104 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 500-byte ICMP Echos to 10.89.178.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 m

ef = dscp 46 = 101110 = tos 0xb8 (184) = ip prec 5 af31 = dscp 26 = 011010 = tos 0x68 (104) = ip prec 3 af32 = dscp 28 = 011100 = tos 0x70 (112) = ip prec 3 cs3 = dscp 24 = 011000 = tos 0x60 (96) = ip prec 3


CUCM Clustering Over The WAN What is Intra Cluster Communications?

Intra Cluster Communications (ICC)   Database traffic from the IBM Informix Dynamic Server (IDS)

database. Per Subscriber

  ICC Signaling (ICCS) real-time traffic, which consists of signaling, call admission control, and other information regarding calls as they are initiated and completed.

  CTI Manager real-time traffic used for CTI devices involved in calls or for controlling or monitoring other third-party devices on the Unified CM servers.

  Calculate BW for all the above


ccm.exe ccm.exe

ccm.exe ccm.exe

CTI Manager MoH

Server

TFTP Server

Publisher

Software Conferencing

Database Subscribers

Database (DB) Replication

Unified CM Cluster

CUCM Clustering Over The WAN Unified CM Clustering: DB Replication and ICCS

DB DB DB DB

DB DB DB DB

DB DB DB DB

DB DB DB DB

ICCS

DB DB

Call Processing Servers MAX = 21 MAX = 16


CUCM CoW Bandwidth Calculation ICCS per BHCA across WAN

•  A minimum of 1.48Mbps (T1) bandwidth is required for 0 (zero) up to 10,000 BHCA from a site across the WAN.

•  For deployments with more than 10,000 BHCA, the following equation should be used (Delay, max RTT in msec) : ‒ Total Estimated ICCS Bandwidth (Mbps) = [Maximum BHCA/10000]*[1 +

(0.006*Delay)]

•  When shared lines are involved across the WAN, there is additional overhead. The following equation should be used:

[Maximum BHCA/10000]*[1 + (0.006*Delay) + (0.012 * Delay * Shared-line) + (0.65 * Shared-line)]

Shared-line = Avg number of additional phones on which a DN is shared across the WAN.

#1


CoW Bandwidth Calculation DB Traffic Per Remote Subscriber

•  Minimum of 1.544 Mbps (T1) bandwidth is required for database and other inter-server traffic for every subscriber server remote to the publisher.

•  3 Subscriber servers located across WAN from Pub:

3 x 1.544 Mbps = 4.632 Mbps

PUB SUB2 SUB3

SUB4 SUB1

#2

P2P Connection MPLS Guaranteed


CUCM CoW Bandwidth Calculation CTI over WAN for 8.6(2)+

  For customers who also want to deploy CTI Manager at another site across from other CUCM Subscribers, the following formula can be used to calculate the CTI bandwidth (Mbps):

Total CTI Bandwidth (Mbps) =

[Maximum BHCA/10000]*.53

  For customers who also want to deploy JTAPI over the WAN to CUCM subscriber(s), the following formula can be used to calculate the CTI bandwidth (Mbps):

Total CTI Bandwidth (Mbps) =

[Maximum BHCA/10000]*.28

PUB CTI Manager

Process

SUB

#3

UCCX P2P Connection

MPLS Guaranteed CTI Controlled Devices

SUB CTI Manager

Process X

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public TECVVT-1001

CUCM CoW Bandwidth Calculation Example: Dallas, Chicago, Denver


•  Deployment ‒ RTT = 80msec

Dallas – Publisher, 2 Subscriber nodes Chicago – 2 Subscriber nodes, 1 TFTP Denver – 2 Subscriber nodes

•  BHCA estimates out ‒ Dallas phones call 4000 Chicago/1000 Denver phones per hour

BHCA = 5000 ‒ Chicago phones call 6000 Dallas/1500 Denver phones per hour

BHCA = 7500 ‒ Denver phones call 500 Chicago/2500 Dallas phones per hour

BHCA = 3000 ‒ Total BHCA = 15500

CUCM CoW Bandwidth CalculationExample: Dallas, Chicago, Denver


•  Total ICCS Bandwidth BHCA = 5000 (to Chi/Den) 6000 (from Chi) + 2500 (from Den) = (13500/10000)*(1+0.006*80) = 1.35 * (1+0.006*80) = 1.998 Mbps

•  Total DB Bandwidth = 5*(1.544) = 7.72 Mbps

•  Total Dallas Bandwidth = 9.718Mbps

CUCM CoW Bandwidth Calculations Example - Dallas to MPLS

Ban

dwid

th

Bandwidth MPLS

Dallas

Denver

Chicago

Band

wid

th


•  Total ICCS Bandwidth BHCA = 7500 (to Dal/Den) 4000 (from Dal) + 500 (from Den) = (12000/10000)*(1+0.006*80) = 1.20 * (1+0.006*80) = 1.776 Mbps


•  Total Calculated Bandwidth = 6.408 Mbps

CUCM CoW Bandwidth Calculations Example – Chicago to MPLS

Bandwidth

Bandw

idth

MPLS

Dallas

Denver

Chicago

Band

wid

th


•  Total ICCS Bandwidth BHCA = 3000 (to Chi/Dal) 1000 (from Chi) + 1500 (from Dal) = (10000/10000)*(1+0.006*80) = 1 * (1+0.006*80) = 1.48 Mbps


•  Total Calculated Bandwidth = 4.568Mbps

CUCM CoW Bandwidth Calculations Example – Denver to MPLS

Bandw

idth

MPLS

Dallas

Denver

Chicago

Band

wid

th

Bandwidth


CUCM Session Manager Edition ”SME” - What and Why

•  SME = CUCM …there is no difference in the SW •  Introduced and supported in CUCM 7.1(2) •  SME deployed for ‒ Trunk aggregation ‒ Dial Plan aggregation ‒  In combination with the above, logical separation of functions ‒ Massive CPS aggregation


CUCM Session Manager Addition Delay and BW

Pre-UC 9.1 CoW BW and delay (80ms) same as CUCM UC 9.1+ BW 1.544 Mbps between call processing and/or between pub and subs Delay <500ms between call processing nodes or between pub and subs


Unity Connection Architecture Review

SIP Trunk From CUCM to Ucxn

Unity Connection

CUCM

Up to 250 Sessions or “Ports”

TUI

Email Client / VMO

HTTP EWS

MediaSense

Jabber Mini Inbox

•  Scalable to 20,000 Users with all feature Speech Rec, Single Inbox, Integrated Messaging, etc.

•  CUCM shall be SIP Integrated

•  Exchange Integration via EWS (Office 365 as well)

•  Clients connect in various ways

•  Google Integration via Esnatech

•  MediaSense for video voicemail (10.x)

IMAP

Email Client

Secure IMAP Services Web Services

Google API’s

Esnatech

Office 365

EWS


Secondary

Writeable DB

Primary

Unity Connection CoWHA Functionality

Unity Connection HA Pair

Up to 20,000 Users

Up to 250 Ports

Access to all User Interfaces (TUI, VUI, IMAP, Admin, etc…)

Heartbeats

Database

Messages

Security and Certificates

Primary

Writeable DB

Up to 250 Ports

Secondary

Proxy to Primary

Split Brain Recovery (SBR) Database

Proxy to Primary


Dallas

Exchange Mailbox Server

Unity Connection CoWCoW BW Considerations

Unity Connection Active/Active Cluster

CUCM Cluster

Chicago

Exchange Network

Bandwidth/Latency

WAN

Guaranteed bandwidth with no steady-state congestion: –For 50 voice messaging ports on each server—7 Mbps –For 100 voice messaging ports on each server—14 Mbps –For 150 voice messaging ports on each server—21 Mbps –For 200 voice messaging ports on each server—28 Mbps –For 250 voice messaging ports on each server—35 Mbps

Clustering over the WAN with Single Inbox doubles the bandwidth requirements if Exchange is only accessible over the WAN connection For more than 2000 users and/or more than 80 milliseconds

of latency, see Design Guide.

Guaranteed bandwidth with no steady-state congestion: –For 50 voice messaging ports on each server—14 Mbps –For 100 voice messaging ports on each server—28 Mbps –For 150 voice messaging ports on each server—42 Mbps –For 200 voice messaging ports on each server—56 Mbps –For 250 voice messaging ports on each server—70 Mbps

Use the CLI command utils cuc networking dscp on to mark

intracluster data and message traffic with a differentiated services code

point (DSCP) value of 18


Unity Connection and SME Centralization of Ucxn with SME

Places call to Europe Cluster Phone

FNA to Ucxn with redirected number (Orig. Called Pty #)

(e)MWI relay Unsolicited Notify

•  To deliver a FNA/RONA to correct mailbox, Ucxn must see Original Called Party/Redirecting Number

•  Ucxn controls MWI in SIP environments with SIP Unsolicited Notify

•  If H.323 trunks or H.323/MGCP GWs are present in the mix, enabled redirecting number IE delivery (not shown)

•  Apply SIP trunk security profile to all trunks in path – make sure “Accept Unsolicited Notifications”

•  Must Configure “Redirecting Diversion Header Delivery” on SIP trunks (both inbound and outbound)


•  Previously called CUPS (Cisco Unified Presence Server), now called CUCM IM and Presence Server

•  Unified CM IM & P shares a user database (native) with UCM

•  User’s are then synchronized to Unified CM IM & P from UCM (via CUCM Local or LDAP)

•  One CUCM IM&P cluster can only service one CUCM cluster

•  Multiple CUCM IM&P clusters can service one CUCM cluster

CUCM IM and Presence Server Relationship to CUCM


IM-Only Mode Full Unified Comm. Mode

Option 1 Option 2

CUCM IM and Presence Server 2 Modes of Operation


Volatile Persistent Data (Login state) Times Ten Soft State Data (Presence info) IDS Global User Data Replication

Cisco Unified Presence Cluster

Cisco UCM

CTI/QBE

SIP Trunk AXL/SOAP

CUCM IM and Presence Server Single Cluster Architecture – All Workloads

Sub Cluster

15,000

15,000

15,000

45,000

7,500 7,500

7,500 7,500

7,500 7,500

15,000 0

15,000 0

15,000 0

IM, Presence, and Other Work Loads (Call Control, VM, etc.)


Volatile Persistent Data (Login state) Times Ten Soft State Data (Presence info) IDS Global User Data Replication

Cisco Unified Presence Cluster

Cisco UCM

CTI/QBE

SIP Trunk AXL/SOAP

CUCM IM and Presence Server Single Cluster Architecture – IM/P Only

Sub Cluster

25,000

25,000

25,000

75,000

12,500 12,500

12,500 12,500

12,500 12,500

25,000 0

25,000 0

25,000 0

**IM and Presence Only


Delay 80ms

5 Mbps per sub-cluster

MPLS

CUCM and CUCM IM&P should be local to one another

Delay between CUCM IM&P sub-clusters relative to # of Contacts

CUCM IM and Presence Server Intra-Cluster BW and Delay


•  This is not just federation, but proprietary Cisco-on-Cisco intra-domain, inter-cluster exchange of full UC workloads (voice, video, IM/P, directory)

•  Assumes same domain

<user>@abc.com

•  If these were different domains, then would simply be inter-domain federation

•  BW relative to # of Contacts

and User distribution amongst servers. Consists of contacts being monitored and messaged

•  Implicit Federation (Cisco-

on-Cisco intra-domain federation)

Unified CM IM & P

Cisco UCM

Unified CM IM & P

Cisco UCM

CUCM IM and Presence Server Inter-Cluster Peering

XMPP

AXL SOAP

URI Re-writes


  Provide site redundancy for disaster recovery   UCCX Local to CUCM, else see CTIoW requirements   Latency: 80 ms RTT between UCCX nodes   Latency: 80 ms RTT between UCCX and Exchange for agent email   Latency: 300 ms RTT between UCCX and remote agents

MPLS

  1.2 Mbps between UCCX servers (DB replication, heartbeat, etc.)   800 Kbps between UCCX and CUCM (JTAPI)   In example above, 2 Mbps   Does not include media

Unified Contact Center Express (UCCX) CoW BW and Latency


•  VCS-C and VCS-E primarily becoming system for Internet Video Firewall Traversal including video to/from TP-enabled WebEx

•  Utilizes H.460 or variant to traverse FW…meaning

only outbound ports needed on FW No H.323 or SIP application inspection wanted or needed

•  Beginning to register all devices to CUCM

•  VCS can be completely virtualized •  Why?

To securely enable B2B calls over the Internet to your entire UC Infrastructure Very, very important feature coming in August

Video Control Server (VCS) What and Why?


MPLS

VCS (Video Control Server) Dual Data Center Design – Common Example

VCS-C-2

Internet 2

VCS-E-2

VCS-C-1

Internet 1

VCS-E-1

H.323 and SIP SRV Records for inbound routing and redundancy (not all records shown) _sip._tcp.cisco.com service = 0 0 5060 vcs-e-1.cisco.com _sip._tcp.cisco.com service = 0 0 5060 vcs-e-2.cisco.com

_h323cs._tcp.cisco.com service = 0 0 1720 vcs-e-1.cisco.com _h323cs._tcp.cisco.com service = 0 0 1720 vcs-e-2.cisco.com

“cisco.com”

DNS automatic discovery of vcs-c.cisco.com to IP address of VCS-C-1 and 2 Endpoint will re-register appropriately

CUCM cluster can use SIP routing to route outbound appropriately

VCS-E-1 outage, CUCM does not know, so VCS-C-1 should route over to VCS-C-2 for outbound redundancy

X Neighbor zone for any VCS-C-2 registered endpoints


Local Edition

SIP Trunking and Gateway Tips


•  SIP Trunks support the “Run On All Unified CM Nodes” and “Up to 16 destination IP addresses” features •  H323 and MGCP Trunks to gateways use standard CUCM Groups and 1 IP destination •  Using standard Call Manager Groups (rather than Run on All Nodes) increases call set up traffic between nodes

within a cluster •  Note – MGCP Trunks are only active on one node in the Call Manager Group (as the signaling channel is back

hauled to CUCM) •  Cisco’s focus on SIP. Not H.323 or MGCP •  MGCP complicates upgrades (CUCM/IOS version dependent)

H323 ICT Trunk H323 Trunk A

H323 Trunk B

Selected outbound Trunk Route List

SIP ICT Trunk MGCP Trunk A

MGCP Trunk B

Selected outbound Trunk Route List

CUCM and SIP Trunking SIP versus H.323/MGCP


•  Outbound SIP Trunks, H323 Inter Cluster Trunks and Route Lists can take advantage of the Route Local Rule by using the “Run On All Unified CM Nodes” feature

•  The Route Local Rule •  If the CUCM node that the inbound call arrives on – also has an instance of the selected outbound trunk for that

call – then use this node to onward route the call •  The Route Local rule reduces (and can eliminate) call set up traffic between CUCM nodes within a cluster

CUBE

CUBE

SIP Trunk

SIP/H323 ICT Trunk

CUBE

CUBE

SIP Trunk A SIP/H323 ICT Trunk

Route List

SIP Trunk B

CUCM and SIP Trunking SIP- Run on All Nodes


•  OPTIONS Ping is activated on a per SIP Trunk basis and run on each node’s SIP daemon to each destination •  Use between CUCM servers, or between CUBE and CUCM servers. But, 3rd party supported also •  CUCM will not attempt to establish a new call to an unavailable remote peer

•  SIP Trunk - “In Service” whilst one remote peer is reachable •  SIP Trunk - “Out Of Service” state when all remote peers are unreachable

•  Provides dynamic reachability detection •  Pre CUCM 8.5 Trunks - Per call time out

SIP Trunk

SIP ICT Trunk

CUBE

CUBE

CUCM and SIP Trunking Options Ping (CUCM 8.5+)


SIP Trunk SP SIP Trunk

CUBE

IP PSTN A

(408)100-1010

(510)100-1010

(919)200-2010

(919)200-2000

(510)100-1000

(408)100-1000

voice class e164-pattern-map 100 e164 919200200. e164 510100100. e164 408100100. dial-peer voice 1 voip destination e164-pattern-map 100 codec g729r8 session target ipv4:10.1.1.1

voice class e164-pattern-map 100 url flash:e164-pattern-map.cfg dial-peer voice 1 voip destination e164-pattern-map 100 codec g711ulaw session target ipv4:10.1.1.1

! This is an example of the contents of E164 patterns text file stored in flash:e164-pattern-map.cfg

9192002010 5101001010 4081001010

Site A

Site B

Site C

Site A

Site B

Site C

G729 Sites

G711 Sites

Provides the ability to combine multiple destination-patterns targeted to the same destination to be grouped into a single dial-peer

CUBE Dial Plan Enhancements


CUBE Inbound Dial Peer Matching Enhancements

SIP Trunk SP SIP Trunk

CUBE

A

Inbound LAN Dial-Peer

IP PSTN

Inbound WAN Dial-Peer Inbound Calls

Outbound Calls

dial-peer voice 5 voip incoming called-number 654321

dial-peer voice 6 voip answer-address 555

dial-peer voice 7 voip destination-pattern 555

voice class uri 1001 sip host ipv4:10.1.1.1 voice class uri 2001 sip host ipv4:10.2.1.1 dial-peer voice 1 voip incoming uri via 1001 dial-peer voice 2 voip incoming uri request 2001 dial-peer voice 3 voip incoming uri to 2001 dial-peer voice 4 voip incoming uri from 1001

Received: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-tag="cid:[email protected]";;branch=z9hG4bK-23955-1-0 From: "555" <sip:[email protected]:5060>;tag=1 To: ABC <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 INVITE Contact: sip:[email protected]:5060 Supported: timer Max-Forwards: 70 Subject: BRKUCC-2934 Session Content-Type: application/sdp Content-Length: 226

1

2

3

4

Priority


CUBE Media Forking

Cisco Search/Play demo app -or-

Partner Application

media class 1 recorder parameter media-recording 20 dial-peer voice 1 voip description dial-peer that needs to be forked session protocol sipv2 media-class 1

dial-peer voice 20 voip description dial-peer pointing to MediaSense session protocol sipv2 session target ipv4:<Mediasense_IP>

Needs to match

SIP SIP

SIP

A SP SIP

CUBE

RTP

RTP RTP

MediaSense

•  Gateway full time recording

•  Recording at the dial-peer level

•  CUBE calls the MediaSense Server •  Entire call recorded from cradle to grave

•  Record entire time a customer in the IVR •  Record even after subsequent transfers

•  CUCM 10.x, Centralized Ad-hoc recording by phone (CUCM to CUBE APIs)


CUBE High Availability

ASR1006 Dual Forwarding plane HW Dual Control plane HW (CPU)

CUSP CUSP

•  L2 Box-to-Box redundancy •  ISR G2 (Stateful failover) •  ASR 1001 & ASR 1004 (Stateful failover) •  Local redundancy and geographical if layer 2 SLA’s met •  ASR needs L2 swjtch for control/data checkpointing

•  Clustering with load balancing •  All platforms •  Load balancing by

•  SP call agent •  Cisco Unified SIP Proxy

•  Local and geographical redundancy

•  Inbox redundancy •  ASR 1006 •  Stateful failover •  Local redundancy

Active

Virtual IP CUBE

CUBE

Virtual IP

Standby

SIP SP

SIP SP

ISR-G2 HA


Local Edition

Dial Plan URI Focused


• What is it? ‒ SIP Uniform Resource Identifier ‒ Typically copy your email address

ex. [email protected] ‒ Popular for Internet video calls today, will

become way to call in future

• Why?, b/c its globally routable and friendly • But E.164 is not going away any time soon • Cisco UC 9.x implements blended identity •  In CUCM, is an alias to the DN ‒ Primary plus up to 4 more will ring DN

SIP URI Dialing Intro


SIP URI Routing The Routing Problem – This ain’t like E.164 routing

•  Host part of URIs might identify home cluster

•  Reachability established through SIP route patterns for host parts

•  Requires hierarchical URI scheme

42

[email protected] [email protected]

[email protected]

ny.cisco.com fra.cisco.com

•  What if it is flat??

? [email protected]

[email protected]

[email protected]


ILS Networking URI Learning /Routing

•  Components of end-to-end URI dialing/routing ‒  ILS networking

‒  URI propagation

‒  SIP trunk

‒  SIP route pattern

•  ILS networking is foundation for exchange or URI reachability information

•  SIP connectivity is foundation for call routing based on SIP route patterns

•  URI propagation is enabled independent of ILS networking ‒  Establish ILS topology, then build supporting SIP trunking topology underneath

‒  For small number of clusters, ILS topology usually will follow SIP trunking topology

43

ILS networking

URI propagation

 [email protected] (sjc.cisco.com) [email protected] (fra.cisco.com)

[email protected] [email protected]

SIP Trunks SIP Route Pattern

fra.cisco.com SIP Route Pattern

sjc.cisco.com

[email protected] sjc.cisco.com

[email protected] fra.cisco.com


•  How do we route calls between VCS and CUCM environments

•  VCS does not talk ILS

•  From VCS, can direct calls into any CUCM cluster, as all URIs known in the ILS network

•  Be as specific as possible from VCS to CUCM (ex. *.cisco.com)

•  Default SIP route towards VCS towards Internet

•  So how do we solve a flat naming space without routing loops?

SIP RP *.*

Search Rule *.cisco.com

CUCM and VCS Together URI Routing Example


CUCM, loop prevention via CSS and PTs

Via ILS, CUCM has full knowledge of all specific URIs, so no need for SIP route patterns amongst clusters

CUCM Trunks have CSS on them

Don’t allow the CUCM inbound trunk from VCS to see the SIP route pattern of *.*

VCS has 3 mechanisms: Search Rule, call coming from specific zone (trunk) is not sent back from where it come unless it’s been modified

Hop Count (0, does not route)

Source Zone (trunk)

1. Joe calls [email protected] via Jabber

2. CUCM cluster(s) check ILS DB, nothing found, so follows *.* SIP route pattern towards VCS

3. VCS-C checks local zone for [email protected] Nothing found, sends “any alias” to VCS-E

4. VCS-E checks local zone for [email protected] Nothing found, if unmodified, stops routing

X

CUCM and VCS URI Routing and Loop Prevention


•  Registration Natively register video endpoints to CUCM w/SIP if limitations are not an issue (FECC, Phone Book)

H.323 endpoints will be registered to VCS

SIP old endpoints can be registered to VCS

•  SIP to H.323 Interworking takes places on VCS

•  +E164 scheme for numbers (H.323 ID on VCS registered endpoints)

•  SIP on all CUCM or VCS registered endpoints and SIP VCS endpoints

CUCM and VCS Together Misc. Dial Plan Recommendations


•  Single Number Reach (SNR) on CUCM

Concept of “Remote Destinations” . May have many (RD1, RD2…)

•  FindMe on VCS

“SNR for the video world”, but URI-based

Concept of FindMe URI (ex. [email protected]) and device specific URIs (ex. [email protected], [email protected])

Used when you have multiple video devices provisioned

FindMe URI is what is called, device URIs are dialed and searched for

•  In Mixed CUCM / VCS environment, Goal is to

Have all devices ring on both CUCM side and VCS side when user is dialed on either side

Avoid loops

CUCM and VCS Together SNR and FindMe


•  In this Example 1, FindMe is on VCS and is needed, so VCS “owns” user’s main URIs and will not route it to CUCM

•  Disable all device-specific URIs for FindMe in TMS (uncheck “initial”)

•  Add globalized number on CUCM side to FindMe in TMS and check initial

•  For each device on VCS (ex. EX90, Movi), add the specific URI as an alternate/remote destination in CUCM options pages

CUCM and VCS Together SNR Functionality with FindMe Example 1

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 49

Unified CM VCS-C

Joe’s VCS Devices

VCS Expressway

*.* to SME Any Alias to VCS-E

SME

Jabber (movi) EX 90

Registered [email protected] Registered [email protected]

[email protected] called from VCS or Internet

FindMe URI

[email protected] 85551212

FindMe to 85551212 Regular E.164 routing

85551212 SNR to RD’s

Joe’s CUCM Phone 85551212

EX 90

RD1 [email protected] RD2 [email protected]

*.* to VCS-C

Any Alias to VCS-C Route (8\d{7}) to CUCM

Regular E.164 routing 85551212

CUCM and VCS Together SNR in Action (With FindMe) - Example 1

Someone Calls


•  In this Example 2, all video users are also on CUCM and using base SNR feature.

•  Here, CUCM owns your main URI

•  For each device on VCS (ex. EX90, Movi), add the specific URI as an alternate/remote destination in CUCM options pages

CUCM and VCS Together SNR Only (Without FindMe) - Example 2


Unified CM VCS-C

Joe’s VCS Devices

VCS Expressway

*.* to SME Any Alias to VCS-E

SME

Jabber (movi) EX 90

Registered [email protected] Registered [email protected]

[email protected] Route *@cisco.com ILS Route [email protected] to CUCM

85551212

Joe’s CUCM Phone 85551212

EX 90

RD1 [email protected] RD2 [email protected]

*.* to VCS-C

Any Alias to VCS-C

[email protected] is alias to 85551212 Ring 85551212

CUCM and VCS Together SNR in Action (Without FindMe) - Example 2

Someone Calls


Unified CM VCS-C

VCS Expressway

SME

[email protected] Route *@cisco.com ILS Route [email protected] to CUCM

Joe’s CUCM Devices 85551212

[email protected]

EX 90

Any Alias to VCS-C

[email protected] is alias to 85551212

Ring [email protected] which is alias to 85551212

(shared line from there)

CUCM and VCS Together No Jabber Video / All CUCM Registered - Example 3

Someone Calls from Internet


Local Edition

CUCM and Video Architecture Video is the new Voice


•  Cisco strategy moving forward Utilize API into video infrastructure (Conductor + Bridges)

Utilize Cisco MRGLs and intelligent bridge selection

Goal is to leverage a single video infrastructure across entire system and UC workloads

Goal to service standard to immersive TP for ad-hoc, rendezvous, and scheduled calls

Goal is to optimize bridge resources, bridge placement and media path

With H.265 and optimized bridging technologies

H.265 SVC, SW switching Mixed with HW bridging

Desktop video a reality

•  PVDM3s

CUCM and Video Architecture Cisco’s Bridging Strategy


•  Is at the heart of Cisco’s bridging strategy

•  Conductor is a layer of abstraction between call control and video bridging resources

It virtualizes pools of MCUs

It leverages mixed pool resources

It has bridging intelligence, can create custom policy

•  A product which will evolve with technology

•  Must understand types of conferences

Ad-Hoc (ex. CUCM), Rendezvous, Scheduled

CUCM and Video Architecture Conductor – What is it

MCU 2

MCU 1

MCU Pool

Conductor


SIP Trunk SIP/H.323 registration SIP/XML RPC SCCP registration

•  Audio conferencing Distributed pool of ad hoc voice resources (no different than today)

•  Centralized Video FW/Internet Traversal

•  Centralized Video Conferencing Ad hoc: Conductors centralized, connected to each UC Manager Rendezvous: Conductor cluster trunked to SME Scheduled: Separate MCU(s) or TelePresence Server(s) registered to local VCS

•  Distributed Ad-hoc and Rendezvous resources

Unified CM Unified CM Unified CM

Session Management

Edition

Ad hoc\Rendezvous video conferencing

Conductor

Ad hoc voice conferencing

Scheduled Video conferencing


Ad hoc\Rendezvous video conferencing


Ad hoc\Rendezvous video conferencing TMS

CUCM and Video Architecture Conductor Architecture Today Multi-Cluster CUCM Example

VCS-C VCS-E

(Centralized)


CUCM and Video Architecture Future Conductor Capabilities

Ad-hoc CUCM Managed

Rendezvous / Scheduled VCS / Conductor Managed

CUCM or VCS

TP Conductor Orchestrator “Virtual Bridge”

“Virtual Bridge” – Pooled MCUs

•  Leverage combined resources for Rendezvous/Scheduled and Ad-hoc conference calls (Audio and Video). Freely mix/match MCUs

•  Will intelligently contain Full-HD from HD, from SD calls to optimize DSPs (TP Server only)

User Site A schedules Conference: 2 endpoints Site A, 3 at Site B

•  Optimally places endpoints on MCUs to minimize bandwidth and resources. Centralized CAC on CUCM

WAN

1 Stream Across WAN, uses minimal resources on both bridges using rules in TP Conductor

TP Conductor Rule: If URI contains “lecture”, automatically record and stream

TCS

Site A (ad-hoc and Rendezvous/Sched)

Site B (ad-hoc and Rendezvous/Sched)


SIP Trunk SIP/H.323 registration SIP/XML RPC SCCP registration

•  Centralized video FW/Internet Traversal

•  Single centralized Conductor attached to all CUCMs with centralized CAC

•  Distributed Resources servicing all types of calls (Ad hoc, Rendezvous, and Scheduled)

•  CUCM registered devices

•  Greatly Simplified!!! Unified CM Unified CM

Unified CM

Session Management

Edition

Ad hoc\Rendezvous\ Scheduled videoconferencing

Conductor






TMS

CUCM and Video Architecture Conductor Architecture Tomorrow Multi-Cluster CUCM Example

VCS-C VCS-E


CU

CM

and

Vid

eo A

rchi

tect

ure

Con

duct

or O

pera

tion


Local Edition

Collaboration on the Edge


Collaboration on the Edge Cisco Firewall Traversal

•  Securely release your internal UC network for B2B voice and video communication over the Internet URI Dialing

•  It is a client/server application VCS-C is a client to the VCS-E server

•  Uses only outbound ports

•  No application FW inspection needed “Fixup” SIP or H.323


•  Combining traditional video with WebEx video

Video

Scheduling

Content Sharing

•  $0 feature

•  User Experience with Active Presence

•  What are the Requirements See versioning

Collaboration on the Edge WebEx-Enabled Telepresence

TMS 14.2

MCU 4.4+or TS 3.0+


Collaboration on the Edge WebEx-Enabled TP Scheduling Experience Add WebEx,

TP, or both

Add TP ports to the meeting

Add WebEx to the meeting

•  Simplified scheduling

•  Combined WebEx / Video Outlook Plugin

•  OBTP TelePresence and WebEx

•  TMS Scheduling and Email scheduling support


Collaboration on the Edge AnyConnect VPN – Option 1

•  Requires AnyConnect application •  For optimal end-user experience

‒  deploy using client-side certificate authentication (no user credentials)

‒  “Always on” user experience. Almost Transparent to end user

•  VPN-on demand with trusted network detection and optimal GW selection ‒  iOS automatically launches with UC Apps

•  Access to all applications on devices •  Consistent point-of-entry (VPN strategy) •  AnyConnect Futures (next-gen security) •  Will you have AnyConnect on mobile devices anyways?

Jabber Clients with AnyConnect

Internet

ASA

Internal Network


Outside corporate firewall (Public Internet) Inside corporate firewall (Intranet)

Jabber Clients

IP Communications

Immersive TelePresence Personal TelePresence

IM and Presence

Visual VM

Directory

Inside Firewall

VCS Expressway

VCS Control

UCM Outside Firewall

Collaboration on the Edge The Collaboration Edge – Option 2

JCF

HTTPS

UDS/HTTPS

Voice Video

TURN Server


Local Edition

Medianet


Medianet What? Why?

•  What is it? Video is the catalyst

Blueprint using old and new network features yielding the deepest visibility into your network infrastructure

Application aware and dynamic

•  Business Drivers Video and explosion of endpoints of different types

Higher expectations of the UC experience and of the network

Reduction of complexity, operational efficiency

With H.265 and optimized bridging technologies, desktop video a reality


Medianet Performance Monitor = Visibility

Classic Netflow / Flexible Netflow Netflow – Interface-based policy

Scalable, some layer 7 intelligence

Provides bit-rate metrics on flows

Lacks RTP Performance Metrics

However a critical technology for Medianet

Medianet Performance Monitor Network device discovers traffic flow

Admin defines metrics to gauge performance

Uses Modular CLI (Class-Map / Service-Policy)

Per-Hop Collection of RTP and TCP metrics

*Proactive Monitoring

Can also export to Netflow Collector

Exports to Netflow Collector

• Works with Medianet Mediatrace


Medianet Performance Monitor Alerts

Instruct monitor to react on upper threshold limit

Will trigger alerts (syslog / snmp)

If jitter is greater than 10ms, alert

Performance Monitor detected 12ms

Sends alert, along with the details of the flow


Medianet Performance Monitor Alone?

•  I have flow stats on a per-hop basis and I have detailed flow information I can nicely configure

•  Below, if I go into each WAN router and issue show commands for a particular flow, I can cobble together and perform manual fault Isolation on RTP stats buried in routers along the media path!

•  But who in the heck is going to do that?

•  Performance Monitor by itself is not user friendly…way too manual. I need some way to automate the collection flows when needed, then illustrate them.


Medianet Mediatrace

• Automatic Node Discovery Along Path • Gathers Performance Stats from Network Nodes, hop-by-hop • Asks each node along the path for information on the particular flow • Initiator – Consumer • Responder – Sender • Below, output cryptic and hard to analyze

How do I automate this and put it in a usable format??


Medianet Prime Collaboration Manager • Performs the Mediatrace

(even from endpoints in 9.0) • Hop by Hop analysis of Mediatrace output • Media Trace supported on many infrastructure devices and endpoints (see end of presentation)

• Collection of CPU memory stats on devices (system keyword) • CPCM is asking a device for a Media Trace along the media path rendering the collective Perf. Monitor stats. • Triggered by alerts


Medianet Application Awareness

Network Based Application Recognition Simplified Policy Configuration (app definitions in router)

Deep Packet Application-Level Inspection

Historically used to classify, schedule, queue traffic

Has Integration with Flexible Netflow / Performance Monitor for monitoring

Only common applications defined

Flow Metadata Need Metadata = Data about Data (in our case, data about flows)

Need Metadata to be produced by some application (Windows / Linux machine)

Need Metadata to be visible, consumed and understood by the network (Routers and Switches)

Need Metadata to be shared to the network edge

Need Metadata to be transported across the network out-of-band to make the network aware of flows and their identity

Must also integrates with Performance Monitor and QoS policies


Medianet Flow Metadata


Medianet Using Flow Metadata for QoS policy – Desktop Example using WebEx

•  Before metadata, cannot tell difference between flows inside of a WebEx session •  With Medianet and Metadata support, a WebEx browser tells MSI who reports reported metadata and flow to route •  The router associated the metadata with the flow and relays to network via RSVP (maybe other protocols some day) •  Router configured via MQC-style service policy to monitor flow for that metadata tags in a class-map •  Below is outcome. ACL would have been 30 plus lines of IOS commands. •  ***The same Metadata/class-map technique used with Performance Monitor can be used for Queuing and Scheduling on

interfaces

• Used “match protocol” for NBAR, but not all applications supported

• Now using “match application”

• Can also match on metadata free text strings


•  Jabber

Shipping with Metadata support only, MSI separately installed (admin priv)

Customer concerns around managing large scale, mobile desktop video deployments Bandwidth management and control (overcomes DSCP marking challenges)

Troubleshooting and Performance management (granular level capacity planning and performance monitoring)

Adding support for Performance Monitoring and Mediatrace in CY13 – 10.0 system release

•  WebEx

Windows browser only today, MSI separately installed (admin priv)

Same visibility issues on desktop as Jabber

Slightly ahead. Supports Performance Monitoring and Mediatrace for TCP and RTP to Cisco Prime

•  CTS/EX/C

Full featured MSI embedded and managed by Cisco Prime Collaboration Manager

Medianet Enabled Endpoints


•  We can Tap into metadata capabilities using the MSI which is now embedded in Cisco endpoints

Metadata capabilities can be used for both visibility and QoS techniques, auto-configured ports for QoS, and pacing devices in the right VLAN (not just for phones)

•  We will have MSI built into all of our collaboration endpoints moving forward

MSI could also be used by an endpoint to pull its location and obtain registration information to find it’s server

MSI Generate IPLSA and IPSLA-VO when idle for endpoints

We publish MSI, so key strategic partners can implement MSI into products we integrate with

3rd party NMS take advantage of MSI registration. MSI uses DHCP or DNS to find NMS and registers using REST

•  This is a Cisco differentiator

Medianet Where are we headed


New Collaboration SRND 9.x

What is the Collaboration SRND? Evolution of our UC SRND and TP design guides:

  Evolve from UC and TP design to Collaboration

  Make video pervasive through doc

  Change overall tone of document from voice to collaboration

  Emphasize recommended but include supported

  Expand scope to include more Social, Cloud and Mobile

  Combine UC and TP/Video Design Guidance

Collaboration SRND


Feedback •  Give us your feedback and you could win fabulous

prizes. Winners announced daily. ‒  Receive 20 Passport points for each session evaluation

you complete

‒  Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

•  Don’t forget to activate your Cisco Live Virtual account for access to all session material, communities, and on-demand and live activities throughout the year. Activate your account at the Cisco booth in the World of Solutions or visit www.ciscolive.com.

79


Register for Cisco Live - Orlando

Cisco Live - Orlando June 23 – 27, 2013 www.ciscolive.com/us

80 80

collaboration architecture-2013 cisco live local

Technology