Brkcol 2125

Deploying SIP Trunks with Cisco
Unified Border Element

(CUBE/vCUBE) Enterprise
Hussain Ali, CCIE# 38068 (Voice, Collaboration)
Technical Marketing Engineer
BRKCOL-2125
Agenda
• SIP Trunking and CUBE Overview

• CUBE Architecture (Physical & Virtual)
• Transitioning to SIP Trunking using CUBE
• Advanced features on CUBE (Call Recording, Multi-Tenancy, HA)
• CUBE Management & Troubleshooting
• Futures & Key Takeaways
CUBE Overview
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

BRKCOL-2125 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 5
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 CUBE Ent ASR 1K1 / ISR-4K1/vCUBE (CSR)1
ASR Parity
CUBE Vers. 2900/ 3900 FCS with ISR CUBE Vers. IOS XE Release FCS
11.0.0 15.5(2)T Mar 2015 >95% 11.0.0 3.15 15.5(2)S Mar 2015
11.1.0 15.5(3)M July 2015 >95% 11.1.0 3.16 15.5(3)S July 2015
11.5.0 15.6(1)T Nov 2015 >95% 11.5.0 3.17 15.6(1)S Nov 2015
CUBE Vers. 2900/ 3900 FCS CUBE 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)M July 2016 11.5.23 16.3.13 July 2016
1 IOS-XE3.13.1/3.16.1 or later recommended for all ISR-4K series and XE3.16.1 or later for vCUBE
2 IOS-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 IOS 15.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
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
Agenda

CUBE Call Flow
CUBE Call Processing
CUBE
 Actively involved in the call treatment,
signaling and media streams
 SIP B2B User Agent IP
Media Flow-Through
 Signaling is terminated, interpreted and
 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 on 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

destination-pattern 1000 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
Control Plane CPU
IOS
RP Control
Plane
IOS IOS
I/O I/O
Signaling
Signaling
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
• Can be installed either using an OVA file or deployed with an ISO image
• 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]
© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
CME/SRST feature set Not Available Exists XE3.11 Not Available
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
Agenda

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
PSTN is now
calls (central and branch) to CUBE via
used only for
a SIP trunk
emergency
SRST calls over
• Make sure all different patterns of calls
FXO lines
– local, long distance, international,
emergency, CME
informational etc.. are
pointing to CUBE
TDM PBX
Enterprise
Branch Offices
Step 2: Get details from SIP Trunk provider
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
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  For Rx/Tx counters to increment on IOS-XE based platforms. W/O this CLI, it will show 0/0
no h323  Disable H323 if not using it
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 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 “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
used only for
• Dial-Peer – “static routing” table mapping phone numbers
emergencytocalls
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 the SIP Trunk provider for sending
TDM PBX
& receiving calls to & from the Branch
Enterprise provider
Offices
WAN Dial-Peer Configuration
Inbound Dial-Peer for call legs from SP to CUBE
dial-peer voice 100 voip
description *** Inbound WAN side dial-peer *** Specific to your DID range
incoming called-number 408527….$
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 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
session target ipv4:<SIP_Trunk_IP_Address>
American Numbering Plan)
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
Apply bind to all dial-peers when
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 408527….$ 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 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Step 5: 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
For Your
Normalize Inbound SIP Message (Example 2) Reference
CUBE SIP Diversion header must include a user portion
Requirement
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
……… ……….
User-Agent: SP-SBC User-Agent: SP-SBC
……… ……….
Diversion: <sip:9.44.44.4>;privacy=off; Diversion: <sip:1234@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
……... ………..
Enable Inbound SIP voice service voip

