Deploying Enterprise SIP Trunks With CUBE, CUCM - Cisco Live PDF

Deploying Enterprise
SIP Trunks with CUBE

and Unified CM
Hussain Ali, CCIE# 38068 (Voice, Collaboration)
Technical Marketing Engineer
Dilip Singh, CCIE# 16545 (Collaboration)
Technical Leader
LTRCOL-2310
Cisco Spark
Questions?
Use Cisco Spark to chat with the
speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
Cisco Spark spaces will be cs.co/ciscolivebot#LTRCOL-2310

available until July 3, 2017.
© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda
• SIP Trunking and CUBE Overview
• SIP Trunking Design & Deployment Models
• CUBE Architecture (Physical & Virtual)
• Transitioning to SIP Trunking using CUBE
• Advanced features on CUBE
• CUBE Management & Troubleshooting
• Futures & Key Takeaways
CUBE Overview
SIP Trunking Overcomes TDM Barriers
• Improves Efficiency of interconnection between networks
• Simplifies PSTN interconnection with IP end-to-end
• Enables rich media services to employees, customers, partners
• Carries converged voice, video and data traffic
Service Provider
TDM Trunking
Enterprise 1 Enterprise 2
A IP IP A
TDM TDM
Rich Media Rich Media

SIP Trunking
Enterprise 2
Enterprise 1
IP
SIP SP IP
CUBECUBE
CUBE
SIP SIP
Rich Media
LTRCOL-2310 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 6
Why does an enterprise need an SBC ?
Enterprise 1 Enterprise 2
IP
SIP IP SIP
IP
CUBE CUBE
Rich Media (Real time Voice, Video, Screenshare etc.. ) Rich Media
SESSION
CONTROL SECURITY INTERWORKING DEMARCATION
Call Admissions Encryption SIP - SIP Fault Isolation

Control Authentication H.323 - SIP Topology Hiding
Trunk Routing Registration SIP Normalization Network Borders
Ensuring QoS SIP Protection DTMF Interworking L5/L7 Protocol
Statistics and Billing Voice Policy Transcoding Demarcation
Redundancy/ Firewall Placement Codec Filtering
Scalability Toll Fraud
Cisco Unified Border Element – Router Integration
An Integrated Network Infrastructure Service
CUBE and Cisco Unified Border Element TDM Gateway
SRST  Address Hiding
PSTN Backup
collocated:  H.323 and SIP interworking
SCCP SRST  DTMF interworking
on ISR G2  SIP security
w/CUBE is  Transcoding
Voice Policy
CUBE
supported Note: An SBC appliance would
have only these features
SIP SRST on
ISR G2
w/CUBE is not
WAN & LAN IP Routing &
supported MPLS
Physical
Any SRST on Interfaces
ISR 4K with
CUBE SRST Unified CM
collocated is Conferencing and
not supported FW, IPS, Transcoding
VXML
QoS
Note: Some features/components may require additional licensing
Primary CUBE Differentiators
• SBC integrated in the Router
• Leverages installed base and knowledge base
• Enables Flexible Deployment Models – Centralized or Distributed
• Broadest Scale of price performance
• Enables Flexible Deployment Models – Centralized or Distributed
• Allows optimal platform sizing for different size customers
• Integrated SBC and TDM Gateway
• Simplifies transition strategy from TDM to IP PSTN
• Voice Policy
• TDOS is a major security issue .
• White List / Black List is static and inadequate
• Integration with CTG Solutions
• CUCM recording solutions
• CVP call center solutions
• Expressway integration based on Use Cases
CUBE (Enterprise) Product Portfolio
50-150 ASR 1004/6 RP2
Introducing CUBE on ASR 1002-X
50-100 CSR
ASR 1001-X
vCUBE [Performance
dependent on vCPU and ISR 4451-X
memory] ISR 4431
20-35 3900E Series ISR-G2
(3925E, 3945E)
CPS
ISR 4351
17
3900 Series ISR-G2 (3925, 3945)

ISR-4K (4321, 4331)
8-12
2900 Series
ISR-G2 (2901, 2911, 2921, 2951) Note: SM-X-PVDM module
supported on XE3.16 or
<5
later for ISR 4K platforms
800 ISR
4 <50 500-600 900-1000 2000-2500 4000 4500-6000 7000-10,000 12K-14K 14-16K
Active Concurrent Voice Calls Capacity

For Your
CUBE Session Capacity Summary Reference
Platform CUBE SIP-SIP Sessions (Audio)

NanoCUBE (8XX and SPIAD Platforms) 15 - 120
2901 – 4321 100
2911 – 2921 200 – 400
4331 500
2951 600
3925 – 3945 800 – 950
4351 1000
3925E – 3945E 2100 – 2500
4431 3000
4451 6000
ASR1001-X 12000
ASR1002-X 14000
ASR1004/1006 RP2 16000
Introducing IOS-XE Release 16
• New OS from the platform team with the intent of consolidating OS’ on different
product portfolio
• UX will be the same as IOS-XE, no difference to end user
• IOS-XE Release 16.3.1 support for UC (CUBE, CME, SRST)
 Impacts XE based (ASR1K, ISR4K, and vCUBE) platforms
 There will be no CUBE 11.5.1 for the XE based platforms [ASR1K, ISR4K,
vCUBE]. CUBE 11.5.2 (July 2016 release) will have newer and March 2016
features for the XE based platforms introduced in IOS-XE release 16.3.1
 IOS-XE 16 requires a minimum of ASR1001-X, 1002-X, 1004/1006 RP2,
