Brkcol 2125

Deploying SIP Trunks with Cisco
Unified Border Element

(CUBE/vCUBE) Enterprise
Hussain Ali, CCIE# 38068 (Voice, Collaboration)
Technical Marketing Engineer
Dilip Singh, CCIE# 16545 (Collaboration)
Technical Leader
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 Serviceability
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 4
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
7 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
Agenda

CUBE Serviceability
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 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
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 fwding and signaling are handled by the
Msg I/f same CPU
ASR: Pkt fwding 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)
Contd
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
Specs based hardware supported but performance benchmarked for Cisco UCS B and
C series only
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
2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda

CUBE Serviceability
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 SBCs 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 SPs 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 signaling towards CUBE, e.g. CUCM, CVP,
ipv4 66.77.37.2 ! ITSP SIP Trunk Service Providers 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
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
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 voice service voip

SIP 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@
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
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 Contd
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 Contd
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

Advanced features on CUBE (Call Recording, Multi-Tenancy,
HA)
CUBE Serviceability
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
Exact Pattern
Match Based on URI match A CUCM SIP Trunk SP SIP Trunk
IP
1 of an incoming Host Name/IP CUBE PSTN
INVITE message Address
Inbound Calls
Inbound WAN Dial-Peer
User portion of
2 Match based on URI Received:
Called Number Phone-number of INVITE sip:654321@10.2.1.1 SIP/2.0
tel-uri Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-
Match based on tag="cid:orange@10.1.1.1";;branch=z9hG4bK-23955-1-0
3 From: "555" <sip:555@10.1.1.1:5060>;tag=1
Calling number To: ABC <sip:654321@10.2.1.1:5060>
Call-ID: 1-23955@10.1.1.1
4 Default Dial-Peer = 0 CSeq: 1 INVITE
Contact: sip:555@10.1.1.1:5060
Supported: timer
Max-Forwards: 70
Subject: BRKUCC-2934 Session
Content-Type: application/sdp
Content-Length: 226
........
Understanding Outbound Dial-Peer Matching Techniques
Priority Outbound WAN Dial-Peer
Outbound Calls
Match Based on URI Exact Pattern
match A
of incoming INVITE CUCM SIP Trunk SP SIP Trunk
IP
1 Host Name/IP
message & carrier-id Address CUBE PSTN
target User portion of Inbound Calls
URI Outbound LAN Dial-Peer
Match based on
Phone-number of
2 Called Number & tel-uri Received:
carrier-id 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 Host Name/IP From: "555" <sip:555@10.1.1.1:5060>;tag=1
3 of an incoming Address To: ABC <sip:654321@10.2.1.1:5060>
INVITE 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
Supported: timer
Match based on tel-uri
Max-Forwards: 70
4 Called 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
Multiple Incoming Patterns Under Same
Incoming/Outgoing Dial-peer
voice class e164-pattern-map 300 Provides the ability to combine multiple
e164 919200200.
incoming called OR calling numbers
e164 510100100.
Site A (919)200-2000 on a single inbound voip dial-peer,
e164 408100100.
reducing the total number of inbound
Site B (510)100-1000 dial-peer voice 1 voip voip dial-peers required with the same
description Inbound DP via Calling
routing capability
(408)100-1000 incoming calling e164-pattern-map 300
Site C Up to 5000 entries in a text file
codec g729r8
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 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 !
destination-pattern 8888
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>
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
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 54
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-1s 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-2s
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 utilized 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 BRKCOL-2125 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 56
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 IDs 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
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 Contd
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 doesnt 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: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

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 destination dpg 200
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

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
voice class dpg 100 VRF1 VRF2 voice class dpg 200
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 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 Contd
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
Redundancy Contd
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
Redundancy Contd
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
Redundancy Contd
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 IDs 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

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
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
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
Agenda

CUBE Serviceability
Serviceability
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

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
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
dur 00:00:14 tx:0/0 rx:0/0
dur 00:00:14 tx:0/0 rx:0/0
SIP call-legs: 2
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 2
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
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
|-----------------------------------------------
Diagnostic Signature Lookup Tool (DSLT)
On-demand Troubleshooting Automation
Agenda

CUBE Management & Troubleshooting
Introducing Cisco Business
Edition 4000 (BE4K)
BE4K Simple, cloud-managed office communications
Features
Packaged Collaboration Offer - Voice and Voicemail

solution for SMBs (200 users)
Based on ISR4321 router running CUCME and virtualized

ISR 4321
CUE.
Support for the latest IP Phones (78xx, 88xx, Jabber,

ATA-190)
Rapid Installation Preconfigured before shipment
Smart licensing
BE4K Contd.
Cisco OEM Cloud Management.
Cloud Deployed - configuration, administration and
management.
Rich Feature Set Auto-attendant, Flexible call
routing, Park, Hold, Transfer, Hunt groups,
Conferencing, Voicemail.
Single or multiple sites.
Fixed configuration SKU for ease of ordering.
Migration options include BE6000 / BE7000, Cisco
Voice & Voicemail
Spark. No throw-away capex.
Add-on Spark and WebEx for messaging and
meetings.
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 165 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
Dont forget: Cisco Live sessions will be available
Communication Stations for viewing on-demand after the event at
CiscoLive.com/Online
Cisco Spark
Ask Questions, Get Answers, Continue the Experience
Use Cisco Spark to communicate with the Speaker and fellow

participants after the session
Download the Cisco Spark app from iTunes or Google Play

1. Go to the Cisco Live Berlin 2017 Mobile app
2. Find this session
3. Click the Spark button under Speakers in the session description
4. Enter the room, room name = BRKCOL-2125
5. Join the conversation!
The Spark Room will be open for 2 weeks after Cisco Live
Presentation ID 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 123
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)

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

Proven Interoperability and Interworking with

SIP Trunking and CUBE Overview

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

ASR: Pkt fwding 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

SIP Trunking and CUBE Overview

2. Configure any other global settings to meet SPs requirements

WAN Dial-Peers Dial-peers that are facing towards

Outbound Dial-Peer for call legs from CUBE to SP

voice class sip-profiles 100

Enable Inbound 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

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