Profile feature sip
sip-profiles inbound
Configure Inbound
SIP Profile to add a voice class sip-profiles 700
dummy user part request INVITE sip-header Diversion modify “sip:” sip:1234@
dial-peer voice 4000 voip voice service voip
Apply to Dial-peer description Incoming/outgoing SP sip
or Globally voice-class sip profiles 700 inbound sip profiles 700 inbound
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
voice class sip-profiles 1 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”
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
• 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
Understanding Inbound Dial-Peer Matching Techniques
Priority
Inbound LAN Dial-Peer Outbound Calls
Filter dial-peers based
0 on incoming VRF if A CUCM SIP Trunk SP SIP Trunk
IP
configured and then 1 CUBE PSTN
to 4 below
Exact Pattern Inbound Calls
match Inbound WAN Dial-Peer
Match Based on URI of
Host Name/IP
1 an incoming INVITE Address Received:
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
tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
Match based on Called Phone-number of
2 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
CSeq: 1 INVITE
Match based on Calling
3 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
........
Understanding Outbound Dial-Peer Matching Techniques
Priority Outbound WAN Dial-Peer
Outbound Calls
Exact Pattern
Match Based on URI of match
A CUCM SIP Trunk SP SIP Trunk
Host Name/IP IP
1 incoming INVITE
Address CUBE PSTN
message & carrier-id
target User portion of
Inbound Calls
URI
Outbound LAN Dial-Peer
tel-uri
2 Number & carrier-id Received:
target INVITE sip:654321@10.2.1.1 SIP/2.0
Exact Pattern Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
match tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
Match based on URI of Host Name/IP From: "555" <sip:555@10.1.1.1:5060>;tag=1
3 an incoming INVITE Address To: ABC <sip:654321@10.2.1.1:5060>
message Call-ID: 1-23955@10.1.1.1
User portion of
CSeq: 1 INVITE
URI
Contact: sip:555@10.1.1.1:5060
Phone-number of
Match based on Called tel-uri
Supported: timer
4 Max-Forwards: 70
number
Subject: BRKUCC-2934 Session
Content-Type: application/sdp
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
Module 7
Multiple Incoming Patterns Under Same
Incoming/Outgoing Dial-peer
voice class e164-pattern-map 300 Provides the ability to combine multiple
e164 919200200.
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-
(510)100-1000 dial-peer voice 1 voip
Site B description Inbound DP via Calling peers required with the same routing
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 Outbound DP via Called
Site C (408)100-1010 9192002010
destination e164-pattern-map 400 5101001010
codec g711ulaw 4081001010
G711 Sites
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 1341
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 1341
description Inbound DP session protocol sipv2
incoming called-number 1341 session target ipv4:10.1.1.2
destination dpg 10000 !
destination-pattern 1341
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
External/PSTN Call Recording
External/PSTN Call Recording Options
• 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>
RTP session protocol sipv2 ! Bind on this DP mandatory
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
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] BRKCOL-2125 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 58
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
Standby (10.10.10.2)
than one SIP Trunk provider for:
CUBE
A
Active • Alternate call routing
CUBE
SIP SP-2
(20.20.20.2)
• Load balancing
Enterprise CUBE with High
Campus Availability
MPLS
SIP SP-1’s interface loopback1 dial-peer voice 20 voip
network ip address 10.10.10.1 255.255.255.0 description “Secondary path to SIP SP-2”
destination-pattern 91[2-9]..[2-9]......
SIP SP-2’s interface loopback2 session protocol sipv2
network ip address 20.20.20.1 255.255.255.0 session target ipv4:20.20.20.2
SRST 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
destination-pattern 91[2-9]..[2-9]...... voice-class sip bind media source-interface loopback2
CMEsession protocol sipv2
session target ipv4:10.10.10.2 NOTE: Dual SPs can be used for outbound calls, but to be
voice-class sip options-keepalive utilized for inbound calls, arrangements between SPs
TDM PBX
voice-class sip bind control source-interface loopback1 required
Enterprise
voice-class sip bind media source-interface loopback1
Branch Offices
Multiple Authenticated/Registered
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 E164 - aaaa Registrar - 1
credentials username bbbb password 7 110B1B0715 realm bbbb.com
voice service voip Registrar - 2
E164 - bbbb
outbound-proxy ipv4:10.64.86.35:9057
bind control source-interface GigabitEthernet0/1
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
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
Understanding Inbound Dial-Peer Matching Techniques
Priority
Inbound LAN Dial-Peer Outbound Calls
Filter dial-peers based
0 on incoming VRF if A CUCM SIP Trunk SP SIP Trunk
IP
configured and then 1 PSTN
CUBE
to 3 below
Exact Pattern Inbound Calls
match Inbound WAN Dial-Peer
Match Based on URI of
Host Name/IP
1 an incoming INVITE Address Received:
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
tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
2 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
CSeq: 1 INVITE
Match based on Calling
3 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 1 is matched
 For VRF 2, dial-peer 2 is matched
CUBE Multi VRF – Inter/Intra VRF Routing
INVITE sip:3000@7.44.44.13 INVITE sip:2000@6.44.44.13
VRF 1 VRF 2
INVITE sip:2000@7.44.44.13 CUBE INVITE sip:3000@6.44.44.13

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
VRF1
VRF2
session-target ipv4: 10.1.1.1 session-target ipv4:10.2.2.2