ESP20 (Embedded Service Processor, SIP40 (SPA Interface processor)
 It will include all features up to and including IOS-XE 3.17 as well
• Due to new hardware requirements, customers will have the following migrations
options as IOS-XE 3.17 rebuilds will stop by June 2017
 Replace unsupported ASR1K hardware and upgrade to IOS-XE 16.3.1 or later
and continue to enjoy new feature set/support for any issues
 Drop using new feature set and move back to IOS-XE3.16 long maintenance
release for longer support
CUBE Software Release Mapping
ISR G2 ASR 1K / ISR-4K/vCUBE (CSR)
CUBE Vers. 2900/ 3900 FCS CUBE Vers. IOS XE Release FCS
11.1.0 15.5(3)M July 2015 11.1.0 3.16 15.5(3)S July 2015
11.5.0 15.6(1)T Nov 2015 11.5.0 3.17 15.6(1)S Nov 2015
CUBE CUBE
Vers.
2900/ 3900 FCS
Vers. IOS XE Release 16 2 FCS
11.5.14 15.6(2)T14 Mar 2016 N/A 3 16.2.13 Mar 2016

11.5.2 15.6(3)M1 Dec 2016 11.5.23 16.3.2/16.4.13 Nov 2016
EOL EOL EOL 11.6.0 16.5.1 Mar 2017
2IOS-XE 16 requires a minimum of ASR1001-X, 1002-X, 1004/1006 RP2, ESP20 (Embedded Service Processor, SIP40 (SPA Interface
processor)
3 IOS-XE release 16.2.1 does not support CUBE functionality on the platforms. There is no CUBE version 11.5.1 for the XE based
platforms. All CUBE features from 11.5.0 (IOS-XE 3.17) and earlier versions along with CUBE 11.5.1 (March 2016 release) on ISR G2
are included in CUBE release 11.5.2 for the IOS-XE based platforms, IOS-XE release 16.3.1 [July 2016 release]
4 IOS15.6(2)T will show CUBE Release version to be 12.0.0 but due to DDTS# CSCuz43735, rebuilds for this release train will align
to CUBE release 11.5.1, that is 15.6(2)T1/T2/T3/T4 and so on will be CUBE version 11.5.1
CUBE Software Release Mapping – Earlier Releases
ISR G2 CUBE Ent ASR 1K Series
ASR Parity
CUBE Vers. 2900/ 3900 FCS with ISR CUBE Vers. IOS XE Release FCS
8.5 15.1(2)T July 2010 <50% 1.4 3.2 15.1(1)S Nov 2010
8.6 15.1(3)T Nov 2010 <50% 1.4.1 3.3 15.1(2)S March 2011
8.7 15.1(4)M April 2011 ~50% 1.4.2 3.4 15.1(3)S July 2011
8.8 15.2(1)T July 2011 ~70% 1.4.3 3.5 15.2(1)S Nov 2011
8.9 15.2(2)T Nov 2011 >80% 1.4.4 3.6 15.2(2)S Mar 2012
15.2(3)T/
9.0 Mar 2012 >85% 9.0 3.7 15.2(4)S July 2012
15.2(4)M
9.0.1 15.3(1)T Oct 2012 >95% 9.0.1 3.8 15.3(1)S Oct 2012
9.0.2 15.3(2)T Mar 2013 >95% 9.0.2 3.9 15.3(2)S Mar 2013
9.5.1 15.3(3)M1 Oct 2013 >95% 9.5.1 3.10.1 15.3(3)S1 Oct 2013
10.0.0 15.4(1)T Nov 2013 >95% 10.0.0 3.11 15.4(1)S Nov 2013
10.0.1 15.4(2)T Mar 2014 >95% 10.0.1 3.12 15.4(2)S Mar 2014
CUBE Software Release Mapping – Earlier Releases
ISR G2 CUBE Ent ASR 1K / ISR-4K Series
CUBE ASR Parity CUBE
2900/ 3900 FCS with ISR IOS XE Release FCS
Vers. Vers.
10.0.2 15.4(3)M July 2014 >95% 10.0.2 3.13 15.4(3)S July 2014
10.5.0 15.5(1)T Nov 2014 >95% 10.5.0 3.14 15.5(1)S Nov 2014
11.0.0 15.5(2)T Mar 2015 >95% 11.0.0 3.15 15.5(2)S Mar 2015
CUBE Interoperability
• Validated with Service
Providers World-Wide
• Independently Tested
with 3-Party PBXs in
tekVizion Labs
• Standards based
Verified by
Proven Interoperability and Interworking with

Service Providers Worldwide
Cisco Interoperability Portal:
www.cisco.com/go/interoperability
Cisco Unified Border Element
Leverage all the advantages Cisco can offer
MIGRATE WITH EXISTING EQUIPMENT INTEROPERABILITY

 Network devices are multipurpose  Tested with PBX’s
 Equipment inventory is simplified  Validated with Service
 Leverage existing training Providers
 Migration to SIP is phased CUBE  Standards Based

ADVANTAGE STATE OF THE ART
END TO END SUPPORT TECHNOLOGY
 Safe, Trusted, Reliable  Largest R&D spending
 Familiar interfaces and  Revolutionary Platforms (ISR G2,
management UCS)
 Portfolio breadth  Broadest depth of protocols: SIP

plus more
CUBE Licensing
For Your
CUBE ISR(G2/4K), ASR and CSR Licensing Reference
Redundancy Licenses
Platform Single-Use Licenses
( 1 SKU for Active/Standby Pair)
Cisco 881, 886, 887, 888, 892F, SPIAD FL-NANOCUBE N/A
FL-CUBEE-5 FL-CUBEE-5-RED
ISR G2 (2901, 2911, 2921, 2951, 3925, 3945,
3925E, 3945E)
ISR-4K (4321, 4331, 4351, 4431, 4451)
FLASR1-CUBEE-100P FLASR1-CUBEE-100R
Cisco ASR1001-X, 1002-X, 1004 RP2, 1006 RP2 FLASR1-CUBEE-4KP FLASR1-CUBEE-4K-R
FLASR1-CUBEE-16KP FLASR1-CUBEE-16KR
vCUBE (CUBE on CSR 1000v)

APPX Package (No TLS/SRTP) or Same SKUs as ASR1K series Same SKUs as ASR1K series
AX (All vCUBE features) CSR licensing package
http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-
element/order_guide_c07_462222.html
CUBE Licensing FAQs
• What is a CUBE license?
 CUBE is part of the UCK9 package on Cisco Routing platforms and is a Right-to-Use (RTU) license. There is no
licensing file to install to use the CUBE feature set. It is a paper/trust-based license on top of the Unified
Communications (UCK9) feature set that is enabled as discussed below.
• How to enable UCK9 (SRST, CME, CUBE, GW, etc) feature set of which CUBE is a
part of?
 General information on IOS Software Activation (licensing) can be found here .
1. For ISR G2s/4K series, install the UCK9 package license to access all the voice features including CUBE. For SIP TLS/SRTP, SEC-K9
license is also required.
2. For ASR1K series, Advanced IP Services or Advanced Enterprise Services package/image needs to be installed for CUBE
3. For vCUBE (CUBE on CSR 1000v), APPX (no TLS/SRTP) or AX (ALL vCUBE features) package license needs to be installed to access
the CUBE feature set and upgrade from the default throughput of 100 kbps
4. For 8XX series, Advanced IP services or higher is needed to access the NanoCUBE feature set
5. Once the platform is ready, CUBE license needs to be purchased to start using the feature set
6. The RED SKUs require a separate SMARTNET and do not need any additional Single-Use case SKUs
• Are CUBE licenses incremental?

 Yes, CUBE licenses can be added together to provide an aggregate session count. This way, a customer can start with
a smaller numbers of sessions and grow their system over time as call volume increases. E.g. a customer may buy a
FL-CUBEE-5 license to start with allowing a total of 5 sessions, and later add 2 more FL-CUBE-5 licenses for a total of
15 sessions.
• Is CUBE Licensing Enforced?

 No, CUBE is a paper-based honor license (no file to install) that allows to run the CUBE RTU (Right-to-Use) feature
set once you have the UCK9 license installed. More info on ordering here.
CUBE Licensing FAQs – Cont’d
• What constitutes as a session?
 A session is a single audio or a video call across the CUBE, regardless of call legs. Some vendors consider one
call as two sessions.
• Does a call recording solution require additional licensing?

 No, Sessions created between CUBE and the Call Recording server such as MediaSense® do not require
additional licenses and are not counted against the CUBE licensing limit. However, keep in mind the platform
capacity numbers.
• Can a customer migrate from a Single-Use to a RED license?

 No, Currently there are no migration SKUs, that is, if the customer previously purchased a Single-Use license, it
cannot be converted into a RED license in future. For further assistance, please reach out to the CUBE team.
• Can standalone CUBE Licenses be transferred?

 No, CUBE licensing is not transferable between chassis at this time.
 FL-CUBEE-XX licenses can be bought for any ISR G2 platform, but cannot be transferred between platforms.
 FL-CUBEE-XX licenses are only for ISR G2 (i.e. you buy FL-CUBEE-5, it applies to a single ISR G2 that you buy
it for, which could be a 2901, 2911, 3925, etc., but only a single platform.)
Customer Deployment Scenario 1
Two active CUBEs, no redundancy (i.e.

NO call preservation on failure of box), no
load balancing
Expecting 100 sessions across each

Location
• Licensing requirement : Two FL-CUBEE-
100
Geographic Redundancy - Two active CUBEs,
NO call preservation on failure of box BUT load
balancing
• Expecting 100 sessions across each Location,
and in case of one Location failing, expecting
newer 100 calls to failover to the other Location
• Licensing requirement : Two FL-CUBEE-100-RED
• No additional Single-Use SKUs are required
• If a box fails in this scenario, the calls on it are
lost . The load balancing algorithm ensures the
next call is sent to the non-failed site
Layer 2 Box-to-Box Redundancy with

Call Preservation
Expecting 100 sessions across an active CUBE

in a CUBE HA pair as shown here
• Licensing requirement : One FL-CUBEE-
100-RED for the pair
• Separate single use case licenses are not
required
What if the standby CUBE was at a different

Location
• Layer 2 Box-to-Box redundancy is not
supported across geographical data centers.
Typically, it is two boxes in the same rack
Box-to-Box and Redundancy (call preservation on failure within location) and load
balancing/redundancy across locations
Expecting 100 sessions per Location
• Licensing requirement : Two FL-CUBEE-100-RED, one per Active/Standby pair. In total you will have 200-RED only and no additional
Single-use case SKUs are required.
Scenarios Covered
• If R1 or R3 went down, R2 or R4 respectively will take over
• If Location 1 (both R1 and R2) becomes unavailable, RED license allows newer calls to flow to Location 2. RED license
allows transfer not only within one redundant pair from Active to Standby, allowing call preservation, but also from one pair
to the other, that is from one Data Center to the other for new calls. In that case, Location 2 will handle 200 sessions. This
is called Dual Redundancy
Stateful Stateful
Preservation Preservation
Geographic Redundancy
Newer Calls
In-box Hardware and Software Redundancy
• Licensing requirement : RED license is not required here, regular Single-
Use CUBE license covers all In-box Redundancies
Agenda
SIP Trunking Design
and Deployment
Models
Cisco Session Management & CUBE
Essential Elements for Collaboration
• CUBE provides session border control

between IP networks
• Demarcation
• Interworking SIP TRUNK TO CUBE
• Session control Mobile CUBE Cisco B2B
• Security
• Cisco SME centralizes
network control IM, Presence,
Cisco Session
Management
Voicemail Video
• Centralizes dial plan
• Centralized applications 3rd Party IP TDM PBX
PBX
• Aggregates PBXs
CUBE/vCUBE Deployment Scenarios
TDM (Not available in vCUBE)
SIP Trunks SIP SIP Trunk SP VOIP
for PSTN
H.323 Services
Access CUBE
SBC
Standby
Partner API MediaSense Extending to Video and
Network- High Availability for Audio Calls
based CUBE
Media
SIP SIP SP IP
Recording
Solution SBC Network
RTP CUBE RTP
Active
IVR CVP Media

vXML Server Server
Integration
for Contact SP IP
SIP Network
Centers CUBE
SBC
Business to SIP SP IP SIP

Business
Telepresence CUBE SBC Network CUBE
NanoCUBE Deployment Scenarios
Service Provider
Call Control
NanoCUBE
CPE NANO- SIP NANO SIP SIP
Hosted CUBE
8xx
-CUBE
IAD
8xx
Service CUBE
Small SIP SIP PRI

CUCM TDM PBX
Business IP PBX
SIP Trunking
Hosted Service SIP Trunking PRI To SIP
Small Enterprise Small Business Small Business
Business
The Centralized Model
Characteristics of Centralized Operational Benefits Challenges
• Central Site is the only location with • Centralizes Physical • Increased campus bandwidth, CAC,
SIP session connectivity to IP PSTN Operations latency; media optimization
• HA in campus
• Voice services delivered to Branch • Centralizes Dial-Peer
Offices over the Enterprise IP WAN Management • Survivability at branch (PSTN
connection at the branch)
(usually MPLS)
• Centralizes SIP Trunk • Emergency services
• Media traffic hairpins through Capacity
• Legal/Regulatory
central site between SP and
branches Centralized
IP PSTN
Enterprise
IP WAN
CUBE
Site-SP Media
The Distributed Model
Characteristics of Distributed Operational Benefits Challenges
• Each site has direct connection • Leverages existing branch • Distributed dial-peer
for SIP sessions to SP routers management
• Takes advantage of SP session • No media hair-pinning thru any • Distributed operational overhead
pooling, if offered by SP site
• IP addressing to Service Provider
• Media traffic goes direct from • Lower latency on voice or video from branch
each branch site to the SP
• Built-in Redundancy strategy
Distributed
• Quickest transition from
existing TDM
IP PSTN
Enterprise
IP WAN
CUBE
CUBE CUBE CUBE Site-SP Media

CUBE
And the Hybrid Model
Characteristics of Hybrid Benefits
• Connection to SP SIP service is determined on a site by • Adaptable to site specific requirements
site basis to be either direct or routed through a regional
• Optimizes BW use on Enterprise WAN
site.
• Adaptable to regional SP issues
• Decision to route call direct or indirect based on various
criteria • Built-in redundancy strategy
• Media traffic goes direct from site to SP or hairpins
through another site, depending on branch configuration.
Hybrid
IP PSTN
Enterprise
IP WAN
CUBE CUBE
CUBE CUBE CUBE
WEBEX CCA Solution using CUBE Enterprise
Requirements
• Replacement for TDM audio connection to WEBEX with
VOIP using SIP signaling.
WEBEX Quad • High capacity SIP media connectivity for WEBEX cloud ,
including telepresence integration.
CUBE How
A
• CUBE Reduces SIP protocol “chatter” between CUCM and
CUBE
Enterprise WEBEX cloud thru normalization.
IP WAN
(MPLS) • CUBE allows SIP sessions from ALL enterprise sites to
WEBEX to avoid “hairpin” media flows.
Headquarters
• CUBE support on ASR provides high performance for
signaling and media transport of WEBEX.
CUBE Benefit
CUBE CUBE
• Best possible WEB conference experience for Enterprise
Branch users, with most efficient network usage.
Office Branch Branch
Office Office Future Capabilities
• Integration with WEBEX One Touch for improved
telepresence session set up (i.e. one touch)
In-Depth Explanation of SIP Deployment Models
New White Paper will be posted by the end of January at the following URL:
www.cisco.com/go/cube
Agenda
CUBE Call Flow
CUBE Call Processing
CUBE
 Actively involved in the call treatment,
signaling and media streams
 SIP B2B User Agent IP
 Signaling is terminated, interpreted and Media Flow-Through

 Signaling and media terminated by the Cisco
re-originated Unified Border Element
 Provides full inspection of signaling, and  Transcoding and complete IP address hiding
protection against malformed and malicious require this model
packets
 Media is handled in two different modes: CUBE
 Media Flow-Through IP
 Media Flow-Around
Media Flow-Around
 Digital Signal Processors (DSPs) are only  Only Signaling is terminated by CUBE
required for transcoding (calls with  Media bypasses the Cisco Unified Border
dissimilar codecs) Element
Cisco Unified Border Element Basic Call Flow
voice service voip
mode border-element
allow-connections h323 to h323
Originating allow-connections h323 to sip Terminating
allow-connections sip to h323
Endpoint - allow-connections sip to sip
Endpoint –
1000 2000
Incoming VoIP Call Outgoing VoIP Call
CUBE
dial-peer voice 1 voip dial-peer voice 2 voip

incoming called-number 2000 destination-pattern 2000
session protocol sipv2 session protocol sipv2
session target ipv4:1.1.1.1 session target ipv4:2.2.2.2
codec g711ulaw codec g711ulaw
1. Incoming VoIP setup message from originating endpoint
2. This matches inbound VoIP dial peer 1 for characteristics such as codec, VAD,
DTMF method, protocol, etc.
3. Match the called number to outbound VoIP dial peer 2
4. Outgoing VoIP setup message
Understanding the Call flow
Incoming VoIP Call Leg Outgoing VoIP Call Leg
Matches an Incoming Dial-peer Matches an Outbound Dial-peer
VRF1 – 10.10.10.10 CUBE 20.20.20.20 – VRF2

1000 2000
INVITE /w SDP
1.1.1.1 INVITE /w SDP 2.2.2.2
c= 1.1.1.1
c= 20.20.20.20
m=audio abc RTP/AVP 0
m=audio xxx RTP/AVP 0
100 TRYING 100 TRYING
180 RINGING 180 RINGING

200 OK
200 OK c= 2.2.2.2
c= 10.10.10.10 m=audio uvw RTP/AVP 0
m=audio xyz RTP/AVP 0 ACK
ACK
RTP (Audio)
1.1.1.1 10.10.10.10 20.20.20.20 2.2.2.2
BYE BYE
200 OK
200 OK
Basic Show Commands for Active Calls
CUBE# show call active voice brief
121A : 17 13:02:24.215 IST Mon Jun 27 2011.1 +2040 pid:1 Answer 1000 active
dur 00:00:14 tx:0/0 rx:0/0
IP 1.1.1.1:6000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF1
121A : 18 13:02:24.225 IST Mon Jun 27 2011.1 +2020 pid:2 Originate 2000 active
dur 00:00:14 tx:0/0 rx:0/0
IP 2.2.2.2:6001 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF2
Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
CUBE# show voip rtp connections

VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 17 18 17474 6000 10.10.10.10 1.1.1.1 NO VRF1
2 18 17 17476 6001 20.20.20.20 2.2.2.2 NO VRF2
Found 2 active RTP connections
CUBE Architecture
ISR G2 vs ASR1K vs ISR 4K vs
vCUBE (CUBE on CSR)
ASR/ISR-4K & ISR-G2 Architecture Comparison
ASR/ISR-4K (IOS-XE) Architecture ISR G2 Architecture
CPU
IOS
RP Control Plane Control
Plane
IOS-XE IOS-XE
Signaling
Signaling
I/O I/O
Kernel Data Plane
 ISR: Pkt fwd’ing and signaling are handled by the
Msg I/f same CPU
 ASR: Pkt fwd’ing and signaling are handled by

different CPUs
I/O ESP I/O
‒ ESP must be programmed or instructed by the
control plane to do specific media functions
Data (Forwarding) Plane
‒ Performed by Forwarding Plane Interface (FPI)
Media
Introducing vCUBE (CUBE on CSR 1000v)
Architecture
• CSR (Cloud Services Router) 1000v runs on a Hypervisor – IOS
XE without the router
ESXi Container
RP (control plane) ESP (data plane) FFP code
Chassis Mgr. QFP Client Chassis Mgr.

IOS-XE Forwarding Mgr. / Driver Forwarding Mgr.
CUBE signaling CUBE media processing

Kernel (incl. utilities)
Virtual CPU Memory Flash / Disk Console Mgmt ENET Ethernet NICs
CSR 1000v (virtual IOS-XE)
Hypervisor vSwitch NIC
X86 Multi-Core CPU Memory Banks Hardware GE … GE

Introducing vCUBE (CUBE on CSR 1000v) –
Cont’d
• CSR1000v is a virtual machine, running on x86 server (no specialized hardware) with
physical resources are managed by hypervisor and shared among VMs
• Requires APPX (No TLS/SRTP) or AX (All vCUBE features) CSR licensing package to
access voice CLI and increase throughput from 100 kbps default. CUBE Licensing
follows ASR1K SKUs and still trust based
• No DSP based features (transcoding/inband-RFC2833 DTMF/ASP/NR) available
• vMotion for vCUBE not supported today
• vCUBE Tested Reference Configurations [UCS base-M2-C460, C220-M3S, ESXi 5.1.0
& 5.5.0]. ESXi 6.0 supported with IOS-XE 16.3.1 or later
vCUBE Considerations
• Explicit subscription of CPU and memory reservation is required which the OVA
for CSR1000V provides
• Disable Hyperthreading
• “vCUBE media performance depends on the underlying VM platform consistently
providing packet switching latency of less than 5ms. Given the platform resource
requirements and latency requirements are met, latency and jitter values observed
on a vCUBE would the same as the values obtained on a CUBE running on a
hardware platform, with a recommended hardware configuration and identical
software configuration, under the same network conditions.”
• 2 network interface required at the very minimum
• Specs based hardware supported but performance benchmarked for Cisco UCS B
and C series only
ASR, CSR & ISR-G2/4K Feature Comparison
General Platform Features ASR1K ISR-G2 4300/4400 (XE3.13.1) vCUBE (XE3.15+)
Redundancy-Group Redundancy-Group Redundancy-Group
High Availability Implementation HSRP Based
Infrastructure Infrastructure Infrastructure
TDM Trunk Failover/Co-
Not Available Exists Exists Not Available
existence
Media Forking XE3.8 15.2.1T XE3.10 Exists
Software MTP registered to
XE3.6 Exists Exists Exists
CUCM (Including HA Support)
DSP Card SPA-DSP PVDM3 PVDM4/SM-X-PVDM Not Available
Transcoder registered to CUCM Not Available Exists via SCCP Exists via SCCP (XE3.11) Not Available
Local Transcoder Interface SCCP or SCCP based on a separate
Transcoder Implementation SCCP and LTI
(LTI) LTI (starting IOS 15.2.3T) platform, CUCM controlled
Embedded Packet Capture Exists Exists Exists Exists
Web-based UC API XE3.8 15.2.2T Exists Exists
Noise Reduction & ASP Exists 15.2.3T Exists Not Available
Call Progress Analysis XE3.9 15.3.2T Exists Not Available
Standalone CME/SRST feature
Not Available Exists XE3.11 Not Available
set, not collocated with CUBE
SRTP-RTP Call flows Exists (NO DSPs needed) Exists (DSPs required) Exists (NO DSPs needed) Exists (No DSPs needed)
VXML GW Not Available Exists Not Available Not Available
vCUBE
Installation using
OVA
vCUBE – CSR1000v Installation with OVA
• Download CSR1000v OVA from cisco.com
vCUBE – Download XE3.15 or later image
vCUBE – Deploy OVA
vCUBE – Installation Cont’d
vCUBE – Installation Cont’d
vCUBE – Choose Form factor
vCUBE Installation Cont’d
vCUBE – Assign LAN, WAN, and VM Network
vCUBE Installation Cont’d
© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 58
vCUBE Installation – Edit Settings to add Serial Port
vCUBE Installation – Edit Settings to add Serial Port
Serial Port – Connect via Network
Serial Port – Define URL
Serial Port – Verify Settings
vCUBE Installation – Power On VM
Install process takes some time
Install process takes some time
vCUBE – Initial Configuration
• Assign IP to VM Network Interface, Gig3 below, and enable console access with
“platform console serial” CLI, and set enable password
vCUBE – Initial Configuration – Telnet into Router
Initial Configuration – Copy License File to Flash:
Initial Configuration – Install License File
Initial Configuration – Verify New Throughput Level
and boot CSR to the correct package
vCUBE Initial Setup – Voice CLI is now accessible
Agenda
Transitioning to Centralized SIP Trunking...
Re-purpose your existing Cisco voice gateway’s as Session Border Controllers
BEFORE SIP/H323/MGCP AFTER Media
Media SIP Trunks
Standby
A Enterprise Campus CUBE

A Active IP PSTN
High-density Dedicated
Gateways
CUBE
CUBE with High

Availability
MPLS MPLS
PSTN is now
used only for
emergency
SRST calls over FXO
lines
SRST CME
CME
TDM PBX
Enterprise TDM PBX
Enterprise
Branch Offices Branch Offices
Steps to transitioning...
SIP Trunk
Media • Step 1 – Configure IP PBX to route
Standby all calls (HQ and branch offices) to
the edge SBC
CUBE
A
Active IP PSTN • Step 2 – Get SIP Trunk details from
the provider
CUBE
Enterprise CUBE with High
Campus Availability • Step 3 – Enable CUBE application
MPLS
on Cisco routers
PSTN is now • Step 4 – Configure call routing on

used only for CUBE (Incoming & Outgoing dial-
emergency
SRST calls over FXO peers)
lines
• Step 5 – Normalize SIP messages
CME
to meet SIP Trunk provider’s
requirements
TDM PBX
Enterprise Branch • Step 6 – Execute the test plan
Offices
Step 1: Configure CUCM to route calls to the edge SBC
SIP Trunk Pointing to CUBE
Standby
CUBE
A
Active IP PSTN
CUBE
Enterprise CUBE with High
Campus Availability
MPLS
• Configure CUCM to route all
PSTN calls (central and branch) PSTN is now
used only for
to CUBE via a SIP trunk emergency
SRST calls over
• Make sure all different patterns FXO lines
of
calls – local, long distance,
CME
international, emergency,
informational etc.. are pointing
TDM to
PBX
CUBE Enterprise
Branch Offices
Step 2: Get details from SIP Trunk provider
Item SIP Trunk service provider requirement Sample Response
1 SIP Trunk IP Address (Destination IP Address for INVITES) 66.77.37.2 or DNS
2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711, G729
5 Fax protocol support T.38
6 DTMF signaling mechanism RFC2833
7 Does the provider require SDP information in initial INVITE (Early offer Yes
required)
8 SBC’s external IP address that is required for the SP to 128.107.214.195
accept/authenticate calls (Source IP Address for INVITES)
9 Does SP require SIP Trunk registration for each DID? If yes, what is the No
username & password
10 Does SP require Digest Authentication? If yes, what is the username & No
password © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Step 3: Enable CUBE Application on Cisco routers
1. Enable CUBE Application
voice service voip
mode border-element license capacity 20  License count entered here not enforced though this CLI is
required to see “show cube” CLI output
allow-connections sip to sip  By default IOS/IOS-XE voice devices do not allow an incoming
VoIP leg to go out as VoIP
2. Configure any other global settings to meet SP’s requirements

voice service voip
media bulk-stats  To increment Rx/Tx counters on IOS-XE based platforms. W/O this CLI, it will show 0/0
sip
early-offer forced
header-passing
error-passthru
3. Create a trusted list of IP addresses to prevent toll-fraud
voice service voip
ip address trusted list  Applications initiating signalling towards CUBE, e.g. CUCM, CVP,
ipv4 66.77.37.2 ! ITSP SIP Trunk Service Provider’s SBC. IP Addresses from dial-peers with “session target
ipv4 10.10.1.20/28 ! CUCM ip” or Server Group are trusted by default and need not be populated here
sip
silent-discard untrusted  Default configuration starting XE 3.10.1 /15.3(3)M1 to mitigate TDoS Attack
Step 4: Configure Call routing on CUBE
Standby CUBE with High
Availability
CUBE
A
Active IP PSTN
CUBE
Enterprise
Campus
MPLS
LAN Dial-Peers WAN Dial-Peers
PSTN is now
• Dial-Peer – “static routing” table mapping phone numbers
used only forto interfaces or IP addresses
emergency calls
• LAN Dial-Peers – Dial-peers
SRST that are facing towards
overthe
FXO IP
linesPBX
for sending and
receiving calls to & from the PBX. Always bind LAN interface(s) on CUBE to LAN dial-
peers CME
• WAN Dial-Peers – Dial-peers that are facing towardsTDM PBX the SIP Trunk provider for sending
Enterprise Branch
& receiving calls to & from Offices
the ITSP. Always bind CUBE’s WAN interface(s) to WAN dial-
peer(s), ensuring SIP/RTP being source from the correct WAN interface(s)
WAN Dial-Peer Configuration
Inbound Dial-Peer for call legs from SP to CUBE
dial-peer voice 200 voip
description *** Inbound WAN side dial-peer *** Specific to your DID range
incoming called-number 702475….$
session protocol sipv2
assigned by the SP
voice-class sip bind control source gig0/1
voice-class sip bind media source gig0/1
Apply bind to all dial-peers when
codec g711ulaw CUBE has multiple interfaces.
dtmf-relay rtp-nte Gig0/1 faces SP.
no vad
Outbound Dial-Peer for call legs from CUBE to SP
dial-peer voice 201 voip Translation rule/profile to strip the
description *** Outbound WAN side dial-peer *** access code (9) before delivering
translation-profile outgoing Digitstrip the call to the SP
destination-pattern 91[2-9]..[2-9]......$
session protocol sipv2 Dial-peer for making long distance
voice-class sip bind control source gig0/1 calls to SP, based on NANP (North
American Numbering Plan)
session target ipv4:<SIP_Trunk_IP_Address>
codec g711ulaw Note: Separate outgoing DP to be created for Local, International,
dtmf-relay rtp-nte Emergency, Informational calls etc.
no vad
LAN Dial-Peer Configuration
Inbound Dial-Peer for call legs from CUCM to CUBE
description *** Inbound LAN side dial-peer ***
CUCM sending 9 (access code) + All
incoming called-number 9T
session protocol sipv2 digits dialed
codec g711ulaw CUBE has multiple interfaces. Gig0/0
dtmf-relay rtp-nte faces CUCM.
no vad
Outbound Dial-Peer for call legs from CUBE to CUCM
description *** Outbound LAN side dial-peer *** SP will be sending 10 digits (NANP)
destination-pattern 702475….$ based on your DID that is being
session protocol sipv2 delivered to CUCM
session target ipv4:<CUCM_IP_Address>
codec g711ulaw Default codec is G729 if none is
dtmf-relay rtp-nte specified
no vad
Note: If more than 1 CUCM cluster exists, you will have to create multiple such LAN dial-peers with “preference CLI” for CUCM redundancy/load balancing as the
traditional way to accommodate multiple trunks
SIP Normalization
SIP profiles is a mechanism to normalize or customize SIP at the
network border to provide interop between incompatible devices
SIP incompatibilities arise due to: Add user=phone for INVITEs
• A device rejecting an unknown header (value Incoming Outgoing
or parameter) instead of ignoring it CUBE
INVITE INVITE
sip:5551000@sip.com:5060 sip:5551000@sip.com:5060
• A device expecting an optional header SIP/2.0 user=phone SIP/2.0
value/parameter or can be implemented in
voice class sip-profiles 100
multiple ways request INVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0"
request REINVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0"
• A device sending a value/parameter that must
be changed or suppressed (“normalized”)
before it leaves/enters the enterprise to comply Modify a “sip:” URI to a “tel:” URI in INVITEs
with policies Incoming Outgoing
CUBE
INVITE INVITE
• Variations in the SIP standards of how to sip:2222000020@9.13.24.6:5060 tel:2222000020
achieve certain functions SIP/2.0 SIP/2.0

• With CUBE 10.0.1 SIP Profiles request INVITE sip-header SIP-Req-URI modify "sip:(.*)@[^ ]+" "tel:\1"
request INVITE sip-header From modify "<sip:(.*)@.*>" "<tel:\1>"
can be applied to inbound SIP request INVITE sip-header To modify "<sip:(.*)@.*>" "<tel:\1>"
messages as well
More information at http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/118825-technote-sip-00.html
Normalize Outbound SIP Message (Example 1)
SIP Provider For Call Forward & Transfer scenarios back to PSTN, the For Your
Requirement Diversion header should match the registered DID of your network Reference
SIP INVITE that CUBE sends SIP INVITE that Service Provider expects
Sent: Sent:
INVITE sip:2000@9.44.44.4:5060 SIP/2.0 INVITE sip:2000@9.44.44.4:5060 SIP/2.0
……… ……….
Diversion: <sip:3000@9.44.44.4>;privacy=off; Diversion: <sip:4085266855@9.44.44.4>;
reason=unconditional;screen=yes privacy=off;reason=unconditional;screen=yes
……... ……….
m=audio 6001 RTP/AVP 0 8 18 101 m=audio 32278 RTP/AVP 18 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
Configure voice class sip-profiles 500

request INVITE sip-header Diversion modify “sip:(.*>)” “sip:4085266855@9.44.44.4>”
SIP Profiles
request REINVITE sip-header Diversion modify “sip:(.*>)” “sip:4085266855@9.44.44.4>”
Apply to dial-peer voice 4000 voip

Outgoing description Incoming/outgoing SP
Dial-peer voice-class sip profiles 500
Normalize Inbound SIP Message (Example 2) For Your
Reference
CUBE
Requirement SIP Diversion header must include a user portion
SIP INVITE received by CUBE SIP INVITE CUBE expects
Received: Received:
INVITE sip:2000@9.44.44.4:5060 SIP/2.0 INVITE sip:2000@9.44.44.4:5060 SIP/2.0
……… ……….
Diversion: <sip:9.44.44.4>;privacy=off; Diversion: <sip:1234@9.44.44.4>;privacy=off;
reason=unconditional;screen=yes reason=unconditional;screen=yes
……... ……….
m=audio 6001 RTP/AVP 0 8 18 101 m=audio 32278 RTP/AVP 18 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
Enable Inbound SIP voice service voip

Profile feature sip
sip-profiles inbound
Configure Inbound
SIP Profile to add a
dummy user part
request INVITE sip-header Diversion modify “sip:” sip:1234@
Apply to incoming description Incoming/outgoing SP
Dial-peer voice-class sip profiles 700 inbound © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 84
SIP Profile Rule
Tagging
SIP Profile – Feature Overview
Existing Implementation
1. Insertion
 New rules are always inserted at the end, there was no way to insert a rule at the beginning or in between
existing rules.
 Only way to achieve this is by removing the complete profile and configuring it again in the desired order.
2. Deletion
 While deleting a rule User has to give complete no form of that rule.
 If there are duplicate rules, always 1st one is deleted.
3. Modification
 There is no direct way to modify an existing rule. User has to delete and reconfigure the profile.
4. Duplication
 If the same profile/rules applied more than once, then the rules are be duplicated
SIP Profile Tagging Enhancement
New rule tagging mechanism is being introduced
1. Insertion :
 New rules can be inserted at any position i.e at the beginning, at the end or in between existing rules
by specifying rule tag number.
2. Deletion :
 Rules can be deleted by giving no form of the rule with just the tag number.
3. Modification :
 Any of the existing rules can be modified by specifying the rule tag number.
4. Duplication :
 When a rule with an existing tag number is applied again, the rule will be over-written, without creating
any duplicate rules.
SIP Profile Tagging Enhancement – Cont’d
 A mechanism to automatically upgrade the legacy SIP Profile configurations to
the new rule format has been provided. The following exec CLI is being provided
to upgrade existing implementation
voice sip sip-profiles upgrade
 A mechanism to automatically downgrade the SIP Profile configurations with the
rule tags to non-rule format has been provided. The following exe CLI has been
provided for this purpose
voice sip sip-profiles downgrade
 Note: When SIP Profiles are configured in “rule <tag>” format and the IOS
version is migrated to a version which does not have this capability, then all the
SIP Profile configurations will be lost. Hence, it is advisable to execute voice
sip sip-profiles downgrade before IOS version migration.
SIP Profile Tagging – Configuration
• For tagging the rules, an additional option of “rule <tag>” has been provided
CUBE(config)#voice class sip-profiles 1
CUBE(config-class)#?
VOICECLASS configuration commands: The new
exit Exit from voice class configuration mode keyword “rule”
help Description of the interactive help system
no Negate a command or set its defaults
request sip request
response sip response “tag” to be
rule Specify the rule provided with
rule keyword
CUBE(config-class)#rule ?
<1-1073741823> Specify the rule tag
before The rule to be inserted before
CUBE(config-class)#rule 1 ?
request sip request
response sip response
SIP Profile Tagging – Configuration Cont’d
• For inserting a rule between two rules, “before” option has been provided
CUBE(config)#voice class sip-profiles 1 For inserting a rule
CUBE(config-class)#rule before ?
between two rules, the
<1-1073741823> Specify the rule tag
new before keyword
CUBE(config-class)#rule before 3 ? is being introduced
request sip request
response sip response
• If rule <tag> option is used to configure a SIP Profile rule, then this rule can
be deleted by specifying just the tag number instead of specifying the entire
rule configuration.
CUBE(config-class)#no rule before <tag>
Configuration Example
• For tagging the rules:

rule 1 request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”
rule 2 request INVITE sip-header Supported Add “Supported: ”
• For inserting a rule between two rules using “before” option:
rule before 2 request INVITE sip-header To Modify “(.*)” “\1;temp=abc”

before
option
rule 2 request INVITE sip-header To Modify “(.*)” “\1;temp=abc”
rule 3 request INVITE sip-header Supported Add “Supported: ” The new rule has
been inserted
between #1 and
#3
Configuration Example continued….
• Auto-Upgrade : Exec command - “voice sip sip-profiles upgrade”
• Suppose we have the following rules configured:
request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

request INVITE sip-header Supported Add “Supported: ”
request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”
• After auto upgrade, the rules will be automatically upgraded as follows:

rule 3 request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”
Configuration Example continued….
• Auto-Downgrade : Exec command - “voice sip sip-profiles downgrade”
• Suppose we have the following rules configured:

rule 3 request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”
• After auto downgrade, the rules will be automatically downgraded as follows:
request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

request INVITE sip-header Supported Add “Supported: ”
request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”
SIP Profile
Support for Non-
Standard
Headers
SIP Profile support for Non-Standard Headers
 Introducing support for adding/copying/removing/modifying non-
standard SIP headers using SIP profiles
 A new 'WORD' option has been added to the SIP Profiles CLI chain to
allow the user to configure any non-standard SIP Header
CUBE(config-class)#request INVITE sip-header ?
Accept-Contact SIP header Accept-Contact The new “WORD”
……. option for specifying
Via SIP header Via unsupported headers
WORD Any other SIP header name
WWW-Authenticate SIP header WWW-Authenticate
CUBE(config-class)#request INVITE sip-header WORD ?

ADD addition of the header
COPY Copy a header
MODIFY Modification of a header
REMOVE Removal of a header
CUBE(config-class)#request INVITE sip-header WORD ADD “MyCustomHeader : Hussain Ali”
Step 6: Execute the Test Plan
• Inbound and outbound Local, Long distance, International calls for G711 &
G729 codecs (if supported by provider)
• Outbound calls to information and emergency services
• Caller ID and Calling Name Presentation
• Supplementary services like Call Hold, Resume, Call Forward & Transfer
• DTMF Tests
• Fax calls – T.38 and fallback to pass-through (if option available)
Transitioning to Distributed SIP Trunking Model..
Re-purpose your existing Cisco voice gateway’s as CUBE at every branch
SIP/H323 Trunks
Standby
Media
• SIP Trunks pointing to CUBE
A CUBE
Active
at each branch
SIP SP-1
• Call Routing change on
CUBE
Enterprise CUBE with High CUCM
Campus Availability
MPLS • Provides the ability to

SIP SP- connect to different service
2
providers
PSTN is
CUBE/SRST
CUBE
now used • Can continue to use
only for centralized call control
emergency
calls over
CUBE/SRST
CUBE CUBE FXO lines
• CUBE & SRST can be co-
CUBE
located on the same platform
TDM PBX
Enterprise
Branch Offices
Agenda
CUBE Dial-Peers
Call Routing
Understanding Dial-Peer Matching Techniques:
LAN & WAN Dial-Peers
• LAN Dial-Peers – Dial-peers that are facing towards the IP PBX for sending
and receiving calls to & from the PBX. Should be bound to the LAN interface(s)
of CUBE to ensure SIP/RTP is sourced from the LAN IP(s) of the CUBE.
• WAN Dial-Peers – Dial-peers that are facing towards the SIP Trunk provider for
sending & receiving calls to & from the provider. Should be bound to WAN
interface(s) of CUBE.
Inbound LAN Dial-Peer Outbound Calls Outbound WAN Dial-Peer
A
CUCM SIP Trunk ITSP SIP Trunk
IP PSTN
CUBE
Inbound Calls
Outbound LAN Dial-Peer Inbound WAN Dial-Peer
Understanding Inbound Dial-Peer Matching Techniques
Priority
Inbound LAN Dial-Peer Outbound Calls
Filter dial-peers based
on incoming VRF if A IP
0 configured and then 1
CUCM SIP Trunk SP SIP Trunk
PSTN
CUBE
to 3 below
Exact Pattern Inbound Calls
Match Based on URI match
Inbound WAN Dial-Peer
Host Name/IP
1 of an incoming Address Received:
INVITE message INVITE sip:654321@10.2.1.1 SIP/2.0
User portion of
URI Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
Match based on Phone-number of
tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
2 Called Number tel-uri From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
Match based on CSeq: 1 INVITE
3 Calling number Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
4 Default Dial-Peer = 0 Subject: BRKUCC-2934 Session
Content-Type: application/sdp
Content-Length: 226
........
Priority Inbound LAN Dial-Peer Outbound Calls
voice class uri 1001 sip
host ipv4:10.1.1.1 A CUCM SIP Trunk SP SIP Trunk IP
voice class uri 2001 sip PSTN
host ipv4:10.2.1.1 CUBE
A Inbound Calls
incoming uri via 1001
1 B Received:
incoming uri request 2001 INVITE sip:654321@10.2.1.1 SIP/2.0
C dial-peer voice 3 voip Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
incoming uri to 2001 tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
From: "555" <sip:555@10.1.1.1:5060>;tag=1
D dial-peer voice 4 voip To: ABC <sip:654321@10.2.1.1:5060>
incoming uri from 1001
Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
dial-peer voice 5 voip Contact: sip:555@10.1.1.1:5060
2 incoming called-number 654321 Supported: timer
Max-Forwards: 70
dial-peer voice 6 voip Subject: BRKUCC-2934 Session
3 answer-address 555 Content-Type: application/sdp
Content-Length: 226
4 dial-peer voice 7 voip
destination-pattern 555
........
host ipv4:10.1.1.1
voice class uri 2001 sip A CUCM SIP Trunk SP SIP Trunk IP
PSTN
A dial-peer voice 1 voip Inbound Calls
1 B dial-peer voice 2 voip
Received:
incoming uri request 2001
C INVITE sip:654321@10.2.1.1 SIP/2.0
dial-peer voice 3 voip Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
D dial-peer voice 4 voip From: "555" <sip:555@10.1.1.1:5060>;tag=1
incoming uri from 1001 To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
2 incoming called-number 654321
Supported: timer
Max-Forwards: 70
3 answer-address 555
Subject: BRKUCC-2934 Session
Content-Length: 226
........
host ipv4:10.1.1.1
A CUCM SIP Trunk SP SIP Trunk IP
PSTN
incoming uri request 2001 Received:
INVITE sip:654321@10.2.1.1 SIP/2.0
incoming uri to 2001 From: "555" <sip:555@10.1.1.1:5060>;tag=1
incoming uri from 1001
Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
3 answer-address 555
Content-Length: 226
........

host ipv4:10.1.1.1
PSTN
voice class uri 2001 sip CUBE
host ipv4:10.2.1.1 Inbound Calls
A
dial-peer voice 1 voip Inbound WAN Dial-Peer
1 B dial-peer voice 2 voip Received:
incoming uri request 2001 INVITE sip:654321@10.2.1.1 SIP/2.0
From: "555" <sip:555@10.1.1.1:5060>;tag=1
incoming uri from 1001 Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
2 incoming called-number 654321 Supported: timer
Max-Forwards: 70
answer-address 555 Content-Type: application/sdp
Content-Length: 226
4 dial-peer voice 7 voip ........

incoming uri via 1001 Inbound WAN Dial-Peer
dial-peer voice 3 voip INVITE sip:654321@10.2.1.1 SIP/2.0
C incoming uri to 2001 Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
dial-peer voice 4 voip tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
D incoming uri from 1001 From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
dial-peer voice 5 voip CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
answer-address 555
Content-Length: 226
4 dial-peer voice 7 voip ........
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
2 incoming called-number 654321 Contact: sip:555@10.1.1.1:5060
Supported: timer
dial-peer voice 6 voip Max-Forwards: 70
3 answer-address 555 Subject: BRKUCC-2934 Session
Content-Length: 226
........
CUBE
host ipv4:10.2.1.1
A Inbound Calls
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
Supported: timer
3 answer-address 555 Max-Forwards: 70
4 dial-peer voice 7 voip Content-Length: 226
destination-pattern 555 ........
Understanding Outbound Dial-Peer Matching Techniques
Priority Outbound WAN Dial-Peer
Outbound Calls
Match Based on DPG,
0 DPPP, COR/LPCOR if A CUCM SIP Trunk SP SIP Trunk IP
configured Exact Pattern PSTN
match CUBE
Match Based on URI of
Host Name/IP Inbound Calls
incoming INVITE Address
1 message & carrier-id Outbound LAN Dial-Peer
User portion of
target URI Received:
Phone-number of INVITE sip:654321@10.2.1.1 SIP/2.0
Match based on Called tel-uri Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
2 Number & carrier-id tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
Exact Pattern
target match
From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
Match based on URI of Host Name/IP
Address Call-ID: 1-23955@10.1.1.1
3 an incoming INVITE CSeq: 1 INVITE
message User portion of Contact: sip:555@10.1.1.1:5060
URI Supported: timer
Match based on Called Phone-number of Max-Forwards: 70
4 number tel-uri Subject: BRKUCC-2934 Session
CSCua14749 – Carrier-id CLI not working on XE based Content-Length: 226
platforms ........
voice class uri 2001 sip Outbound Calls
host ipv4:10.2.1.1
1 dial-peer voice 1 voip PSTN
CUBE
destination uri 2001
Inbound Calls
carrier-id target orange
Outbound LAN Dial-Peer
2 destination-pattern 654321 Received:
carrier-id target orange INVITE sip:654321@10.2.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
voice class uri 2001 sip tag="cid:orange@10.1.1.1";branch=z9hG4bK-
host ipv4:10.2.1.1 23955-1-0
3 From: "555" <sip:555@10.1.1.1:5060>;tag=1
dial-peer voice 3 voip To: ABC <sip:654321@10.2.1.1:5060>
destination uri 2001 Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
dial-peer voice 4 voip Supported: timer
4 destination-pattern 654321 Max-Forwards: 70
Content-Length: 226
Outbound WAN Dial-Peer
Priority
Outbound Calls
host ipv4:10.2.1.1
1 dial-peer voice 1 voip CUBE
PSTN
destination uri 2001
Inbound Calls
Received:
2 destination-pattern 654321
INVITE sip:654321@10.2.1.1 SIP/2.0
carrier-id target orange Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
voice class uri 2001 sip From: "555" <sip:555@10.1.1.1:5060>;tag=1
host ipv4:10.2.1.1 To: ABC <sip:654321@10.2.1.1:5060>
3 Call-ID: 1-23955@10.1.1.1
destination uri 2001 Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
Content-Length: 226
........
Priority
voice class uri 2001 sip Outbound Calls
host ipv4:10.2.1.1
1 dial-peer voice 1 voip PSTN
destination uri 2001 CUBE
carrier-id target orange Inbound Calls
Received:
INVITE sip:654321@10.2.1.1 SIP/2.0
voice class uri 2001 sip tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
host ipv4:10.2.1.1 From: "555" <sip:555@10.1.1.1:5060>;tag=1
3 To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
CSeq: 1 INVITE
Supported: timer
Max-Forwards: 70
dial-peer voice 4 voip Subject: BRKUCC-2934 Session
4 destination-pattern 654321 Content-Type: application/sdp
Content-Length: 226
........
Priority Outbound Calls
1 dial-peer voice 1 voip CUBE
PSTN
destination uri 2001 Inbound Calls

2 destination-pattern 654321 Received:
carrier-id target orange INVITE sip:654321@10.2.1.1 SIP/2.0
voice class uri 2001 sip tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
host ipv4:10.2.1.1 From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
3 Call-ID: 1-23955@10.1.1.1
Supported: timer
dial-peer voice 4 voip Max-Forwards: 70
4 Subject: BRKUCC-2934 Session
destination-pattern 654321 Content-Type: application/sdp
Content-Length: 226
........
CUBE Advanced Call
Routing
Priority Exact Pattern
Outbound Calls
match
Match Based on URI of A SIP Trunk SP SIP Trunk
Host Name/IP IP PSTN
incoming INVITE message Address
1 & carrier-id target CUBE
User portion of URI
Inbound Calls
Phone-number of
Match based on Called tel-uri
Number & carrier-id target Received:
2 INVITE sip:654321@10.2.1.1 SIP/2.0
Exact Pattern
match
Match based on URI of an From: "555" <sip:555@10.1.1.1:5060>;tag=1
Host Name/IP
Address To: ABC <sip:654321@10.2.1.1:5060>
incoming INVITE message
3 Call-ID: 1-23955@10.1.1.1
User portion of URI CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
Phone-number of Supported: timer
Match based on Called tel-uri Max-Forwards: 70
number Subject: BRKUCC-2934 Session
4 Content-Type: application/sdp
Content-Length: 226
........
Additional Headers for Outbound Dial-Peer Matching
Match Based on URI of incoming INVITE message with Outbound Calls
or without carrier-id target
A SIP Trunk SP SIP Trunk
IP PSTN
Match based on CALLED Number with or without CUBE
carrier-id target
Inbound Calls
Match Based on FROM Header of incoming INVITE Outbound LAN Dial-Peer
Received:
Match Based on TO Header of incoming INVITE INVITE sip:654321@10.2.1.1 SIP/2.0
Match Based on VIA Header of incoming INVITE From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
Match based on DIVERSION Header of incoming CSeq: 1 INVITE
INVITE Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
Match based on REFERRED-BY Header of incoming Subject: BRKUCC-2934 Session
INVITE Content-Type: application/sdp
Content-Length: 226
........
Match based on CALLING Number
Introducing Outbound Dial-peer Provision Policy
• Flexibility to choose how outbound dial-peers are selected
• Dynamically set the priority based on Inbound dial-peers
• Additional Inbound Leg Headers for Outbound Dial-peer Matching
VIA FROM TO DIVERSION REFERRED-BY Calling Number
• User-defined outbound dial-peer provision policy on a per incoming call bases

1. A provision policy contains two rules to save the match attributes and its precedence
2. Up to two match attributes can be defined from each rule of a provision policy
3. A provision policy setup will be used to match outbound dial-peers once it is associated to an
incoming VoIP call.
• Outbound dial-peer match attributes

destination uri-via destination uri-diversion destination e164-pattern-map
destination uri-to destination uri-referred-by destination uri

destination uri-from destination calling destination-pattern
Dial-peer Provision Policy Configuration
1. Define Voice Class Dial-peer Provision Policy
CUBE(config)#voice class dial-peer provision-policy <tag>

CUBE(config-class)# description “Match outbound dial-peer based on this Criteria”
CUBE(config-class)#preference ?
<1-2> Preference order
CUBE(config-class)#preference 1 first-attribute second-attribute
called Match called number calling Match calling number
carrier-id Match carrier id diversion Match diversion uri
from Match from uri to Match to uri
uri Match destination uri via Match via uri
referred-by Match referred-by uri
voice class dial-peer provision-policy <tag>

description ‘Match outbound dial-peer based on criteria defined here’
preference 1 first-attribute second-attribute
preference 2 first-attribute second-attribute
Dial-peer Provision Policy Configuration – Cont’d
2. Associate Voice Class Provision Policy to an Incoming Dial-peer
description Inbound Dial-peer
destination provision-policy <tag>
3. Define Outbound Dial-peer with match patterns based on attributes in a policy
CUBE(config)#dial-peer voice 2 voip

CUBE(config-dial-peer)#description Outbound Dial-peer
CUBE(config-dial-peer)#destination ?
calling Match destination calling number
e164-pattern-map Configure voice class to match destination e164-pattern-map
uri Configure voice class to match destination URI
uri-diversion voice class uri to match sip diversion header
uri-from voice class uri to match sip from header
uri-referred-by voice class uri to match sip referred-by header
uri-to voice class uri to match sip to header
uri-via voice class uri to match sip via header
Dial-peer Provision Policy Configuration For Your
– Cont’d Reference
Configuring a match command for an outbound dial-peer according to the provision policy rule
attribute configured
Provision Policy Rule Attribute Outbound Dial-peer Match command

Called destination-pattern pattern
destination e164-pattern-map pattern-map-class-id
Calling destination calling e164-pattern-map pattern-map-class-id
carrier-id carrier-id target
Uri destination uri uri-class-tag
Via destination uri-via uri-class-tag
To destination uri-to uri-class-tag
from destination uri-from uri-class-tag
diversion destination uri-diversion uri-class-tag
referred-by destination uri-referred-by uri-class-tag
Dial-peer Provision Policy Example – Match on FROM
voice class uri 10 sip dial-peer voice 20201 voip
user-id 555 description "Outbound dialpeer based on FROM"
destination uri-from 10
host 10.2.1.1 dial-peer voice 20202 voip
description "Outbound dialpeer based on TO"
dial-peer voice 1000 voip destination uri-to 20
description "Inbound dialpeer. Choose outbound based on DPP 10"
destination provision-policy 10 dial-peer voice 10000 voip
description "Outbound dialpeer based on FROM and TO"
dial-peer voice 2000 voip destination uri-from 10
description "Inbound dialpeer. Choose outbound based on DPP 20" destination uri-to 20
destination provision-policy 20
voice class dial-peer provision-policy 10 Received:

description "Match outbound dialpeer on both From AND To Headers" INVITE sip:654321@10.2.1.1 SIP/2.0
preference 1 from to Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
! tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
voice class dial-peer provision-policy 20 From: "555" <sip:555@10.1.1.1:5060>;tag=1
description "Match outbound DP based on FROM first, if no match To: ABC <sip:654321@10.2.1.1:5060>
select based on TO" Call-ID: 1-23955@10.1.1.1
preference 1 from CSeq: 1 INVITE
preference 2 to Contact: sip:555@10.1.1.1:5060
........

CSeq: 1 INVITE
preference 1 from
Contact: sip:555@10.1.1.1:5060
preference 2 to
........

........
Dial-peer Provision Policy Example – Match on TO
voice class uri 20 sip shutdown
host 10.2.1.1
dial-peer voice 1000 voip description "Outbound dialpeer based on TO"
dial-peer voice 2000 voip description "Outbound dialpeer based on FROM and TO"
description "Inbound dialpeer. Choose outbound based on DPP 20" destination uri-from 10
destination provision-policy 20 destination uri-to 20

........
Dial-peer Provision Policy Example – Match on TO
voice class uri 20 sip shutdown
host 10.2.1.1
dial-peer voice 1000 voip description "Outbound dialpeer based on TO"
dial-peer voice 2000 voip description "Outbound dialpeer based on FROM and TO"
description "Inbound dialpeer. Choose outbound based on DPP 20" destination uri-from 10
destination provision-policy 20 destination uri-to 20

........
Dial-peer Provision Policy Example – Match on FROM & TO

.....

host 10.2.1.1
destination uri-to 20
description "Inbound dialpeer. Choose outbound based on DPP 10" dial-peer voice 10000 voip
destination provision-policy 10 description "Outbound dialpeer based on FROM and TO"
destination uri-to 20

Destination Dial-peer Group
• Allows grouping of outbound dial-peers based on an incoming dial-peer, reducing
existing outbound dial-peer provisioning requirements
• Eliminates the need to configure extra outbound dial-peers that are sometimes
needed as workarounds to achieve desired call routing outcome
• Multiple outbound dial-peers are saved under a new “voice class dpg <tag>”. The
new “destination dpg <tag>” command line of an inbound voip dial-peer
can be used to reference the new dpg (dial-peer group)
• Once an incoming voip call is handled by an inbound voip dial-peer with an
active dpg, dial-peers of a dpg will then be used as outbound dial-peers for an
incoming call
• The order of outgoing call setups will be the sorted list of dial-peers from a dpg,
i.e, the destination-patterns of the outgoing dial-peers is not relevant for selection
Destination Dial-peer Group Configuration
voice class dpg 10000 dial-peer voice 1001 voip
description Voice Class DPG for SJ destination-pattern 8888
dial-peer 1001 preference 1 session protocol sipv2
dial-peer 1002 preference 2 session target ipv4:10.1.1.1
dial-peer 1003 !
! dial-peer voice 1002 voip
dial-peer voice 100 voip destination-pattern 8888
description Inbound DP session protocol sipv2
incoming called-number 1341 session target ipv4:10.1.1.2
destination dpg 10000 !
session target ipv4:10.1.1.3
1. Incoming Dial-peer is first
matched 2. Now the DPG associated with
the INBOUND DP is selected
Outbound Dial-Peer Matching Criteria Summary
Outbound Calls
Match Based on DPG,
0 DPPP, COR/LPCOR if A CUCM SIP Trunk SP SIP Trunk
IP
configured Exact Pattern CUBE PSTN
match
Match Based on URI of Inbound Calls
Host Name/IP
incoming INVITE Address Outbound LAN Dial-Peer
1 message & carrier-id
User portion of
target Received:
URI
INVITE sip:654321@10.2.1.1 SIP/2.0
Phone-number of
Match based on Called tel-uri
2 Number & carrier-id tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
target Exact Pattern From: "555" <sip:555@10.1.1.1:5060>;tag=1
match To: ABC <sip:654321@10.2.1.1:5060>
Match based on URI of Host Name/IP Call-ID: 1-23955@10.1.1.1
Address CSeq: 1 INVITE
3 an incoming INVITE
message User portion of
Contact: sip:555@10.1.1.1:5060
URI Supported: timer
Match based on Called Phone-number of
Max-Forwards: 70
4 number tel-uri
CSCua14749 – Carrier-id CLI not working on XE based
Content-Length: 226
platforms ........
Destination Server Group
• Supports multiple destinations (session targets) be defined in a group and applied to
a single outbound dial-peer
• Once an outbound dial-peer is selected to route an outgoing call, multiple
destinations within a server group will be sorted in either round robin or preference
[default] order
• This reduces the need to configure multiple dial-peers with the same capabilities but
different destinations. E.g. Multiple subscribers in a cluster
voice class server-group 1 dial-peer voice 100 voip
hunt-scheme {preference | round-robin} description Outbound DP
ipv4 1.1.1.1 preference 5 destination-pattern 1234
ipv4 2.2.2.2 session protocol sipv2
ipv4 3.3.3.3 port 3333 preference 3 codec g711ulaw
ipv6 2010:AB8:0:2::1 port 2323 preference 3 dtmf-relay rtp-nte
ipv6 2010:AB8:0:2::2 port 2222 session server-group 1
* DNS target not supported in server group
Multiple Destination-Patterns Under Same
Outbound Dial-Peer voice class e164-pattern-map 100
e164 919200200.
e164 510100100.
e164 408100100. Provides the ability to combine multiple
Site A (919)200-2000
destination-patterns targeted to the
dial-peer voice 1 voip same destination to be grouped into a
Site B (510)100-1000
destination e164-pattern-map 100 single dial-peer
codec g729r8
Site C (408)100-1000 session target ipv4:10.1.1.1 Up to 5000 entries in a text file
G729 Sites A SIP Trunk SP SIP Trunk IP PSTN

CUBE
Site A voice class e164-pattern-map 200 ! This is an example of the contents of

(919)200-2010
url flash:e164-pattern-map.cfg E164 patterns text file stored in
flash:e164-pattern-map.cfg
Site B (510)100-1010 dial-peer voice 1 voip
destination e164-pattern-map 200 9192002010
Site C (408)100-1010
codec g711ulaw 5101001010
4081001010
G711 Sites
Multiple Incoming Patterns Under Same
Incoming Dial-peer
voice class e164-pattern-map 300
e164 919200200. Provides the ability to combine multiple
e164 510100100. incoming called OR calling numbers on
Site A (919)200-2000 e164 408100100. a single inbound voip dial-peer, reducing
the total number of inbound voip dial-
Site B (510)100-1000 peers required with the same routing
description Inbound DP via Calling
incoming calling e164-pattern-map 300 capability
Site C (408)100-1000 codec g729r8
Up to 5000 entries in a text file
G729 Sites A SIP Trunk SP SIP Trunk IP PSTN

CUBE
Site A voice class e164-pattern-map 400 ! This is an example of the

(919)200-2010 contents of E164 patterns text
url flash:e164-pattern-map.cfg
file stored in flash:e164-
Site B (510)100-1010
dial-peer voice 2 voip pattern-map.cfg
description Inbound DP via Called
Site C (408)100-1010 9192002010
incoming called e164-pattern-map 400 5101001010
codec g711ulaw 4081001010
G711 Sites
URI Based Dialing Overview
INVITE sip:user@xyz.com
INVITE sip:user@xyz.com
SBC
CUBE
Enterprise
Enterprise xyz.com
abc.com
Existing CUBE behavior:

• In CUBE URI based routing (user@host), the “user” part must be present and must be an
E164 number
• The outgoing SIP ‘Request-URI’ and ‘To header URI’ are always set to the session target
information of the outbound dial-peer
• For Req-URIs with same user name e.g. hussain@cisco.com, hussain@google.com, two
different dial-peers are configured with the respective session targets
URI Based Dialing Enhancement – For Your
Reference
URI Pass Through
INVITE sip:1234@cisco.com CUBE
dial-peer voice 100 voip INVITE sip:1234@cisco.com

incoming uri request 1 dial-peer voice 200 voip
session protocol sipv2 destination uri 1
voice-class sip call-route url session protocol sipv2
voice-class sip requri-passing

host cisco.com
• By default, the host portion is replaced with the session target value of the matched
outbound dial-peer
• Enhancement : Outgoing INVITE has same request URI as received in Incoming INVITE.
This can be achieved by configuring ‘requri-passing’ in the outgoing dial-peer or
globally.
• Allows for peer-to-peer calling between enterprises using URIs
Reference
‘User’ portion non-E164 format
INVITE sip:hussain@cisco.com CUBE
dial-peer voice 100 voip INVITE sip:hussain@10.1.1.1


host cisco.com
• By default, alphanumeric/non-E164 users were not allowed

• Enhancement : User part in Incoming INVITE Req-URI can be of Non-E164 format. e.g.
sip:hussain@cisco.com. Outgoing INVITE will have user portion as it is received i.e.
‘hussain’ (unless SIP profiles are applied).
• Useful for video calls
‘User’ portion absent Reference
INVITE sip:cisco.com CUBE
dial-peer voice 100 voip INVITE sip:cisco.com

voice-class sip requri-passing

host cisco.com
• By default, call is rejected with “400 Bad Request”
• Enhancement : Incoming INVITE with no user portion (e.g. sip:cisco.com.) is supported. Dial-peer
matching will happen based on ‘host’ portion. Outgoing INVITE Req-URI will not have any user portion in
this case (unless sip-profiles are applied).
• If user portion is present in incoming INVITE ‘To header’, it is retained in outgoing INVITE ‘To Header’
• If ‘voice-class sip requri-passing’ is not configured, INVITE will go out as sip:10.1.1.1
• REFER and 302, both consume and pass-through cases supported as well
URI Based Dialing Enhancement –
Deriving Target host from Incoming INVITE Req-URI
INVITE sip:hussain@cisco.com CUBE

INVITE sip:hussain@10.1.1.1
session target sip-uri

user hussain
user .*
• For different hosts with the same ‘user’, multiple outgoing dial-peers had to be configured
• Enhancement : To support URIs with the same user portion but with different domains, only one
dial-peer per can be configured. Outgoing dial-peer needs to be configured with ‘session
target sip-uri’ instead of regular session target configuration. This will trigger DNS
resolution of the domain of incoming INVITE Req-URI and dynamically determine the session
target IP.
Media Manipulation
Audio Transcoding and Transrating
iLBC, iSAC,
Speex Enterprise IP Phones:
SP VoIP VoIP G.711, G.729 20 ms,
CUBE G.722
G.729 30 ms
• Transcoding (12.4.20T) • Transcoding: G.711, G.723.1, G.726, G.728,

G.729/a, iLBC, G.722
• One voice codec to any other codec E.g. iLBC-G.711 or iLBC- • Transrating: G.729 20ms ↔ 30ms (AT&T)
G.729
• CUCM 7.1.5 or later supports universal Transcoding Packetization
Supported Codecs
(ms)
• Transrating (15.0.1M) G.711 a-law 64 Kbps 10, 20, 30
• Different packetizations of the same codec
G.711 µlaw 64 Kbps 10, 20, 30
• E.g. G.729 20ms to G.729 30ms
• Support for SIP-SIP calls G.723 5.3/6.3 Kbps 30, 60
• No sRTP support with transrating
G.729, G.729A, G.729B, 10, 20, 30, 40, 50,
dial-peer voice 2 voip !Call volume (gain/loss) adjustment G.729AB 8 Kbps 60
codec g729r8 bytes 30 fixed-bytes dial-peer voice 2 voip
audio incoming level-adjustment x G.722—64 Kbps 10, 20, 30
audio outgoing level-adjustment y
Configuration for SCCP based Transcoding For Your
(ISR-G2/4K) Reference
1. Enabling dspfarm services 3. SCCP configuration
under voice-card
sccp local GigabitEthernet0/0
voice-card 1 sccp ccm <CUBE_internal_IP> identifier 1 version 7+
dspfarm ! Only ISR G2
dsp services dspfarm sccp
sccp ccm group 1
2. telephony-service configuration associate ccm 1 priority 1
telephony-service associate profile 1 register CUBE-XCODE
sdspfarm units 1
sdspfarm transcode sessions 128 4. dspfarm profile configuration
sdspfarm tag 1 CUBE-XCODE
max-ephones 10 dspfarm profile 1 transcode
max-dn 10 codec g711ulaw
ip source-address codec g711alaw
<CUBE_internal_IP> port 2000 codec g729r8
maximum sessions 10
associate application SCCP
Configuration for LTI based Transcoding
(ISR-G2/4K & ASR)
1. Enabling dspfarm services
under voice-card
voice-card 0/1 Feature Notes:
dspfarm ! Only ISR G2 • This uses Local Transcoding Interface to
dsp services dspfarm communicate between CUBE and DSPs
• Also available on ISR-G2 starting IOS 15.2.3T
2. dspfarm profile configuration • Can only be used if CUBE invokes the DSP
for media services
dspfarm profile 1 transcode
codec g711ulaw • CUCM cannot invoke DSPs using this LTI
codec g711alaw interface
codec g729abr8
codec g729ar8
codec ilbc
maximum sessions 100
associate application CUBE
External/PSTN Call
Recording
External/PSTN Call Recording Options (no DSPs needed for Call-
Recording on CUBE)
• CUBE Controlled (Dial-peer based ORA)
• Based on Open Recording Architecture, metadata sent in Cisco Proprietary format from CUBE to Recorder
• Dial-peer controlled, IP-PBX independent
• Source of recorded media (RTP only) is always CUBE (External calls only). For SRTP-RTP calls, apply
media forking CLI on the RTP leg only.
• Records both audio and video calls and supported with CUBE HA (Inbox or box-2-box)
• CUBE Controlled (Dial-peer based SIPREC)

• Based on SIPREC (RFC 6341, 7245, Metadata-draft-17, Protocol-draft-15), CUBE sends metadata in XML
format
• Dial-peer controlled, IP-PBX independent
• Source of recorded media (RTP only) is always CUBE (External calls only). For SRTP-RTP calls, apply
media forking CLI on the RTP leg only.
• Records both audio and video calls and supported with CUBE HA (Inbox or box-2-box)
• CUCM NBR (Network Based Recording)

• CUCM Controlled, requires CUCM 10+ and UC Services API be enabled on CUBE
• Recording triggered by CUCM and this mode records only Audio calls
• Source of Recorded Media can be CUBE or Endpoint (BiB), CUBE as source desired for PSTN calls
CUBE Controlled Recording Option – Media Forking
Dial-peer based – Open Recording Architecture (ORA)
• CUBE sets up a stateful SIP session
Cisco Search/Play demo app or Partner with MediaSense server
Application • After SIP dialog established, CUBE
forks the RTP and sends it for
MediaSense to record
Cisco MediaSense MediaSense
(authentication disabled w/o UCM) • With XE 3.10.1, Video calls supported
SIP
and CUBE HA for audio calls
Cisco Proprietary Metadata

A SIP SIP
SP SIP
CUBE
RTP RTP
media class 9 dial-peer voice 950 voip
recorder parameter
• Call agent media-recording 950
description dial-peer pointing to MediaSense
destination-pattern 9999 ! Dummy
independent Needs to
match
• Configured on a per dial-peer voice 901 voip session transport tcp
Dial-peer level to fork description dial-peer that needs to be forked session target ipv4:<Mediasense_IP>
session protocol sipv2 ! Bind on this DP mandatory
RTP
media-class 9
Audio only Media Forking for an Audio/Video Call
CUBE Controlled Recording – Dial-peer based
• MediaSense 10+ or any recording server can decline the video stream and choose to have only the audio
stream recorded by setting the video port as 0 in the SDP answer
• CUBE can be configured to offer only audio streams to be recorded even if the call that is being recorded
is an audio/video call
• Support for forwarding any 3rd
MediaSense
party IP PBX GUID to the
SIP recording server by use of SIP
Profiles
Cisco Proprietary Metadata
A SIP SIP
SP SIP
CUBE
RTP RTP
media profile recorder 100 dial-peer voice 950 voip

media-type audio description dial-peer pointing to MediaSense
media-class 1 media-recording 950 destination-pattern 9999 ! Dummy
recorder profile 100 session protocol sipv2
dial-peer voice 1 voip session transport tcp
description dial-peer that needs to be forked session target ipv4:<Mediasense_IP>
session protocol sipv2 ! Bind on this DP mandatory
media-class 1 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 147
CUBE Controlled Recording Option - SIPREC
Dial-peer based – SIPREC Standard
• SIP is used as a protocol between CUBE and the recording server, where CUBE acts as the recording
client and any third party recorder acts as the recording server
• Along with SDP, metadata information is passed by CUBE to the recording server in XML format
SIPREC Compliant Recorder Recorder • Metadata includes the

communication session details of
audio or video calls and also
identifies the participants of the call
XML Metadata
A SIP SIP
SP SIP
CUBE
RTP RTP
media class 9 dial-peer voice 950 voip

• SIP Profiles can recorder parameter siprec description dial-peer pointing to MediaSense
media-recording 950 destination-pattern 9999 ! Dummy
additionally be used to Needs to
forward 3rd party IP PBX dial-peer voice 901 voip match
session transport tcp
Call Identifier to the description dial-peer that needs to be forked session target ipv4:<Mediasense_IP>
Recorder for Correlation session protocol sipv2 ! Bind on this DP mandatory
media-class 9
CUCM (10.X or later) Controlled Recording
UC Services API – Network Based Recording
3.
1. Enable HTTP on IOS

Gateway/CUBE Recording ip http server
Enabled http client persistent
2. Enable the API on IOS

4. uc wsapi
1. 2. source-address [IP_Address_of_CUBE]
3. Enable XMF service within the API

5. provider xmf
remote-url 1 http://CUCM:8090/ucm_xmf
no shutdown
[1] – [3]: An external call is answered by user with IP phone

[4] – [5]: CUCM sends forking request over HTTP to CUBE, which
sends two media streams towards the Recording Server
• Recording not preserved on failover in CUBE HA
• Selective Recording, Mobile/SNR/MVA Calls
• Recording Call Preservation
Now Supports Inbound CVP (Survivability.tcl) Call Recording

[IOS 15.6(1)T, IOS-XE 3.17] LTRCOL-2310 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 149
Call Admission Control
Call Admission Control at the edge...
CUBE provides various CAC mechanisms to safeguard your network from SIP based attacks and to enforce policies based on:
• Total calls • Maximum connections per destination
• CPU & Memory • Dial-peer or interface bandwidth
• Call spike detection
Total Calls, Call Spike call spike call-number [steps

High Water Mark Detection number-of-steps size milliseconds]
CPU, Memory call spike 10 steps 5 size 200
Low Water Mark
CUBE CUBE
call threshold global [total/mem/cpu] calls low xx high yy If a call spike is detected,
call treatment on reject calls
Max Calls per Max Bandwidth Call #3 Rejected

Call #3
Destination Rejected by based by CUBE
Call #1 CUBE Call #1 – 80Kbps
Call #2 Call #2 – 80 Kbps
Call #3 CUBE Call #3 – 80 Kbps
CUBE

max-conn 2 max-bandwidth 160

Low Water Mark
CUBE CUBE

Call #3
CUBE

Multiple Non-
Authenticated SIP
Trunks on a CUBE
Non-Authenticated SIP Trunking to more than one
Service Provider
SIP SP-1 Large enterprises are deploying more
(10.10.10.2)
than one SIP Trunk provider for:
A
Active • Alternate call routing
CUBE SIP SP-2
(20.20.20.2)
• Load balancing
Enterprise
Campus
MPLS
interface loopback1 dial-peer voice 20 voip
SIP SP-1’s ip address 10.10.10.1 255.255.255.0 description “Secondary path to SIP SP-2”
network destination-pattern 91[2-9]..[2-9]......
interface loopback2 session protocol sipv2
SIP SP-2’s
SRSTip address 20.20.20.1 255.255.255.0 session target ipv4:20.20.20.2
network preference 2
dial-peer voice 10 voip voice-class sip options-keepalive
description “Primary path to SIP SP-1” voice-class sip bind control source-interface loopback2
CME
destination-pattern 91[2-9]..[2-9]...... voice-class sip bind media source-interface loopback2
session target ipv4:10.10.10.2 TDM PBX NOTE: Dual SPs can be used for outbound calls, but to
Enterprisesip options-keepalive
voice-class be utilised for inbound calls, arrangements between
Branch Offices
voice-class sip bind control source-interface loopback1 SPs required
voice-class sip bind media source-interface loopback1 LTRCOL-2310 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 154
Multiple
Authenticated/Register
ed SIP Trunks on a
CUBE
Multiple Instances of SIP-UA on a CUBE
Existing Implementation, prior to IOS 15.6(2)T and IOS-XE 16.3.1
• CUBE Configuration generally consists of
• Global – Everything under voice service voip
• Call Routing – Dial-peers (Any configuration under dial-peers always overrides Global config)
• SIP User Agent Config – Everything under sip-ua, applicable globally on the platform
• No provision to configure specific bind/credentials/outbound proxy for

different registrar
• No provision to configure specific configs (e.g. timers, retry) for
different tenants
• Unable to handle authentication challenge for more than one trunk that
have the same SIP realm
Introducing Tenants on CUBE
• Every Registrar/User Agent/ITSP connected to CUBE can be

considered a Tenant to CUBE
• Allows specific global configurations (CLI under sip-ua) for multiple
tenants such as specific SIP Bind for REGISTER messages
• Allows differentiated services for different tenants
“Voice class Tenant” Overview
• Most configs under “sip-ua” and “voice service voip” added in “voice class tenant <tag>”,
e.g. Registrar and Credentials CLI under tenant using different bind and outbound proxy
Prior to Multi Tenancy
sip-ua
registrar 1 ipv4:60.60.60.60:9051 expires 3600 Global OB Proxy and Bind
registrar 2 ipv4:70.70.70.70:9052 expires 3600
credentials username aaaa password 7 06070E204D realm aaaa.com
credentials username bbbb password 7 110B1B0715 realm bbbb.com E164 - aaaa Registrar - 1
voice service voip
outbound-proxy ipv4:10.64.86.35:9057
bind control source-interface GigabitEthernet0/1 E164 - bbbb Registrar - 2
With Voice Class Tenant (Multi-Tenancy)

voice class tenant 1
registrar 1 ipv4:60.60.60.60:9051 expires 3600 OB Proxy 1 & Bind-1
credentials username aaaa password 7 06070E204D realm aaaa.com E164 - aaaa Registrar - 1
bind control source-interface GigabitEthernet0/0
OB Proxy 2 & Bind-2
credentials username bbbb password 7 110B1B0715 realm bbbb.com E164 - bbbb Registrar - 1
Authenticating Multiple trunks with same Realm
• Requirement : To register two different authenticated numbers/usernames to different
registrars, but with the same realm
• Prior to IOS 15.6(2)T / IOS-XE 16.3.1, CUBE could register multiple trunks only with
different realms as the “authentication” command only accepted different realms. If the
realms were the same, it just overwrote the username and password
• Now each credential/authentication pair can be defined under its own voice class tenant
so that the same realm can be used for authentication
With Voice Class Tenant (Multi-Tenancy)

registrar 1 dns:cisco.com expires 3600
credentials number +1234 username aaaa@cisco password 0 AAAA realm cisco.com
authentication username aaaa@cisco password 7 AAAA realm cisco.com
registrar 1 dns:cisco.com expires 3600
credentials number +6789 username bbbb@cisco password 0 BBBB realm cisco.com
authentication username bbbb@cisco password 7 BBBB realm cisco.com
Configuring Voice Class Tenant
• Configure voice class tenant
voice class tenant 1 Add new voice class tenant
credentials username aaaa password 7 06070E204D realm aaaa.com
credentials number bbbb username bbbb password 7 110B1B0715 realm bbbb.com
bind media source-interface GigabitEthernet0/0
copy-list 1
early-offer forced
• Apply tenant to the desired dial-peer

session target ipv4:10.64.86.35:9051
session transport udp
voice-class sip tenant 1 Apply Tenant to a Dial-peer
Multi-VRF Aware
CUBE
Introduction to Multi-VRF
ATT
VZN
SPT
• Virtual Routing and Forwarding (VRF) is an IP technology that allows for multiple
instances of a routing table to coexist on the same router at the same time as
opposed to a single global route table, allowing for multiple virtual networks within a
single network entity to isolate between media and data virtual networks
• Multi-VRF allows for the use of only one router to accomplish the tasks that
multiple routers usually perform
• Prior to IOS 15.6(2)T / IOS-XE 16.3.1, CUBE only supports a single VRF for Voice
[voice vrf vrfname]
Multi-VRF and CUBE Enterprise
Multi-VRF Aware Call Routing on CUBE
• CUBE allows intra and inter VRF routing of voice and video calls without the need of Route
Leaks improving security at the network level
• Overlapped IP addressing and Dial Plan with Multi VRF feature provides seamless integration
of networks
• Show command outputs enhanced to display the VRF ID’s for active voice and video calls
• Provision to configure RTP port ranges for each VRF and allocation of Local RTP ports based
upon VRF. Listen sockets on UDP, TCP and TLS transports based on the VRF
Multi-VRF Design Considerations
• It is strongly recommended to deploy CUBE 11.5.2 or later [IOS 15.6(3)M, IOS-
XE 16.3.1] for Multi-VRF aware call routing as inbound dial-peers are filtered
based on the incoming VRF FIRST and then followed by the regular inbound
dial-peer matching. This ensures no potential routing issues will exist for
incoming INVITES or any out-of-dialog messages such as REGISTER,
OPTIONS, NOTIFY, etc
• Dial-peer bind statements are mandatory as the VRF association to a dial-peer
is based upon the interface sip bind and both Control and Media on a dial-peer
has to bind with the same VRF
• Whenever global sip bind interface associated with a VRF is
added/modified/removed, user should restart the sip services under
“voice service voip  sip  call service stop/no call service stop”
• Default incoming dial-peer (dial-peer 0) match is not supported with VRF
Priority
Inbound LAN Dial-Peer Outbound Calls
Filter dial-peers based
on incoming VRF if A
0 configured and then 1
CUCM SIP Trunk SP SIP Trunk
IP
CUBE PSTN
to 3 below
Exact Pattern Inbound Calls
match Inbound WAN Dial-Peer
Match Based on URI
Host Name/IP
1 of an incoming Address Received:
INVITE message INVITE sip:654321@10.2.1.1 SIP/2.0
User portion of Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
URI
Match based on tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
Phone-number of
2 Called Number tel-uri
From: "555" <sip:555@10.1.1.1:5060>;tag=1
To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
Match based on CSeq: 1 INVITE
3 Calling number
Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
Default Dial-Peer = 0 Subject: BRKUCC-2934 Session
4 Content-Type: application/sdp
Content-Length: 226
........
Multi-VRF Design Considerations – Cont’d
• Whenever destination server group is used with VRF, ensure that the server
group should have the candidates (i.e. session targets) belonging to the same
network as that of sip bind on the dial-peer where the server-group is
configured. Sample Configuration in notes section below
• Dial-peer group feature or COR (Class of Restriction) lists can be used to
restrict call routing to the same or group of VRFs (e.g. Overlapping Dial
plans)
• The DSP resources are a global pool and not reserved on a per VRF basis. It is
used on a first come first serve basis
For Your
Multi-VRF Feature Restrictions Reference
• CUBE + CME co-located with VRF and TDM-SIP gateway are not supported
• IPV6 with VRF is not supported on CUBE. Only IPv4 is supported with VRF
• Multi-VRF calls across CUBE are supported in SIP-SIP flow-through mode only and not
supported in flow-around mode. Media Anti-trombone is not supported with VRF
• Legacy global voice vrf and Multi VRF doesn’t co-exist. Customers using global voice vrf
have to remove the CLI in order to use Multi VRF feature
• UC Services API (CUCM NBR Recording) is not VRF aware. Works globally for all call
recordings and will not separate the call notification on a per VRF basis
• With Single/Multi VRF configured, DNS request will be at global (i.e. no vrf is associated with
the DNS request)
CUBE Multi VRF - Basic Configuration
Gig0/0/0 Gig0/0/1
VRF 1 VRF 2
CUBE
ip vrf vrf1 ip vrf vrf2

rd 1:1 rd 2:2
interface GigabitEthernet0/0/0 interface GigabitEthernet0/0/1

ip address 7.44.44.13 255.255.0.0 ip address 6.44.44.13 255.255.0.0
ip vrf forwarding vrf1 ip vrf forwarding vrf2
voice-class sip bind all interface GigE0/0/0 voice-class sip bind all interface GigE0/0/1
1. Configure VRF
2. Apply VRF under the interface/sub-interface
3. Bind the VRF associated interface to the dial-peer (VRF association by dial-peer bind CLI)
• Up to 54 different VRFs supported in 15.6(3)M and IOS-XE 16.3.1 or later releases
CUBE Multi VRF – Inbound dial-peer match
INVITE INVITE
VRF 1 VRF 2
sip:2000@7.44.44.13 CUBE
sip:2000@6.44.44.13

rd 1:1 rd 2:2
! !
ip vrf forwarding vrf1 ip vrf forwarding vrf2
! !
incoming called-number 2000 incoming called-number 2000
 Inbound match based on VRF where SIP INVITE received

 For VRF 1, dial-peer 100 is matched
 For VRF 2, dial-peer 200 is matched
CUBE Multi VRF – Inter/Intra VRF Routing
INVITE sip:3000@7.44.44.13 INVITE sip:3000@6.44.44.13
VRF 1 VRF 2
CUBE

rd 1:1 rd 2:2

ip vrf forwarding vrf1 Inter VRF ip vrf forwarding vrf2
dial-peer voice 1 voip Routing dial-peer voice 2 voip
VRF1
VRF2
destination-pattern 2000 destination-pattern 3000
session-target ipv4: 10.1.1.1 session-target ipv4:10.2.2.2
VRF2
incoming called-number 2000 Intra VRF incoming called-number 3000
Routing LTRCOL-2310 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 171
CUBE Multi VRF – Routing w/ Overlapped Dial Plan
INVITE INVITE
sip:2000@10.1.1.1 sip:2000@10.1.1.1
INVITE INVITE
sip:2000@7.44.44.13 sip:2000@6.44.44.13

interface GigabitEthernet0/0/0 Route Inter or interface GigabitEthernet0/0/1
ip vrf forwarding vrf1 Intra VRF calls ip vrf forwarding vrf2
based on
voice class dpg 100 voice class dpg 200
dial-peer 11 preference 1
outbound
dial-peer 22 preference 1
dial-peer groups
destination dpg 100 VRF1 VRF2 destination dpg 100
session-target ipv4:10.1.1.1 VRF1 session-target ipv4:10.2.2.2
CUBE Multi VRF – Call Routing w/ Overlapped IP
INVITE INVITE
sip:1000@10.1.1.1 sip:2000@10.1.1.1
INVITE INVITE
sip:1000@7.44.44.13 sip:2000@7.44.44.13

interface GigabitEthernet0/0/0 Overlapped interface GigabitEthernet0/0/1
ip vrf forwarding vrf1 local IP
ip vrf forwarding vrf2
destination dpg 100 destination dpg 200
VRF1 VRF2 voice class dpg 200
voice class dpg 100
dial-peer 11 preference 1 dial-peer 22 preference 1
session-target ipv4:10.1.1.1 session-target ipv4:10.1.1.1
CUBE Multi Tenant Configuration Example
VRF 1 VRF 2
CUBE

rd 2:2
rd 1:1

ip address 6.44.44.13 255.255.0.0
ip address 7.44.44.13 255.255.0.0
voice class tenant 1 voice class tenant 2

registrar ipv4:10.2.2.5 expires 3600
registrar ipv4:10.1.1.5 expires 3600
credentials username vrf1 password 7 104F081804 realm vrf2.com
credentials username vrf1 password 7 104F081804 realm vrf1.com
max-forwards 58
max-forwards 57
retry invite 5
retry invite 7
timers trying 200
timers trying 100
bind all source-interface GigabitEthernet0/0/1
bind all source-interface GigabitEthernet0/0/0

voice-class sip bind all interface GigabitEthernet0/0/1
incoming called-number 3000
incoming called-number 2000
voice class sip tenant 2
voice class sip tenant 1

session-target ipv4: 10.2.2.2
session-target ipv4: 10.1.1.1
voice-class sip tenant 2
voice-class sip tenant 1
High Availability
CUBE High Availability Options
• Inbox redundancy
• ASR 1006, preserves signaling & media
• Stateful failover
• Local redundancy
ASR(config)#redundancy
ASR-RP2(config-red)#mode sso
ASR-RP2(config-red)#end
• L2 Box-to-Box redundancy
Active
• ISR G2/4K (Stateful failover)
• ASR 1001-X/2-X/4/6 (Stateful failover)
• Local redundancy (Both routers must be Virtual
CUBE
Virtual
SIP SP
physically located on the same Ethernet LAN) IP IP
• Not supported across data centers CUBE
• Only 1 RP and 1 ESP in ASR1006 Standby
• Preserves both signaling and media
• Clustering with load balancing

• All platforms
• Load balancing by
• SP call agent SIP SP
• Cisco Unified SIP Proxy CUSP CUSP
• Local and geographical redundancy
CUBE HA Design Considerations on ISR-G2 for Box-to-Box
Redundancy
• Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby

• All active calls are checkpointed (Calls that are connected - 200OK / ACK transaction completed)
• All signaling/media is sourced from/to the Virtual IP Address
• Multiple Traffic (SIP/RTP) interfaces (Gig0/0, Gig0/1) require preemption and interface tracking
• HSRP Group number should be unique to a pair/interface combination on the same L2
• All interfaces of the same group have to be configured with the same priority
• No media-flow around or UC Services API (CUCM NBR) support for CUBE HA
Redundancy – Cont’d
• Lower IP Address for ALL the interfaces (Gig0/0, Gig0/1, Gig0/2) should be on the same platform,
which is used as a tie breaker for the HSRP Active state
• Multiple HSRP Groups/Interfaces/sub-interfaces can be used on either LAN or WAN side
• Upto 6 multimedia lines in the SDP are checkpointed for CUBE HA
• SDP Passthru (upto 2 m-lines) calls are also checkpointed starting IOS 15.6(1)T
• TDM or SRST or VXML GW cannot be collocated with CUBE HA
• Both platforms must be connected via a physical Switch across all likewise interfaces for CUBE HA to
work, i.e. Gig0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on
• Cannot have WAN terminated on CUBEs directly or Data HSRP on either side. Both Active/Standby
must be in the same Data Center
• Both the CUBEs must be running on the same type of platform and IOS version and identical
configuration. Loopback interfaces cannot be used for bind as they are always up. Sub-interfaces are
supported for all interfaces. Port Channels are supported for all interfaces from IOS 15.6(3)M
• CUBE HA only checkpoints SIP/RTP Traffic. Support for Survivability.tcl preservation was added in
15.6(2)T for CVP deployments
• Out-of-band DTMF (Notify/KPML) will not work post switchover
• CCB (courtesy callback) feature is not supported if a callback was registered with CVP and then a
switchover was done on CUBE. The CCB will not work in these scenarios.
• Recommended to configure TCP session transport for the SIP trunk between CVP and CUBE
• LTI based transcoding called flows including SRTP/RTP interworking preserved starting 15.5(2)T.
Requires same PVDM3 chip capacity on both active and standby in the same slot/subslot. CPA calls
(prior to being transferred to the agent), SCCP based media resources, Noise Reduction, ASP,
transrating calls are not checkpointed
• SRTP - RTP, SRTP - SRTP and SRTP passthru supported on ISR-G2
• CUBE HA with HSRP is supported with VRFs configured

• Traffic interfaces (SIP/RTP) can have VRFs configured but HSRP interface [ipc zone default config –
Gig0/2 above] cannot have any VRF associated with it. This means for every CUBE HA deployment
where VRFs are being utilized for SIP/RTP interfaces, at least three interfaces are required. Otherwise,
any of the LAN interfaces (Gig0/0 above) can be used as an HSRP interface
• VRF ID’s will be check pointed for the calls before and after switchover. VRF Configurations in both
active and standby routers have to be identical. This includes VRF based rtp port range as well
• Upon failover, the previously ACTIVE CUBE goes through a reload by design, preserving
signaling/media. Thus, running config should always be saved to avoid losing it due to the reload
CUBE Configuration on ISR-G2 Box-to-Box Redundancy
CUBE 1 CUBE 2
CUBE-1> enable CUBE-2> enable
CUBE-1# configure terminal CUBE-2# configure terminal
CUBE-1(config)# ip vrf LAN-VRF Configure VRFs CUBE-2(config)# ip vrf LAN-VRF
CUBE-1(config)# rd 1:1 on the platform CUBE-2(config)# rd 1:1
CUBE-1(config)# ip vrf WAN-VRF (if applicable) CUBE-2(config)# ip vrf WAN-VRF
CUBE-1(config)# rd 2:2 CUBE-2(config)# rd 2:2
CUBE 1 CUBE 2
interface GigabitEthernet0/0 interface GigabitEthernet0/0
description “Enterprise LAN” Inside interfaces : description “Enterprise LAN”
ip vrf forwarding LAN-VRF HSRP group 1 ip vrf forwarding LAN-VRF
ip address 10.10.1.11 255.255.255.0 VRF ID : LAN-VRF ip address 10.10.1.12 255.255.255.0
standby version 2 (if applicable) standby version 2
standby 1 ip 10.10.1.13 Interface can be standby 1 ip 10.10.1.13
standby delay minimum 30 reload 60 utilized as an HSRP standby delay minimum 30 reload 60
standby 1 preempt interface if no VRFs standby 1 preempt
standby 1 track 2 decrement 10 standby 1 track 2 decrement 10
standby 1 track 3 decrement 10 are required or
standby 1 track 3 decrement 10
standby 1 priority 50 configured standby 1 priority 50
CUBE 1 CUBE 2
description “Enterprise WAN” description “Enterprise WAN”
ip vrf forwarding WAN-VRF ip vrf forwarding WAN-VRF
ip address 128.107.66.77 255.255.255.0
Outside
ip address 128.107.66.78 255.255.255.0
standby version 2 interfaces : standby version 2
standby 10 ip 128.107.66.79 HSRP group 10 standby 10 ip 128.107.66.79
standby delay minimum 30 reload 60 VRF ID : WAN- standby delay minimum 30 reload 60
standby 10 preempt standby 10 preempt
standby 10 track 1 decrement 10 VRF (if
standby 10 track 1 decrement 10
standby 10 track 3 decrement 10 applicable) standby 10 track 3 decrement 10
standby 10 priority 50 standby 10 priority 50
CUBE 1 CUBE 2
description “HSRP Interface” description “HSRP Interface”
standby version 2 standby version 2
standby 100 ip 1.1.1.3 HSRP interfaces : standby 100 ip 1.1.1.3
standby delay minimum 30 reload 60 HSRP group 100 standby delay minimum 30 reload 60
standby 100 preempt CANNOT HAVE VRFs standby 100 preempt
standby 100 name CUBEHA associated standby 100 name CUBEHA
standby 100 priority 50 standby 100 priority 50
! !
Configure Interface
track 1 interface Gig0/0 line-protocol track 1 interface Gig0/0 line-protocol
Tracking (for line protocol
on corresponding
interfaces of the platform
CUBE 1 CUBE 2
redundancy inter-device Define Redundancy scheme: Creates redundancy inter-device
scheme standby CUBEHA interdependency b/w CUBE scheme standby CUBEHA
voice service voip redundancy & HSRP
voice service voip
mode border-element mode border-element
allow-connections sip to sip Turn on CUBE Redundancy allow-connections sip to sip
redundancy redundancy
ipc zone default HSRP Interface - IPC configuration : ipc zone default
association 1 Allows the ACTIVE CUBE to tell the association 1
no shutdown STANDBY about the state of the calls. no shutdown
protocol sctp CONFIG SHOULD BE APPLIED on the protocol sctp
local-port 5000 LAN SIDE (to avoid SPLIT BRAIN) and a local-port 5000
local-ip 1.1.1.1 NON-VRF associated interface
local-ip 1.1.1.2
remote-port 5000 CANNOT HAVE VRFs remote-port 5000
remote-ip 1.1.1.2 associated with this interface remote-ip 1.1.1.1
Configuration on Active and Standby
description TO SERVICE PROVIDER Bind traffic destined to the outside (SP SIP trunk)
destination-pattern 9T to the outside Physical interface.
session protocol sipv2 This ensures that all RTP and SIP packets are
session target ipv4:y.y.y.y created with the virtual IP associated with the
voice-class sip bind control source-interface GigabitEthernet0/1 respective physical interface.
voice-class sip bind media source-interface GigabitEthernet0/1 CUBE HA does not work with loopback interfaces
! as they are always up
description TO CUCM Bind traffic destined to the inside (CUCM or IP
destination-pattern 555…. PBX) to the inside Physical interface.
session protocol sipv2 This ensures that all RTP and SIP packets are
session target ipv4:10.10.1.10 created with the virtual IP associated with the
voice-class sip bind control source-interface GigabitEthernet0/0 respective physical interface.
voice-class sip bind media source-interface GigabitEthernet0/0
!
ip rtcp report interval 3000
!
gateway Configure media inactivity feature to clean up any
calls that may not disconnect after a failover
media-inactivity-criteria all
timer receive-rtcp 5
timer receive-rtp 86400
CUBE HA Design Considerations on ASR1K/ISR-4K/vCUBE
for Box-to-Box Redundancy
• Uses Redundancy Group (RG) Infrastructure Protocol

• Only active calls are checkpointed (Calls that are connected - 200OK / ACK transaction completed)
• GE0/0/0 and GE0/0/1 are referred to as traffic (SIP/RTP) interfaces and GE0/0/2 is RG (Redundancy
Group) Control/data interface
• Starting IOS-XE 16.3.1, Port channel is supported for both RG Control/data and traffic interfaces
• All signaling/media is sourced from/to the Virtual IP Address
• When configuration is applied and saved, the platform must go through a reload cycle
CUBE HA Design Considerations on ASR1K/ISR-4K/vCUBE
for Box-to-Box Redundancy
• Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby

• Lower address for all the interfaces (GE0/0/0, GE0/0/1, and GE0/0/2) should be on the same platform
• Redundancy Interface Identifier, rii (HSRP Group number) should be unique to a pair/interface
combination on the same L2
• Configuration on both the CUBEs must be identical including physical configuration and must be
running on the same type of platform and IOS-XE version. Loopback interfaces cannot be used as
bind as they are always up. Sub-interfaces are supported
• Multiple RII Groups/Interfaces/sub-interfaces can be used on either LAN or WAN side
CUBE HA Design Considerations on ASR1K/ISR-4K/vCUBE for
Box-to-Box Redundancy
• Multiple traffic (SIP/RTP) interfaces (GE0/0/1, GE0/0/1) require interface tracking to be configured
• Upto 6 multimedia lines in the SDP are checkpointed for CUBE HA. SDP Passthru (upto 2 m-lines) calls
are also checkpointed starting IOS-XE 3.17
• No media-flow around or UC Services API (CUCM NBR) support for CUBE HA
• CUBE-HA preserves both signaling and media and is not supported over a crossover cable connection
for the RG-control/data link (GE0/0/2)
• Both platforms must be connected via a physical Switch across all likewise interfaces for CUBE HA to
work, i.e. GE0/0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on. Multiple
interfaces/sub-interfaces can be used on either LAN or WAN side
• Cannot have WAN terminated on CUBEs directly or Data HA on either side. Both Active/Standby must
be in the same Data Center
• CUBE HA only checkpoints SIP/RTP Traffic. Support for Survivability.tcl preservation was added in IOS-
XE 3.17 for CVP deployments
• CCB (courtesy callback) feature is not supported if a callback was registered with CVP and then a
switchover was done on CUBE. The CCB will not work in these scenarios.
• Recommended to configure TCP session transport for the SIP trunk between CVP and CUBE
• Out-of-band DTMF (Notify/KPML) will not work post switchover
• LTI based transcoding called flows are preserved starting IOS-XE 3.15. Requires same SPA-DSP
module capacity on both active and standby in the same slot/subslot. CPA calls (prior to being
transferred to the agent), SCCP based media resources, Noise Reduction, ASP, transrating calls are
not checkpointed
• CUBE HA with RG Infra protocol is supported with VRFs configured. Traffic interfaces (SIP/RTP) can
have VRFs configured but RG Control/Data interface [GE0/0/2] cannot have any VRF associated with it
• VRF ID’s will be check pointed for the calls before and after switchover. VRF Configurations in both
active and standby routers have to be identical. This includes VRF based rtp port range as well
• SRTP - RTP, SRTP - SRTP supported partially. SRTP Passthru completely supported as packets
pass without encryption/decryption [See Note below]
• Upon failover, the previously ACTIVE CUBE goes through a reload by design, preserving
signaling/media
• Upon failover, starting IOS-XE3.11, the previously ACTIVE CUBE can be moved to a PROTECTED
state to avoid the reload
• Running configuration should always be saved to avoid losing it due to the reload by design when the
switchover happens
• It is mandatory to use separate interface for redundancy (RG Control/data, GE0/0/2). i.e interface used
for traffic cannot be used for HA keepalives and checkpointing
CUBE Configuration on ASR/ISR-4K/vCUBE Box-to-
Box Redundancy
CUBE 1 CUBE 2
CUBE-1> enable CUBE-2> enable
CUBE-1# configure terminal CUBE-2# configure terminal
CUBE-1(config)# ip vrf LAN-VRF Configure VRFs CUBE-2(config)# ip vrf LAN-VRF
CUBE-1(config)# rd 1:1 on the platform CUBE-2(config)# rd 1:1
CUBE-1(config)# ip vrf WAN-VRF (if applicable) CUBE-2(config)# ip vrf WAN-VRF
CUBE-1(config)# rd 2:2 CUBE-2(config)# rd 2:2
CUBE Configuration on ASR/ISR-4K/vCUBE Box-to-
Box Redundancy
CUBE 1 CUBE 2
Disables software redundancy redundancy
redundancy
For ASR1006: mode rpr mode none
mode none
application redundancy application redundancy
group 1 group 1
name voice-b2bha Configure RG name voice-b2bha
priority 100 failover threshold 75 Group for use priority 100 failover threshold 75
control GigabitEthernet 0/0/2 protocol 1 control GigabitEthernet 0/0/2 protocol 1
with CUBE HA
data GigabitEthernet 0/0/2 data GigabitEthernet 0/0/2
timers delay 30 reload 60 timers delay 30 reload 60
voice service voip Turn on CUBE voice service voip

mode border-element Redundancy mode border-element
allow-connections sip to sip allow-connections sip to sip
redundancy-group 1 redundancy-group 1
CUBE Configuration on ASR1K/ISR-4K/vCUBE Box-to-
Box Redundancy
CUBE 1 CUBE 2
track 1 interface GigabitEthernet 0/0/0 track 1 interface GigabitEthernet 0/0/0
line-protocol line-protocol
track 2 interface GigabitEthernet 0/0/1 track 2 interface GigabitEthernet 0/0/1
line-protocol Track interfaces line-protocol
to trigger
redundancy switchover redundancy
application redundancy application redundancy
group 1 group 1
track 1 shutdown track 1 shutdown
track 2 shutdown track 2 shutdown
Box Redundancy
CUBE 1 CUBE 2
interface GigabitEthernet0/0/0 Inside interfaces : interface GigabitEthernet0/0/0
description “Enterprise LAN” description “Enterprise LAN”
Redundancy Interface ip vrf forwarding LAN-VRF
ip vrf forwarding LAN-VRF
Identifier 1 ip address 10.10.1.2 255.255.255.0
ip address 10.10.1.1 255.255.255.0
redundancy rii 1 VRF ID : LAN-VRF (if redundancy rii 1
redundancy group 1 ip 10.10.1.3 exclusive applicable) redundancy group 1 ip 10.10.1.3 exclusive

Outside interfaces: description “Enterprise WAN”
description “Enterprise WAN”
ip vrf forwarding WAN-VRF Redundancy Interface ip vrf forwarding WAN-VRF
ip address 20.20.1.1 255.255.255.0 Identifier 2 ip address 20.20.1.2 255.255.255.0
redundancy rii 2 VRF ID : WAN-VRF (if redundancy rii 2
redundancy group 1 ip 20.20.1.3 exclusive applicable) redundancy group 1 ip 20.20.1.3 exclusive
Box Redundancy
CUBE 1 CUBE 2
interface GigabitEthernet 0/0/2 RG Control/Data interface : interface GigabitEthernet 0/0/2

ip address 3.3.1.1 255.255.255.0 CANNOT HAVE VRFs associated ip address 30.3.1.2 255.255.255.0
Box Redundancy
Configuration on Active and Standby
description to-SIP-SP Bind traffic destined to the outside (SP SIP
destination-pattern 9T trunk) to the outside Physical interface to
session protocol sipv2 make sure it uses the virtual IP address as
session target ipv4:y.y.y.y the source-IP for all calls
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
!
dial-peer voice 200 voip Bind traffic destined to the inside (CUCM or
description to-CUCM IP-PBX) to the inside Physical interface
destination-pattern 555….
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
!
ip rtcp report interval 3000
! Configure media inactivity feature to
gateway clean up any calls that may not
media-inactivity-criteria all disconnect after a failover
timer receive-rtcp 5
timer receive-rtp 86400
Additional Supported options for CUBE HA
CUBE-1
PortChannel2
Gig0/0/0
Gig0/0/2.200
Gig0/0/2.100 – ITSP 1
Gig0/0/1
CUBE
Gig0/0/3 Gig0/0/4 ITSP 1
PortChannel34
redundancy
redundancy
redundancy
vPC
WAN
rii 1
rii 2
rii 3
Switch D Switch E Switch A Switch B Switch C Edge
vPC
PortChannel34
CUCM ITSP 2
Gig0/0/3 Gig0/0/4
Gig0/0/1
PortChannel2
Gig0/0/2.100
Gig0/0/2.200 – ITSP 2
Gig0/0/0 CUBE
CUBE-2
• The RG control data interfaces can be a sub interface that is part of the same port channel used for voice traffic. This will go to switch D and E
thereby eliminating the need for additional switches for RG control/data. This is provided there is sufficient bandwidth for voice + RG
data/control on the port channel (for example when using 10G)
• Multiple ITSPs or multiple trunks from the same ITSP can be terminated on the same CUBE ENT HA (ISR G2, ISR 4K, ASR 1K, vCUBE) pair
• Port Channel(s) can be used on the WAN/ITSP side as well as shown for the LAN side in the above© diagram with
2017 Cisco and/or L2 and
its affiliates. CEreserved.
All rights routerCisco
redundancy
Public
ASR B2B Redundancy : PROTECTED MODE
• Default failover redundancy behavior in a B2B HA pair is to reload the affected router to avoid out-of-sync
conditions/Split brain
• Starting XE3.11, an ASR can be configured to transition into PROTECTED mode
• In PROTECTED mode
o Bulk sync request, Call checkpointing, and incoming call processing are disabled
o The router in PROTECTED mode needs to be manually reloaded to come out of this state
• The PROTECTED mode is enabled with the following CLI

voice service voip
no redundancy-reload !  Default is ‘redundancy-reload’
• Track for the RG Control/data interface (GE0/0/2) with the same ‘track <id> shutdown’ under redundancy
group needs to be added
track 1 interface GigabitEthernet0/0/0 line-protocol
track 2 interface GigabitEthernet0/0/1 line-protocol
track 3 interface GigabitEthernet0/0/2 line-protocol !  Track for RG Control/data interface
redundancy
application redundancy
group 1
track 1 shutdown
track 2 shutdown
track 3 shutdown
CUBE SIP Trunk Monitoring with OOD Options message
A CUCM SIP Trunk SP SIP Trunk
SP
CUBE SIP
OOD Options
200 OK • Out-of-dialog OPTIONS message sent

to check the status of the SIP Trunk
DP 100 =
ACTIVE
INVITE
INVITE • The dial-peer is “busyout” if it does
200 OK 200 OK not receive a response within a
configurable time period
OOD Options
• For an INVITE that matches a
“busyout” dial-peer, CUBE sends “503
Timeout – no
response Service Unavailable”
DP 100 = BUSYOUT • If there is a secondary dial-peer

INVITE OOD Options configured, the call will be re-routed
503 Service Unavailable the secondary path
OOD Options
CUBE SIP Trunk Monitoring with OOD Options message
A CUCM SIP Trunk SP SIP Trunk
SP SIP
CUBE
OOD Options
voice-class sip options-keepalive
200 OK
up-interval 20 down-interval 20 retry 3
DP 100 =
INVITE ACTIVE Three timers that can be configured:
INVITE • up-Interval: OPTIONS keepalive
200 OK
200 OK timer interval for UP endpoint
• down-interval: OPTIONS keepalive
OOD Options timer interval for DOWN endpoint
• retry: Retry count for OPTIONS
Timeout – no keepalive transmission
response
DP 100 = BUSYOUT Warning:

INVITE OOD Options • Each dial-peer that has options
503 Service Unavailable
message configured sends out a
separate message.
OOD Options
• EEM Script can be used to busyout
other dial-peers
OOD OPTIONS Ping Keepalive Enhancement
CUCM SIP Trunk SP SIP Trunk • Each dial-peer that has OPTIONS message
A SP SIP configured sends out a separate message, even
CUBE
if the session targets are same
OOD Options (DP 100)
200 OK • Network bandwidth and process runtime are
DP 100 : Session Target IPv4:1.1.1.1 wasted in CUBE and remote targets to sustain
INVITE INVITE (DP 100)
duplicate OOD OPTIONS Ping heartbeat
200 OK keepalive connection
200 OK
OOD Options (DP 200) • Consolidate SIP OOD Options Ping connections
200 OK by grouping SIP dial-peers with same OOD
Options Ping setup
DP 200: Session Target IPv4:1.1.1.1
OOD Options (DP 300) • New CLI : “voice class sip-keepalive-
200 OK profile <tag>” is used to define OOD
OPTIONS Ping setup
DP 300: Session Target IPv4:1.1.1.1
OOD Options (DP 400) • Consolidated SIP OOD Options Ping connection
200 OK will then be established with a target for multiple
SIP dial-peers with the same target and OOD
DP 400: Session Target IPv4:1.1.1.1 Options Ping profile setup
OOD OPTIONS Ping Keepalive Enhancement -
Configuration
voice class sip-options-keepalive 1 Sample Show command output
description UDP Options consolidation CUBE#sh voice class sip-options-keepalive 1
down-interval 49
Voice class sip-options-keepalive: 1 AdminStat: Up
up-interval 180
retry 7 Description: UDP Options consolidation
Single OOD Option
transport udp Ping Group applied Transport: udp Sip Profiles: 0
to multiple dial-peers Interval(seconds) Up: 180 Down: 49
dial-peer voice 1 voip with same session
Retry: 7
destination-pattern 6666 targets
session target ipv4:10.104.45.253 Peer Tag Server Group OOD SessID OOD Stat IfIndex
voice-class sip options-keepalive profile 1 -------- ------------ ---------- -------- -------
1 4 Active 9
destination-pattern 5555 2 4 Active 10
session protocol sipv2 OOD SessID: 4 OOD Stat: Active
session target ipv4:10.104.45.253 Target: ipv4:10.104.45.253
voice-class sip options-keepalive profile 1
Transport: udp Sip Profiles: 0
• With OOD Options Ping Keepalive group, an options ping keepalive connection is established on per remote target base as opposed
an options ping keepalive connection established per dial-peer basis. Up to 10,000 “voice class sip-options-keepalive <tag>” can be
defined per system
• Either legacy “sip options-keepalive” or the new “sip options-keepalive profile <tag>” can be configured on a dial-peer. Dial-peers with
Destination Server Group instead of Session Target IP must use Options Keepalive Profile and not the legacy CLI.
SIP Trunk to TDM PSTN Failover
• Collocated Cisco Unified Border Element and TDM GW offers:
• Alternate call routing path (upon congestion or SIP Trunk failure)
• Easy SIP Trunking migration
SIP Trunk
(Primary)
SP
SBC VoIP
IP CUBE
TDM Trunk
• Deployed in small to medium sized (Secondary)
enterprise networks description “Primary path to SIP Trunk provider”
• Deployed at branch locations for destination-pattern 91[2-9]..[2-9]......
PSTN calls during survivability session target ipv4:10.10.10.1
voice-class sip options-keepalive
mode
• Deployed at branch locations for dial-peer voice 20 pots
description “Secondary path to PSTN”
destination-pattern 91[2-9]..[2-9]......
emergency services preference 2
port 0/0/0:23
Video Suppression
Video Suppression
INVITE w/
audio only
A SP
CUBE
SIP
SBC
CUBE(config)#voice service voip

INVITE w/ audio, CUBE(conf-voi-serv)#sip
Video video, application CUBE(conf-serv-sip)#audio forced
Endpoints
CUBE(conf-serv-sip)#dial-peer voice 100 voip
CUBE(conf-serv-sip)#description “Outgoing Dial-peer”
CUBE(config-dial-peer)#voice-class sip audio forced
• When CUBE receives video capabilities as part of SDP, it passes them across by
default
• This feature adds a mechanism on CUBE to allow only audio and image (for T.38
fax) media capabilities and drop all other media capabilities like video,
application m-lines etc. while routing calls to service providers
»Only supported for SIP-SIP calls not in SDP Passthru mode
MMoH
Multicast MoH to Unicast MoH Conversion- CUBE
Multicast MoH Unicast MoH
Hold A ♬ ♬ ♬ ♬ ♬ SP
SIP
CUBE
Active Call
ccm-manager music-on-hold
ip multicast-routing distributed
“ip pim dense-mode” under interface
• Extends the ability for enterprises to play Multicast MoH to Service Providers
• CUBE converts Multicast MoH from the MoH server to unicast MoH streamed to
the service provider
• Provides the ability to play Multicast MoH over the WAN from the MoH server at
the HQ to the CUBE at the remote branch (distributed architecture), saving WAN
bandwidth
Contact Center
Features
Mid-call codec renegotiation
Provider supports both
G.711 G.711 and G.729 codecs
CVP 2 1
3
Call Xfer (signaling only) G.711 G.729 /
G.711
SIP SP SIP
CUBE
4
G.729
G.729
1 Call arrives on G.729 SIP trunk
2 CVP connects call to speech recognition server that

requires G.711 so the call renegotiates G.711 e2e
3 CVP xfers call to a remote agent that uses G.729
4 Call renegotiates to G.729 e2e
Mid-call Xcoder Insert/Drop
Provider supports only
G.711 G.729 codec
CVP 2 1
3 Transcoder Inserted
Call Xfer (signaling only) G.711 G.729 /
G.711
SIP SP SIP
CUBE
4
G.729
G.729 Transcoder Dropped
1 Call arrives on G.729 SIP trunk
2 CVP connects call to speech recognition server that

requires G.711. Since provider does not support G711
CUBE inserts transcoder
3 CVP xfers call to a remote agent that uses G.729
4 CUBE drops xcoder and e2e call becomes G.729 again

REFER Handling for Contact Centers
• Enables CUBE to handle REFER messages more efficiently in contact center deployments
• CUBE can operate in either consume mode or pass-through mode
REFER Consumption Based on “Refer-To” header,
CUBE does outbound dial-peer
A 3. INVITE
match and sends out an INVITE
message
SIP SP No supplementary-service sip refer
CUBE
CVP 2. INVITE supplementary-service media-renegotiate
1. REFER
REFER Pass-through (Default mode)
A
CUBE will pass across the
SIP SP Refer message “as-is” without
CUBE
2. REFER
any modification
CVP
1. REFER
REFER Handling Enhancement
• A new CLI, “refer consume”, has been added to the SIP dial peer.
• The final decision to consume or pass-through REFER is determined based on this new
CLI option configured on the Refer-To dial-peer.
“supplementary-service sip refer” “refer consume” Outcome
Configured globally or Configured at dial-
at inbound dial-peer peer that matches
‘refer-To’
Yes (default) No (default) REFER Pass-through
Yes (default) Yes REFER Consume
No No (default) REFER Consume
No Yes REFER Consume
Call Progress Analysis on SIP Trunks Sent:
Received:
INVITE sip:2776677@9.41.35.205:5060
UPDATE SIP/2.0
sip:sipp@9.42.30.151:7988;transport=UDP SIP/2.0
Via: SIP/2.0/UDP
Via: SIP/2.0/UDP 9.41.35.205:5060;branch=z9hG4bK6F26CF
9.42.30.151:7988;branch=z9hG4bK-16368-1-0
……………..
…………….
event=detected
--uniqueBoundary
status=Asm
Content-Type: application/x-cisco-cpa
pickupT=2140
Content-Disposition: signal;handling=optional
maxActGlitchT=70
numActGlitch=12
Events=FT,Asm,AsmT,Sit
valSpeechT=410
CPAMinSilencePeriod=608
maxPSSGlitchT=40
CPAAnalysisPeriod=2500
numPSSGlitch=1
CPAMaxTimeAnalysis=3000
silenceP=290
CPAMaxTermToneAnalysis=15000
termToneDetT=0
CPAMinValidSpeechTime=112
SIP Dialer noiseTH=1000
actTh=32000
SIP SP
CVP CUBE
CUBE detects fax tone
Transcoder Inserted
Contact Center Dialer will then instruct to detect tones
Configuration on CUBE:
CUBE on whether to
connect the call to an agent voice service voip
or disconnect the call by CUBE will then cpa
sending REFER, RE-INVTE, connect/disconnect the
BYE, CANCEL etc. call appropriately
dspfarm profile 1 transcode universal
call-progress analysis
CUBE Security
Note
• CUBE version 11.5.0 [IOS 15.6(1)T, IOS-XE 3.17] or later was used to
develop the best practices included in the CUBE Security presentation,
unless a specific version is mentioned on a slide
• The CUBE Configuration guide is the comprehensive resource for
security configuration and more
• All best practices around Cisco IOS/IOS-XE Routers apply to CUBE as
well
• CUBE Configuration generally consists of
• Global – Everything under voice service voip
• Call Routing – Dial-peers (Any configuration under dial-peers always overrides Global config)
• SIP User Agent Config – Everything under sip-ua
Collaboration Deployment
Enterprise LAN ITSP WAN (SIP Provider)
PSTN (PRI/FXO)
Unified CM TDM Backup
(Not available in vCUBE)
PSTN
CUBE
SIP
H.323
RTP
MediaSense
CUBE/GW
Security
Overview
CUBE Voice Security Protection per Design Specs
DOS Identity / Service Theft
• B2BUA – L7 Voice Application Code • SIP Digest Authentication
Inspection L7 Protocol-independent memory structures holding call • SIP Hostname Validation
state and attributes (CLID, Called #, Codec…)
• Call Volume/BW • SIP Trunk Register
Limiting (CAC) • CDR
• Call Codec • Toll Fraud
Limiting Dial-peer Dial-peer • Co-resident IOS: ACLs, COR
• SIP Malformed
Inspection
• SIP Listen Port DTMF xlation SIP/H.323 Privacy
SIP/H.323
Codec Filtering Protocol
Configuration Protocol • SIP Header Manipulation
Xcoding Control Stack
• RTP Malformed Stack • Authentication and
• Topology Hiding encryption (media) – SRTP
• Co-resident IOS: RTP RTP • Authentication and
Library Library
ACLs, FW, IPS encryption (signaling) – TLS
DSP API • Co-resident IOS: All VPN
TCP UDP TLS TCP UDP TLS features
DSP Hardware
IOS Infrastructure (ACLs, FW, IPS, VPN)

Ingress I/F HW LAN/WAN Interfaces Egress I/F
Signaling Media
Five Layers of Security in CUBE
EXTERNAL
SECURITY
Policy
APPLICATION LAYER
Dialpeer
Matching
Voice Trust
List
TCP & UDP

Mechanisms
NETWORK LAYER
Access
Control Lists
CUBE Security Best Practices Summary
• IP TRUST LIST: Don’t respond to any SIP INVITEs if not originated
from an IP address specified in this trust list
• CALL THRESHOLD: Protect against CPU, Memory & Total Call spike
• CALL SPIKE PROTECTION: Protect against spike of INVITE
messages within a sliding window
• BANDWIDTH BASED CAC: Protect against excessive media
• MEDIA POLICING: Protect against negotiated Bandwidth overruns and
RTP Floods
• USE NBAR POLICIES: Protect against overall SIP, RTP flood attacks
from otherwise “trusted” sources
• DEFINE VOICE POLICIES: identify patterns of valid phone calls that
might suggest potential abuse.
Topology Used in this section
Topology/Address Hiding
10.10.1.10 10.10.1.11 128.107.214.21 66.66.66.66
MPLS
SP IP
Inside Network
CUBE SBC
Enterprise LAN —10.10.1.x/24 Outside ITSP WAN
• Requirements
• Maintain connectivity without exposing the IP network details
• B2BUA provides complete topology hiding on signaling and media
• Maintains security and operational independence of both networks
• Provides implicit NAT service by substituting Cisco Unified Border Element IP
addresses on all traffic
SIP Trunk to ITSP
Sample
Item SIP Trunk service provider requirement
Response
1 SIP Trunk IP Address (Destination IP Address for INVITES) 20.1.1.2 or DNS
2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711, G729
5 Fax protocol support T.38
6 DTMF signaling mechanism RFC2833
7 Does the provider require SDP information in initial INVITE (Early offer required) Yes
8 SBC’s external IP address that is required for the SP to accept/authenticate calls 20.1.1.1
(Source IP Address for INVITES)
9 Does SP require SIP Trunk registration for each DID? If yes, what is the No
username & password
10 Does SP require Digest Authentication? If yes, what is the username & password No
IP Trust List for Signaling
1. Enable CUBE Application
voice service voip
mode border-element license capacity 20  License count entered here not enforced though
this CLI is required to see “show cube” CLI output
allow-connections sip to sip  By default IOS/IOS-XE voice devices do not allow
an incoming VoIP leg to go out as VoIP
2. Configure any other global settings or security measures

voice service voip
h323
call service stop  Disable H323 if not using it
3. Create a trusted list of IP addresses to prevent toll-fraud
voice service voip
ip address trusted list  Applications initiating signaling towards CUBE, e.g. CUCM, CVP,
ipv4 66.77.37.2 ! ITSP SIP Trunk Service Provider’s SBC. IP Addresses from dial-peers with
ipv4 10.10.1.20/28 ! CUCM “session target ip” or Server Group are trusted by default and
need not be populated here
sip
silent-discard untrusted  Default configuration starting XE 3.10.1 /15.3(3)M1 to mitigate TDoS Attack
Toll Fraud Mitigation
• Default operation in 15.1.2T has changed
• As of 15.1.2T, by default, only calls from “trusted” source IP addresses will be
accepted – similar to CUCM operation
• If you want to restore pre-15.1.2T default operation, use “voice service voip >
no ip address trusted authenticate”. This is NOT RECOMMENDED.
10.10.1.10 SP
SIP
IP
CUBE 66.66.66.66
10.10.10.2
router#sh ip address trusted list
IP Address Trusted Authentication
Administration State: UP
voice service voip Operation State: UP
ip address trusted list
ipv4 10.10.1.10 IP Address Trusted Call Block Cause: call-reject (21)
ipv4 66.66.66.66 VoIP Dial-peer IPv4 Session Targets:
Peer Tag Oper State Session Target
-------- ---------- --------------
1 UP ipv4:30.1.1.1
2 DOWN ipv4:40.1.1.1
Toll Fraud Prevention – more info:
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_te IP Address Trusted List:
ipv4 10.10.1.10
ch_note09186a0080b3e123.shtml ipv4 66.66.66.66
Configure Call Routing on CUBE
Standby CUBE with High
Availability
CUBE
A
Active IP PSTN
CUBE
Enterprise
Campus
MPLS
LAN Dial-Peers WAN Dial-Peers
PSTN is now
used only for
• Dial-Peer – “static routing” table mapping phone numbers
emergency callsto interfaces or IP addresses
SRST over FXO lines
• LAN Dial-Peers – Dial-peers that are facing towards the IP PBX for sending and
receiving calls to & from the PBX
CME
• WAN Dial-Peers – Dial-peers that are facing towards

TDM PBX the SIP Trunk provider for
Enterprise
sending & receiving calls to &Branch
from the provider
Offices
Understanding Dial-Peer Matching Techniques:
LAN & WAN Dial-Peers
• LAN Dial-Peers – Dial-peers that are facing towards the IP PBX for sending
and receiving calls to & from the PBX
• WAN Dial-Peers – Dial-peers that are facing towards the SIP Trunk provider for
sending & receiving calls to & from the provider
Inbound LAN Dial-Peer Outbound Calls Outbound WAN Dial-Peer
A
CUCM SIP Trunk ITSP SIP Trunk
IP PSTN
CUBE
Inbound Calls
Outbound LAN Dial-Peer Inbound WAN Dial-Peer
WAN Dial-Peer Configuration
Inbound Dial-Peer for call legs from SP to CUBE
dial-peer voice 100 voip Specific to your DID range
description *** Inbound WAN side dial-peer ***
assigned by the SP
incoming called-number 70247595..$
OR No “incoming called-number . ”
incoming uri via tag
voice-class sip bind control source gig0/1 CUBE has multiple interfaces.
voice-class sip bind media source gig0/1 Gig0/1 faces SP.
Outbound Dial-Peer for call legs from CUBE to SP

dial-peer voice 200 voip Translation rule/profile to strip the
description *** Outbound WAN side dial-peer *** access code (9) before delivering
translation-profile outgoing Digitstrip the call to the SP
destination-pattern 91[2-9]..[2-9]......$
session protocol sipv2 Dial-peer for making long distance
voice-class sip bind control source gig0/1 calls to SP, based on NANP (North
American Numbering Plan)
session target ipv4:<SIP_Trunk_IP_Address>
codec g711ulaw No “destination-pattern .T ”
dtmf-relay rtp-nte
LAN Dial-Peer Configuration
Inbound Dial-Peer for call legs from CUCM to CUBE
description *** Inbound LAN side dial-peer ***
CUCM sending 9 (access code) + All
incoming called-number 9T
session protocol sipv2 digits dialed
codec g711ulaw CUBE has multiple interfaces. Gig0/0
dtmf-relay rtp-nte faces CUCM.
Outbound Dial-Peer for call legs from CUBE to CUCM

description *** Outbound LAN side dial-peer *** SP will be sending 10 digits (NANP)
destination-pattern 70247595..$ based on your DID that is being
session protocol sipv2 delivered to CUCM
session target ipv4:<CUCM_IP_Address>
codec g711ulaw Default codec is G729 if none is
dtmf-relay rtp-nte specified
Note: If more than 1 CUCM cluster exists, you will have to create multiple such LAN dial-peers with “preference CLI” for
CUCM redundancy/load balancing as the traditional way to accommodate multiple trunks
ACLs Applied on WAN Interfaces
ip access-list extended ITSP-INBOUND
permit udp host ITSP_IP_ADDRESS host CUBE_WAN_IP_ADDRESS eq 5060
permit tcp host ITSP_IP_ADDRESS host CUBE_WAN_IP_ADDRESS eq 5060
permit udp host ITSP_IP_ADDRESS host CUBE_WAN_IP_ADDRESS range 16384 32767
ip access-list extended APPLY_to_GIG0-1

permit udp host 66.66.66.66 host 128.107.214.21 eq 5060
permit tcp host 66.66.66.66 host 128.107.214.21 eq 5060
permit udp host 66.66.66.66 host 128.107.214.21 range 16384 32767
SIP Listening Port Protection
 Default SIP Listen ports are 5060 (UDP/TCP) and 5061 (TLS)
 These ports are well-known and can be the target of attacks
 Change the SIP Listen port to a different setting that is not well-known
 Global setting, i.e. single port per router can be configured
 Cannot configure the same listening port for both UDP/TCP and TLS
 Cannot reconfigure a SIP listen port when calls are active
voice service voip

sip
listen-port non-secure 2000 secure 2050
RTP Port Range and Phantom Packets
 A phantom packet is a valid RTP packet meant for the CUBE or Voice TDM gateway without an
existing signaling session
 When a phantom packet is received by the VoIP RTP layers of the gateways, the packet is punted
to the UDP process to check if it is required by any other applications causing performance issues
 A malicious attacker can also send a large number of phantom/rogue packets to impact CPU
 Configure VoIP port range for phantom packets. If a phantom packet is received on the configured
port, the VoIP RTP layer can safely drop the packet. If a phantom packet is received on any other
port, the VoIP RTP layer punts the packet to the UDP process.
 RTP port range on ISR G2 is from 16K to 32K, and 8K to 48K on ISR 4K, ASR1K, and vCUBE
voice service voip
rtp-port range 16384 32766
! applies to the global port table which is all ipaddress outside of the media-address ranges
media-address range 10.10.1.11 10.10.1.11 port-range 16384 32766  Internal Interface
media-address range 128.107.214.21 128.107.214.21 port-range 16384 32766  External Interface
! the port-range here decides which ports to be used for this media-range
port-range 16384 32766
! used to drop phantom packets within this port-range, no impact on which ports to use
sip
source filter ! Filter out incoming incorrect remote addr/port RTP packets
Close Unused Session Transport Mechanisms
• Close Unused H.323/SIP Ports and Transport Mechanisms
• By default these ports are open when a voice-enabled software load is
deployed on the router (either as a PRI gateway or Cisco UBE).
sip-ua
no transport tcp
no transport udp
SIP Registration/Digest Authentication
• SIP Registration: A SP SIP trunk requiring a registration sequence is
more secure than one that doesn’t. However, many SPs do not
currently support or offer SIP registration.
sip-ua
credentials username 1001 password 0822455D0A16 realm cisco.com
• SIP Digest Authentication: Cisco UBE responds to SIP Digest

Authentication challenges from a SP call agent.
sip-ua
authentication username xxx password yyy

Low Water Mark
CUBE CUBE

Call #3
CUBE


Low Water Mark
CUBE CUBE

Call #3
CUBE

Call Admission Control Based on Total Calls, CPU
and Memory usage
• CUBE provides various different CAC mechanisms – based on Total
calls, CPU Utilization & Memory utilization
Total Calls, CPU, High Water Mark

Low Water Mark
Memory CUBE
Configuration on CUBE
Step1 :  Set the threshold for Total-Calls
call threshold global total-calls low <low-threshold> high <high-threshold>
 Set the threshold for Total-memory

call threshold global total-mem low <low-threshold> high <high-threshold>
 Set the threshold for CPU usage (Average or last 5 seconds)

call threshold global cpu-5sec low <low-threshold> high <high-threshold>
OR
call threshold global cpu-avg low <low-threshold> high <high-threshold>
Call Admission Control Based on Total Calls, CPU
and Memory usage
Step 2 :  Enable the Call Treatment using:

call treatment on
 Enter the Call Treatment cause-code:

call treatment cause-code ?
busy Insert cause code indicating the GW is busy (17)
no-QoS Insert cause code indicating the GW cant provide QoS (49)
no-resource Insert cause code indicating the GW has no resource (47)
Step 3 : Call Treatment Options
call treatment action ?
hairpin Hairpin
playmsg Play the selected message
reject Disconnect the call and pass down cause code
Call Admission Control based on Call spikes
 Call spike CAC monitors call arrival rate over a moving window of time; calls
exceeding the configured rate threshold are rejected
 Protection against unexpected high call volumes, and INVITE-based DOS
attacks
 Can be configured globally or on a per dial-peer level
 Error code will be sent when a call spike occurs
 This error code is also configurable globally or on a per dial-peer level
Call Spike CUBE

Detection
If a call spike is detected, reject calls
Call Admission Control based on Call spikes
call spike call-number [steps number-of-steps size milliseconds]
SIP SP A
CUBE
Example: If a call spike is detected, reject calls

call spike 10 steps 5 size 200 • 10 calls accepted during the most recent window
• The most recent window is 1-second (5x200ms)
• The window moves on every 200ms
Call arrival 2 2 2 2 2 3 1 4
200ms 200ms 200ms 200ms 200ms 200ms 200ms 200ms
10 calls; all accepted
Most recent 11 calls; 10 acc, 1 rejected

time window
10 calls; all accepted
12 calls; 10 acc, 2 rejected
Call Admission Control based on Bandwidth
 Bandwidth based CAC feature provides a mechanism to limit number of SIP calls
based on the aggregate media bandwidth limit either at:
 Dial-Peer level or,
 Interface level
 Provides the ability to configure the SIP error response code for calls rejected by this
feature
 Examples:
Call #1 – 80Kbps
Call #2 – 80 Kbps dial-peer voice 1 voip
max-bandwidth 160
Call #3 – 80 Kbps
CUBE Call #3 Rejected by CUBE
At Dial-Peer level At Interface level
dial-peer voice 1 voip !
destination-pattern 2... CUBE# call threshold interface GigabitEthernet0/0 int-
max-bandwidth 160 bandwidth low 120 high 160
session protocol sipv2 !
session target ipv4:9.44.44.9:6080
Media Policing to protect against RTP Floods
 Leaky Bucket Algorithm (LBA) checks RTP payload in the
RTP packet against the expected negotiated rate in SIP
signaling and identify violation if any
 LBA identifies violation and triggers policing actions on
violated rtp packets.
 Policing actions can be one of the following:
 Drop all violated packets
 Drop all the violated packets as well as disconnect call
once it reaches the configured number of violations, or
 Ignore the violations
 SYSLOG and SNMP trap can be generated to inform
violation to the system administrator.
NBAR to protect against SIP flooding and UDP
attacks at opened RTP ports
Interface configuration
interface GigabitEthernet0/0-1 ! Both Internal and External interfaces
service-policy input throttle
global configuraiton
class-map match-any rtp
match protocol rtp
class-map match-any sip
match protocol sip
!
policy-map throttle
class sip
police 8000
class rtp
police 150000
class class-default
police 8000
Control Plane Policing (CoPP) – To prevent packet
flooding/Large Rate of packet arrival
ip access-list extended coppacl-udp-icmp
permit udp any host 10.10.1.11 range 16384 32767
permit udp any host 128.107.214.21 range 16384 32767
permit icmp any host 10.10.1.11 range 16384 32767
permit icmp any host 128.107.214.21 range 16384 32767
!
class-map match-all copp-rtp-icmp
match access-group name coppacl-udp-icmp
!
policy-map copp-policy-rtp-icmp
class copp-rtp-icmp
police rate 100 pps conform-action transmit exceed-action drop
!
control-plane
service-policy input copp-policy-rtp-icmp
Proposed Network Topology for Integrated Voice Gateway /
Voice Policy Solution based on UC Services API
SIP
MGCP
H323
IP RTP
CUBE +
TDM GW
Service
Provider
TDM
VOIP
Network
Private
TDM Protocols Call Control
CUCM
API features for Media
API features for control & stats,
TDM & VOIP including Media
Signaling Forking
Voice Policy
SRE Distribution &
ETM Voice Aggregation Secure Logix
Policy Voice Policy
Appliance Server
http://www.cisco.com/c/dam/en/us/products/collateral/unified-communications/unified-border-element/tdos_brochure.pdf
Voice Security Attacks
CUBE Protection with an External Voice Policy
Threat / Use Case Mitigation Action provided by CUBE w/ SecureLogix
IVR cycling with repeating DTMF tones in Detect repeated DTMF tones that cause cycling, then take policy action
WAVE files (disconnect, transfer)
Harassing Calls Detect multiple phone calls from same phone # (or exchange), then take
policy action (disconnect, record)
Contact Center abuse Detect unusual activity from specific phone # or exchange, then take policy
action (transfer, record)
Unauthorized Modem Usage Detect Modem traffic, then take policy action (disconnect)
911 Notification Detect 911 activity then take policy action (send alert)
Toll Fraud Detect secondary dial tones then take policy action (disconnect)
Social Network Attacks Detect call patterns from area codes or exchange then take policy
Unauthorized FAX usage Limit time of day usage on FAX
Inappropriate use of phones Detect phone calls to 900 area codes and disconnect
Firewall : General Guidelines
• Purchase SIP Trunking services from a trusted SP
• Use an external Firewall for connections that have both voice and data, though most customers just
use a dedicated circuit for voice
• Have the firewall rules work on data (i.e. Non port 5060 and non UDP port) (setup firewall rules on
CUBE to drop anything that is not voice)
• Use a voip trust list
• When it comes to have colocation of Firewall with CUBE on the same platform, ZBFW is only
supported on ISR G2 with CUBE collocated and not with ASR1K/ISR4K/CSR1000v (vCUBE) series
• Having an MPLS for terminating only SIP traffic from a trusted provider should be sufficient and CUBE
basically acts as a Voice Firewall (address/topology hiding). An external Firewall is still supported and
assumes
• UDP RTP port range and SIP signaling port range is opened up to CUBE
• CUBE is agnostic to the underlying IP path and cannot be behind a NAT
CUBE Firewall Deployment Scenarios
F/W
between SIP SIP Trunk SP VOIP
CUBE and H.323
CUBE SBC Services
ITSP
F/W between
CUBE and SIP SIP Trunk SP VOIP
rest of H.323 SBC Services
Enterprise UC CUBE
Network
F/W on SIP SIP Trunk SP VOIP

either side H.323 SBC Services
of CUBE CUBE
No SIP SIP Trunk SP VOIP

Firewall H.323 Services
CUBE SBC
Zone-based Firewall (ISR G2)
Global configuraiton
class-map match-any throttle_rtp
match protocol rtp
class-map type inspect sip match-any options-png
class-map type inspect sip match-any sip-match
class-map type inspect sip match-any options-ping policy-map type inspect sip throttle-Policy
match request method invite class type inspect sip options-throttle
class-map type inspect match-any sip-protocol rate-limit 2
match protocol sip policy-map throttle
class-map type inspect sip match-any options-throttle class sip
match request method options police 20000
class-map match-any sip class throttle_rtp
match protocol sip police 150000
! class class-default
police 8000
zone security inside policy-map throttle_rtp
zone security outside policy-map type inspect nonoptions-throttle
zone-pair security in2out source inside destination class type inspect sip-protocol
outside inspect
service-policy type inspect nonoptions-throttle service-policy sip throttle-Policy
zone-pair security out2in source outside destination class class-default
inside drop
service-policy type inspect nonoptions-throttle !
zone-pair security selfout source self destination
outside
service-policy type inspect nonoptions-throttle
zone-pair security outself source outside destination
self
service-policy type inspect nonoptions-throttle
Improving Security through Multi-VRF Call Routing
• Virtual Routing and Forwarding (VRF) is an IP technology that allows for multiple
instances of a routing table to coexist on the same router at the same time as
opposed to a single global route table, allowing for multiple virtual networks within a
single network entity to isolate between media and data virtual networks
Multi-VRF Aware Call Routing on CUBE
• Multi-VRF allows for the use of only one router to accomplish the tasks that multiple routers usually
perform as it provides logical separation of routing instances/tables (and by the implication address
space) within one router, that is, each VRF has its own routing table as opposed to a single global
route table
• CUBE allows intra and inter VRF routing of voice and video calls between Service providers and
customer networks
• Security can be improved by deploying Multi VRF at the network level
• IP address and Overlapped Dial Plan with Multi VRF feature provides seamless integration of
networks. CUBE can route VoIP calls across different VRF’s without the need of Route Leaks
SIP TLS Support
with SRTP
Secure SIP
• Requires deploying both SIP TLS (secure signaling) and SRTP (secure media)
• SRTP-RTP Interworking requires DSPs (secure transcoder) only on ISR G2s. DSPs are not needed
for SRTP-RTP interworking on ISR 4K, ASR 1K, and vCUBE
• CUBE initially supported only TLS v1.0 with following Cipher Suites
SSL_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_AES_128_CBC_SHA
• CUBE now supports TLS v1.2 with the following Cipher Suites
TLS_DHE_RSA_WITH_AES_128_CBC_SHA1
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS v1.2 is backward compatible ( fallback to TLS v1.0 / TLS v1.1 )
TLS Cipher Suite Category
• Default Ciphers – TLS_RSA_WITH_RC4_128_MD5,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA1,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
• Strict Ciphers – TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA1,
• ECDSA Ciphers – TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
SRTP Support
• CUBE and DSP initially provided SRTP support for the following crypto suites:
AES_CM_128_HMAC_SHA1_32
AES_CM_128_HMAC_SHA1_80
• AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) is required

AEAD_AES_128_GCM
AEAD_AES_256_GCM
AEAD_AES_128_CCM
AEAD_AES_256_CCM
• Since DSP doesn’t support these new crypto suites – CUBE will provide signaling and
media pass-through for the unsupported crypto suites
• CUBE will now be able to pass across crypto attributes (containing any unsupported
crypto suites) as well as media packets (encrypted with unsupported crypto suites)
SRTP Passthrough Configuration (Unsupported
Crypto Suites)
• A CLI has been enhanced to configure/enable pass-through of
unsupported crypto suites:
Global Configuration:
Dial-peer level configuration:
SIP TLS/SRTP support for Microsoft Skype for Business
(Lync) Interop
TLS 1.2 support on CUBE
• Secure SIP signaling from either/both Microsoft Skype4Business (Lync) Business to Business
clients or CUCM endpoints to CUBE
• Requires CUBE 11.5 or later
CUCM
Cluster
Cisco A
End Point
Internet
IP-PSTN Consumer to Business
CUBE
Lync
Client
SIP over TLS 1.2
Lync
Server SIP over TCP/UDP
CUBE Protection at Various Layers (1 of 4)
SBC Threat / Network Layer (protects at entry point Application Layer (CUBE)
in the network)
Security Protection built in the B2BUA layer
Requirement ACLs, NBAR, CoPP
Calls/Traffic from Access Control Lists (ACLs) to Allow/Deny Toll Fraud prevention using
untrusted sources Explicit Sources of Calls
a. IP Trust Lists [IOS 15.1(2)T]
a. Only allow service provider’s SBC to
b. Silent-discard CLI – TDoS attack
initiate traffic from PSTN side
mitigation [IOS 15.3(3)M]
b. Only allow your enterprise call agent
c. Topology/Address Hiding for both
(CUCM) to initiate traffic from internal
media and signaling
network side
d. SIP Trunk Registration/Authentication
c. Modifiable port range
– prevents session hijacking
Close unused H323/SIP ports and transport
e. Option to change well known listening
DoS/TDoS Attacks mechanisms.
sip-ua
ports
no transport tcp f. Explicit incoming/outgoing dial-peer
no transport udp
matching
Malformed Signaling NBAR – protection against Automatic checks by SIP/H.323 Protocol

Packets signaling(SIP/H.323/SIP-TLS), UDP attacks on stacks in IOS Voice code 261
open RTP ports, and crafted packets © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
in the network)
Large Rate of packet Control Plane Policing (CoPP policy) • CAC mechanisms based on
arrival, flooding implemented with ACLs – limits the rate of CPU/memory/bandwidth utilization and
packets and mitigates attacks from otherwise total number of calls
Trustred Sources
• Call Spike monitors call arrival rate over
a moving window of time
• UC Services API, External Voice Policy,
SecureLogix Solution (SIP Flooding)
Rogue/Phantom RTP / Deep packet inspection with ACL and NBAR • Define media address and RTP port
RTCP packets Policing ranges
• Source filter - Filters out incoming
incorrect remote address/port RTP
Packets
• Automatic checks by IOS Voice code on
Call-ID, RTP sequence numbers, SSRC
Malformed RTP / RTCP NBAR Policing to classify them as invalid RTP Library check in the IOS Voice code, 262
packets DSP check
in the network)
Encrypted signaling or • Service Providers provide SIP trunks over • TLS signed INVITES / Digest
media secure VPN Authentication
• IPSec for untrusted WAN segments, deploy • TLS to non-TLS, SRTP Passthru,
TLS/SRTP internally SRTP/RTP interworking
• Optional : Front end CUBE with an external • SHA1-80, SHA1-128, SHA1-256 crypto
FW suite
• Most SPs do not offer encrypted SIP
Trunks today
Rogue BYEs Policed with ACLs and Control Plane Policing Automatic checks at signaling Protocol
(ie Bye with Random Stack, Call Leg Transaction checks within
CallID) IOS Voice code
Eavesdropping/Privacy Encryption SIP-TLS with sRTP, UC Services API,
External Voice Policy, SecureLogix Solution
263
in the network)
Service Theft ACLs • Class of Restriction
IPSec • Toll Fraud prevention mechanisms listed
above
• SIP Trunk Registration
(authentication/credentials CLI)
• SIP Hostname Validation
• Encryption (TLS with SRTP)
• Monitor CDR from CUBE to scan for call
patterns and volumes that may indicate
unauthorized use
• UC Services API, External Voice Policy,
SecureLogix Solution
• TCL (blacklist/whitelist), PIN
authorization
Agenda
Monitoring
CUBE Monitoring
• Network Management Tools can be used to monitor key CUBE Some Network Management Tools:
statistics like SIP Trunk status, Trunk utilization, Call Arrival Rate,
Call Success/Failure count, voice quality metrics etc.. - Cisco Unified Operations Manager
- Arcana Networks
• Network Management Tools can send SNMP Queries to CUBE - Solarwinds
• CUBE responds to the SNMP queries with real time values

of the monitored objects
• CUBE can also send SNMP Traps to alert the
network management tool of certain events like
SIP Trunk failure, link down, high CPU etc..
Network
SNMP Management
Tool
Query
SNMP
Response
H.323 or SIP SIP SP IP

CUBE SBC Network
CUBE Monitoring For Your
Reference
Area Information Method

 CISCO-PROCESS-MIB, cpmCPUTotal5minRev
Router Health CPU, Memory, I/f  CISCO-MEMORY-POOL-MIB, ciscoMemoryPoolTable
 IF-MIB, IfEntry
SIP Trunk Status SIP Trunk Status  SIP OOD Options Ping, CLI dial-peer status
 CUBE 1.4: CISCO-VOICE-DIAL-CONTROL-MIB, cvCallVolume

 Older CUBE: DIAL-CONTROL-MIB, callActive
Trunk Utilization  CISCO-DIAL-CONTROL-MIB, cCallHistoryTable
 CUBE 8.5: SIP RAI Trunk Utilization
Traffic Reports (Calls, Call Arrival Rate  CUBE 1.4: CISCO-VOICE-DIAL-CONTROL-MIB, cvCallRateMonitor
Sessions, Capacity Planning,
Errors)
 DIAL-CONTROL-MIB, dialCtlPeerStatsSuccessCalls, dialCtlPeerStatsAcceptCalls,