VRF1
VRF2
incoming called-number 2000 Intra VRF incoming called-number 3000
Routing © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
CUBE Multi VRF – Routing w/ Overlapped Dial Plan
INVITE INVITE
sip:2000@10.1.1.1 sip:2000@10.2.2.2
INVITE INVITE
sip:2000@7.44.44.13 sip:2000@6.44.44.13
ip vrf vrf1
ip vrf vrf2
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 111 voice class dpg 222
dial-peer 11 preference 1 outbound
dial-peer 22 preference 1
dial-peer groups
destination dpg 111 destination dpg 222
VRF1 VRF2
session-target ipv4:10.1.1.1 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
ip vrf vrf1
ip vrf vrf2
interface GigabitEthernet0/0/0 Overlapped interface GigabitEthernet0/0/1
ip vrf forwarding vrf1 local IP
ip vrf forwarding vrf2
destination dpg 111 destination dpg 222
voice class dpg 111 VRF1 VRF2 voice class dpg 222
dial-peer 11 preference 1 dial-peer 22 preference 1
destination-pattern 1000 Overlapped destination-pattern 2000
session-target ipv4:10.1.1.1 Remote IP 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 standby 1 preempt
interface if no VRFs
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 address 128.107.66.77 255.255.255.0 Outside ip vrf forwarding WAN-VRF
standby version 2 ip address 128.107.66.78 255.255.255.0
interfaces : standby version 2
standby 10 ip 128.107.66.79
standby delay minimum 30 reload 60
HSRP group 10 standby 10 ip 128.107.66.79
standby 10 preempt VRF ID : WAN- standby delay minimum 30 reload 60
standby 10 track 1 decrement 10 VRF (if standby 10 preempt
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
! !
track 1 interface Gig0/0 line-protocol Configure Interface
Tracking (for line protocol track 1 interface Gig0/0 line-protocol
track 2 interface Gig0/1 line-protocol track 2 interface Gig0/1 line-protocol
track 3 interface Gig0/2 line-protocol on corresponding
interfaces of the platform track 3 interface Gig0/2 line-protocol
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

• 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
• When configuration is applied and saved, the platform must go through a reload cycle
• RG Control/Data Interfaces (GE0/0/2) must be connected through a Switch and not a Crossover Cable
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
WAN
rii 1
rii 2
rii 3
Switch D Switch E Switch A Switch B Switch C Edge
PortChannel34
CUCM
Gig0/0/3 Gig0/0/4 ITSP 2
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
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 97
BRKCOL-2125 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda

Serviceability
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 tag
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 voice 5000 voip !
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 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-
5. Registration services | 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)
CCSIP SPI: dtmf debugging for ccsip info is enabled (active) Audio(2) debug code
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:
Call 444 set InfoType to SPEECH
Debugging Made Easier
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 17,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
• Please complete your Online
Session Evaluations after each
session
• Complete 4 Session Evaluations &
the Overall Conference Evaluation
(available from Thursday) to receive
your Cisco Live T-shirt
• All surveys can be completed via
the Cisco Live Mobile App or the
Don’t forget: Cisco Live sessions will be available
Communication Stations for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Lunch & Learn
• Meet the Engineer 1:1 meetings
• Related sessions
Thank You

Brkcol 2125

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

Brkcol 2125

Uploaded by

Copyright:

Available Formats

Deploying SIP Trunks with Cisco

Unified Border Element

• SIP Trunking and CUBE Overview

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)

Proven Interoperability and Interworking with

• SIP Trunking and CUBE Overview

 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

 ISR: Pkt fwd’ing and signaling are handled by the

 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

• SIP Trunking and CUBE Overview

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

3. Create a trusted list of IP addresses to prevent toll-fraud

Outbound Dial-Peer for call legs from CUBE to SP

voice class sip-profiles 100

Enable Inbound SIP voice service voip

voice class sip-profiles 1

• For inserting a rule between two rules using “before” option:

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

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

• After auto upgrade, the rules will be automatically upgraded as follows:

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

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

• After auto downgrade, the rules will be automatically downgraded as follows:

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

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

• SIP Trunking and CUBE Overview

Inbound LAN Dial-Peer Outbound Calls Outbound WAN Dial-Peer

* DNS target not supported in server group

G729 Sites A SIP Trunk SP SIP Trunk IP PSTN

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

• CUBE Controlled (Dial-peer based SIPREC)

• CUCM NBR (Network Based Recording)

Cisco Proprietary Metadata

media profile recorder 100 dial-peer voice 950 voip

SIPREC Compliant Recorder Recorder • Metadata includes the

media class 9 dial-peer voice 950 voip

1. Enable HTTP on IOS

2. Enable the API on IOS

3. Enable XMF service within the API

[1] – [3]: An external call is answered by user with IP phone

Now Supports Inbound CVP (Survivability.tcl) Call Recording

• No provision to configure specific bind/credentials/outbound proxy for

• Every Registrar/User Agent/ITSP connected to CUBE can be considered a

With Voice Class Tenant (Multi-Tenancy)

• Apply tenant to the desired dial-peer

ip vrf vrf1 ip vrf vrf2

interface GigabitEthernet0/0/0 interface GigabitEthernet0/0/1

ip vrf vrf1 ip vrf vrf2

 Inbound match based on VRF where SIP INVITE received

ip vrf vrf1 ip vrf vrf2