Call Success/Failure dialCtlPeerStatsFailCalls, dialCtlPeerStatsRefuseCalls
 CISCO-SIP-UA-MIB, cSipStatsErrClient, cSipStatsErrServer, cSipStatsGlobalFail
SIP retries  CISCO-SIP-UA-MIB, cSipStatsRetry
DSP Availability  CISCO-DSP-MGMT-MIB, cdspCardResourceUtilization, cdspDspfarmUtilObjects

Media Resources
Transcoding util.  CUBE 1.4: CISCO-DSP-MGMT-MIB, cdspTotAvailTranscodeSess, cdspTotUnusedTranscodeSess
(DSPs)
MTP utilization  CUBE 1.4: CISCO-DSP-MGMT-MIB, cdspTotAvailMtpSess, cdspTotUnusedMtpSess
Loss, delay, jitter  CISCO-VOICE-DIAL-CONTROL-MIB, cvVoIPCallActiveTable

Voice Quality
IP SLA  CISCO-RTTMON-RTP-MIB, rttMonJitterStatsTable , rttMonLatestJitterOperTable
More info in CUBE Management and Manageability Specification at:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/white_paper_c11-613550.html
Also see BRKNMS-2333
Also see BRKUCC-2670
Prime Collaboration
Monitoring CUCM SIP Trunk Status Monitoring CUBE Status

• Capacity, Busy Hour Traffic, Average • CPU, DSP, Active Calls, etc.
Capacity
Prime Collaboration
CUBE Provisioning with Templates
service timestamps debug datetime msec

service timestamps log datetime msec
no service password-encryption
!
hostname ${hostname}
!
logging message-counter syslog
logging buffered 51200 warnings
no logging console
!
voice service voip
allow-connections sip to sip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
sip
rel1xx disable
header-passing error-passthru
early-offer forced
midcall-signaling passthru
sip-profiles 100
!
voice class codec 1
codec preference 1 ${codec-pref-1}
!
Prime Collaboration - Assurance
CUBE Features Benefits matrix
Features Benefits
Monitoring Cisco Unified  Has built in knowledge to auto-discover the CUBE system.
Border Element  It will also enable administrator to monitor CPU and DSP intensive tasks
(CUBE)
like Transcoding and MTP session usage. Administrator will get notified
when usage crosses the configured threshold.
Detecting SIP trunk Outage  Accurate Option Ping Method based CUBE SIP Trunk outage detection
Pro-actively Monitoring  Incoming or Outgoing Call stats to understand call traffic pattern
SIP trunk Utilization  Incoming or Outgoing Utilization to understand trunk usage pattern
Detecting DSP failure  Detects and notifies when a DSP chip/card fails that might potentially
cause service disruption such as call drop due to unavailability for
resources for transcoding.
Call Performance metrics  Additional CUBE KPIs such as call stats for deeper monitoring
Prime Collaboration
CUBE Performance metrics
Prime Collaboration - Assurance
CUBE SIP Trunk Usage Monitoring
• Monitors both individual SIP trunk
usage and Aggregated SIP Route
Group usage
• Provides 7 days trend graph
Prime Collaboration Assurance
CUBE Performance metrics
• Monitors and provide 7 days of

historical report for various CUBE
performance metrics
Prime Collaboration - Analytics
CUBE SIP Trunk Capacity Planning report
• Monitors both individual SIP trunk

usage and Aggregated SIP Route
Group usage
• Provides up to 1 year trend graph
Prime Collaboration - Analytics
CUBE SIP Trunk Busy Hour Erlang Capacity Planning report
Introducing ManageExpress® Border Manager
• Simplified provisioning
and management
• Uniform policies across all SBCs
• Real time 911/211 alerting
and monitoring
• Voice quality monitoring
• Reduce operational costs
• Available on the Cisco price list
Topology with Real Time Monitoring
Voice Quality Metrics
Voice Call Quality Monitoring on CUBE
• Three mechanism exist to monitor call quality statistics
1. End of call statistics in BYE message, 5 critical call parameters (MoSQe, Delay,
Jitter, Loss, OoO)
2. End of call CDRs if configured
3. Real time export of 30+ AQM via Flexible NetFlow
CDR Example or MIB file: CISCO-VOICE-DIAL-CONTROL-MIB
<MOS-Con>4.4072</MOS-Con>
<round-trip-delay>1 ms</round-trip-delay>
<receive-delay>64 ms</receive-delay>
<voice-quality-total-packet-loss>0.0000 %</ voice-quality-total-packet-loss>
< voice-quality-out-of-order>0.0000 %</ voice-quality-out-of-order>
• CDR will be sent to Radius server at the end of a call if AAA accounting is
configured
Audio Quality Monitor using Flexible NetFlow
• AQM uses FNF to export up to 30 voice quality metrics measured by “media monitoring” CLI
• To help the NetFlow collector to process the flow record, AQM also reports call related
information such as calling number, called number, call setup time, etc
Configuration to enable VQM Calculation

voice service voip
media monitoring [num] persist
! The max number of channels used for monitoring
media statistics
! Enable media statistics for VQM calculation
dial-peer voice [tag] voip

media monitoring
! Enable media monitoring on this dial-peer, every call leg matching this dial-peer will be monitored
For Your
FNF Configuration Reference
flow record type performance-monitor aqm collect application voice r-factor 1
match ipv4 source address collect application voice r-factor 2
match ipv4 destination address collect application voice mos conversation
match transport source-port collect application voice mos listening
match transport destination-port collect application voice concealment-ratio average
collect application voice number called collect application voice jitter configured type
collect application voice number calling collect application voice jitter configured minimum
collect application voice setup time collect application voice jitter configured maximum
collect application voice call duration collect application voice jitter configured initial
collect application voice rx bad-packet collect application voice rx early-packet count
collect application voice rx out-of-sequence collect application voice rx late-packet count
collect application voice codec id collect application voice jitter buffer-overrun
collect application voice play delay current collect application voice packet conceal-count
collect application voice play delay minimum !
collect application voice play delay maximum
collect application voice sip call-id
collect application voice router global-call-id
collect application voice delay round-trip
collect application voice delay end-point
For Your
FNF Configuration – Cont’d Reference
class-map match-all aqm-class

flow exporter aqm-exporter
match application rtp
destination <IP addr>
match application attribute media-type audio
source FastEthernet8
!
transport udp 2055
policy-map type performance-monitor aqm-policy
option application-attributes
! class aqm-class
flow monitor aqm-mon
flow monitor type performance-monitor aqm-mon
!
record aqm
interface FastEthernet8
exporter aqm-exporter
ip address 10.10.10.11 255.255.0.0
cache entries 1000
load-interval 30
cache timeout synchronized 10
history size 60 timeout 5 duplex full
speed 100
service-policy type performance-monitor input aqm-policy
service-policy type performance-monitor output aqm-policy
For Your
Viewing AQM Reference
CUBE# show call active voice stats
DSP/TX: PK=0, SG=0, NS=0, DU=0, VO=0

DSP/RX: PK=34, SG=0, CF=1, RX=660, VO=660, BS=0, BP=0, LP=0, EP=0
DSP/PD: CU=69, MI=69, MA=69, CO=0, IJ=0.0000
DSP/PE: PC=0, IC=0, SC=0, RM=0, BO=0, EE=0
DSP/LE: TP=0, TX=0, RP=0, RM=0, BN=0, ER=0, AC=0
DSP/ER: RD=0, TD=0, RC=0, TC=0
DSP/IC: IC=0
DSP/EC: CI=g711alaw, FM=5, FP=1, VS=0, GT=1.0000, GR=1.0000, JD=adaptive, JN=60,
JM=40, JX=1000
DSP/KF: KF=0.0000, AV=0.0000, MI=0.0000, BS=0.0000, NB=0, FL=0, NW=0, VR=0.0
DSP/CS: CR=0.0000, AV=0.0000, MX=0.0000, CT=0, TT=0, OK=0, CS=0, SC=0, TS=50, DC=0
DSP/RF: ML=-1.0000, MC=-1.0000, R1=-1, R2=-1, IF=0, ID=0, IE=0, BL=25, R0=93, VR=2.0
DSP/UC: U1=0, U2=0, T1=0, T2=0
DSP/DL: RT=0, ED=0
AQM viewing through ARCANA’s MEBM
AQM stats per network segment
Incremental metrics are provided through out the call
Troubleshooting
Troubleshooting of Calls
show cube status
Is CUBE Active ? CUBE-Version : 9.0
SW-Version : 15.2.1T, Platform 2911
HA-Type : none
Licensed-Capacity : 200
debug voip ccapi inout

Is the call matching Oct 26 18:59:01.146: //-1/66A6B1BF8013/CCAPI
cc_api_call_setup_ind_common:
right Dial-peers ? .................
Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE
Present=TRUE,
.................
Outgoing Dial-peer=100, Params=0x26E8574, Progress
Indication=NULL(0)
Are we sending the

debug ccsip messages
right SIP call to SP based
Received:
on their requirements ? INVITE sip:912025552000@14.128.101.24:5060 SIP/2.0
Date: Wed, 26 Oct 2011 18:59:01 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK,
UPDATE, REFER, SUBSCRIBE, NOTIFY
From: "Paul Hewson"
<sip:1500@10.88.156.166>;tag=90d94d92-6ee4-45aa-9f18-
2d09025c1ee4-27352390
................
CUBE Debugging
• When debugging in IOS, configure logging buffered to a fairly large value
(based on available memory)
• Disable logging to the console with command ‘no logging console’
• Enable timestamps for debugs
• Make sure router has NTP enabled
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
logging buffered 10000000

no logging console
clock timezone EST -5 0

clock summer-time EDT recurring
ntp server 10.14.1.1
SIP EO Debug
Sent: Example Internal External
INVITE sip:1000@20.1.1.2:5060 SIP/2.0 Network Network
Via: SIP/2.0/UDP 20.1.1.1:5060;branch=z9hG4bK1216FC SIP SP
Remote-Party-ID: <sip:2000@20.1.1.1>;party=calling;screen=no;privacy=off 10.1.1.1 CUBE 20.1.1.1
From: <sip:2000@20.1.1.1>;tag=48AE80-CD8 B2B User 20.1.1.2
To: <sip:1000@20.1.1.2> Agent
Date: Wed, 22 Jun 2011 12:33:15 GMT
Call-ID: A2F9661D-9C0211E0-803289BC-624E6E32@9.44.44.71
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800  Outbound INVITE message
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
User-Agent: Cisco-SIPGateway/IOS-12.x
 Sent with destination number as 1000 and IP address
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 20.1.1.2 on port 5060
SUBSCRIBE, NOTIFY, INFO, REGISTER  Calling number is 2000 with source IP address of call is
......... 20.1.1.1
.........  Cisco-GUID uniquely identifies this call leg
v=0
o=CiscoSystemsSIP-GW-UserAgent 2026 314 IN IP4 9.44.44.71
s=SIP Call  “c” parameter identifies the IP address (20.1.1.1) that the
c=IN IP4 20.1.1.1 peer device should send the media to
t=0 0  “m” parameter identifies:
m=audio 16950 RTP/AVP 18 101  the type of call (audio)
c=IN IP4 20.1.1.1
a=rtpmap:18 G729/8000
 port number for media (16950)
a=fmtp:18 annexb=no  payload type for the 1st preferred codec (18 for G729)
a=rtpmap:8 PCMA/8000  dtmf (101 for RFC2833)
a=rtpmap:101 telephone-event/8000  “a’” parameter identifies all the codecs and other
a=fmtp:101 0-15 descriptors for this call leg
SIP EO Debug
Example
Sent: Internal External

SIP SP
Sent:
Via: SIP/2.0/UDP 20.1.1.1:5060;branch=z9hG4bK1216FC
Remote-Party-ID: <sip:2000@20.1.1.1>;party=calling;screen=no;privacy=off
10.1.1.1 CUBE 20.1.1.1
INVITE
To: <sip:1000@20.1.1.2>
Date: Wed, 22 Jun 2011 12:33:15 GMT
Agent
Call-ID: A2F9661D-9C0211E0-803289BC-624E6E32@9.44.44.71  Outbound INVITE message

Supported: timer,resource-priority,replaces,sdp-anat  Sent with destination number as 1000 and IP address
Min-SE: 1800
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
20.1.1.2 on port 5060
User-Agent: Cisco-SIPGateway/IOS-12.x  Calling number is 2000 with source IP address of call is
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 20.1.1.1
SUBSCRIBE, NOTIFY, INFO, REGISTER
.........
 Outbound INVITE message  Cisco-GUID uniquely identifies this call leg
.........
v=0  “c” parameter identifies the IP address (20.1.1.1) that the

o=CiscoSystemsSIP-GW-UserAgent 2026 314 IN IP4 9.44.44.71 peer device should send the media to
s=SIP Call  “m” parameter identifies:
c=IN IP4 20.1.1.1  the type of call (audio)
t=0 0  port number for media (16950)
m=audio 16950 RTP/AVP 18 101
 payload type for the 1st preferred codec (18 for G729)
c=IN IP4 20.1.1.1
a=rtpmap:18 G729/8000  dtmf (101 for RFC2833)
a=fmtp:18 annexb=no  “a’” parameter identifies all the codecs and other
a=rtpmap:8 PCMA/8000 descriptors for this call leg
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
SIP EO Debug
Example
10.1.1.1 CUBE 20.1.1.1
To: <sip:1000@20.1.1.2> Agent
Date: Wed, 22 Jun 2011 12:33:15 GMT
Supported: timer,resource-priority,replaces,sdp-anat  Sent with destination number
Min-SE: 1800
INVITE sip:1000@20.1.1.2:5060 SIP/2.0
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
as 1000 and IP address
User-Agent: Cisco-SIPGateway/IOS-12.x 20.1.1.2 on port 5060
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,  Calling number is 2000 with source IP address of call is
To: <sip:1000@20.1.1.2>
SUBSCRIBE, NOTIFY, INFO, REGISTER 20.1.1.1
.........
v=0  “c”with
Sent parameter identifies the
destination IP address (20.1.1.1) that the
number
s=SIP Call
as 1000 and IP address
“m” parameter identifies:
c=IN IP4 20.1.1.1 20.1.1.2
 theon
typeport 5060
of call (audio)
t=0 0  port number for media (16950)
 payload type for the 1st preferred codec (18 for G729)
c=IN IP4 20.1.1.1
a=fmtp:101 0-15
SIP EO Debug
Example
10.1.1.1 20.1.1.1
Remote-Party-ID: <sip:2000@20.1.1.1>;party=calling;screen=no;privacy=off CUBE
To: <sip:1000@20.1.1.2> Agent
Date: Wed, 22 Jun 2011 12:33:15 GMT
From: <sip:2000@20.1.1.1>;tag=48AE80-CD8
Min-SE: 1800
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
20.1.1.2 on port 5060
User-Agent: Cisco-SIPGateway/IOS-12.x  Calling number is
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 2000 with source IP
SUBSCRIBE, NOTIFY, INFO, REGISTER address of call is 20.1.1.1
.........

s=SIP Call  Calling
 number
“m” parameter is 2000
identifies:
c=IN IP4 20.1.1.1  the type of call (audio)
t=0 0 with source
 port number IP address
for media (16950)of
c=IN IP4 20.1.1.1 call payload
is 20.1.1.1 st
type for the 1 preferred codec (18 for G729)
a=fmtp:101 0-15
SIP EO Debug
Example
Network Network
INVITE sip:1000@20.1.1.2:5060 SIP/2.0
SIP SP
Via: SIP/2.0/UDP 20.1.1.1:5060;branch=z9hG4bK1216FC 10.1.1.1 20.1.1.1
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
B2B User
CUBE
20.1.1.2
From: <sip:2000@20.1.1.1>;tag=48AE80-CD8
Agent
To: <sip:1000@20.1.1.2>
Date: Wed, 22 Jun 2011 12:33:15 GMT
Min-SE: 1800
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
20.1.1.2 on port 5060
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 2000 with source IP address of call is 20.1.1.1
SUBSCRIBE, NOTIFY, INFO, REGISTER  Cisco-GUID uniquely
......... identifies this call leg
.........

s=SIP Call  “m” parameter identifies:
c=IN IP4 20.1.1.1
t=0 0
 Cisco-GUID
 the type of call (audio)
uniquely
c=IN IP4 20.1.1.1
identifies this
 payload typecall
for the 1st preferred codec (18 for G729)
a=fmtp:101 0-15
SIP EO Debug
Example
10.1.1.1 CUBE 20.1.1.1
To: <sip:1000@20.1.1.2> Agent
Date: Wed, 22 Jun 2011 12:33:15 GMT
Supported: timer,resource-priority,replaces,sdp-anat  “c” parameter
 Sent withidentifies the IP
destination number address
as 1000 and IP address
Min-SE: 1800
20.1.1.2 on port 5060
c=IN2734093693-2617381344-2150402492-1649307186
Cisco-Guid: IP4 20.1.1.1 (20.1.1.1) that the peer device should
 Calling number is
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, send the2000
media to IP address of call is 20.1.1.1
with source
c=IN IP4NOTIFY,
SUBSCRIBE, 20.1.1.1INFO, REGISTER  Cisco-GUID uniquely identifies this call leg
.........
.........
v=0  “c” parameter identifies the IP address

o=CiscoSystemsSIP-GW-UserAgent 2026 314 IN IP4 9.44.44.71 (20.1.1.1) that the peer device should
s=SIP Call send the media to
c=IN IP4 20.1.1.1  “m” parameter identifies:
t=0 0  the type of call (audio)
c=IN IP4 20.1.1.1
a=rtpmap:18 G729/8000  payload type for the 1st preferred codec (18 for G729)
a=fmtp:18 annexb=no  dtmf (101 for RFC2833)
a=rtpmap:8 PCMA/8000  “a’” parameter identifies all the codecs and other
a=rtpmap:101 telephone-event/8000 descriptors for this call leg
a=fmtp:101 0-15
SIP EO Debug
Example
Network Network
INVITE sip:1000@20.1.1.2:5060 SIP/2.0
SIP SP
Via: SIP/2.0/UDP 20.1.1.1:5060;branch=z9hG4bK1216FC 10.1.1.1 CUBE 20.1.1.1
Agent
To: <sip:1000@20.1.1.2>
Date: Wed, 22 Jun 2011 12:33:15 GMT
Call-ID: A2F9661D-9C0211E0-803289BC-624E6E32@9.44.44.71
Supported: timer,resource-priority,replaces,sdp-anat
 m” parameter identifies:
 Outbound INVITE message
 Sent with destination number as 1000 and IP address
Min-SE: 1800  the type ofoncall
20.1.1.2 port (audio)
5060
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
User-Agent: Cisco-SIPGateway/IOS-12.x  port number for media (16950)
 Calling number is
SUBSCRIBE, NOTIFY, INFO, REGISTER  payload type uniquely
 Cisco-GUID 1st preferred
for theidentifies this call leg
.........
.........
codec (18 for G729)
 dtmf (101 for RFC2833)
“c” parameter identifies the IP address
m=audio
v=0 16950 RTP/AVP 18 101 (20.1.1.1) that the peer device should
o=CiscoSystemsSIP-GW-UserAgent 2026 314 IN IP4 9.44.44.71
c=IN IP4 20.1.1.1  “m” parameter identifies:
t=0 0  the type of call (audio)
c=IN IP4 20.1.1.1
a=rtpmap:18 G729/8000  payload type for the 1st preferred
a=fmtp:18 annexb=no codec (18 for G729)
a=rtpmap:8 PCMA/8000  dtmf (101 for RFC2833)
a=rtpmap:101 telephone-event/8000  “a’” parameter identifies all the codecs and other
a=fmtp:101 0-15 descriptors for this call leg
SIP EO Debug
Example
Network Network
INVITE sip:1000@20.1.1.2:5060 SIP/2.0
SIP SP
Via: SIP/2.0/UDP 20.1.1.1:5060;branch=z9hG4bK1216FC
a=rtpmap:18 G729/8000
10.1.1.1 CUBE 20.1.1.1
B2B User 20.1.1.2
a=fmtp:18 annexb=no
From: <sip:2000@20.1.1.1>;tag=48AE80-CD8
To: <sip:1000@20.1.1.2>
Agent
a=rtpmap:8 PCMA/8000
Date: Wed, 22 Jun 2011 12:33:15 GMT
Min-SE: 1800
a=fmtp:101 0-15
Cisco-Guid: 2734093693-2617381344-2150402492-1649307186
20.1.1.2 on port 5060
SUBSCRIBE, NOTIFY, INFO, REGISTER  Cisco-GUID uniquely identifies this call leg
.........
.........
v=0  “c” parameter identifies the IP address

o=CiscoSystemsSIP-GW-UserAgent 2026 314 IN IP4 9.44.44.71 (20.1.1.1) that the peer device should
c=IN IP4 20.1.1.1  “a’” parameter identifies
 “m” parameter all the codecs
identifies:
t=0 0  the type of call
m=audio 16950 RTP/AVP 18 101 and other descriptors for(audio)
this call leg
c=IN IP4 20.1.1.1
a=rtpmap:18 G729/8000  payload type for the 1st preferred codec (18 for G729)
a=fmtp:18 annexb=no  dtmf (101 for RFC2833)
a=rtpmap:8 PCMA/8000  “a’” parameter identifies all the codecs
a=rtpmap:101 telephone-event/8000 and other descriptors for this call leg
a=fmtp:101 0-15
CUBE Per-Call Debugging (PCD)
• Useful for CUBE under high call volume
• Available on all CUBE(Ent) ASR releases and in 15.1(2)T and later on ISR
• All the debug pertaining to a particular call goes into a buffer
• “Trigger-points” looks for specific info in the buffers to export the debug info to
an output destination
• Can trigger based on user-defined criteria or log every call
• SIP 4XX, 5XX, or 6XX Response
• Q.850 Cause code
• Call Admission Control limits
For Your
Reference
CUBE Per-Call Debugging (PCD)
1. Define buffers and buffer sizes 4. Export debug buffer content
per-call num-buffer <num> per-call export primary [flash | ftp |
per-call buffer-size debug <num> http | pram | rcp | tftp] secondary
[flash | ftp | http | pram | rcp | tftp]
2. Turn per-call debugging on/off 5. Show buffer content status

per-call shutdown show per-call stat
per-call active debug show per-call buffer list
per-call inactive
3. Set trigger points 6. Show buffer contents on console

per-call trigger cause 1 router#show per-call buffer content ?
per-call trigger cause 41 <0-10000000> Specify the buffer num
per-call trigger sip-message 404
per-call trigger sip-message 488 router#show per-call buffer content 1
IOS Embedded Packet capture on ISR-G2
Provides ability to do packet captures only for interested traffic from within IOS
Step 1. Configure capture profile
ip traffic-export profile BRKUCC2934 mode
capture Create profile with
bidirectional name “BRKUCC2934”
incoming access-list 123
outgoing access-list 123 Create access-lists to define “interesting” traffic
In this eg, only SIP Traffic (TCP/UDP port 5060) is
access-list 123 permit udp any any eq 5060 being captured
access-list 123 permit tcp any any eq 5060
interface fa0/0 Apply this profile to an

ip traffic-export apply BRKUCC2934 [size interface that this traffic
<bytes>] traverses
2. Capture traffic with these exec

(enable) level commands
Note: The exec cmds don’t appear until a profile has been configured
router# traffic-export interface fa0/0 clear • Clear the buffer to remove
router# traffic-export interface fa0/0 start previous contents
<capture the problem> • Start the capture when ready
router# traffic-export interface fa0/0 stop • Stop after the problem is captured
IOS Embedded Packet capture (.. cont’d)
Step 3. Export the pcap file to a server
router# traffic-export interface fa0/0 copy Export the contents of the
ftp://x.x.x.x/BRKUCC2934_capture.pcap buffer to an external FTP
server as a PCAP file
Step 4. Display ladder diagram
(with Wireshark)
The PCAP file can be viewed

in Wireshark. It provides the
ability to filter based on
calling/called numbers and
create a flow graph as
shown
Debug Decoder: http://translatorx.cisco.com
IP Traffic Capture: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html

Serviceability
New CUBE Serviceability Features
Call Arrival Rate
Example:
show call history stats cps
Histogram for Call rate 1122222357676678753222211111122247545789774322213311112245654598843333222

10
Histogram for Concurrent calls 9 * *
8 * ** ***
Histogram for Call duration 7 * * *** * ***** * ##*
6 ******** * ***** ** *##*
Histogram for SIP message rate 5 *########* #* *####* *######*
High/Low watermark for Call Rate 4 *########* *#***####** *########*
3 **########** *#########** ** *########*****
High/Low watermark for Concurrent calls 2 ******#########***** ****##########**** ** ***########********
1 *######################################################################*
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
High/Low watermark for SIP message rate 0 5 0 5 0 5 0 5 0 5 0 5 0
Call switching rate / CPS (last 72 hours)
* = maximum calls/s # = average calls/s
Histogram for Call Failure Rate
High/Low watermark for Call Failure Rate
Call History Stats – Graphical or Tabular form
Last 60 sec, 60 minutes, 72 hours
show call history stats connected [table]
Ability to sort dial-peers
show run dial-peer sort
dial-peer (default) dial-peer sort dial-peer sort descending

dial-peer voice 4020 pots dial-peer voice 5 pots dial-peer voice 5000 voip
destination-pattern 4020 incoming called-number 1... destination-pattern 5...
port 0/2/0 port 1/0/0:23 session protocol sipv2
! ! session target ipv4:1.4.65.5
dial-peer voice 5000 voip dial-peer voice 4020 pots !
destination-pattern 5... destination-pattern 4020 dial-peer voice 4020 pots
session protocol sipv2 port 0/2/0 destination-pattern 4020
session target ipv4:1.4.65.5 ! port 0/2/0 Dial Peer
! dial-peer voice 5000 voip ! tag
dial-peer voice 5 pots destination-pattern 5... dial-peer voice 5 pots
incoming called-number 1... session protocol sipv2 incoming called-number 1...
port 1/0/0:23 session target ipv4:1.4.65.5 port 1/0/0:23
Total Number of Active Concurrent Calls
Total Number of Active Calls
Router# show call active total-calls

 A single call can have multiple call-
Total Number of Active Calls : 10
legs. To determine the total number
of active calls from call-legs is Connected
challenging Call Flow Call-legs
call
 CLI added to display the value of Basic call (audio/video) 2 1
current number of active
(connected) calls on CUBE Transferred call (Refer 3 2
handling)
 The table defines the relation
between call-legs and number of Transcoded call (SCCP) 4 1
active calls Calls after rotary/hunt 2+x 1
Forwarded calls (CUBE 3 1
handling)
Forked call (media forking) 3 2
Forked call (signaling forking) 2 1
Avoiding Non-Call-Context Debug Logs
• Many times SIP debugs contain unrelated debugs that are not useful in
debugging issues related to call failures
• Starting CUBE 10.0.1, non-call-context debugs will not be printed when
debug ccsip is issued
• This applies to messages originating from CUBE. Non-call context
INBOUND messages towards CUBE will still be printed when
debug ccsip is issued.
• If a message is not part of any call, that debug will not be printed
• Affected messages: OPTIONS, REGISTER, SUBSCRIBE/NOTIFY
• To see the above OUTBOUND messages in debugs, issue the following
command
debug ccsip non-call
Debugging Made Easier
Categorize Debugs based on Severity
 Existing SIP debugs have become Router# debug ccsip level <critical | info |
too verbose and un-manageable. To notify | verbose>
minimize verbosity, the SIP-INFO
debugs are further categorized
based on functionality and Level
Severity Level Description
 Categories only applicable when
CCSIP INFO or ALL debug is 1 Critical Feature specific Errors, things going wrong,
enabled resource failures that does not fail call as such
 Categorization based on Severity 2 Notifications Important milestones reached. Important steps

while processing that needs to be noticed
1. Critical
3 Informational Much of the details to understand flow. These
2. Notifications
give more information related to working of flow
3. Informational
4 Verbose Information that is in too detail and not really
4. Verbose
much helpful in debugging
Categorize Debugs based on Functionality
 Categorization based on
Functionality Router# debug ccsip feature < audio | cac |
1. Audio/video/sdp/control config | control | dtmf | fax | line | misc |
2. Configuration /sip-transport misc-features | parse | registration | sdp-
3. CAC negotiation | sdp-passthrough | sip-profiles |
4. DTMF/FAX/Line-side sip-transport | srtp | supplementary-services
5. Registration | transcoder | video >
6. Sdp - passthrough
7. Sip-profile/SRTP/transcoder
Example: enabling DTMF and audio debugs only with default log level is considered.
DTMF(32) debug code
CUBE#sh debugging
CCSIP SPI: SIP info debug tracing is enabled (filter is OFF)
CCSIP SPI: audio debugging for ccsip info is enabled (active) Audio(2) debug code
CCSIP SPI: dtmf debugging for ccsip info is enabled (active)
May 21 17:54:53.377: //444/5FE632EB8479/SIP/Info/verbose/32/sipSPI_ipip_store_channel_info: dtmf negotiation

done, storing negotiated dtmf = 0,
May 21 17:54:53.377: //444/5FE632EB8479/SIP/Info/info/2/sipSPIUpdateCallEntry:
Categorize Debugs based on Functionality
|-----------------------------------------------
| show cube debug category codes values.
CUBE# show cube debug category codes |-----------------------------------------------
| Indx | Debug Name | Value
|-----------------------------------------------
| 01 | SDP Debugs | 1
 This CLI is used to collect the | 02 | Audio Debugs | 2
predefined debug features category | 03 | Video Debugs | 4
| 04 | Fax Debugs | 8
codes , which helps in analysis of | 05 | SRTP Debugs | 16
debugs manually. | 06 | DTMF Debugs | 32
| 07 | SIP Profiles Debugs | 64
| 08 | SDP Passthrough Deb | 128
| 09 | Transcoder Debugs | 256
| 10 | SIP Transport Debugs | 512
| 11 | Parse Debugs | 1024
| 12 | Config Debugs | 2048
| 13 | Control Debugs | 4096
| 14 | Mischellaneous Debugs| 8192
| 15 | Supp Service Debugs | 16384
| 16 | Misc Features Debugs| 32768
| 17 | SIP Line-side Debugs | 65536
| 18 | CAC Debugs | 131072
| 19 | Registration Debugs | 262144
|-----------------------------------------------
Agenda
IP Trunk Evolution – Cutting edge designs
Media Manipulation & Optimization Cloud Connected Audio
Improved quality of speech
by Noise Cancellation, Customer
Acoustic shock prevention Speech corrupted with Network
background noise
SIP Trunk to
IP Cloud
Webex
Cisco
peerin
WebEx
A g
iPOP
SIP Trunk SP Cisco WebEx
CUBE Collaboration Cloud conne
ction
Network based recording Integration of Voice Policies

SecureLogix
Application Layer
Partner Voice Policy:
Application
 Centralized voice policy
creation/distribution
Cisco
Media UC  Protection from external
MediaSense
Application harassing calls
Sense  Service Abuse control
A Network by internal users
SIP Trunk SP  Enterprise-wide UC
CUBE reporting & analytics
Platform  Compliance & Data
Leakage prevention
Key Takeaways
• It is a manageable transition from existing TDM based networks to SIP
networks using these network design techniques
• Enterprise SBC (Cisco Unified Border Element - CUBE) is an essential
component of a UC solution providing;
• Security, Session Management, Interworking, Demarcation
• Over 18,000 Enterprise customers all over the Globe
• Proven interoperability with 3rd party PBX vendors and different service providers
around the world (more than 160 countries)
• Now is the time to deploy SIP Trunking in either a Centralized or a Distributed
solution to save money, simplify your topology and setup your infrastructure for
future services
• Complete feature Presentations, Lab Guide, Free Hands-on Lab access &
Application Notes :
»https://cisco.box.com/cube
Complete Your Online
Session Evaluation
• Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner will
receive a $750 gift card.
• Complete your session surveys
through the Cisco Live mobile
app or on www.CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be

available for viewing on demand after the
event at www.CiscoLive.com/Online.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Lunch & Learn
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you

Deploying Enterprise SIP Trunks With CUBE, CUCM - Cisco Live PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deploying Enterprise SIP Trunks With CUBE, CUCM - Cisco Live PDF

Uploaded by

Copyright:

Available Formats

Deploying Enterprise

SIP Trunks with CUBE

Cisco Spark spaces will be cs.co/ciscolivebot#LTRCOL-2310

Rich Media Rich Media

Call Admissions Encryption SIP - SIP Fault Isolation

3900 Series ISR-G2 (3925, 3945)

4 <50 500-600 900-1000 2000-2500 4000 4500-6000 7000-10,000 12K-14K 14-16K

Active Concurrent Voice Calls Capacity

Platform CUBE SIP-SIP Sessions (Audio)

11.5.14 15.6(2)T14 Mar 2016 N/A 3 16.2.13 Mar 2016

Proven Interoperability and Interworking with

MIGRATE WITH EXISTING EQUIPMENT INTEROPERABILITY

 Migration to SIP is phased CUBE  Standards Based

 Portfolio breadth  Broadest depth of protocols: SIP

Cisco 881, 886, 887, 888, 892F, SPIAD FL-NANOCUBE N/A

vCUBE (CUBE on CSR 1000v)

• Are CUBE licenses incremental?

• Is CUBE Licensing Enforced?

• Does a call recording solution require additional licensing?

• Can a customer migrate from a Single-Use to a RED license?

• Can standalone CUBE Licenses be transferred?

Two active CUBEs, no redundancy (i.e.

Expecting 100 sessions across each

Layer 2 Box-to-Box Redundancy with

Expecting 100 sessions across an active CUBE

What if the standby CUBE was at a different

• CUBE provides session border control

• Session control Mobile CUBE Cisco B2B

IVR CVP Media

Business to SIP SP IP SIP

Small SIP SIP PRI

CUBE CUBE CUBE Site-SP Media

CUBE CUBE CUBE

 Signaling is terminated, interpreted and Media Flow-Through

 Media is handled in two different modes: CUBE

dial-peer voice 1 voip dial-peer voice 2 voip

VRF1 – 10.10.10.10 CUBE 20.20.20.20 – VRF2

180 RINGING 180 RINGING

CUBE# show voip rtp connections

 ASR: Pkt fwd’ing and signaling are handled by

RP (control plane) ESP (data plane) FFP code

Chassis Mgr. QFP Client Chassis Mgr.

CUBE signaling CUBE media processing

CSR 1000v (virtual IOS-XE)

Hypervisor vSwitch NIC

X86 Multi-Core CPU Memory Banks Hardware GE … GE

VXML GW Not Available Exists Not Available Not Available

A Enterprise Campus CUBE

CUBE with High

PSTN is now • Step 4 – Configure call routing on

2. Configure any other global settings to meet SP’s requirements

voice class sip-profiles 100

Configure voice class sip-profiles 500

Apply to dial-peer voice 4000 voip

Enable Inbound SIP voice service voip

voice class sip-profiles 1

rule before 2 request INVITE sip-header To Modify “(.*)” “\1;temp=abc”

request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

rule 1 request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

rule 1 request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

CUBE(config-class)#request INVITE sip-header WORD ?

MPLS • Provides the ability to