0% found this document useful (0 votes)
30 views183 pages

CUBE Lab Guide

This document is a lab guide for deploying SIP trunks using Cisco Unified Border Element (CUBE) with Cisco Unified Communications Manager (CUCM). It includes detailed instructions on setting up the lab environment, configuring SIP trunks, and implementing various modules related to SIP profiles, media transcoding, and secure call flows. The guide aims to provide hands-on training to enhance collaboration experiences in enterprise voice networks.

Uploaded by

gabe
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views183 pages

CUBE Lab Guide

This document is a lab guide for deploying SIP trunks using Cisco Unified Border Element (CUBE) with Cisco Unified Communications Manager (CUCM). It includes detailed instructions on setting up the lab environment, configuring SIP trunks, and implementing various modules related to SIP profiles, media transcoding, and secure call flows. The guide aims to provide hands-on training to enhance collaboration experiences in enterprise voice networks.

Uploaded by

gabe
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

LAB Guide

Deploying SIP Trunks with Cisco


Unified Border Element (CUBE)
Enterprise and CUCM

Hussain Shoaib Ali


CCIE# 38068 (Voice, Collaboration)
Technical Marketing Engineer

Dilip Singh, CCIE# 16545 (Collaboration)


Technical Leader
TABLE OF CONTENTS

Introduction ............................................................................................................................... 3
Objective ...................................................................................................................................... 4
Prerequisites .............................................................................................................................. 4
DCloud Lab Infrastructure: ................................................................................................... 5
Lab Setup ..................................................................................................................................... 6
Module 1 – Connecting Enterprise UC Network to ITSP’s SIP Trunk ................... 11
A. Adding a SIP Trunk to CUCM ........................................................................................................... 12
B. Configure Call Routing on CUCM ................................................................................................... 16
C. Configure the ISR2911 to enable the CUBE application ...................................................... 22
D. Configure CUBE per the Service Provider’s requirements ................................................. 24
E. Configure Call routing on CUBE to deliver PSTN calls to the ITSP .................................. 27
F. Out-of-Dialog OPTIONS Ping for keepalive ............................................................................... 38
G. Consolidating OPTIONS messages from CUBE......................................................................... 47
Module 2 – Basic SIP Profiles and Debug Categorization ........................................ 54
Module 3 – Configuring Media Transcoding ................................................................ 62
Module 4 – Configuring Call Admission Control ......................................................... 67
Module 5 – Configurable SIP Error codes ...................................................................... 73
Module 6 – Destination Dial-peer Group and Inbound SIP Profiles .................... 78
Module 7 – SIP Profile Rule Tagging ............................................................................... 87
Module 8 – Multiple E164 Pattern matching under the same dial-peer ............ 90
Module 9 – Destination Server Group ............................................................................ 93
Module 10 – PSTN Call Recording .................................................................................... 96
A. Open Recording Architecture with Cisco MediaSense.......................................................... 97
B. SIPREC ................................................................................................................................................... 105
C. CUCM Network based Recording (NBR) using UC Gateway Services API ................. 111
Module 11 – Implementing Secure Call Flows with SIP TLS / SRTP................... 124
A. Pre-Configured tasks ....................................................................................................................... 125
B. Enable trustpoint on CUBE and manage certificates.......................................................... 134
C. Enable TLS transport for SIP signaling and sRTP for media ........................................... 146
D. Configure secure SIP trunk on CUCM towards CUBE ......................................................... 149
Module 12 – CUBE + SIP SRST Co-location and Multi-tenancy ............................. 161

2|Page
Introduction
Innovations in collaboration services have delivered significant improvements in employee
productivity and enterprises are widely deploying IP based Unified Communications, both
for internal calling within the enterprise and external PSTN access. This has resulted in
significant migration from TDM based circuits, by both enterprises and telephony service
providers, to IP-based trunks for Unified Communication. At the heart of IP-based
telephony trunks lies the Session Initiation Protocol (SIP), which is an industry standard
communications protocol based on RFC3261, and is widely used for controlling multimedia
communication sessions and applications such as voice, video, unified messaging,
voicemail, and conferencing.

These SIP trunks terminate on a session Border Controller (SBC) at the enterprise that
serves as a demarcation point between the enterprise and the service provider IP networks,
similar to how firewalls separate two data networks. The Cisco Unified Border Element
(CUBE) Enterprise is Cisco’s SBC offering and it enables rich multimedia communications
for enterprises by providing:

Session Control – Call Admission Control, Trunk Routing, QoS, Statistics, Billing,
Redundancy, Scalability, Voice Quality Monitoring

Security – Encryption, Authentication, Registration, SIP Protection, Voice Policy, Toll


Fraud Prevention, Telephony Denial of Service (TDoS) Attack protection

Interworking – Various SIP and H323 Stack Interoperability, SIP Normalization, DTMF,
Transcoding, Transrating, Codec Filtering

Demarcation – Fault Isolation, Topology and Address Hiding, L5/L7 Protocol


Demarcation, Network Border

CUBE enables substantial cost savings by providing essential capabilities that ensure
interoperability, security and service assurance when carrying IP traffic via SIP trunking
across different enterprises and service provider networks. It is a Back-to-Back User Agent
(B2BUA) and is part of the IOS infrastructure on ISR G2/800 series platforms, IOS-XE for
the ASR1K, ISR4K series and CUBE on CSR1000v (virtual CUBE – vCUBE).

As the use of SIP continues to expand in the industry, Cisco continues to provide
capabilities in Cisco IOS/IOS-XE Software products and features to enable rich
communications methods along with significant cost savings by leveraging existing
infrastructure and flexibility for migration.

3|Page
Objective
The objective for this bootcamp is to provide hands-on training in deploying SIP Trunking
in an enterprise voice network based on Cisco Unified Communications Manager (CUCM)
and Cisco Unified Border Element (CUBE) Enterprise edition.
This bootcamp provides detailed explanation, verification procedures, best practices, and is
designed to maximize learning by providing practical hands-on training. It will also
introduce newer features released as part of Collaboration 11.5.X, 11.6.X, and 12.X.X
offerings that existing enterprises can deploy to enhance their collaboration experience.

Prerequisites
Make sure you meet the following prerequisites before making an attempt to this training
course.
- Have a basic knowledge of voice principles as it applies to networking
- Have a basic working knowledge of Cisco IOS/IOS-XE and IOS/IOS-XE voice
concepts
- Basic understanding of Session Initiation Protocol (SIP)
- Basic understanding of Cisco Unified Communications Manager (CUCM)

The information in this document was created from the devices in a specific lab
environment. All of the devices used in this document started with a cleared (default)
configuration. If your network is live, make sure that you understand the potential impact of
any command.

NOTE: To achieve the stated objective of the lab exercises,


certain software versions may be used that may not be supported
in production environments. Please check with your Cisco
representative or [Link] for details on supported
software combinations for your deployments.

4|Page
Note: This lab is modularized where Module 1 is a pre-requisite to every other module.
Any additional pre-requisites are listed at the start of a module. If you would like to attempt
any module other than Module 1, you will need to complete Sections A and B of Module 1.
The CUBE configuration (sections C to G of Module 1) can be copied from the flash to the
running configuration as shown below.

CUBE#copy flash:[Link] running-config


Destination filename [running-config]?
You need to save and reload the router for this configuration
change to be effective

4543 bytes copied in 0.460 secs (9876 bytes/sec)

vpod-2911-cube-01#wr
Building configuration...

[OK]

DCloud Lab Infrastructure:

5|Page
Lab Setup

1. Components

The following equipment is used to stage and build this Lab:


 29xx Integrated Services Router – G2 running IOS version 15.7(3)M2 or higher
(CUBE 11.5.2).
NOTE: To display some advance CLI output, we are using 15.7(3)M2.
 Cisco Unified Communications Manager running version 11.5. or higher
 Windows Workstation with Jabber Softphone
 PVDM3-16 or higher required for transcoding on ISR-G2

Network Diagram

This lab uses the network setup as shown in the diagram below for all PODs:

 CUCM acting as the central call agent


 CUBE acting as the Enterprise Session Border Controller
 Jabber IP phone registered to CUCM as full e.164 extension
 ITSP SIP trunk for PSTN dialing
 Cisco MediaSense as the call recording server

CUCM LAN WAN


CUBE
Gig0/0 – [Link] SP IP
Gig0/1 – [Link] Network
CUBE
Cisco MediaSense
[Link] ITSP SIP Trunk
[Link]

[Link]
Windows Work Station Classroom PC
1 or 3 with Jabber OR
SoftPhone Internet Your PC
IP – [Link]/39 with AnyConnect
Phone# +1(408)944-29DN

1 – POD : Refer to table on page 8 to find the last octet of your WAN IP
2 – DN : Refer to table on page 8 to find the last two digits of your DID Number

6|Page
2. IP Addressing Scheme and Checklist

Get all the requirements from the SIP Trunk provider before attempting the lab (Provided by
the proctor for this lab). Refer to the IP Addressing Scheme & Checklist provided below.

POD Information POD

CUBE – SBC
CUBE (Gig0/1) – WAN 10.1.40.POD1
CUBE (Gig 0/0) – LAN TELNET ACCESS [Link]
Username cisco
Password Cu8ELab!

ITSP
IP Address for SIP Calls [Link]

CUCM – Call Agent


CUCM IP Address [Link]
CUCM Username administrator
CUCM Password dCloud123!

MediaSense – Call Recording Server


MediaSense IP Address [Link]
MediaSense Search and Play Username mcheng
MediaSense Search and Play Password C1sco12345

Phone Number
DID Number +1 408-944-29DN2
Jabber Phone Extension on WKST 3 - +14085557700
CSFMCHENG
Jabber User ID mcheng
Jabber Password C1sco12345

Student PC wkst3 (To access lab components)


IP Address [Link]
Remote Desktop Username dcloud\mcheng
Remote Desktop Password C1sco12345

1 – Every 2911 (CUBE) in this lab will have a different WAN IP indicated by POD. Please
refer to the tables on next page to find your pod’s corresponding WAN IP that will be used
to communicate with the ITSP.

7|Page
2 – Every pod will have its own phone number for making and receiving PSTN calls. Please
refer to the tables on next page to find your pod’s corresponding DID Number. All

INBOUND PSTN calls requested as part of an exercise needs to be placed


to your respective DID number listed below in the last column, while all
OUTBOUND PSTN calls will display 408-944-7700 as the caller ID on the
PSTN phone

Pod CUBE-(Gig0/0) CUBE-(Gig0/1) DID Number


Number LAN WAN
[Link] / 18 [Link] / 24 +1-408-944-29DN
Pod 1 [Link] +1-408-944-2970

Pod 2 [Link] +1-408-944-2971

Pod 3 [Link] +1-408-944-2972


[Link]
Pod 4 [Link] +1-408-944-2973

Pod 5 [Link] +1-408-944-2974

Pod 6 [Link] +1-408-944-2975

Pod 7 [Link] +1-408-944-2976

Pod 8 [Link] +1-408-944-2977

Pod 9 [Link] +1-408-944-2978

Pod 10 [Link] +1-408-944-2979

Pod 11 [Link] +1-408-944-2980

Pod 12 [Link] +1-408-944-2981

Pod 13 [Link] +1-408-944-2982

Pod 14 [Link] +1-408-944-2983

Pod 15 [Link] +1-408-944-2984

Pod 16 [Link] +1-408-944-2985

8|Page
3. Pre-Setup

Use Cisco AnyConnect VPN to connect to Cisco dCloud infrastructure. VPN


connection details are provided in the printed information sheet for your pod.

Once VPN’d in, connect to the following workstation using the local RDP client on
your laptop.

Workstation 3: [Link], Username: dcloud\mcheng, Password: C1sco12345

Once connected to WKST3, launch the Cisco Jabber for Windows client by double-

clicking the desktop icon .

Login to the Jabber client by entering the password: C1sco12345 and clicking Sign
In. Note that the username field is already pre-populated with our WKST3 user’s
login username: mcheng.

9|Page
Note: Jabber registration with UCM can be verified from CUCM Administration - From
menu, click on Device and select Phone in the drop-down:

10 | P a g e
Module 1 – Connecting Enterprise UC Network to
ITSP’s SIP Trunk

This section will cover the needed configurations to successfully connect your enterprise
UC network to the SIP Trunk provider.

There are 7 basic tasks as follows:

A. Adding a SIP Trunk to CUCM


B. Configure Call Routing on CUCM
C. Configure the ISR2911 to enable the CUBE application
D. Configure CUBE per the Service Provider’s requirements
E. Configure Call Routing on CUBE to deliver PSTN Calls to the ITSP
F. Out-of-Dialog OPTIONS Ping for keepalive
G. Consolidating OPTIONS messages from CUBE

11 | P a g e
A. Adding a SIP Trunk to CUCM

Task :

1. Open your browser and type in [Link] as shown


below. Confirm any security exception. The username is administrator and
password is dCloud123!

2. Create a SIP Trunk to your POD’s CUBE


a. Click on Device  Trunk

12 | P a g e
b. Click on Add New, select “SIP Trunk” from the drop down menu and click
Next:

c. Configure the SIP Trunk. Fill out the following values as shown:
i. Device Name – CUBE
ii. Description – SIP TRUNK TO CUBE
iii. Device Pool – Default
iv. Inbound Calls – Calling Search Space – Change this to Prime-CSS
which contains the Prime-DN-PT partition. The Directory Number
for our softphones (CSF) belong to this partition.
v. Destination Address – CUBE’s LAN IP Address (Gig 0/0
[Link]) from page 7
vi. SIP Trunk Security Profile – Non Secure SIP Trunk Profile
vii. SIP Profile – Standard SIP Profile

13 | P a g e
14 | P a g e
viii. Click Save
ix. Click OK on the popup
x. Click Reset
xi. On the Reset popup click Reset
xii. Click Close

15 | P a g e
B. Configure Call Routing on CUCM

Task:
1. Configure call routing on CUCM for long-distance calls to the SIP Trunk provider
based on North American Numbering Plan (NANP)
2. The calling number display on the called party’s phone should appear as
“4089447700”.

Solution:
To achieve complete call routing functionality, we have to configure CUCM to send/receive
calls to/from CUBE. Likewise, we would then need to configure CUBE to send/receive calls
to/from the service provider.
In this section, we will focus on the call routing functionality of CUCM.

Inbound call routing:

CUCM will be receiving the PSTN inbound calls from CUBE. CUBE will send digits that it
receives from the service provider. In order for CUCM to route the call to the right phone, it
can be configured to accept certain number of “significant digits” based on the extensions
configured enterprise-wide. CUCM counts significant digits from the right (last digit) of the
called number (DNIS)

In this lab, we have configured full E.164 extensions enterprise-wide, where the softphone’s
(CSFMCHENG) extension is +14085557700. Thus, we have to configure CUCM to accept
and route calls based on ALL the significant digits, which is the Default option on the SIP
Trunk configuration page.

This was configured on the SIP Trunk page in the previous step.

16 | P a g e
Outbound call routing:

CUCM uses the concept of Route Patterns, Route Lists and Route Groups to make outbound
calls.

First step is to create Route Patterns that match the way the user will dial the PSTN number.
Route Patterns point directly to the gateways or CUBE (via SIP Trunk); however, the best
practice recommendation is to point a Route Pattern to a Route List that contains Route
Groups. These Route Groups contain Gateways/Trunks. This allows you to reuse these
devices for other Route Groups.

In addition, configuring a Route List with multiple Route Groups allows you to perform
different digit manipulations per Route Group for each Route List. Thus, it enables your
enterprise network to have flexible call-routing policies.

1. Create a Route Group.


a. Click Call Routing  Route/Hunt  Route Group:

b. Click Add New:


c. Configure the Route Group by filling in the values:
i. Name – RG-CUBE
ii. Highlight the CUBE under Available Devices, and then click Add to
Route Group.
iii. Click Save
iv. You should see the SIP Trunk created in Task A Adding a SIP
Trunk to CUCM as shown below

17 | P a g e
18 | P a g e
2. Create a Route List
a. Click Call Routing  Route/Hunt  Route List:
b. Click Add New:
c. Configure the Route List by filling in the values:
i. Name – RL-CUBE
ii. Choose the Default Cisco Unified Communications Manager Group
iii. Click Save

iv. Click Add Route Group

v. Choose the RG-CUBE you created from the drop-down menu as


shown on next page
vi. Click Save, and then OK
vii. Click Apply Config
viii. Click OK on the popup
ix. Click Reset
x. On the reset popup click Reset
xi. Click Close

19 | P a g e
The final screen should look like below.

20 | P a g e
3. Create a Route Pattern for long distance calls
a. Click Call Routing  Route/Hunt  Route Pattern
b. Click Add New:
c. Configure the Route Pattern by filling in the values:
i. Route Pattern – 81[2-9]XX[2-9]XXXXXX
ii. Route Partition – None (For this bootcamp, we will set this to None
as we don’t have any Calling restrictions to be defined)
iii. Description – NANP Long Distance
iv. Gateway/Route List – RL-CUBE from the drop down menu to select
the RL that we created pointing to the SIP Trunk to CUBE
v. Check Use Calling Party’s External Phone Number Mask as
shown below to send the full 4089447700 DID for outbound calls.
vi. Click Save and Click OK and OK again on the popups

21 | P a g e
C. Configure the ISR2911 to enable the CUBE application

Task:
Enable CUBE on your ISR G2 platform.

Solution:
The router must be equipped with the basic UC technology package (UCK9), for any voice
related features. To find more about how to activate the UC technology package, please
visit:
[Link]
l

Open PuTTY and telnet to Gig0/0 IP ([Link]) of CUBE as shown below. The
username and password is cisco and Cu8ELab! respectively.

22 | P a g e
The following commands needs to be entered to turn the CUBE application on:

voice service voip


mode border-element license capacity 200
allow-connections sip to sip
ip address trusted list
ipv4 [Link] ! ITSP SIP Trunk
ipv4 [Link] ! CUCM1

CUBE#conf t
CUBE(config)#voice service voip
CUBE(conf-voi-serv)#mode border-element license capacity 200
You need to save and reload the router for this configuration
change to be effective

CUBE(conf-voi-serv)#allow-connections sip to sip


CUBE(conf-voi-serv)#ip address trusted list
CUBE(cfg-iptrust-list)#ipv4 [Link]
CUBE(cfg-iptrust-list)#ipv4 [Link]
CUBE(cfg-iptrust-list)#end

“mode border-element license capacity 200” indicates that you have licensed this
platform for 200 IP to IP sessions (end-to-end calls). A reload is not necessary.

“allow-connections sip to sip” allows this platform to bridge two VoIP SIP call legs. It is
disabled by default.

“ip address trusted list” To explicitly enable the source IP addresses of entities from which
you expect legitimate VoIP calls, e.g. CUCMs, CVP servers, ITSP’s SBC. By default,
CUBE will block all incoming VoIP call setups from IP addresses not in its trusted list. IP
Addresses from dial-peers with “session target ip” or Server Group are trusted by default
and need not be populated here.
For more information visit [Link]
dial-plans/[Link]

Verification:

To verify how many CUBE sessions, your router is licensed/configured for, issue the
following command:

CUBE#show cube status

CUBE-Version : 11.5.2
SW-Version : 15.7.3.M2, Platform CISCO2911/K9
HA-Type : none
Licensed-Capacity : 200

23 | P a g e
D. Configure CUBE per the Service Provider’s requirements

Task:
Different service providers have different requirements to make sure customer’s voice
network can successfully interwork with their SIP network. In order to successfully get this
interoperability to work, the service provider needs to provide some information about their
networks. Based on these requirements, you can configure the CUBE to make sure your
voice network can interwork with the service provider’s network.

The items mentioned in the checklist below will be configured in this step and Task E.
These requirements are based on the SIP Trunk from our ITSP for this lab. All other items
will be covered in the subsequent section. In this section we will address Items 5, 7, 9, 10,
and 11.

Overall Requirements from SIP ITSP:

Item SIP Trunk service provider requirement Response

1 SIP Trunk IP Address (Destination IP Address for INVITES) [Link]

2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711

5 Fax protocol support T.38


6 DTMF signaling mechanism RFC2833
7 Does the provider require SDP information in initial INVITE Yes
(Early offer required)
8 SBC’s external IP address that is required for the SP to 10.1.40.POD1
accept/authenticate calls (Source IP Address for INVITES) Gig0/1 in this lab

9 Does SP require SIP Trunk registration for each DID? If yes, No


what is the username & password
10 Does SP require Digest Authentication? If yes, what is the No
username & password
11 Mid-call codec renegotiation support Yes
12 Does SP accept/authenticate calls based on specific calling 4089447700
number? If yes, what is the calling number

1 – POD : Refer to table on page 8 to find the last octet of your WAN IP

24 | P a g e
Solution:

Based on the requirements above, we will configure the following parameters on CUBE:
1. Forced early-offer for all calls (Requirement Item 7)

voice service voip


sip
early-offer forced

This command forces the CUBE to send the SDP information in the initial INVITE message
itself instead of waiting to send the information till it gets an acknowledgement from the
neighboring peer.

2. In order to make sure all different call flows work and that your network can
interwork with the Service provider’s network, it is highly recommend to enable
some global level commands.

voice service voip


sip
header-passing
error-passthru
midcall-signaling passthru

Screenshot of the commands is below:

CUBE(config)#voice service voip


CUBE(conf-voi-serv)#sip
CUBE(conf-serv-sip)#early-offer forced
CUBE(conf-serv-sip)#header-passing
CUBE(conf-serv-sip)#error-passthru
CUBE(conf-serv-sip)#midcall-signaling passthru

25 | P a g e
Explanation of commands used above:

“header-passing” enables or disables SIP header-passing to applications. When CUBE


receives SIP INVITE, SUBSCRIBE, and NOTIFY messages, this command enables passing
SIP headers associated with these messages to the other party in the call.

“error-passthru” Error messages that may not be supported on CUBE are transparently
passed through CUBE from one SIP leg to the other when the header-passing and error-
passthru command are configured.

“midcall-signaling passthru” The midcall-signaling command distinguishes between the


way CUBE handles signaling messages. Most SIP-to-SIP video and SIP-to-SIP ReINVITE
based supplementary services require the midcall-signaling command to be configured
before configuring other supplementary services. Supplementary service features that are
functional without configuring midcall-signaling include: session refresh, fax, and refer-
based supplementary services. The midcall-signaling command is for SIP-to-SIP calls only.
All other calls (H323-to-SIP, and H323-to-H323) do not require the midcall-signaling
command be configured.

The overall configuration will look like as below:

CUBE#sh run | sec voice service voip


voice service voip
ip address trusted list
ipv4 [Link]
ipv4 [Link]
mode border-element license capacity 200
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
header-passing
error-passthru
early-offer forced
midcall-signaling passthru
CUBE#

26 | P a g e
E. Configure Call routing on CUBE to deliver PSTN calls to the ITSP

Task:
1. Configure call routing on CUBE for long-distance calls to the SIP Trunk provider
based on NANP.
2. Configure the CUBE to meet the Service Provider requirements per the checklist on
page 24:
a. Codec between CUCM and CUBE call leg – g711ulaw
b. Codec between CUBE call leg to service provider – g711ulaw
c. DTMF signaling on both call legs – RFC 2833

Item SIP Trunk service provider requirement Response

1 SIP Trunk IP Address (Destination IP Address for INVITES) [Link]

2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711

6 DTMF signaling mechanism RFC2833


8 SBC’s external IP address that is required for the SP to 10.1.40.POD1
accept/authenticate calls (Source IP Address for INVITES) Gig0/1 in this lab

12 Does SP accept/authenticate calls based on specific calling 4089447700


number? If yes, what is the calling number

1 – POD : Refer to table on page 8 to find the last octet of your WAN IP

27 | P a g e
Solution:
In Tasks A and B, we configured CUCM to send/receive calls to the CUBE. This section
will teach you how to configure CUBE to send/receive calls to/from the service provider.

CUBE uses the concept of dial-peers to route calls. Every call that traverses through CUBE
has to match an inbound dial-peer and an outbound dial-peer.

Refer to the following diagrams to understand the dial-peer matching process, which will
help when we configure CUBE.

As you can see from the above diagrams, we need to have dial-peers for inbound &
outbound calls.

The best practice will be to explicitly define the inbound and outbound dial-peers for
inbound & outbound calls. We can generalize them in 2 broader sets – LAN Dial-peers &
WAN Dial-peers as explained below:

LAN dial-peers are dial-peers that reside towards the enterprise network. These will act as:
- Inbound dial-peers for calls from CUCM towards SP (To accept call legs from
CUCM to CUBE)
- Outbound dial-peers for calls to CUCM from SP. (To originate call legs from CUBE
to CUCM)

WAN dial-peers are dial-peers that reside towards the service provider’s network. These
will act as:
- Inbound dial-peers for calls from SP towards CUCM.(To accept call legs from SP to
CUBE)
- Outbound dial-peers for calls to SP from CUCM. (To originate call legs from CUBE
to SP

28 | P a g e
Dial-peer matching algorithm:

There are number of ways in which you can match to a particular dial-peer. These are:
- URI of incoming INVITE
- DNIS
- ANI
- Port (For TDM gateways)

For more information on the dial-peer matching algorithms, please refer to the following
link:
[Link]
ml

And for CUBE Call Routing, please refer to [Link]

In this lab, we will match dial-peers based on the DNIS (called number) and URI. Please
move to the next page.

29 | P a g e
Inbound LAN Dial-peers:

1. To configure the dial-peer to act as “inbound dial-peer to accept call legs from CUCM
towards CUBE” we will use the CLI incoming called-number as shown below:

dial-peer voice 100 voip


description *** Inbound LAN dial-peer. From CUCM to CUBE ***
session protocol sipv2
incoming called-number 8T
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

“description” Always put good descriptions on your dial-peers to ease management and
troubleshooting.

“session protocol sipv2” specifies that this dial-peer will be handling SIP call legs. Some
SIP based commands only show up once a dial-peer has session protocol sipv2 configured

“incoming called-number 8T” Since we did “No discard digits” on CUCM, we will be
receiving the access code “8” plus any length of digits. This statement allows this dial-peer
to match any incoming call beginning with 8 as the called number.

“voice-class sip bind” Though it is not required for incoming dial-peers, it has been put as a
good practice. All inbound communication from CUCM will come through Gig0/0.

“dtmf-relay” defines RTP-NTE (RFC2833) as the DTMF capability expected on this call
leg.

“codec g711ulaw” defines G.711ULAW as the expected codec on the incoming call leg.

“no vad” disables Voice Activity Detection (VAD) for call legs using this dial-peer.

30 | P a g e
Outbound LAN Dial-peer:

2. To configure the dial-peer to act as “outbound dial-peer to originate call legs to CUCM
from CUBE” we will use the CLI destination-pattern as shown below:

dial-peer voice 101 voip


description *** Outbound LAN dial-peer. From CUBE to CUCM ***
session protocol sipv2
destination-pattern +1408944....$
session target ipv4:[Link]
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

“description” Always put good descriptions on your dial-peers to ease management and
troubleshooting

“session protocol sipv2” specifies that this dial-peer will be handling SIP call legs

“destination-pattern +1408944....$” Digit pattern that will allow selection of this dial-peer.
Any number beginning with +1408944…. will match this dial-peer. We will be applying a
translation rule that will changed the DNIS (called number) from +140894429DN (Your
specific pod’s DID number) to +14085557700, the DN configured on the Jabber Softphone
[CSFMCHENG] within CUCM

“voice-class sip bind” indicates which source interface’s IP Address to use to bind SIP
signaling and media packets. Since this dial-peer is pointing towards CUCM, we bind this
dial-peer to Gig0/0 as CUCM does not know about Gig0/1.

“session target ipv4” indicates the destination’s target address where this call leg will be
send

“dtmf-relay” defines RTP-NTE (RFC2833) as the DTMF capability expected on this call
leg

“codec g711ulaw” defines G.711ULAW as the expected codec on the incoming call leg

“no vad” disables Voice Activity Detection (VAD) for call legs using this dial-peer

Note: If you have a CUCM cluster consisting of 1 Publisher & multiple Subscribers, you
can configure different dial-peers each pointing to Publisher & Subscribers using the
preference CLI. This will make sure that if at any time a subscriber node is down, the calls
will be sent to another node for processing.

31 | P a g e
Translating the Called Number for Dial-peer 101 from +1408944 . . . . to +14085557700

1. Create a voice translation-rule with the tag 7700 as shown below

This translation rule uses regular expressions to match any number pattern that starts
with +1408944 and can have any of the digits between 0 and 9 for the last four digits.
And it replaces +1408944 . . . . with +14085557700.

CUBE(config)#voice translation-rule 7700


CUBE(cfg-translation-rule)#rule 1 /\+1408944....$/ /+14085557700/

Verification:

To verify how voice translation-rule 7700 works, issue the following commands. This rule
converts +14089440000 to +14085557700 as shown below

CUBE#test voice translation-rule 7700 +14089440000


Matched with rule 1
Original number: +14089440000 Translated number: +14085557700
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

2. Create a voice translation-profile named CUBE_to_CUCM that will utilize voice


translation rule 7700 created above. We will setup this profile to apply translation-
rule 7700 to called (DNIS) numbers only.

CUBE(config)#voice translation-profile CUBE_to_CUCM


CUBE(cfg-translation-profile)#translate called 7700

3. Lastly we will apply voice translation-profile CUBE_to_CUCM to dial-peer 101


that delivers call legs from CUBE to CUCM so the DNIS (Called number) is
changed to +14085557700 as the CUCM is configured for it on Jabber’s Softphone
[CSFMCHENG]

CUBE(config)#dial-peer voice 101 voip


CUBE(config-dial-peer)#translation-profile outgoing CUBE_to_CUCM

32 | P a g e
The final dial-peer voice 101 voip should look like below:

dial-peer voice 101 voip


description *** Outbound LAN dial-peer. From CUBE to CUCM ***
translation-profile outgoing CUBE_to_CUCM
destination-pattern +1408944....$
session protocol sipv2
session target ipv4:[Link]
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

33 | P a g e
Inbound WAN Dial-peer:

1. To configure the dial-peer to act as “inbound dial-peer to accept call legs from SP to
CUBE” we will use the VIA header of the incoming SIP INVITE message from ITSP.
URI based matching requires creation of voice class URI statements to specify
hostname, IP address, or FQDN names.

! Service Provider’s SBC’s IP Address from where CUBE receives the SIP INVITE

CUBE(config)#voice class uri 200 sip


CUBE(config-voice-uri-class) host ipv4:[Link]
CUBE(config-voice-uri-class) end
!
dial-peer voice 200 voip
description ***Inbound WAN dial-peer. From Provider to CUBE***
session protocol sipv2
incoming uri via 200
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

34 | P a g e
Outbound WAN Dial-peers:

Separate dial-peers should be configured for different types of call routing – local, long
distance, international, emergency services etc..

2. To configure the dial-peer to act as “outbound dial-peer to originate call legs from
CUBE towards SP” we will use the CLI destination-pattern.

For Long-distance calls according NANP:

We will match the Outbound WAN dial-peer for long distance calls based on access code
“8” and then the rest of the 1+10 digits of the North American Numbering Plan (NANP).
Generally, the access code is always stripped before the call is sent to the ITSP, either at the
CUBE or the CUCM level. However, the way this lab is setup, we must send the access
code “8” along with the country code of “1” and the rest of the 10 digits of NANP. So we
will create an Outbound WAN dial-peer to match “81[2-9]. . [2-9]. . . . . .$”.

Create dial-peer voice 201 voip as shown below to act as the Outbound WAN dial-peer,
delivering call legs from the CUBE to the ITSP for this lab

dial-peer voice 201 voip


description *Outbound WAN dial-peer. Long distance from CUBE to SP*
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

35 | P a g e
Test:

At this point inbound calls to your Jabber Softphone’s DN from your mobile phone (PSTN)
and outbound calls from your Jabber Softphone to PSTN numbers (e.g. your cell phone)
should work. However, there may not be audio on these calls if Work Station 3 is being
accessed via Remote Desktop.

To troubleshoot call setup failures, proceed as shown on the next page:

Collecting debugs in Router logging buffer


------------------------------------------
CUBE#conf t
CUBE(config)#no logging console
CUBE(config)#no logging monitor
CUBE(config)#service timestamps debug datetime msec
CUBE(config)#logging buffered 9999999 debugging
CUBE(config)#service sequence-numbers
CUBE(config)#no logging rate-limit
CUBE(config)#exit
CUBE#

The following debugs will assist in troubleshooting call failures for this lab:

“debug ccsip message”


“debug voip ccapi inout”

You can view the debugs by issuing the “show log” command.

36 | P a g e
Verification:

An outbound call placed to +1-678-555-5555 should first match Inbound LAN dial-peer 100
and then Outbound WAN dial-peer 201 as displayed below with the “show” command. The
calling number coming from CUCM is 408-944-7700 as required in Task B.2 of this module

Note : If you are using an International Cell Phone (according to NANP) as the PSTN
phone to test your calls, you may not be able to dial it as International dialing is not
allowed in this lab and hence, you will not be able to verify the calling number display
required in Task B.2.

cube#show call active voice brief | incl pid

<ID>: <CallID> <start>ms.<index> (<start>) +<connect> pid:<peer_id> <dir> <addr> <state>


1CB2 : 7 518005910ms.1 (15:09:15.706 PDT Tue Oct 24 2017) +6120 pid:100
Answer 4089447700 active
1CB2 : 8 518005920ms.1 (15:09:15.716 PDT Tue Oct 24 2017) +6100 pid:201
Originate 816785555555 active

Similarly, an inbound PSTN call to your pod can be verified as shown below. PSTN number
dialing your pod in this example is +1-678-555-5555 and the called number [page 8 for
your respective POD] is being changed on CUBE to your Jabber’s extension, +1-408-555-
7700

cube#show call active voice brief | incl pid

<ID>: <CallID> <start>ms.<index> (<start>) +<connect> pid:<peer_id> <dir> <addr> <state>


1CB3 : 11 518917890ms.1 (15:24:27.686 PDT Tue Oct 24 2017) +2370 pid:200
Answer 6785555555 active
1CB3 : 12 518917900ms.1 (15:24:27.696 PDT Tue Oct 24 2017) +2360 pid:101
Originate +14085557700 active

Note: Save your ISR running configuration by issuing


“write mem” after every module of this lab.

37 | P a g e
F. Out-of-Dialog OPTIONS Ping for keepalive
In a robust SIP network, it is essential for one SIP entity to know the status of another SIP
entity. The SIP Out-of-Dialog OPTIONS ping mechanism in CUBE allows for SIP layer
monitoring of target destinations. This generic heartbeat mechanism allows for CUBE to
query a target and also respond to incoming keepalive requests from trusted SIP sources.
Additionally, the OPTIONS keepalive mechanism allows to query the far end capabilities
without actually establishing a dialog.

In a CUBE Enterprise deployment, it is recommended to configure OPTIONS on an


outbound (LAN/WAN) dial-peer(s). When a total heartbeat failure is experienced for a SIP
dial-peer’s target destination, the dial-peer is busied-out. If an alternate dial-peer is
configured for the same destination-pattern, the call is failed over to that next preferred dial-
peer. Otherwise, the call is rejected with an error cause code. For an incoming INVITE on
CUBE that matches a “busyout” outbound dial-peer, CUBE sends a “503 Service
Unavailable” by default.

For an outbound OPTIONS ping originating from CUBE towards a SIP target, the following
responses are considered unsuccessful and the dial-peer is busied-out:

Response Code Description


503 Service Unavailable
505 SIP version not supported
No Response Request Timeout

All other response codes, including 4XX are considered valid responses and the dial peer is
not busied out.

The diagram on the next page explains the OPTIONS keepalive mechanism on CUBE.

38 | P a g e
39 | P a g e
Task:
1. Configure Out-of-Dialog OPTIONS on CUBE to monitor reachability towards
CUCM

Solution:

So far we have configured the following four dial-peers on the CUBE. We will apply
OPTIONS keepalive to dial-peer 101 to monitor reachability towards the CUCM
[[Link]]

40 | P a g e
The syntax of the OPTIONS keepalive command is as follows

voice-class sip options-keepalive {up- • up-Interval: the number of seconds


interval seconds | down-interval seconds | between successive OPTIONS for a
retry retries} dial-peer in active state. Default is
60

• down-interval: OPTIONS
keepalive timer interval for a
busied-out dial-peer. Default is 30

• retry: Retry count for OPTIONS


keepalive transmission before
busying out a dial-peer. Default is 5

Let’s first verify the state of dial-peers configured.

cube#show dial-peer voice summary


dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF
100 voip up up 0 syst NA
101 voip up up +1408944....$ 0 syst ipv4:[Link] NA
200 voip up up 0 syst NA
201 voip up up 81[2-9]..[2-9]..- 0 syst ipv4:[Link] NA
....$
For server-grp details please execute command:show voice classserver-group <tag_id>
To see complete session target for ipv6 use 'sh running config | section dial-peer <tag>

As seen above, the KEEPALIVE column has no output because we currently do not have
OPTIONS configured. Let’s proceed on configuring OPTIONS on dial-peer 101 as shown
below

CUBE#conf t
CUBE(config)#no logging console
CUBE(config)#no logging monitor
CUBE(config)#service timestamps debug datetime msec
CUBE(config)#logging buffered 9999999 debugging
CUBE(config)#service sequence-numbers
CUBE(config)#no logging rate-limit
CUBE(config)#exit

CUBE(config)#dial-peer voice 101 voip


CUBE(config-dial-peer)#voice-class sip options-keepalive up-
Interval 10 down-Interval 5 retry 1
CUBE(config-dial-peer)#exit
CUBE(config)#exit
CUBE#

41 | P a g e
Wait a few seconds and issue show dial-peer voice summary. We can see that dial-peer
101 is in active state.

CUBE#show dial-peer voice summary


dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF
100 voip up up 0 syst NA
101 voip up up +1408944....$ 0 syst ipv4:[Link] active NA
200 voip up up 0 syst NA
201 voip up up 81[2-9]..[2-9]..- 0 syst ipv4:[Link] NA
....$
For server-grp details please execute command:show voice classserver-group <tag_id>
To see complete session target for ipv6 use 'sh running config | section dial-peer <tag>

Now let’s verify through debugs that while dial-peer 101 is in active state, an OPTIONS
message is sent towards [Link] [CUCM] every 10 seconds, and if it is in busyout
state, an OPTIONs is sent every 5 seconds. Additionally, CUBE will retry only a single
OPTIONs message before busying out the dial-peer.

Starting CUBE 10.0.1 [IOS 15.4(2)T / IOS-XE 3.12], non call-context debugs are not
printed when debug ccsip is issued on CUBE, meaning if a message is not part of any call,
that debug will not be printed. This affects OPTIONS, REGISTER,
SUBSCRIBE/NOTIFY messages originating from CUBE towards a target SIP destination.
Inbound non-call context messages are still printed as part of the debugs.

To see non-call context debugs originating from CUBE version 10.0.1 or later, issue the
following along with the intended debug ccsip command:

debug ccsip non-call


CUBE#debug ccsip message
SIP Call messages tracing is enabled
CUBE#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled

Wait for about 10 to 15 seconds and issue the CLIs as shown below in bold. Observe the
debug output to verify that the destination of the SIP OPTIONs is the CUCM [[Link]]
and successive OPTIONS are about 10 seconds apart. The output from your CUBE will
vary from the one shown on the next page.

42 | P a g e
CUBE#term len 0
CUBE#show log

001073: May 31 23:53:04.491:


//818/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK330D2A
From: <sip:[Link]>;tag=DB1F38-1923
To: <sip:[Link]>
Date: Thu, 31 May 2018 23:53:04 GMT
Call-ID: 98071D92-646411E8-8336941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

001074: May 31 23:53:04.495:


//818/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK330D2A
From: <sip:[Link]>;tag=DB1F38-1923
To: <sip:[Link]>;tag=516124356
Date: Thu, 31 May 2018 23:53:04 GMT
Call-ID: 98071D92-646411E8-8336941E-48173748@[Link]
Server: Cisco-CUCM11.5
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

001075: May 31 23:53:14.495:


//819/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK331DE3
From: <sip:[Link]>;tag=DB464C-41C
To: <sip:[Link]>
Date: Thu, 31 May 2018 23:53:14 GMT
Call-ID: 9DFD9DB5-646411E8-8337941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

CUBE#

43 | P a g e
Now we will clear the log and block all traffic from the CUBE going towards the CUCM
[[Link]] to simulate heartbeat failure and we will see that dial-peer voice 101 is
busied out. Proceed as shown below.

CUBE(config)#do clear log !!--> Press Enter to confirm


Clear logging buffer [confirm]
CUBE(config)#ip route [Link] [Link] Null0

CUBE(config)#do show log

Log Buffer (9999999 bytes):

Successful SIP OPTIONS Dialog shown below


001199: Jun 1 00:03:34.539:
//881/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK36F2FF
From: <sip:[Link]>;tag=E4BC54-1CD4
To: <sip:[Link]>
Date: Fri, 01 Jun 2018 00:03:34 GMT
Call-ID: F90D7FA-646611E8-8375941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

001200: Jun 1 00:03:34.539:


//881/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK36F2FF
From: <sip:[Link]>;tag=E4BC54-1CD4
To: <sip:[Link]>;tag=1387404949
Date: Fri, 01 Jun 2018 00:03:34 GMT
Call-ID: F90D7FA-646611E8-8375941E-48173748@[Link]
Server: Cisco-CUCM11.5
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

44 | P a g e
A single OPTION message for which no response was received by CUBE
001201: Jun 1 00:03:44.539:
//882/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK370B5E
From: <sip:[Link]>;tag=E4E364-1434
To: <sip:[Link]>
Date: Fri, 01 Jun 2018 00:03:44 GMT
Call-ID: 1586BB5D-646611E8-8376941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

The status of dial-peer voice 101 is busied out.


001202: Jun 1 00:03:45.039: %SIP-5-DIALPEER_STATUS: VoIP dial-
Peer <101> is Busied out

While the dial-peer is busied out, an OPTION is sent every 5 second (500
msec added for processing)

001203: Jun 1 00:03:50.039:


//883/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK371C72
From: <sip:[Link]>;tag=E4F8E0-90B
To: <sip:[Link]>
Date: Fri, 01 Jun 2018 00:03:50 GMT
Call-ID: 18CDF950-646611E8-8377941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

001204: Jun 1 00:03:55.539:


//884/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK3721CB5
From: <sip:[Link]>;tag=E50E5C-25D1
To: <sip:[Link]>
Date: Fri, 01 Jun 2018 00:03:55 GMT
Call-ID: 1C1535D8-646611E8-8378941E-48173748@[Link]
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2

45 | P a g e
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:[Link]:5060>
Content-Length: 0

CUBE#

Let’s see the status of dial-peer voice 101 with the show dial-peer voice summary.

cube#show dial-peer voice summary


dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF
100 voip up up 0 syst NA
101 voip up up +1408944....$ 0 syst ipv4:[Link] busyout NA
200 voip up up 0 syst NA
201 voip up up 81[2-9]..[2-9]..- 0 syst ipv4:[Link] NA
....$
For server-grp details please execute command:show voice classserver-group <tag_id>
To see complete session target for ipv6 use 'sh running config | section dial-peer <tag>

Before we move to section , let’s undo the following changes on CUBE.

CUBE#term no len 0
CUBE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CUBE(config)#no ip route [Link] [Link] Null0

46 | P a g e
G. Consolidating OPTIONS messages from CUBE

Task:
1. Add a second Outbound WAN dial-peer (tag it dial-peer voice 211 voip) for
International Calls using 011 as the International Access code
2. Busyout dial-peers 201 and 211 while monitoring CUBE’s response code towards
CUCM on an Outbound PSTN call attempt

Solution

1. Similar to dial-peer 201, we will create the following dial-peer 201 on CUBE to
deliver International calls to PSTN. However, international calls will not work as
there is no Route Pattern in CUCM for International calls and our ITSP for
this lab does not allow International calls.

dial-peer voice 211 voip


description *Outbound WAN dial-peer. INTL from CUBE to ITSP*
destination-pattern 8011T
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

2. As a keepalive monitoring mechanism, both the outbound WAN dial-peers, dial-


peer 201 and dial-peer 211 may be configured with voice-class sip options-
keepalive CLI to monitor the target destination(s). In this case both the dial-peers
have the same target destination IP, resulting in each dial-peer sending its own
respective OPTIONS to [Link].

Network bandwidth and process runtime are wasted in CUBE and remote targets to
sustain duplicate OOD OPTIONS ping heartbeat keepalive connections.

The resultant SIP OOD OPTIONS exchange through CUBE in such a scenario is
displayed on the next page.

47 | P a g e
Starting CUBE 10.0.0 [IOS 15.4(1)T / IOS-XE 3.11], the concept of SIP Out-of-Dialog
OPTIONS ping keepalive Group was introduced, which allows consolidation of OOD
Options Ping connections by grouping SIP dial-peers with same OOD Options Ping setup.

With OOD Options Ping Keepalive group, an options ping keepalive connection is
established on per remote target basis as opposed an options ping keepalive connection
established per dial-peer basis. If an OOD option ping keepalive profile is applied to dial-
peers with different destination target IPs, an OPTIONS will be sent per the target IP and if
an unsuccessful response is received for a target IP, only that dial-peer is busied out.

If OOD options ping keepalive profile is applied to dial-peers with the same target IP, a
single OPTIONS is sent on behalf of all those dial-peers. If an unsuccessful response is
received from the target IP, all the dial-peers for that target IP are busied out, provided the
same OPTIONS ping keepalive profile ID was applied on them.

Either legacy “voice-class sip options-keepalive” or the new “voice class sip options-
keepalive profile <tag>” can be configured on a dial-peer. Dial-peers with Destination
Server Group [Module 9] instead of Session Target IP must use Options Keepalive Profile
and not the legacy CLI.

48 | P a g e
Proceed as shown below to apply OPTIONS to dial-peers 201 and 211 which have the same
destination target IP [[Link]]

! Create an OOD SIP OTIONS keepalive profile with the tag of 200 and apply it to
! dial-peers 201 and 211

voice class sip-options-keepalive 200


description Target PSTN
down-interval 5
up-interval 10
retry 2
transport udp
!
CUBE(config)#voice class sip-options-keepalive 200
CUBE(config-class)# description Target PSTN
CUBE(config-class)# down-interval 5
CUBE(config-class)# up-interval 10
CUBE(config-class)# retry 2
CUBE(config-class)# transport udp
CUBE(config-class)#exit

CUBE(config)#dial-peer voice 201 voip


CUBE(config-dial-peer)#voice-class sip options-keepalive profile 200

CUBE(config-dial-peer)#dial-peer voice 211 voip


CUBE(config-dial-peer)#voice-class sip options-keepalive profile 200
CUBE(config-dial-peer)#end

! Let’s monitor the status of the OPTIONS keepalive group 200. Dial-peers 201 and 211
! can be seen in Active state below

CUBE#show voice class sip-options-keepalive 200


Voice class sip-options-keepalive: 200 AdminStat: Up
Description: Target PSTN
Transport: udp Sip Profiles: 0
Interval(seconds) Up: 10 Down: 5
Retry: 2

Peer Tag Server Group OOD SessID OOD Stat IfIndex


-------- ------------ ---------- -------- -------
201 1 Active 11
211 1 Active 12

OOD SessID: 1 OOD Stat: Active


Target: ipv4:[Link]
Transport: udp Sip Profiles: 0

------------------------------------------------------
CUBE#

49 | P a g e
Now we will simulate connectivity failure to ITSP’s IP address [[Link]] by adding a
null route and then see the state of dial-peers 201 and 211.

CUBE(config)#ip route [Link] [Link] null0


CUBE(config)#exit

! Wait for about 10 seconds and issue the following command. The dial-peers can
! be seen in busyout state

CUBE#show voice class sip-options-keepalive 200


Voice class sip-options-keepalive: 200 AdminStat: Up
Description: Target PSTN
Transport: udp Sip Profiles: 0
Interval(seconds) Up: 10 Down: 5
Retry: 2

Peer Tag Server Group OOD SessID OOD Stat IfIndex


-------- ------------ ---------- -------- -------
201 1 Busy 11
211 1 Busy 12

OOD SessID: 1 OOD Stat: Busy


Target: ipv4:[Link]
Transport: udp Sip Profiles: 0

------------------------------------------------------
CUBE#

! Now let’s enable SIP call debugs and place an outbound long distance PSTN call
! from your Jabber softphone [CSFMCHENG] by dialing 8-1-678-555-1111, which
we know
! from earlier sections of this Module that it will use dial-peer voice 201.

CUBE#
CUBE#un all
All possible debugging has been turned off
CUBE#clear log
Clear logging buffer [confirm]
CUBE#debug ccsip message
SIP Call messages tracing is enabled
CUBE#term len 0
CUBE#show log

! Since dial-peer voice 201 is in busyout state, CUBE will respond with 503 Service
! Unavailable to the incoming INVITE from CUCM for an outbound long distance
! call request

Log Buffer (9999999 bytes):

50 | P a g e
! Incoming INVITE from CUCM for an outbound PSTN call

010973: Jun 1 13:06:46.117: //-


1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:816785551111@[Link]:5060 SIP/2.0
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK511c648aa496
From: "Monica Cheng"
<sip:4089447700@[Link]>;tag=21985~72443a9a-68a6-49b2-8a3d-
9533cc415eaa-33022025
To: <sip:816785551111@[Link]>
Date: Fri, 01 Jun 2018 13:06:46 GMT
Call-ID: a1da7c80-b11144e6-511b-38512c6@[Link]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM11.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info:
<sip:[Link]:5060>;method="NOTIFY;Event=telephone-
event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-
class=DESKTOP
Session-ID:
0000366800105000a000005056acffc8;remote=0000000000000000000000000
0000000
Cisco-Guid: 2715450496-0000065536-0000000003-0059052742
Session-Expires: 1800
P-Asserted-Identity: "Monica Cheng" <sip:4089447700@[Link]>
Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=of
f
Contact:
<sip:4089447700@[Link]:5060;transport=tcp>;video;audio;+u.s
ip![Link]="CSFMCHENG";bfcp
Max-Forwards: 69
Content-Length: 0

51 | P a g e
! TRYING sent back by CUBE
010974: Jun 1 13:06:46.125:
//7290/A1DA7C800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK511c648aa496
From: "Monica Cheng"
<sip:4089447700@[Link]>;tag=21985~72443a9a-68a6-49b2-8a3d-
9533cc415eaa-33022025
To: <sip:816785551111@[Link]>
Date: Fri, 01 Jun 2018 13:06:46 GMT
Call-ID: a1da7c80-b11144e6-511b-38512c6@[Link]
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.7.3.M2
Session-ID:
00000000000000000000000000000000;remote=0000366800105000a00000505
6acffc8
Content-Length: 0

! Since there is no active outbound WAN dial-peer available, CUBE


! sends back a 503 Service Unavailable to CUCM
010975: Jun 1 13:06:46.129:
//7290/A1DA7C800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK511c648aa496
From: "Monica Cheng"
<sip:4089447700@[Link]>;tag=21985~72443a9a-68a6-49b2-8a3d-
9533cc415eaa-33022025
To: <sip:816785551111@[Link]>;tag=3B1C3FC-2439
Date: Fri, 01 Jun 2018 13:06:46 GMT
Call-ID: a1da7c80-b11144e6-511b-38512c6@[Link]
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.7.3.M2
Reason: Q.850;cause=0
Session-ID:
00000000000000000000000000000000;remote=0000366800105000a00000505
6acffc8
Content-Length: 0

CUBE#

52 | P a g e
Before proceeding to the next module, please proceed as shown below

CUBE#
CUBE#un all
All possible debugging has been turned off
CUBE#clear log
Clear logging buffer [confirm]
CUBE#term no len 0
CUBE#conf t
Enter configuration commands, one per line. End with CNTL/Z.

CUBE(config)#no ip route [Link] [Link] Null0


CUBE(config)#

53 | P a g e
Module 2 – Basic SIP Profiles and Debug
Categorization
Prior to attempting this Module, ensure Module 1 has been completed

This module describes how to configure CUBE to create SIP profiles to manipulate and
normalize SIP messages to make sure your voice network is able to interoperate with
Service provider’s network successfully.

SIP Profiles are classified into two categories.


1. Basic SIP Profile - This provides the flexibility for users to add/modify/remove
SIP/SDP header values in outgoing SIP messages
2. Conditional SIP Profile
a. This provides the ability to pass unsupported parameter(s) present in a
mandatory header from one leg to the other leg of CUBE.
b. Also this provides the ability to copy contents from one header to another
header in an outgoing SIP message

Starting CUBE 10.0.1 [IOS 15.4(2)T / IOS-XE 3.12] SIP Profiles can be applied to
Incoming SIP messages to CUBE. Inbound SIP message normalization takes place before
regular SIP call processing happens so that the behavior of CUBE would be as if it received
the normalized message directly from transport.

CUBE 11.0.0 [IOS 15.5(2)T / IOS-XE 3.15] adds the capability to ADD, MODIFY,
REMOVE, and COPY non-standard (custom) SIP headers using SIP Profiles

Task:

Configure basic outgoing SIP Profiles to meet the following requirements


1. Strip min-SE and session-expires headers from the SIP INVITE going towards
the Service provider from CUBE
2. Add a non-standard header to any outgoing SIP INVITE.

54 | P a g e
Solution:

1. Create a voice-class SIP Profile to strip min-SE and session-expires header from the SIP
INVITE message as shown below;

voice class sip-profile 1


request INVITE sip-header Min-SE remove
request INVITE sip-header Session-Expires remove

SIP profiles can either be applied globally or at the dial-peer level. It is generally
recommended to apply the SIP Profile at a dial-peer level, which is what we will do in this
lab.
We will apply SIP-Profile 1 to dial-peer 201 for this task as the task asks as to remove the
headers from the INVITE going from CUBE to the ITSP

dial-peer voice 201 voip


description *Outbound WAN dial-peer. Long distance from CUBE to SP*
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip options-keepalive profile 200
voice-class sip profiles 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

Turn on “debug ccsip messages” on CUBE and follow the steps to collect debugs as
mentioned in Module 1, Section E. Make a test long distance call. Disconnect the call and
scroll through the debugs to verify that min-SE and Session-expires timers were removed
from the outbound invite from CUBE to ITSP.

NOTE : Min-SE and Session-Expires will still be visible in the incoming


SIP message from CUCM to CUBE.

55 | P a g e
Debugs prior to application of SIP Profile 1, showing SIP INVITE from CUBE to
ITSP.

012300: Oct 12 23:21:05.119: //150/03B18C000000/SIP/Msg/ccsipDisplayMsg:


Sent:
INVITE sip:816785555555@[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link];branch=z9hG4bKB31B22
Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=6C37FC94-19F4
To: <sip:816785555555@[Link]>
Date: Thu, 12 Oct 2017 23:21:05 GMT
Call-ID: DA920D39-AEDA11E7-81C7EB98-6E1C05F0@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0061967360-0000065536-0000000055-0059052742
User-Agent: Cisco-SIPGateway/IOS-15.6.3.M0a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1507850465
Contact: <sip:4089447700@[Link]>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-ID:
00007f5b00105000a000005056acffc8;remote=00000000000000000000000000000000
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241

v=0
o=CiscoSystemsSIP-GW-UserAgent 8000 4250 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16682 RTP/AVP 0 101
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

After SIP Profile 1 is applied to dial-peer 201, the outbound INVITE from CUBE to ITSP
will not have Min-SE: 1800 and Session-Expires: 1800 fields.

56 | P a g e
2. Add a non-standard header to any outgoing SIP INVITE.

Solution:

Create a voice-class SIP Profile to add a custom header called “HUSSAIN ALI” to
outgoing SIP INVITES with a value of “DK SINGH”.

voice class sip-profiles 3


request INVITE sip-header WORD ADD "HUSSAIN ALI: CCIE# 38068"
request INVITE sip-header WORD ADD "DK SINGH: CCIE# 16545"

We will apply SIP-Profile 3 to dial-peer 201 for this task. Before we can do so, let’s remove
SIP Profile 1 from dial-peer 201

CUBE(config-class)#dial-peer voice 201


CUBE(config-dial-peer)#no voice-class sip profiles 1
CUBE(config-dial-peer)#voice-class sip profiles 3

57 | P a g e
Verification:

Turn on “debug ccsip messages” on CUBE and follow the steps to collect debugs as
mentioned at the in Module 1, Section E. Make a test long distance call. Disconnect the call
and scroll through the debugs to verify that “HUSSAIN ALI: CCIE# 38068” and “DK
SINGH: CCIE# 16545” headers were appended to the outgoing SIP INVITE towards the
ITSP by CUBE.

012373: Oct 12 23:37:47.506: //158/58EE9D000000/SIP/Msg/ccsipDisplayMsg:


Sent:
INVITE sip:816785555555@[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link];branch=z9hG4bKBD11E9
Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=6C474820-24BF
To: <sip:816785555555@[Link]>
Date: Thu, 12 Oct 2017 23:37:47 GMT
Call-ID: 300A2764-AEDD11E7-81DFEB98-6E1C05F0@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1492032768-0000065536-0000000059-0059052742
User-Agent: Cisco-SIPGateway/IOS-15.6.3.M0a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1507851467
Contact: <sip:4089447700@[Link]>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-ID:
000010c500105000a000005056acffc8;remote=00000000000000000000000000000000
Session-Expires: 1800
Content-Type: application/sdp

Content-Disposition: session;handling=required
Content-Length: 241
HUSSAIN ALI: CCIE# 38068
DK SINGH: CCIE# 16545
v=0
o=CiscoSystemsSIP-GW-UserAgent 5202 9484 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16698 RTP/AVP 0 101
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

58 | P a g e
Troubleshooting Tips:

Existing CCSIP INFO debugs was becoming too verbose and un-manageable as more
features were added to CUBE. These debugs were enhanced with sub-categories for better
debugging and to control the amount of information logged.

Starting CUBE 9.5.1 [IOS 15.3(3)M1 / IOS-XE 3.10.1] SIP INFO debugs are now
categorized based on functionality. For example, to see the application of SIP Profile for
the above call, we will only run SIP Profile debugs to see a more manageable and specific
output.

The following functional categories are available for SIP INFO debugs

CUBE# debug ccsip info


CUBE# debug ccsip feature ?
audio enable audio debugging
cac enable cac debugging
config enable config debugging
control enable control debugging
dtmf enable dtmf debugging
fax enable fax debugging
line enable SIP/CME line debugging
misc-features enable miscellaneous feature debugging
miscellaneous enable misc (catch all) debugging
parse enable parse debugging
registration enable SIP registration debugging
sdp-negotiation enable sdp debugging
sdp-passthrough enable sdp-passthrough debugging
sip-profiles enable sip-profiles debugging
sip-transport enable SIP transport debugging
srtp enable srtp debugging
supplementary-services enable supplementary services debugging
transcoder enable transcoder debugging
video enable video debugging

We will turn on sip-profiles feature debug to verify the application of SIP Profile 3 for this
call. Proceed as shown below:

CUBE# un all
CUBE# debug ccsip info
CUBE# debug ccsip feature sip-profiles
CUBE# clear log
Clear logging buffer [confirm]!!!!!!! Press Enter to confirm

Make a test long distance call again and issue show log.

59 | P a g e
CUBE#show log

Log Buffer (9999999 bytes):

012388: Oct 12 23:40:54.727: //-


1/xxxxxxxxxxxx/SIP/Info/info/64/sipSPISetSipProfilesTag: voice class SIP
Profiles tag is set : 3
012389: Oct 12 23:40:54.727: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_change_sip_headers:
New header added to the SIP message : HUSSAIN ALI: CCIE# 38068
012390: Oct 12 23:40:54.727: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_change_sip_headers:
New header added to the SIP message : DK SINGH: CCIE# 16545
012391: Oct 12 23:40:54.731: //-
1/xxxxxxxxxxxx/SIP/Info/ccsip_process_tcp_queue_event: Event type: send msg,
connid: 38, fd: 3

64 is the debug category code for SIP-Profile feature within the CUBE SIP Info debugs.
Rest of the category codes are shown below:

CUBE#show cube debug category codes


|-----------------------------------------------
| show cube debug category caodes values.
|-----------------------------------------------
| Indx | Debug Name | Value
|-----------------------------------------------
| 01 | SDP Debugs | 1
| 02 | Audio Debugs | 2
| 03 | Video Debugs | 4
| 04 | Fax Debugs | 8
| 05 | SRTP Debugs | 16
| 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
|----------------------------------------------

60 | P a g e
NOTE: Let’s remove SIP Profile 3 from dial-peer 201 to proceed with the
rest of the lab and turn off debugging for now.
CUBE(config-class)#dial-peer voice 201
CUBE(config-dial-peer)#no voice-class sip profiles 3
CUBE(config-dial-peer)#end
CUBE#undebug all
All possible debugging has been turned off
CUBE#

61 | P a g e
Module 3 – Configuring Media Transcoding
Prior to attempting this Module, ensure Module 1 has been completed

Media Transcoding is required whenever you need to convert from one codec on an
incoming call leg to another codec for an outgoing call leg. Per the requirements, we will
configure:
- Call leg between CUCM and CUBE as g729ar8
- Call leg between CUBE and ITSP as g711ulaw

Thus, for CUBE to transcode the call from one codec to another, we will need to setup a
transcoder. The following section will cover the configurations required to configure a
transcoder on the ISR G2 platforms

62 | P a g e
Prerequisites:

Configuring transcoding on CUBE requires DSPs to be available on the platform. You


should use the dsp calculator to determine the number of DSPs required.

ISR G2 Platform
The ISR G2 uses PVDM3 DSPs to enable services such as transcoding and transrating of
audio calls. This functionality also exists on the ASRs that use DSP-SPAs and ISR 4000
series that use PVDM4 and SM-X-PVDM DSPs. The transcoding implementation on ASR
leverage the codec used on ISR but with significant changes while providing the same
features and functionality. There are two ways CUBE can invoke and communicate with the
DSPs. SCCP based DSP invocation and Local Transcoding Interface (LTI) which uses
internal APIs to control the DSPs. In this lab we will configure steps that use the LTI
method. ASR 1000 series uses SPA DSPs that can only be invoked using LTI and starting
CUBE 9.0, LTI was introduced on ISR G2 platforms. For more information, visit
[Link]
element/[Link]

There are two steps in configuring the DSPfarm for Transcoding

1. Enabling dspfarm services under voice-card


2. Configuring dspfarm profile

1. Enabling dspfarm services under voice-card

Configure the following under voice-card to enable the dspfarm services.

CUBE(config)#voice-card 0
CUBE(config-voicecard)#dsp services dspfarm
CUBE(config-voicecard)#

63 | P a g e
2. Dspfarm profile configuration

CUBE(config)#dspfarm profile 3 transcode


CUBE(config-dspfarm-profile)#codec g729r8
CUBE(config-dspfarm-profile)#maximum session 2
CUBE(config-dspfarm-profile)#associate application CUBE
CUBE(config-dspfarm-profile)#no shut
CUBE(config-dspfarm-profile)#

Final configuration of the dspfarm should look like as below:

CUBE#sh run | sec dspfarm profile 3


dspfarm profile 3 transcode
codec g729r8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 2
associate application CUBE

On your dial-peer towards UCM, change the codec to G.729. Thus, you will be sending the
calls as G.711 towards the SIP trunk provider and the call towards CUCM would be as
G.729. Make the highlighted changes to dial-peers 100 and 101 as shown below:

dial-peer voice 100 voip


description *** Inbound LAN dial-peer. From CUCM to CUBE ***
codec g729r8

dial-peer voice 101 voip


description *** Outbound LAN dial-peer. From CUBE to CUCM ***
codec g729r8

The final configuration of dial-peers 100 and 101 is displayed on the next page. Note G729
is the default codec for a dial-peer and as such will not be displayed when show run is
issued.

64 | P a g e
dial-peer voice 100 voip
description *** Inbound LAN dial-peer. From CUCM to CUBE ***
session protocol sipv2
incoming called-number 8T
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
no vad

dial-peer voice 101 voip


description *** Outbound LAN dial-peer. From CUBE to CUCM ***
translation-profile outgoing CUBE_to_CUCM
destination-pattern +1408944....$
session protocol sipv2
session target ipv4:[Link]
voice-class sip options-keepalive up-interval 10 down-interval 5 retry 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
no vad

Verification:

1. Place an inbound call to your Jabber Softphone or an outbound call from it. Issue the
following show command to see the active transcoded call on CUBE:

CUBE#show call active voice compact


<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> VRF
Total call-legs: 2
63 ANS T2 g711ulaw VOIP P6785555555 [Link]:19642 NA
64 ORG T2 g729r8 VOIP P+14085557700 [Link]:19224 NA

2. To verify the dspfarm profile configuration, issue the following command on CUBE
with the call up;

CUBE#show dspfarm all


Dspfarm Profile Configuration

Profile ID = 3, Service = TRANSCODING, Resource ID = 1


Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Total Number of Resources Configured : 2
Total Number of Resources Available : 1
Total Number of Resources Out of Service : 0
Total Number of Resources Active : 1
Codec Configuration: num_of_codecs:5
Codec : g729r8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60

65 | P a g e
Codec : g729abr8, Maximum Packetization Period : 60

SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED
PKTS_RXED

0 1 46.2.4 UP 1 USED xcode 1 440 2630 2633


0 1 46.2.4 UP 1 USED xcode 1 439 2628 2630
0 1 46.2.4 UP N/A FREE xcode 1 - - -

Total number of DSPFARM DSP channel(s) 2

3. To check the active DSP information, issue the following command on CUBE with the
call up:
CUBE#show dspfarm dsp active
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 46.2.4 UP 1 USED xcode 1 62 32796 32821


0 1 46.2.4 UP 1 USED xcode 1 61 32816 32796

Total number of DSPFARM DSP channel(s) 1

For the rest of the lab, let’s change the codecs on dial-peers 100 and 101 back to G.711

dial-peer voice 100 voip


description *** Inbound LAN dial-peer. From CUCM to CUBE ***
codec g711ulaw

dial-peer voice 101 voip


description *** Outbound LAN dial-peer. From CUBE to CUCM ***
codec g711ulaw

66 | P a g e
Module 4 – Configuring Call Admission Control
Prior to attempting this Module, ensure Module 1 has been completed

It is a best practice to configure CUBE for Call Admission Control to make sure it adheres
to certain user-defined thresholds. If it exceeds these thresholds, CUBE will stop accepting
new calls to prevent any catastrophic effects like crashing the router, or security violation of
your network policies. These thresholds can be based on CPU, memory, call spikes, SIP
based Denial of Service attacks, etc.

Task:
Configure CUBE for the following requirements:
1. CAC based on call spike to manage call arrival rate
2. CAC based on maximum simultaneous connections per destination
3. CAC based on different thresholds like total call count, CPU or memory

67 | P a g e
Solution:

1. CAC based on call spike:

Call spikes can occur due to SIP based Denial of service attacks, e.g., a spike of REGISTER
messages, INVITE messages etc. CUBE can detect these spikes defined as a surge in
incoming requests within a short window by use of following commands:

Call spike <call-number 1-2147483647> steps <3–10> size <100–


250>

Example 1: To configure 10 incoming call requests per 300 milliseconds, configure

CUBE(config)#call spike 10 steps 3 size 100

Example 2: To Configure the CPS (Calls per second) to be no more than 12, configure

CUBE(config)#call spike 12

Verification:

Make a test call and issue the following command repeatedly. You will see one call in that
window. Given call setup is instantaneous; you may not see the output shown below as
you execute the show call spike status CLI.

CUBE#show call spike status


Call Spiking: Configured
Call spiking : NOT TRIGGERED
total call count in sliding window :: 1

68 | P a g e
2. CAC based on Max Connections:

“Max Connection” feature restricts the number of calls that can be active on a VOIP dial-
peer. This feature provides CAC on a per dial-peer basis. For this lab, make sure that only 1
long-distance call is allowed:

To achieve this, we will make use of the max-conn CLI. Since only 1 call is to be allowed,
we will apply the following command under the “Long-distance Dial-peer”, dial-peer 201.

max-conn 1

dial-peer voice 201 voip


description *Outbound WAN dial-peer. Long distance from CUBE to SP*
max-conn 1
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip options-keepalive profile 200
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

Verification:

Make a long distance call and keep it up. Press the HOLD or CONFRN key on Jabber and
dial another long distance number. You should get a busy tone for that call. Upon removal
of the CLI “max-conn 1” you will be able to complete the 2nd call successfully.

Remove the above change by issuing “no max-conn 1” on dial-peer 201

69 | P a g e
3. CAC based on different thresholds:

“Call Threshold” command is used to configure two thresholds, high and low. “Call
treatment” is triggered when the current value of a resource goes beyond the configured
high. The “call treatment” remains in effect until the current resource value falls below the
configured low.

CUBE(config)#call threshold global ?


cpu-5sec the CPU utilization in the last 5 seconds
cpu-avg the average CPU utilization
io-mem the IO memory utilization
proc-mem the Processor memory utilization
total-calls the total number of calls
total-mem the total memory utilization

For example, the following command configures a threshold based on total number of calls
traversing CUBE

Call threshold global total-calls low <low threshold> high


<high-threshold>

Let’s configure the following thresholds:

CUBE(config)#call threshold global total-calls low 1 high 1


CUBE(config)#call threshold global cpu-avg low 75 high 85
CUBE(config)#call threshold global total-mem low 75 high 85
CUBE(config)#call treatment on

70 | P a g e
Verification:

Call threshold status can be verified by issuing the following command on CUBE:

CUBE#show call threshold status


Status IF Type Value Low High Enable
------ --- ------ ----- ---- ---- ------
Avail N/A total-calls 0 1 1 busy&treat
Avail N/A cpu-avg 1 70 90 busy&treat
Avail N/A total-mem 31 70 75 busy&treat

For any calls rejected by CUBE when the threshold is exceeded, it sends a 503 Service
Unavailable by default. We have configured the total-calls threshold to be 1. Make a test
long distance call, put it on hold, and make an inbound PSTN call to your Jabber from a
PSTN phone as the second call. Upon making that second call to the CUBE while the first
one is on hold, you can see the following in the debugs (debug ccsip message and
debug voip ccapi inout) and you should get a busy tone for that call.

Received:
INVITE sip:+140894429DN@[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK4C1667
Remote-Party-ID:
<sip:6785555555@[Link]>;party=calling;screen=yes;privacy=off
From: <sip:6785555555@[Link]>;tag=CA61C086-533
To: <sip:+140894429DN@[Link]>
Date: Fri, 13 Oct 2017 00:28:09 GMT
Call-ID: 39743A06-AEE411E7-879ECF11-D1189DED@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0963918342-2934182375-2306339063-1433811328
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1507854489
Contact: <sip:6785555555@[Link]:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 239

v=0
o=CiscoSystemsSIP-GW-UserAgent 5290 35 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16644 RTP/AVP 0 101
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

71 | P a g e
012544: Oct 13 00:28:09.780: %SIP-3-TOTCALLCAC: Call rejected due to CAC
based on Total-calls, sent response 503

012545: Oct 13 00:28:09.784: //184/39743A068977/SIP/Msg/ccsipDisplayMsg:

Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK4C1667
From: <sip:6785555555@[Link]>;tag=CA61C086-533
To: <sip:+140894429DN@[Link]>;tag=6C7565D0-22F
Date: Fri, 13 Oct 2017 00:28:09 GMT
Call-ID: 39743A06-AEE411E7-879ECF11-D1189DED@[Link]
Timestamp: 1507854489
CSeq: 101 INVITE
Allow-Events: telephone-event
Warning: 399 [Link] "Call Threshold Exceeded"
Server: Cisco-SIPGateway/IOS-15.6.3.M0a
Session-ID:
02762aa058385607ad7cd91d6cf686f3;remote=498be644adf25d0b9813a653a7167677
Content-Length: 0

NOTE: For DN and POD, refer to table on page 8 to find the last octet of your pod’s
CUBE’s WAN (Gig 0/1) IP Address and your respective POD’s DID number.

72 | P a g e
Module 5 – Configurable SIP Error codes
Prior to attempting this Module, ensure Modules 1 and 4 have been
completed
Prior to CUBE 10.0.0, the sip profiles can be classified based on the message type (i.e
request or response). For example, a sip profile configured for a 200 response-code will be
applied to 200 response-code sent for all requests such as INVITE, UPDATE, BYE,
PRACK etc. In many cases, it is desirable to selectively apply the profiles based on the
request to which the response is sent.

Take for example the total-call threshold CAC configured in the last task of Module 4
where we just send a “503 Service Unavailable” response when the threshold is exceeded.
Sending a more meaningful response back to the initiating party when a certain CAC
threshold is exceeded allows for the initiating party to take appropriate action and makes
troubleshooting easier.

In this exercise we will configure CUBE to send “502 Total Number of Calls Allowed
Exceeded” when the total call limit on CUBE is exceeded. There are three steps to
configure this:

1. Configure Error code at the dial-peer level when total-calls are exceeded
2. SIP response status line modification with SIP Profiles
3. Apply SIP profile to the inbound WAN dial-peer (dial-peer 200) to accept legs
from the service provider

73 | P a g e
1. Configure Error code at the dial-peer level when total-calls are exceeded

The error-code-override command can either be configured globally or under the dial-peer.

Global Configuration for your reference. For this task we will only configure this under the
dial-peer.

CUBE(config)#call threshold global total-calls low 1 high 1


CUBE(config)#call treatment on
CUBE(config)#voice service voip
CUBE(conf-voi-serv)#sip
CUBE(conf-serv-sip)#error-code-override ?
cac-bandwidth Status code to be sent for max-bandwidth CAC
call Configure call parameters
cpu Status code to be sent for all cpu threshold
max-conn Status code to be sent for max-conn threshold
mem Status code to be sent for all memory threshold
options-keepalive Status code to be sent for options keepalive
sip-shutdown Status code to be sent for all SIP Shutdown
total-calls Status code to be sent for total call threshold

CUBE(conf-serv-sip)#error-code-override total-calls failure 502

Dial-peer level configuration: Update dial-peer 200 with the following CLI as highlighted
below:

dial-peer voice 200 voip


description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
voice-class sip error-code-override total-calls failure 502
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

2. SIP response status line modification with SIP Profiles

By default 502 message says “Bad Gateway”. With SIP Profile 4, we are change the
default response status to say “502 Total Number of Calls Allowed Exceeded”

voice class sip-profiles 4


response 502 sip-header SIP-StatusLine modify "(.*)" "502 Total
Number of Calls Allowed Exceeded"

74 | P a g e
3. Apply SIP profile to the inbound WAN dial-peer (dial-peer 200)

Apply SIP Profile 4 to dial-peer 200 as shown below:

CUBE(config)#dial-peer voice 200 voip


CUBE(config-dial-peer)#voice-class sip profiles 4

Dial-peer 200 should look like as below:

dial-peer voice 200 voip


description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
voice-class sip profiles 4
voice-class sip error-code-override total-calls failure 502
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

75 | P a g e
Verification:

Place an inbound call to your IP Phone from your cell phone and keep it up. Run
debug ccsip message and debug voip ccapi inout on CUBE. Now place a second call to
your IP Phone to exceed the total-calls high threshold of 1. Compare the debugs to the last
task in Module 4. You may continue to hear ringback or a carrier announcement for call
failure.

012576: Oct 13 00:43:05.478: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:
INVITE sip:+140894429DN@[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK531CBC
Remote-Party-ID:
<sip:6785555555@[Link]>;party=calling;screen=yes;privacy=off
From: <sip:6785555555@[Link]>;tag=CA6F6A62-A9A
To: <sip:+140894429DN@[Link]>
Date: Fri, 13 Oct 2017 00:43:05 GMT
Call-ID: 4F556F5D-AEE611E7-87BCCF11-D1189DED@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1330999133-2934313447-2306666743-1433811328
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1507855385
Contact: <sip:6785555555@[Link]:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 240

v=0
o=CiscoSystemsSIP-GW-UserAgent 710 8063 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 19268 RTP/AVP 0 101
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

012577: Oct 13 00:43:05.486: %CALLTREAT-3-HIGH_TOTAL_CALLS: High


call volume. Processing for callID(190) is rejected.

76 | P a g e
012579: Oct 13 00:43:05.486: %SIP-3-TOTCALLCAC: Call rejected due to
CAC based on Total-calls, sent response 502

012580: Oct 13 00:43:05.486: //190/4F556F5D897C/SIP/Msg/ccsipDisplayMsg:


Sent:
502 Total Number of Calls Allowed Exceeded
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK531CBC
From: <sip:6785555555@[Link]>;tag=CA6F6A62-A9A
To: <sip:+140894429DN@[Link]>;tag=6C8310A0-166B
Date: Fri, 13 Oct 2017 00:43:05 GMT
Call-ID: 4F556F5D-AEE611E7-87BCCF11-D1189DED@[Link]
Timestamp: 1507855385
CSeq: 101 INVITE
Allow-Events: telephone-event
Warning: 399 [Link] "Call Threshold Exceeded"
Server: Cisco-SIPGateway/IOS-15.6.3.M0a
Reason: Q.850;cause=47
Session-ID:
f79d39321a685f4b8e58f1f99d49f73e;remote=06d98d73b1f25ffaad8d7ec0b1f607d7
Content-Length: 0

Note: To proceed with the rest of the lab, remove the changes made to
dial-peer 200 as part of this module. They are highlighted below in yellow.
dial-peer voice 200 voip
description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
no voice-class sip profiles 4
no voice-class sip error-code-override total-calls failure 502
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

Note: Disable the total-calls threshold as shown below. We will need to make
multiple calls through CUBE for the rest of the modules.
CUBE(config)#no call threshold global total-calls low 1 high 1
CUBE(config)#no call treatment on

77 | P a g e
Module 6 – Destination Dial-peer Group and
Inbound SIP Profiles
Prior to attempting this Module, ensure Module 1 has been completed

CUBE 10.0.0 introduces Destination Dial-peer Group (dpg) that allows grouping multiple
outbound dial peers as the destination of an inbound dial-peer. Multiple outbound dial-peers
are saved under a voice class dpg. This voice class dpg is referenced in an inbound dial-
peer. Once an incoming call matches and selects an inbound dial-peer configured with an
active destination dpg, outbound dial-peer provisioning to select outbound dial-peers is
skipped. Only the dial-peers specified in the destination dpg are then used for setting up and
routing the outbound leg of the call. In other words, it enables the inbound dial-peer to
control outbound dial-peer(s) used for delivering the call without considering the
destination-pattern for the best match algorithm otherwise used in outbound dial-peer
selection

This feature simplifies dial plan provisioning on a CUBE by reducing existing outbound
dial-peer provisioning requirements. It eliminates the need to configure extra outbound dial-
peers that are sometimes needed as workarounds to achieve desired call routing outcome.
Existing global “dial-peer hunt” command line will still be used to sort target dpg dial-
peers in order. Hence, longest matched digits will no longer significant because call number
is not used to selected outbound dial-peers.

One use case could be to reference all your Subscribers from a single inbound WAN dial-
peer on CUBE. Since we only have one CUCM node per pod in this lab, we will use an
alternate benefit of Dial-peer Group to understand the feature better, whereby we will call an
outgoing PSTN dial-peer directly from an inbound LAN dial-peer.

Task

For this exercise we will call the Cisco TAC Toll Free number, 1-800-553-2447. In
addition to ensuring that this call is routed using new dial-peers being provisioned, it’s
also desired that Identity headers of the SIP messages reflect some relevant
information.

1. Create a SIP profile with tag 1800 to modify Identity headers (To, From, Remote-
Party-ID) in the incoming SIP request. This profile will be applied to the inbound
dialpeer that we will create in the next step.

2. Create an Inbound LAN dial-peer similar to dial-peer 100 but with a different tag. It
will allow accepting incoming calls destined for TAC number above to be accepted
by CUBE. We will call it dial-peer 81800

3. Create an Outbound WAN dial-peer towards ITSP similar to dial-peer 201. We will
call it dial-peer 81800553

78 | P a g e
4. Create Dial-peer group (DPG) 1800 with outbound dial-peer 81800553 as its
member. Apply dpg 1800 to incoming dial-peer 81800 created in step 1 above.

79 | P a g e
Solution

1. Turn on inbound SIP Profile feature and create sip profile to handle identity header
changes:

voice service voip


sip
sip-profiles inbound

voice class sip-profiles 1800


request INVITE sip-header To modify "(<sip.*)" "\"Cisco TAC\" \1"
request INVITE sip-header Remote-Party-ID modify "(\"Monica.*)( <sip.*)" "\"DK Singh\"\2"
request INVITE sip-header From modify "(\"Monica.*)( <sip.*)" "\"Hussain Ali\"\2"

2. Create the following Inbound LAN Dial-peer to accept incoming calls destined for TAC
number to be accepted by CUBE. Apply the sip profile created above, to this dial-peer.

dial-peer voice 81800 voip


description *** Inbound for TAC Calls. From CUCM to CUBE ***
session protocol sipv2
incoming called-number 818005532447$
voice-class sip profiles 1800 inbound
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

3. Create Outbound WAN dial-peer to allow delivering of the above call leg towards ITSP.

dial-peer voice 81800553 voip


destination-pattern 81..........$ !! 10-Dots following 81
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

80 | P a g e
Test

Now call Cisco TAC Toll Free number by dialing 818005532447 from your Jabber soft
phone. The call will work and you will notice that it still uses dial-peer 201 as opposed to
the intended dial-peer 81800553 that we created for routing outbound calls to Cisco TAC.

CUBE#show call active voice brief | incl pid

<ID>: <CallID> <start>ms.<index> (<start>) +<connect> pid:<peer_id> <dir> <addr> <state>


1CB4 : 37 523369850ms.1 (16:38:39.677 PDT Tue Oct 24 2017) +2510
pid:81800 Answer 4089447700 active
1CB4 : 38 523369860ms.1 (16:38:39.687 PDT Tue Oct 24 2017) +2500 pid:201
Originate 818005532447 active

As noticed, dial-peer 201 was used to route this call to ITSP and not dial-peer 81800553.
Here’s why? For all incoming calls towards CUBE, where the DNIS is 818005532447,
either dial-peer 201 or 81800553 can be chosen to process the outbound call.

CUBE# show dialplan number 818005532447 | incl VoiceOverIpPeer


VoiceOverIpPeer201
VoiceOverIpPeer81800553

dial-peer voice 201 voip


description *Outbound WAN dial-peer. Long distance from CUBE to SP*
translation-profile outgoing AccessCode_and_CLI_Changes
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

dial-peer voice 81800553 voip


destination-pattern 81..........$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

81 | P a g e
However, IOS uses dial-peer 201 to route calls to 818005532447 as it’s a more explicit
match and dial-peer hunt 0 is enabled by default. You have to issue show run all to see
dial-peer hunt in the output.

CUBE#show run all | sec dial-peer hunt


dial-peer hunt 0

p10_CUBE-1(config)#dial-peer hunt ?
<0-7> Dial-peer hunting choices, listed in hunting order within each
choice:
0 - Longest match in phone number, explicit preference, random selection.
1 - Longest match in phone number, explicit preference, least recent use.
2 - Explicit preference, longest match in phone number, random selection.
3 - Explicit preference, longest match in phone number, least recent use.
4 - Least recent use, longest match in phone number, explicit preference.
5 - Least recent use, explicit preference, longest match in phone number.
6 - Random selection.
7 - Least recent use.

4. Now create Dial-peer Group (DPG) 1800 as shown below and apply it to the Incoming
dial-peer 81800 created above

voice class dpg 1800


dial-peer 81800553 preference 1

dial-peer voice 81800 voip


destination dpg 1800

To verify dpg setup, issue following CLI:

CUBE#show voice class dpg


Voice class dpg: 1800 AdminStatus: Up
Description:
Total dial-peer entries: 1

Peer Tag Pref


-------- ----
81800553 1

Applying DPG 1800 to the inbound dial-peer ensures the best match in phone number is
forgone and inbound dial-peer 81800 directly calls the outgoing dial-peer 81800553 to route
the call.

Verification

Again place a call to Cisco TAC by dialing 8-1800-553-2447 from your Jabber Softphone
while enabling SIP Profile debugging as shown below to follow the application of Inbound
SIP Profiles to change the Identity headers and the dial-peers used to route the call.

82 | P a g e
CUBE# undebug all
All possible debugging has been turned off

CUBE# clear log


Clear logging buffer [confirm]

CUBE# debug ccsip info


SIP Call info tracing is enabled

CUBE# debug ccsip feature sip-profile


sip-profiles debugging for ccsip info is enabled (active)

CUBE# debug voip ccapi inout


Voip ccapi inout debugging is on

Place a call to Cisco TAC from your Jabber SoftPhone by dialing 8 1


800 553 2447. Once the call is up, we can verify the dial-peers being used
for this call, which are 81800 as the incoming dial-peer and 81800553 as
the outgoing dial-peer.
CUBE# show log

001993: Oct 24 23:54:56.598: //-


1/xxxxxxxxxxxx/SIP/Info/verbose/64/ccsip_inbound_profile_populate_callin
fo_in_ccb: Dial-peer 81800 is used for inbound profiles config
001994: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sipSPISetSipProfilesTag: voice class SIP
Profiles inbound tag is set : 1800
001995: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header before modification : To: <sip:818005532447@[Link]>
001996: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header after modification : To: "Cisco TAC"
<sip:818005532447@[Link]>
001997: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header before modification : Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
001998: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header after modification : Remote-Party-ID: "DK Singh"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
001999: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header before modification : From: "Monica Cheng"
<sip:4089447700@[Link]>;tag=2244~72443a9a-68a6-49b2-8a3d-
9533cc415eaa-28814612
002000: Oct 24 23:54:56.598: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_h
eader: Header after modification : From: "Hussain Ali"

83 | P a g e
<sip:4089447700@[Link]>;tag=2244~72443a9a-68a6-49b2-8a3d-
9533cc415eaa-28814612
002001: Oct 24 23:54:56.602: //-
1/xxxxxxxxxxxx/SIP/Info/info/64/sipSPISetSipProfilesTag: voice class SIP
Profiles inbound tag is set : 1800
002242: Oct 25 00:03:02.834: //-
1/DCE644800000/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=4089447700
----- ccCallInfo IE subfields -----
cisco-ani=sip:4089447700@[Link]
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=sip:818005532447@[Link]:5060
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

002243: Oct 25 00:03:02.834: //-


1/DCE644800000/CCAPI/cc_api_call_setup_ind_common:
Interface=0x22C82D1C, Call Info(
Calling Number=sip:4089447700@[Link],(Calling
Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed,
Presentation=Allowed),
Called Number=sip:818005532447@[Link]:5060(TON=Unknown,
NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown,
FinalDestinationFlag=TRUE,
Incoming Dial-peer=81800, Progress Indication=NULL(0), Calling
IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID
Transparent=FALSE), Call Id=41
002244: Oct 25 00:03:02.834: //-1/DCE644800000/CCAPI/ccCheckClipClir:
In: Calling Number=sip:4089447700@[Link](TON=Unknown,
NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
002245: Oct 25 00:03:02.834: //-1/DCE644800000/CCAPI/ccCheckClipClir:
Out: Calling Number=sip:4089447700@[Link](TON=Unknown,
NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
002246: Oct 25 00:03:02.834: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

002247: Oct 25 00:03:02.834: :cc_get_feature_vsa malloc success


002248: Oct 25 00:03:02.834: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

002249: Oct 25 00:03:02.834: cc_get_feature_vsa count is 1


002250: Oct 25 00:03:02.834: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

84 | P a g e
002251: Oct 25 00:03:02.834: :FEATURE_VSA attributes are:
feature_name:0,feature_time:977958704,feature_id:36
002252: Oct 25 00:03:02.834:
//41/DCE644800000/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=(TON=Unknown, NPI=Unknown, Screening=User,
Passed, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown))
002253: Oct 25 00:03:02.834:
//41/DCE644800000/CCAPI/cc_process_call_setup_ind:
Event=0x3F32B170
002254: Oct 25 00:03:02.834: //-
1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 818005532447
002255: Oct 25 00:03:02.834: //41/DCE644800000/CCAPI/ccCallSetContext:
Context=0x3A4D04F8
002256: Oct 25 00:03:02.834:
//41/DCE644800000/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 41 with tag 81800 to app
"_ManagedAppProcess_Default"
002257: Oct 25 00:03:02.834: //-
1/xxxxxxxxxxxx/SIP/Info/ccsip_process_tcp_queue_event: Event type: send
msg, connid: 18, fd: 3

002258: Oct 25 00:03:02.834: //41/DCE644800000/CCAPI/ccCallProceeding:


Progress Indication=NULL(0)
002259: Oct 25 00:03:02.838: //-
1/xxxxxxxxxxxx/CCAPI/ccGetMemPoolFromContainer:
mempool not found from usrContainer(3F2F68DC)
002260: Oct 25 00:03:02.838: //-
1/xxxxxxxxxxxx/CCAPI/ccCreateMemPoolInContainer:
Mempool(210405DC) created in usrContainer(3F2F68DC)
002261: Oct 25 00:03:02.838: //41/DCE644800000/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=81800553, Params=0x3A4CEF98, Progress
Indication=NULL(0)
002262: Oct 25 00:03:02.838: //41/DCE644800000/CCAPI/ccCheckClipClir:
In: Calling Number=sip:4089447700@[Link](TON=Unknown,
NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
002263: Oct 25 00:03:02.838: //41/DCE644800000/CCAPI/ccCheckClipClir:
Out: Calling Number=sip:4089447700@[Link](TON=Unknown,
NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
002264: Oct 25 00:03:02.838: //41/DCE644800000/CCAPI/ccCallSetupRequest:
Destination Pattern=81..........$, Called Number=818005532447, Digit
Strip=FALSE
002265: Oct 25 00:03:02.838: //41/DCE644800000/CCAPI/ccCallSetupRequest:
Calling Number=sip:4089447700@[Link](TON=Unknown, NPI=Unknown,
Screening=User, Passed, Presentation=Allowed),
Called Number=818005532447(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=DK Singh
Account Number=4089447700, Final Destination Flag=TRUE,
Guid=DCE64480-0001-0000-0000-000D038512C6, Outgoing Dial-
peer=81800553
002266: Oct 25 00:03:02.838:
//41/DCE644800000/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=4089447700
----- ccCallInfo IE subfields -----

85 | P a g e
cisco-ani=sip:4089447700@[Link]
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=818005532447
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

002267: Oct 25 00:03:02.838:


//41/DCE644800000/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x22C82D1C, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=sip:4089447700@[Link],(Calling
Name=DK Singh)(TON=Unknown, NPI=Unknown, Screening=User, Passed,
Presentation=Allowed),
Called Number=818005532447(TON=Unknown, NPI=Unknown), Calling
Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing
Dial-peer=81800553, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=,
tg_label_flag=0, Application Call Id=)
002268: Oct 25 00:03:02.838: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Final dial-peers for call to TAC will look like below


dial-peer voice 81800 voip
description *** Inbound for TAC Calls. From CUCM to CUBE ***
session protocol sipv2
destination dpg 1800
incoming called-number 818005532447$
voice-class sip profiles 1800 inbound
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

dial-peer voice 81800553 voip


destination-pattern 81..........$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

86 | P a g e
Module 7 – SIP Profile Rule Tagging
Prior to attempting this Module, ensure Modules 1 and 2 have been
completed. Additionally some show command output shown here will vary
if Modules 5 and 6 have also been attempted, though not required for
this module.
Starting CUBE 11.0.0 [IOS 15.5(2)T, IOS-XE 3.15], the SIP profile rule tagging feature
was introduced. This feature allows to tag individual rules in a SIP profile like voice
translation rules. Tagging the rules within a SIP profile enables users to insert or delete
rules at any position of the existing SIP profile configuration without deleting and
reconfiguring the entire voice-class sip profile.

Additionally, with this feature, users have the option to upgrade or downgrade all the
existing SIP profile configurations to the rule-format and non-rule format.

Task

1. Upgrade all the existing SIP profiles within the CUBE configuration to the new
tagged format
2. Modify SIP Profile 3 created in Module 2 and insert a rule in between the existing
two rules

87 | P a g e
Solution

1. Let’s view the existing SIP Profiles within our configuration. Your output will vary
depending on what modules have you attempted prior to this module. The output
shown below includes exercises done as part of modules 2, 5, and 6.

CUBE#sh run | sec voice class sip-profiles

voice class sip-profiles 1


request INVITE sip-header Min-SE remove
request INVITE sip-header Session-Expires remove

voice class sip-profiles 3


request INVITE sip-header WORD add "HUSSAIN ALI: CCIE# 38068"
request INVITE sip-header WORD add "DK SINGH: CCIE# 16545"

voice class sip-profiles 4


response 502 sip-header SIP-StatusLine modify "(.*)" "502 Total
Number of Calls Allowed Exceeded"

voice class sip-profiles 1800


request INVITE sip-header To modify "(<sip.*)" "\"Cisco TAC\" \1"
request INVITE sip-header Remote-Party-ID modify "(\"Monica.*)(
<sip.*)" "\"DK Singh\"\2"
request INVITE sip-header From modify "(\"Monica.*)( <sip.*)"
"\"Hussain Ali\"\2"

2. Issue the global config mode CLI voice sip sip-profiles upgrade to convert the
above into the new syntax.

CUBE#voice sip sip-profiles upgrade


CUBE#sh run | sec voice class sip-profiles

voice class sip-profiles 1


rule 1 request INVITE sip-header Min-SE remove
rule 2 request INVITE sip-header Session-Expires remove

voice class sip-profiles 3


rule 1 request INVITE sip-header WORD add "HUSSAIN ALI: CCIE# 38068"
rule 2 request INVITE sip-header WORD add "DK SINGH: CCIE# 16545"

voice class sip-profiles 4


rule 1 response 502 sip-header SIP-StatusLine modify "(.*)" "502
Total Number of Calls Allowed Exceeded"

voice class sip-profiles 1800


rule 1 request INVITE sip-header To modify "(<sip.*)" "\"Cisco TAC\" \1"
rule 2 request INVITE sip-header Remote-Party-ID modify "(\"Monica.*)(
<sip.*)" "\"DK Singh\"\2"
rule 3 request INVITE sip-header From modify "(\"Monica.*)( <sip.*)"
"\"Hussain Ali\"\2"

88 | P a g e
3. Now we will modify sip profile 3 and insert a rule in between rules 1 and 2.

CUBE#conf t
CUBE(config)#voice class sip-profiles 3
CUBE(config-class)#rule ?
<1-1073741823> Specify the rule tag
before The rule to be inserted before

! The new “before” keyword allows to insert a rule before the specified rule tag.
! In our case we want to insert a rule before the existing rule 2 of this SIP profile
! The new rule inserted will take tag 2 while the existing rule 2 will be moved to
! tag 3

CUBE(config-class)#rule before ?
<1-1073741823> Specify the rule tag

CUBE(config-class)#rule before 2 ?
request sip request
response sip response

CUBE(config-class)#rule before 2 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)#rule before 2 request INVITE sip-header WORD


add "SBC: CUBE"
CUBE(config-class)#end

! Verify that the new rule has position/tag 2 while the previous tag 2 has moved to
! position/tag 3 within the SIP profile
CUBE#sh run | sec voice class sip-profiles 3

voice class sip-profiles 3


rule 1 request INVITE sip-header WORD add "HUSSAIN ALI: CCIE# 38068"
rule 2 request INVITE sip-header WORD add "SBC: CUBE"
rule 3 request INVITE sip-header WORD add "DK SINGH: CCIE# 16545"

89 | P a g e
Module 8 – Multiple E164 Pattern matching under
the same dial-peer
Prior to attempting this Module, ensure Module 1 has been completed

E164 pattern map provides the ability to group multiple patterns under the same dial-peer
for both incoming and outgoing dial-peers respectively, eliminating the need to create
additional dial-peers.

This feature is particularly useful in reducing the total number of dial-peers on CUBE when
you have a non-contiguous block of numbers, especially in case of faxing, which would
otherwise require different dial-peers be configured.

This feature allows:

1. Multiple destination-patterns under the same outbound dial-peer.

It provides the ability to combine multiple destination-patterns targeted to same


destination IP to be grouped into a single dial-peer

90 | P a g e
2. Multiple incoming called or calling numbers under the same inbound dial-peer

It provides the ability to combine multiple incoming called OR calling numbers on a


single inbound voip dial-peer, reducing the total number of inbound voip dial-peers
required with the same routing capability.

Pattern maps can either be created in a text file (up to 5000 entries tested without any
performance impact), which can be uploaded to the flash: of CUBE and then referenced by
voice class e164-pattern-map <tag> using the url flash:filename OR as entries under the
voice class e164-pattern-map <tag> CLI.

In this exercise we will create an incoming e164-pattern-map to accept incoming PSTN call
legs from ITSP. Let’s proceed as follows:

1. Create the following e164-pattern-map in config mode:

voice class e164-pattern-map 800


e164 +1408944....$

91 | P a g e
2. Create the following incoming dial-peer to utilize the above e164 pattern map to accept
incoming PSTN call legs destined for your Jabber Softphone [CSFMCHENG – WKST3].

dial-peer voice 800 voip


description **Incoming E164 pattern match from SP**
session protocol sipv2
incoming called e164-pattern-map 800
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

3. Create the following outgoing dial-peer to utilize the above e164 pattern map to deliver
call from ITSP to CUCM via the CUBE. However, we will not yet define the target IP for
CUCM.

dial-peer voice 901 voip


description **Outbound LAN, CUBE->CUCM using E164-pattern-map**
translation-profile outgoing CUBE_to_CUCM
session protocol sipv2
destination e164-pattern-map 800
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

Verification:

E164 pattern-map entries can be verified as shown below

CUBE#show voice class e164-pattern-map

There are 1 e164-pattern-map configured

e164-pattern-map 800
-----------------------------------------
It has 1 entries
It is not populated from a file.
Map is valid.

E164 pattern
-------------------
+1408944....$

Note: No test call needs to be made in this section to verify the E164
Pattern Maps. We will test them in the next module.

92 | P a g e
Module 9 – Destination Server Group
Prior to attempting this Module, ensure Modules 1 and 8 have been
completed

In a VoIP dial-peer, we can only define one session target IP address, which often times
requires creating multiple outbound dial-peers for the same destination-pattern such as in a
multi-cluster (various Subscribers) environment. CUBE 10.0.0 [IOS 15.4(2)T / IOS-XE
3.12] introduces the concept of Destination Server Group, which supports multiple session
targets (up to 5) to be defined in a group and applied to a single outbound dial-peer. This
reduces the need to configure multiple dial-peers with the same capabilities and destination-
patterns but different destination target IP Addresses.

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.

Task:

In the last module we created incoming and outgoing dialpeers with E164 pattern map to
accept calls from ITSP and route towards CUCM. Now we will utilize Destination Server
Group to setup the outbound leg towards CUCM for call delivery.

Let’s configure a voice class server-group with CUCM’s target IP

CUBE(config)#voice class server-group 9


CUBE(config-class)#hunt-scheme round-robin
CUBE(config-class)#ipv4 [Link]
CUBE(config-class)#

93 | P a g e
Now update dial-peer 901 with the destination IP, which would serve as an outbound LAN
dial-peer for the CUBE. We will use the session server-group 9 instead of session target
ipv4 and destination e164-pattern-map 800 created in the previous module. The session
server group will have IP targets for your CUCM. Updates to dial-peer 901 are highlighted
in yellow.

dial-peer voice 901 voip


description **Outbound LAN, CUBE->CUCM using E164-pattern-map & server group**
translation-profile outgoing CUBE_to_CUCM
session protocol sipv2
session server-group 9
destination e164-pattern-map 800
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711ulaw
no vad

Verification:

Voice class Server-group entries can be checked by issuing:

CUBE#show voice class server-group


Voice class server-group: 9
AdminStatus: Up OperStatus: Up
Hunt-Scheme: round-robin Last returned server:
Description:
Total server entries: 1

Pref Type IP Address IP Port


---- ---- ---------- -------
0 ipv4 [Link]

Test:

Before testing the call let’s shut down all dial-peers we originally created in Module 1:

CUBE(config)#dial-peer voice 100


CUBE(config-dial-peer)#shutdown

CUBE(config)#dial-peer voice 101


CUBE(config-dial-peer)#shutdown

CUBE(config)#dial-peer voice 200


CUBE(config-dial-peer)#shutdown

CUBE(config)#dial-peer voice 201


CUBE(config-dial-peer)#shutdown

94 | P a g e
Now place an inbound call to your Jabber SoftPhone by dialing your POD’s DID number,
40894429DN* from your cell phone and keep it up. Then verify with the show command
below that dial-peers 800 (Inbound WAN) and 901 (Outbound LAN) are being utilized to
process the call legs for this incoming call.

*Refer to info sheet or table on page-8 of this lab guide to find


the DID assigned to your POD.

CUBE#show call active voice brief

1CBB : 43 525748260ms.1 (17:18:18.103 PDT Tue Oct 24 2017) +4760 pid:800


Answer 6785555555 active
dur 00:03:15 tx:9759/1561440 rx:9761/1561760 dscp:0 media:0 audio tos:0xB8
video tos:0x0
IP [Link]:23758 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:f80953a551b95515ab4d8a6dbad6c745
RemoteUUID:000012d100105000a000005056acffc8
VRF: NA

1CBB : 44 525748270ms.1 (17:18:18.113 PDT Tue Oct 24 2017) +4740 pid:901


Originate +14085557700 active
dur 00:03:15 tx:9761/1561760 rx:9759/1561440 dscp:0 media:0 audio tos:0xB8
video tos:0x0
IP [Link]:20890 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:000012d100105000a000005056acffc8
RemoteUUID:f80953a551b95515ab4d8a6dbad6c745
VRF: NA

Before proceeding to the next Module, ensure we shutdown dial-peers created as part of
Modules 8 and 9 and no shut dial-peers created in Module 1 of this lab guide

CUBE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CUBE(config)#dial-peer voice 100
CUBE(config-dial-peer)#no shut
CUBE(config-dial-peer)#dial-peer voice 101
CUBE(config-dial-peer)#no shut
CUBE(config-dial-peer)#dial-peer voice 200
CUBE(config-dial-peer)#no shut
CUBE(config-dial-peer)#dial-peer voice 201
CUBE(config-dial-peer)#no shut
CUBE(config-dial-peer)#dial-peer voice 800
CUBE(config-dial-peer)#shutdown
CUBE(config-dial-peer)#dial-peer voice 901
CUBE(config-dial-peer)#shutdown

95 | P a g e
Module 10 – PSTN Call Recording
Prior to attempting this Module, ensure Module 1 has been completed

This Module will explore the different PSTN call recording mechanisms we can use within
Cisco Collaboration architecture. They are

A. Open Recording Architecture with Cisco MediaSense


B. SIPREC
C. CUCM Network based Recording (NBR)

96 | P a g e
A. Open Recording Architecture with Cisco MediaSense
CUBE can be used in a network based recording solution to fork active SIP to SIP calls
traversing through it. The media forking on CUBE supports Cisco’s Open Recording
Architecture (ORA), where CUBE acts as a recording client at the network layer and Cisco
MediaSense will act as the recording server at the application layer. The functionalities of
CUBE in this setup are:
 To set up a separate SIP dialog with Cisco MediaSense
 To fork the active calls traversing through it, and to act as the source of the recorded
media, sending it to the Recording Server (Cisco MediaSense).
 During the initial SIP dialog setup, CUBE sends information to the server, which
would help the server associate the call with the media streams and identify the
participants of the call. This information is called “metadata”
 This recording can then be consumed via any 3rd party partner application.

Here is how the setup looks:

In this lab setup MediaSense is already integrated with CUCM and we will setup the
configuration on CUBE to fork media towards MediaSense located at [Link]. This
will allow us to see how the metadata is sent to MediaSense to correlate calls. We will setup
CUBE to record all inbound PSTN calls that reach from CUBE to CUCM using dial-peer
101 as the outbound LAN dial-peer created in Module 1. Dial-peer 101 is known as the

97 | P a g e
anchor dial-peer as we will apply media class elements to this dial-peer. To configure media
forking on CUBE, we need to perform the following steps:

1. Create a dial-peer [tag 1050] that will be used to set up the SIP dialog with the recording
server. The IP address used as the session target is the IP address of the recording server,
[Link]. The destination-pattern in this dial-peer would be a dummy destination-
pattern, 9999. Additionally, MediaSense requires TCP as the session transport.

CUBE(config)#dial-peer voice 1050 voip


CUBE(config-dial-peer)#description *Dial-peer pointing to MediaSense*
CUBE(config-dial-peer)#destination-pattern 9999
CUBE(config-dial-peer)#session protocol sipv2
CUBE(config-dial-peer)#session transport tcp
CUBE(config-dial-peer)#session target ipv4:[Link]

2. Configure the media class <tag> CLI that will store the dial-peer tag that is used to point
to the recording server under “recorder parameter” CLI. In our case that is dial-peer 1050
created above

CUBE(config)#media class 10
CUBE(cfg-mediaclass)#recorder parameter
CUBE(cfg-mediaclass-recorder)#media-recording 1050

3. Apply the media class 10 on the anchoring dial-peer, which will be dial-peer 101. All
calls traversing this dial-peer will be recorded.

dial-peer voice 101 voip


description * Outbound LAN/Anchor dial-peer. From CUBE to CUCM *
media-class 10

Verification:

Enable the following debugs and make an inbound PSTN call to your Jabber SoftPhone.
[408-944-29DN - CSFMCHENG].
The debugs would look like as follows for this section of the lab.

CUBE(config)#no logging console


CUBE(config)#no logging monitor
CUBE(config)#logging buffer 9999999 debug
CUBE(config)#end
CUBE#clear log
Clear logging buffer [confirm]
CUBE#debug ccsip message
CUBE#debug voip ccapi inout

98 | P a g e
Relevant debug snippet. PSTN Party Number in this example : 678-555-5555

Incoming INVITE from PSTN

Received:
INVITE sip:+140894429DN@[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK1251727
Remote-Party-ID:
<sip:6785555555@[Link]>;party=calling;screen=yes;privacy=off
From: <sip:6785555555@[Link]>;tag=7341CFA0-1037
To: <sip:+140894429DN@[Link]>
Date: Fri, 01 Jun 2018 17:13:23 GMT
Call-ID: EC62D722-64F511E8-81BACF11-D1189DED@[Link]
Cisco-Guid: 3965900578-1693782504-2824532215-1433811328

CCAPI debug showing dial-peer selected for the above leg

Jun 1 17:13:23.054: //-


1/EC62D722A85A/CCAPI/cc_api_call_setup_ind_common:
Incoming Dial-peer=200, Progress Indication=NULL(0), Calling IE
Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID
Transparent=FALSE), Call Id=9447

Outbound dial-peer 101 selected to establish leg with CUCM

Jun 1 17:13:23.058:
//9447/EC62D722A85A/CCAPI/ccIFCallSetupRequestPrivate:
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing
Dial-peer=101, Call Count On=FALSE,

INVITE sent to CUCM

Sent:
INVITE sip:+14085557700@[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK250E252E
Remote-Party-ID:
<sip:6785555555@[Link]>;party=calling;screen=yes;privacy=off
From: <sip:6785555555@[Link]>;tag=4938C1C-60
Cisco-Guid: 3965900578-1693782504-2824532215-1433811328

PAI/RPID update from CUCM in 180 RINGING

Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK250E252E
Date: Fri, 01 Jun 2018 17:13:23 GMT
Contact: <sip:+14085557700@[Link]:5060>;+[Link]!
[Link]="CSFMCHENG";video;bfcp

99 | P a g e
Call is now established between the PSTN and IP Phone after 200 OK has been
exchanged.

CUBE will now setup a session with MediaSense using dial-peer 1050 to dummy
destination 9999. CCAPI debugs showing dial-peer selection towards MediaSense

Jun 1 17:13:28.550:
//9449/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
Called Number=9999(TON=Unknown, NPI=Unknown), Calling
Translated=FALSE,
Subscriber Type Str=, FinalDestinationFlag=FALSE, Outgoing Dial-
peer=1050, Call Count On=FALSE,

SIP INVITE sent to MediaSense [[Link]] from CUBE

Sent:
INVITE sip:9999@[Link]:5060 SIP/2.0
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK251011B4
X-Cisco-Recording-Participant: sip:+14085557700@[Link];media-
index="0"
X-Cisco-Recording-Participant: sip:6785555555@[Link];media-
index="1"

! Participant details for which recording is being done are informed to Recorder-
! Server(MediaSense) through “X-Cisco-Recording-Participant” header in INVITE/Re-
! INVITE.
! media-index=“0” indicates that SDP media line 0 is for this recording participant.
! +14085557700 is your phone’s DN and is indicated by m-line 0 below in green.
! Similarly media-index=”1” indicates media line 1 for the PSTN leg.

From: <sip:[Link]>;tag=493A18C-2292
To: <sip:9999@[Link]>
Date: Fri, 01 Jun 2018 17:13:28 GMT
Cisco-Guid: 3965900578-1693782504-2824532215-1433811328

! The above GUID information is also sent to MediaSense to correlate calls from CUCM
! CDR records. This is the same GUID ID that is used to establish the call between SP to
! CUBE to CUCM.

v=0
o=CiscoSystemsSIP-GW-UserAgent 4987 3801 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16506 RTP/AVP 0 101 19
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

100 | P a g e
a=rtpmap:19 CN/8000
a=ptime:20
a=sendonly
m=audio 16508 RTP/AVP 0 101 19
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
a=sendonly

Both the m-lines indicate “a=sendonly” as media is just being sent to MediaSense from
CUBE and NOT vice versa.

Relevant output of show call active voice brief

3A42 : 9447 76778510ms.1 (10:13:23.053 PDT Fri Jun 1 2018) +5490


pid:200 Answer 6785555555 active
dur 00:00:35 tx:1784/285440 rx:1792/286720 dscp:0 media:0 audio
tos:0xB8 video tos:0x0
IP [Link]:24400 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0
delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off

3A42 : 9448 76778520ms.1 (10:13:23.063 PDT Fri Jun 1 2018) +5470


pid:101 Originate +14085557700 active
dur 00:00:35 tx:1792/286720 rx:1784/285440 dscp:0 media:0 audio
tos:0xB8 video tos:0x0
IP [Link]:23098 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0
delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off

3A42 : 9450 76784010ms.1 (10:13:28.553 PDT Fri Jun 1 2018) +280


pid:1050 Originate 9999 active
dur 00:00:35 tx:3557/569120 rx:0/0 dscp:0 media:0 audio tos:0xB8
video tos:0x0
IP [Link]:32940 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0
delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off

101 | P a g e
Output of show voip rtp connections showing 4 RTP streams, with two streams going
towards MediaSense.

CUBE#show voip rtp connections


VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 4
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 4
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 9447 9448 16502 24400 [Link] [Link] NO NA
2 9448 9447 16504 23098 [Link] [Link] NO NA
3 9450 9449 16506 32940 [Link] [Link] NO NA
4 9451 9449 16508 38984 [Link] [Link] NO NA
Found 4 active RTP connections

102 | P a g e
CUBE#show call active voice compact

<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> VRF
Total call-legs: 3

9447 ANS T70 g711ulaw VOIP P6785555555 [Link]:24400 NA


9448 ORG T70 g711ulaw VOIP P+14085557700 [Link]:23098 NA
9450 ORG T70 g711ulaw VOIP P9999 [Link]:32940 NA

CUBE#show voip recmsp session

RECMSP active sessions:

MSP Call-ID AnchorLeg Call-ID ForkedLeg Call-ID


9449 9448 9450

Found 1 active sessions

CUBE-1#show voip recmsp session detail call-id 9449

RECMSP active sessions:


Detailed Information
=========================
Recording MSP Leg Details:
Call ID: 9449
GUID : EC62D722A85A

AnchorLeg Details:
Call ID: 9448
Forking Stream type: voice-nearend
Participant: +14085557700

Non-anchor Leg Details:


Call ID: 9447
Forking Stream type: voice-farend
Participant: 6785555555

Forked Leg Details:


Call ID: 9450
Voice Near End Stream CallID 9450
Stream State ACTIVE
Voice Far End stream CallID 9451
Stream State ACTIVE
Found 1 active sessions

103 | P a g e
Retrieving your call recording from Cisco MediaSense:
Go to MediaSense at [Link] and Click “Cisco MediaSense Search and
Play”. Sign-in with “mcheng” as the username and “C1sco12345” as the password

Click on Recent Calls and search for your call either by using the PSTN Cell Phone number
or your SoftPhone’s extension, +14085557700. The screenshot below shows a call made
from a PSTN Phone to the Jabber softphone. You can download the recording either as mp4
or a wav file.

104 | P a g e
B. SIPREC

The SIPREC (SIP Recording) mechanism on CUBE supports media recording for Real-time
Transport Protocol (RTP) streams in compliance with section 3.1.1 of RFC 7245, with
CUBE acting as the Session Recording Client. SIP is used as a protocol between CUBE and
the recording server. Recording of a media session is done by sending a copy of a media
stream to the recording server. Metadata in XML format is the information that is passed by
the recording client to the recording server in a SIP session. The recording metadata
describes the communication session and its media streams, and also identifies the
participants of the call. CUBE acts as the recording client and any third party recorder acts
as the recording server. SIP Profiles can additionally be used to forward 3rd party IP PBX
Call Identifier to the Recorder for correlation

On CUBE Enterprise, the operation of SIPREC is similar to the ORA with Cisco
MediaSense. The following diagram displays the setup.

Task

We will configure SIPREC based recording in this section. However, Cisco MediaSense
does not support SIPREC and we will only view the INVITE from CUBE to MediaSense to
understand how the metadata is constructed by CUBE. Cisco MediaSense will reject the
INVITE with 488 Not Acceptable Here. Please proceed as shown in the next page.

105 | P a g e
CUBE#conf t
CUBE(config)#media class 10
CUBE(cfg-mediaclass)#recorder parameter ?
siprec INVITE is sent to recording server with application/rs-
metadata SDP
<cr>

CUBE(cfg-mediaclass)#recorder parameter siprec


CUBE(cfg-mediaclass-recorder)#end
CUBE#clear log
Clear logging buffer [confirm]
CUBE#debug ccsip message

! Place an inbound PSTN call like in the previous section and answer it from your
! Jabber Softphone. We will view the raw exchange between CUBE and MediaSense

013192: Jun 1 18:36:55.924: //-


1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:9999@[Link]:5060 SIP/2.0
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK28FFAD1
From: <sip:[Link]>;tag=4E00968-2297
To: <sip:9999@[Link]>
Date: Fri, 01 Jun 2018 18:36:55 GMT
Call-ID: 9848E5CE-650111E8-A968941E-48173748@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Require: siprec
Min-SE: 1800
Cisco-Guid: 2538492162-1694568936-2825384183-1433811328
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1527878215
Contact: <sip:[Link]:5060;transport=tcp>;+[Link]
Expires: 180
Allow-Events: telephone-event
Session-ID:
2bf1fb56e59a5f95b9bd074dfb1ef5e7;remote=0000000000000000000000000
0000000
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 2487

106 | P a g e
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 4306 5454 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16518 RTP/AVP 0 101 19
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
a=sendonly
a=label:1

m=audio 16520 RTP/AVP 0 101 19


c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
a=sendonly
a=label:2

107 | P a g e
--uniqueBoundary
Content-Type: application/rs-metadata+xml
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>


<recording xmlns="urn:ietf:params:xml:ns:recording:1">
<datamode>complete</datamode>
<session session_id="mEhJpmUBEeipYJQeSBc3SA==">

<sipSessionID>a26cd1991f1754038f4d426366a04e26;remote=000017da001
05000a000005056acffc8</sipSessionID>
<start-time>2018-06-01T18:36:55.904Z</start-time>
</session>
<participant participant_id="mEhJpmUBEeipYZQeSBc3SA==">
<nameID aor="sip:+14085557700@[Link]">
<name xml:lang="en">Monica Cheng</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="mEhJpmUBEeipYZQeSBc3SA=="
session_id="mEhJpmUBEeipYJQeSBc3SA==">
<associate-time>2018-06-01T18:36:55.904Z</associate-time>
</participantsessionassoc>
<stream stream_id="mEjlzmUBEeipZpQeSBc3SA=="
session_id="mEhJpmUBEeipYJQeSBc3SA==">
<label>1</label>
</stream>
<participant participant_id="mEhJpmUBEeipYpQeSBc3SA==">
<nameID aor="sip:6785555555@[Link]">
</nameID>
</participant>
<participantsessionassoc
participant_id="mEhJpmUBEeipYpQeSBc3SA=="
session_id="mEhJpmUBEeipYJQeSBc3SA==">
<associate-time>2018-06-01T18:36:55.904Z</associate-time>
</participantsessionassoc>
<stream stream_id="mEjlzmUBEeipZ5QeSBc3SA=="
session_id="mEhJpmUBEeipYJQeSBc3SA==">
<label>2</label>
</stream>
<participantstreamassoc
participant_id="mEhJpmUBEeipYZQeSBc3SA==">
<send>mEjlzmUBEeipZpQeSBc3SA==</send>
<recv>mEjlzmUBEeipZ5QeSBc3SA==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="mEhJpmUBEeipYpQeSBc3SA==">
<send>mEjlzmUBEeipZ5QeSBc3SA==</send>
<recv>mEjlzmUBEeipZpQeSBc3SA==</recv>
</participantstreamassoc>
</recording>
--uniqueBoundary--

108 | P a g e
Jun 1 18:36:55.932:
//10457/974E5102A867/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK28FFAD1
To: <sip:9999@[Link]>;tag=dsa31d2704
From: <sip:[Link]>;tag=4E00968-2297
Call-ID: 9848E5CE-650111E8-A968941E-48173748@[Link]
CSeq: 101 INVITE
Content-Length: 0

The relevant metadata fields are highlighted above and also in the screenshot below.
CUBE’s SIPREC documentation available at [Link]
xml/ios/voice/cube/configuration/cube-book/[Link] explains the fields in
greater detail.

Sample SIPREC XML metadata generated on CUBE

109 | P a g e
Disable SIPREC triggering on dial-peer 101 as shown below before proceeding to the next
section.

CUBE(config)#dial-peer voice 101


CUBE(config-dial-peer)#no media-class 10
CUBE(config-dial-peer)#end

110 | P a g e
C. CUCM Network based Recording (NBR) using UC Gateway
Services API
CUCM can also utilize the media forking capability of CUBE for call recording purposes in
the event of PSTN calls. This form of recording is known as CUCM Network based
recording – GW preferred option.

Once a PSTN call is connected with an end user, CUCM requests the CUBE/Voice GW to
fork the media of that session to a recording server through the UC gateway services API
integration. The diagram below shows how the flow for this type of recording works:

Task

Configure the Gateway preferred option of CUCM NBR to ensure all PSTN calls made and
received by Katelyn O’Neal [CSFKONEAL – Workstation 1 at [Link]] are
recorded.

111 | P a g e
Solution

1. First we will create a Recording Profile to be used by Katelyn O’Neal’s Jabber


SoftPhone [CSFKONEAL].

a. Within the CUCM administration page, go to Device  Device Settings 


Recording Profile as displayed below:

b. Click on Add New and create the Recording Profile as displayed below

112 | P a g e
c. Click Save

2. Create a new SIP trunk pointing towards our Cisco MediaSense server at
[Link]

a. Under the CUCM Administration page, navigate to Device  Trunk


b. Add a new SIP Trunk and call it CiscoMediaSense. Follow the screenshots below
for the required parameters of this SIP Trunk

113 | P a g e
114 | P a g e
3. Create a Route Pattern for the Recording Profile destination number we have created
above and point it to the CiscoMediaSense SIP trunk we have created above.

a. Click Call Routing  Route/Hunt  Route Pattern


b. Click Add New:
c. Configure the Route Pattern as shown below

115 | P a g e
4. Enable recording of all calls made to and from Katelyn O’Neal’s Cisco Jabber
Softphone, CSFKONEAL

a. Navigate to Device  Phone and click Find. Click on CSFKONEAL as displayed


below

b. Click on the Directory Number as displayed below

116 | P a g e
c. Scroll down to Line 1 on Device CSFKONEAL and select the options shown
below
i. Under the Recording Option*, select Automatic Call Recording Enabled
which will allow all calls made to and from this phone to be recorded.
ii. Choose MediaSense – NBR Recording Profile we have created above
iii. Leave the Recording Media Source* as Gateway Preferred to allow forking
of the media from our CUBE.
iv. Click Save, Apply Config, Reset and do the same at the Device level.

117 | P a g e
5. Go to Device  Trunk and click Find. Click on the CUBE SIP Trunk we created in
Module 1.

a. Scroll down to Recording Information. Select This trunks connects to a


recording enabled gateway. Click Save and Reset.

118 | P a g e
6. Next we will configure CUBE as the Extended Media Forking (XMF) provider under
the UC gateway services API. CUCM will be configured as the external application
invoking the API.

For all calls that CUCM [[Link]] wants CUBE [[Link]] to fork media for,
it sends an HTTP message towards CUBE with the IP address of the recorder [Cisco
MediaSense – [Link]], and the two RTP ports for the CUBE to send the forked
media towards.

Configure the CUBE as shown below

CUBE#conf t

! Enable HTTP server on the CUBE router

CUBE(config)#ip http server

! Enable the UC gateway services API on CUBE

CUBE(config)#uc wsapi

! Source IP Address of the XMF Connection. Should be the IP Address of CUBE

CUBE(config-uc-wsapi)#source-address [Link]

! Enter XMF Provider configuration mode within the API

CUBE(config-uc-wsapi)#provider xmf

! Specify the URL (IP address and port number) that the application (CUCM – [Link])
! will use to communicate with the XMF provider. The XMF provider uses the IP address and
! port to authenticate incoming requests.

CUBE(config-wsapi-xmf)#remote-url 1 [Link]

! Activate the XMF Provider


CUBE(config-wsapi-xmf)#no shutdown
CUBE(config-wsapi-xmf)#end
CUBE#

119 | P a g e
Let’s verify the application (CUCM) registration to the XMF Provider

CUBE#show wsapi registration xmf

Provider XMF
=====================================================
registration index: 1
id: 59B58B4:XMF:Unified CM 11.5.1.12900-21:4
appUrl:[Link]
appName: Unified CM 11.5.1.12900-21
provUrl: [Link]
prober state: STEADY
connEventsFilter: CREATED|DISCONNECTED
mediaEventsFilter:

Verification

Let’s make a test outbound PSTN call from CSFKONEAL. Keep in mind CSFKONEAL
can be accessed by doing a remote desktop to Workstation 1[[Link]] within our lab
topology. Information is listed below.

MediaSense – Call Recording Server


MediaSense IP Address [Link]
MediaSense Search and Play Username mcheng
MediaSense Search and Play Password C1sco12345

Katelyn O’Neal’s Phone Number


DID Number +1 408-944-29DN
Jabber Phone Extension +14085551074
Jabber User ID koneal
Jabber Password C1sco12345

Student PC wkst1 (To access WORKSTATION 1)


IP Address [Link]
Remote Desktop Username dcloud\koneal
Remote Desktop Password C1sco12345

120 | P a g e
Workstation 1: [Link], Username: dcloud\koneal, Password: C1sco12345

Once connected to WKST3, launch the Cisco Jabber for Windows client by double-clicking

the desktop icon .

Login to the Jabber client by entering the password: C1sco12345 and clicking Sign In. Note
that the username field is already pre-populated with our WKST1 user’s login username:
koneal.

Accept any certificates and ignore any errors.

121 | P a g e
Note: Jabber registration with UCM can be verified from CUCM Administration - From
menu, click on Device and select Phone in the drop-down:

122 | P a g e
Now place and outbound PSTN Call from CSFKONEAL and keep the call up. Verify that
the CUBE is forking the media towards the MediaSense [[Link]] server.

CUBE#show call media-forking

Warning: Output may be truncated if sessions are


added/removed concurrently!

Session Call n/f Destination (port address)


13807 35EB near 46414 [Link]
13808 35EB far 45252 [Link]

We can also login to MediaSense Search and Play with mcheng/C1sco12345 and see the
call that was recorded.

123 | P a g e
Module 11 – Implementing Secure Call Flows with
SIP TLS / SRTP
Prior to attempting this Module, ensure Module 1 has been completed.
Some show command output shown here will vary if Module 3 has also
been attempted

While secure SIP trunks from ITSPs are still not very common, more and more enterprise
customers are not taking their internal private collaborations networks as secure without
considering additional cryptography. As such, CUBE Enterprise offers SIP TLS transport
for secure signaling and sRTP for encrypted and authenticated media.

Task

Implement secure voice (SIP TLS and SRTP) within the Enterprise LAN network while
CUBE communicates with the ITSP in the clear. Refer to the diagram below:

LAN WAN
Gig0/0 Gig0/1
SIP TLS TCP/UDP SP IP
RTP Network
CUBE
[Link]

Solution

We will implement SIP TLS between CUBE and CUCM and enable SRTP between Jabber
Softphone and CUBE, while CUBE takes care of SRTP-RTP interworking. There are 4
main steps in this exercise:

A. Familiarize yourself with the Pre-Configured tasks


B. Enable trustpoint on CUBE and manage certificates
C. Enable TLS transport for SIP signaling and sRTP for media
D. Configure secure SIP trunk on CUCM towards CUBE

124 | P a g e
A. Pre-Configured tasks

No Configuration is needed in this section. Just go through the steps listed here.

1. Navigate to Cisco Unified Serviceability and enter the credentials to login


[administrator/dCloud123!]. Go to Tools  Service Activation and select CUCM
([Link]). Ensure Security Services are Activated

125 | P a g e
126 | P a g e
2. Convert CUCM to Mixed-Mode via CLI (soft e-Token) Method
a. SSH into CUCM [[Link] – administrator/dCloud123!]
b. Enter utils ctl set-cluster mixed-mode and Confirm by typing ‘y’
c. To verify, navigate to Cisco Unified CM Administration. Go to System 
Enterprise parameters. Scroll down to Security Parameters and verify that
Cluster Security Mode* is set to ‘1’
d. Restart Cisco TFTP, CallManager, and CTIManager services from within the Cisco
Unified Serviceability portal. Go to Tools  Control Center – Feature Services

127 | P a g e
128 | P a g e
129 | P a g e
3. Navigate to System  Security  Phone Security Profile. Search for ‘Name’, ‘begins
with’ UDT
a. Click on [Link] and click
b. Create the new profile as shown below and click Save

130 | P a g e
4. Update the CSFMCHENG Jabber Softphone for CAPF Enrollment and Confirm
Enrollment via Authentication String. Click Save, Apply Config, and Reset.

5. Next time mcheng logs into Jabber on workstation 3, you should see a pop-up window
prompting for the Authentication String, which was set as 12345 . Once the Secure
Phone Verification is completed, the Jabber IP phone service will connect and be ready
for encrypted calling

131 | P a g e
6. Ensure that the CUCM, endpoints, and CUBE point to the same NTP server

CUBE

CUBE#show ntp status

Clock is synchronized, stratum 4, reference is [Link]


nominal freq is 250.0000 Hz, actual freq is 249.9983 Hz, precision is 2**21
ntp uptime is 15031700 (1/100 of seconds), resolution is 4016
reference time is DEBCFC27.06B2A7DD (04:21:11.026 PDT Sat Jun 2 2018)
clock offset is 1.1408 msec, root delay is 2.83 msec
root dispersion is 149.92 msec, peer dispersion is 1.14 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000006745 s/s
system poll interval is 1024, last update was 8307 sec ago.

CUCM

admin:utils ntp status


ntpd (pid 7995) is running...

remote refid st t when poll reach delay offset jitter


=======================================================================
*[Link] [Link] 3 u 909 1024 377 1.326 0.232 1.142

synchronised to NTP server ([Link]) at stratum 4


time correct to within 54 ms
polling server every 1024 s

Current time in UTC is : Sat Jun 2 13:38:26 UTC 2018


Current time in Etc/UTC is : Sat Jun 2 13:38:26 UTC 2018

Jabber Softphone – CSFMCHENG – Phone NTP Reference is part of the Date/Time


Group, which is assigned to the Device Pool

132 | P a g e
7. Ensure CUBE router has the correct security license(s) to generate certificates

CUBE#show license right-to-use

Index 2 Feature: securityk9


Period left: Life time
License Type: RightToUse
License State: Active, In Use
License Count: Non-Counted
License Priority: Low
Index 3 Feature: uck9
Period left: Life time
License Type: RightToUse
License State: Active, In Use
License Count: Non-Counted
License Priority: Low

133 | P a g e
B. Enable trustpoint on CUBE and manage certificates
1. Generate an RSA key pair. These will be CUBE’s public and private keys.

CUBE(config)#crypto key generate rsa general-keys label CUBE-


RSA-KeyPair modulus 2048
The name for the keys will be: CUBE-RSA-KeyPair

% The key modulus size is 2048 bits


% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 14 seconds)

2. Create a PKI trustpoint using the key pair above to hold CUBE’s self-signed
certificate.

vpod-2911-cube-01(config)#crypto pki trustpoint CUBE-TrustPoint

! We will specify self-signed enrollment parameters

vpod-2911-cube-01(ca-trustpoint)#enrollment selfsigned
vpod-2911-cube-01(ca-trustpoint)#fqdn none

! The subject-name should match the hostname and IP domain name of the
! router. We do not have an IP domain name configured on our CUBE. The
! hostname will vary for your pod.

! Do not change the IP domain name or the hostname of the router after creating the
! self-signed certificate. Changing either name triggers the regeneration of the self-
! signed certificate and overrides the configured trustpoint

vpod-2911-cube-01(ca-trustpoint)#subject-name cn=vpod-2911-cube-XX
vpod-2911-cube-01(ca-trustpoint)#revocation-check none

! This is the KeyPair we have generated in the previous step

vpod-2911-cube-01(ca-trustpoint)#rsakeypair CUBE-RSA-KeyPair
vpod-2911-cube-01(ca-trustpoint)#exit

134 | P a g e
3. Instruct the CUBE router to generate a persistent self-signed certificate.

! The name should match with the trustpoint created above

vpod-2911-cube-01(config)#crypto pki enroll CUBE-TrustPoint


% The fully-qualified domain name will not be included in the
certificate
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Generate Self Signed Router Certificate? [yes/no]: yes

! The following message should be displayed indicating a successful enrollment

Router Self Signed Certificate successfully created


vpod-2911-cube-01(config)#

4. Next we will display the self-signed certificate on the CUBE terminal so it can be
copied and saved locally on your PC. This certificate must be uploaded to CUCM
Publisher, which then replicates it to the subscribers in the cluster

! Export the certificate to a PEM file by displaying it to the terminal for cut and paste

vpod-2911-cube-01(config)#crypto pki export CUBE-TrustPoint pem ?


terminal Export via the terminal (cut-and-paste)
url Export via the file systems

! Copy only the “Self-signed CA certificate” and copy starting with the -----BEGIN
! CERTIFICATE------ and end with -------END CERTIFICATE---------------

vpod-2911-cube-01(config)#crypto pki export CUBE-TrustPoint pem terminal

% Self-signed CA certificate:
-----BEGIN CERTIFICATE-----
MIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQUFADAcMRowGAYDVQQDExF2cG9k
LTI5MTEtY3ViZS0wMTAeFw0xODA2MDIxNTAzNDBaFw0yMDAxMDEwMDAwMDBaMBwx
GjAYBgNVBAMTEXZwb2QtMjkxMS1jdWJlLTAxMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAm4oFDNVZJujPiessZmjpb5RhHlKkLwDVyr2fD7QR9ppCGW64
tuyQT1ZH/W1C+wyJOpXLITnQt2uLOZzXjJGdC4p1xPeysPmQBd6sjpotwuRxeoVW
olNQBuDeQ79Q/b3hJvr+38GwplcX+XKZagl5o1lq0goKfAd9WP1QOBoN7DeFjP4T
lg1z6lncYUx2QMkLl93DOL4VKojGVCAGJk3U5SjG6US/4A/VCxfPffgEZTqPCg/3
DQgBKhcw8+KvgCXbxZImcE5T0AIiUjiBcv8le+6fKUb+itlmPPgjhq9NbtJ3Bj0/
HThnfwdhzBvxpMBAm1zUy+rh42p9HYVjEujm6wIDAQABo1MwUTAPBgNVHRMBAf8E
BTADAQH/MB8GA1UdIwQYMBaAFG/1WmAw5gWkfszwXhu2tbS/UBRrMB0GA1UdDgQW
BBRv9VpgMOYFpH7M8F4btrW0v1AUazANBgkqhkiG9w0BAQUFAAOCAQEAfFIy12wk
Kb7EORQlh3JVv3BYULKQsA3v9+U7QrWbmG57eNmnuvcsMi8roQABdabJRXjmZ+bj
yHgA1QTR21xryp72W84KDkpoUnICfcdgBrdWelxCPQw+A6ih5Zfqn1ltxw1L2kAn
1eBCJa2zZhciRgLvrCZcV1fak7Xi5RdvvBnahqlgGL9JsUK3eAeNSYVLAIkEulox
2/W3q/a30HTzX/L1N2EIC4mpWbAHViZPSAWMPD2wrEhHg1rJysQnEPNtki+tItmI
81X7djy3FzuuWY9w6N/Q5fwjPhkiE4l5a3POBfItICGDwYZuTBoy8gIvj/nvuJBM
Mr7T4Gb8ezkDww==
-----END CERTIFICATE-----

135 | P a g e
% General Purpose Certificate:
-----BEGIN CERTIFICATE-----
MIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQUFADAcMRowGAYDVQQDExF2cG9k
LTI5MTEtY3ViZS0wMTAeFw0xODA2MDIxNTAzNDBaFw0yMDAxMDEwMDAwMDBaMBwx
GjAYBgNVBAMTEXZwb2QtMjkxMS1jdWJlLTAxMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAm4oFDNVZJujPiessZmjpb5RhHlKkLwDVyr2fD7QR9ppCGW64
tuyQT1ZH/W1C+wyJOpXLITnQt2uLOZzXjJGdC4p1xPeysPmQBd6sjpotwuRxeoVW
olNQBuDeQ79Q/b3hJvr+38GwplcX+XKZagl5o1lq0goKfAd9WP1QOBoN7DeFjP4T
lg1z6lncYUx2QMkLl93DOL4VKojGVCAGJk3U5SjG6US/4A/VCxfPffgEZTqPCg/3
DQgBKhcw8+KvgCXbxZImcE5T0AIiUjiBcv8le+6fKUb+itlmPPgjhq9NbtJ3Bj0/
HThnfwdhzBvxpMBAm1zUy+rh42p9HYVjEujm6wIDAQABo1MwUTAPBgNVHRMBAf8E
BTADAQH/MB8GA1UdIwQYMBaAFG/1WmAw5gWkfszwXhu2tbS/UBRrMB0GA1UdDgQW
BBRv9VpgMOYFpH7M8F4btrW0v1AUazANBgkqhkiG9w0BAQUFAAOCAQEAfFIy12wk
Kb7EORQlh3JVv3BYULKQsA3v9+U7QrWbmG57eNmnuvcsMi8roQABdabJRXjmZ+bj
yHgA1QTR21xryp72W84KDkpoUnICfcdgBrdWelxCPQw+A6ih5Zfqn1ltxw1L2kAn
1eBCJa2zZhciRgLvrCZcV1fak7Xi5RdvvBnahqlgGL9JsUK3eAeNSYVLAIkEulox
2/W3q/a30HTzX/L1N2EIC4mpWbAHViZPSAWMPD2wrEhHg1rJysQnEPNtki+tItmI
81X7djy3FzuuWY9w6N/Q5fwjPhkiE4l5a3POBfItICGDwYZuTBoy8gIvj/nvuJBM
Mr7T4Gb8ezkDww==
-----END CERTIFICATE-----

5. Open a notepad file and paste the self-signed certificate as shown below. Save the
file to your desktop and call it [Link]. Ensure the file extension is
.pem and not .txt

136 | P a g e
6. Navigate to Cisco Unified Operating System Administration portal of CUCM and
login with administrator/dCloud123!

137 | P a g e
7. Go to Security  Certificate Management and select

8. In the new window that pops up, select CallManager-trust as the Certificate
Purpose* and give it a good description as shown below. Then browse to the
[Link] we had earlier saved on the desktop, select it, and click
Upload.

138 | P a g e
9. The status will show as success and will instruct to restart Cisco CallManager and
Cisco TFTP services.

10. Navigate to Cisco Unified Serviceability portal of CUCM and login with
administrator/dCloud123! if needed.

11. Navigate to Tools  Control Center - Feature Services

139 | P a g e
12. Select the CUCM as shown below

13. Restart the Cisco CallManager and Cisco Tftp services.

14. Next we will enroll the CUCM self-signed certificate [[Link]] into the
CUBE. For this, navigate to Cisco Unified Operating System Administration portal
of CUCM and login with administrator/dCloud123! if needed.

15. Go to Security  Certificate Management and click Find

140 | P a g e
16. Select CallManager as displayed below by clicking on the Common Name
[Link]

141 | P a g e
17. In the new window that pops up, click on Download .PEM File and save it to your
desktop

142 | P a g e
18. Open [Link] with a text editor and copy the contents as shown below

143 | P a g e
19. Create another PKI trustpoint to hold CUCM self-signed certificate on CUBE. Then
we will paste the CUCM certificate into the CUBE for PKI authentication. Proceed
as shown below

vpod-2911-cube-01(config)#crypto pki trustpoint CUCM-TrustPoint

! We will use the manual cut and paste method of certificate enrollment

vpod-2911-cube-01(ca-trustpoint)#enrollment terminal
vpod-2911-cube-01(ca-trustpoint)#revocation-check none
vpod-2911-cube-01(ca-trustpoint)#exit

! The next step is to import the CUCM self-signed certificate using


! crypto pki authenticate

! CUCM certificate [[Link]] will be authenticated after we paste it


! Paste the complete [Link] from
! ----BEGIN CERTIFICATE----
! to
! -----END CERTIFICATE-------

! Ensure you hit Enter/Return twice, till you see a prompt asking you
! Do you accept this certificate? [yes/no]:
! Type yes and hit Enter again

vpod-2911-cube-01(config)#crypto pki authenticate CUCM-TrustPoint

Enter the base 64 encoded CA certificate.


End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----
MIIDzTCCArWgAwIBAgIQchN7YcIrM3h7yQXHzqqq2DANBgkqhkiG9w0BAQsFADB7
MQswCQYDVQQGEwJVUzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczEPMA0GA1UECwwG
ZENsb3VkMR4wHAYDVQQDDBV1Y20xLmRjbG91ZC5jaXNjby5jb20xDjAMBgNVBAgM
BVRleGFzMRMwEQYDVQQHDApSaWNoYXJkc29uMB4XDTE1MDcyOTE5NDUzNFoXDTIw
MDcyNzE5NDUzM1owezELMAkGA1UEBhMCVVMxFjAUBgNVBAoMDUNpc2NvIFN5c3Rl
bXMxDzANBgNVBAsMBmRDbG91ZDEeMBwGA1UEAwwVdWNtMS5kY2xvdWQuY2lzY28u
Y29tMQ4wDAYDVQQIDAVUZXhhczETMBEGA1UEBwwKUmljaGFyZHNvbjCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAIpFIfbGW/wtKccJlIoU1bDwzT8yPA5D
B82EpTZ87M2NASzieIFyIpBT/tACtiOwY2SGL0+87y5PMPG1GsfJEAb7NJNvBBR5
xoyjaeRbrMefotsEULQ6R6AWCwLiMMHIyRnyTRhfENcOVxc24ehBzr5FFUANBrSk
O16y9l7ra+4hO20S0yXUGuU98NzVc3WTJg822rYhqzUDVCPj26qy9OoCOP/6eXtl
eiebAFhCCCrz17+293+HUjN3CUhL6o/WKJjKslbrUq1b1HNNv5XlB5F8BG0D8LCx
wPnqjuDazr7yH57eTizZUYaHNDLRLVxUbpynK6YK0pI+xYKSl/Ezdr0CAwEAAaNN
MEswCwYDVR0PBAQDAgK0MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAd
BgNVHQ4EFgQUqlbxpV4gt8HxVa3JN5TBuHj29LAwDQYJKoZIhvcNAQELBQADggEB
ACI9etKkfPijajsaAhWBKh1VQ1IVdUNg5tENdU53903baoZYweKsVNBq40gbAJmK
4eVsVQtolduryndANEy1qYb9u3YvCEbEsASgqjlpZGohNmKE6VoyG0zPN2LepUox
nB4j0xejbQ57QOkdr6/FtVu07ElhjOCe1b7VyTqezTzHsUkaW3vwHK99HFdFcMJa

144 | P a g e
KSG2u5+sIFnQsXjZTV+uT2k+tWmjurtXux4e/O/cgM1ryKhVoUWmL8K9UMAI4us4
DGQ9RA3TaFrGJNbL1z62a81oLIHPRSVdmJ2xq6hw90CgWiHzEvQAg0rOMXD5k+0D
owTN+sL1gTFTyVzXjMSwYdQ=
-----END CERTIFICATE-----
!  Enter
!  Enter

Certificate has the following attributes:


Fingerprint MD5: 973BB8CC 64B7D398 3F976CD3 D00A501D
Fingerprint SHA1: D7BEE149 C4D69E64 59FF3656 2A70930F
F210AF53

% Do you accept this certificate? [yes/no]: yes


Trustpoint CA certificate accepted.
% Certificate successfully imported

20. If your Cisco Unified Communications Manager Group has other servers, then
repeat steps 16 to 19 above for each of the server to ensure failover works. That is, a
TrustPoint for every Subscriber in the cluster has to be created on CUBE, and their
respective self-signed certificate has to go through PKI authentication on CUBE.

145 | P a g e
C. Enable TLS transport for SIP signaling and sRTP for media
1. First let’s enable secure SIP signaling by associating the CUBE trustpoint with
CUCM, which was created in Section B¸Step 2.

Note: If the “crypto” option is not visible under “sip-ua”, enable “session
transport tcl tls” under the LAN dial-peers (100 and 101) before doing this step.
That will be done in step 2 of this section.

vpod-2911-cube-01(config)#sip-ua

! The default option will ensure all SIP signaling from CUBE uses the specified
! trustpoint. Or we can create a trust point per destination, which in our case would
! be CUCM at [Link] and we will be using CUBE-TrustPoint created earlier
! for SIP over TLS.

vpod-2911-cube-01(config-sip-ua)#crypto signaling ?
default Configure the default trustpoint
remote-addr Associate an IP network to a trustpoint

! CUBE will use its trustpoint “CUBE-TrustPoint” when it establishes or accepts a


TLS connection with [Link]

vpod-2911-cube-01(config-sip-ua)#crypto signaling remote-add


[Link] [Link] trustpoint CUBE-TrustPoint
vpod-2911-cube-01(config-sip-ua)#

2. Configure TCP TLS transport on the LAN dial-peers [100 and 101] for secure SIP
signaling between CUCM and CUBE. The CLI enables CUBE to listen on port TCP
5061
3. Additionally enable sRTP for media on these dial-peers. The fallback option ensures
if sRTP cannot be negotiated, the call is still established with standard RTP.

vpod-2911-cube-01(config)#dial-peer voice 100


vpod-2911-cube-01(config-dial-peer)#session transport tcp tls
vpod-2911-cube-01(config-dial-peer)#srtp fallback
vpod-2911-cube-01(config-dial-peer)#
vpod-2911-cube-01(config)#dial-peer voice 101
vpod-2911-cube-01(config-dial-peer)#session transport tcp tls
vpod-2911-cube-01(config-dial-peer)#srtp fallback
vpod-2911-cube-01(config-dial-peer)#

146 | P a g e
4. On ISR G2 platforms, SRTP-RTP interworking requires a secure transcoder. The
DSPs take care of encrypting/decrypting the media stream. On IOS-XE based
platforms (ISR 4000 series, vCUBE, and ASR 1000 series) secure transcoders are
not required for SRTP-RTP interworking as the processor takes care of
encryption/decryption.

We will configure the LTI based transcoder like we did in Module 3 as it has
minimal configuration requirements and does not require a PKI trustpoint for SRTP-
RTP interworking

! Enable dspfarm services under the voice card if not already done in Module 3
vpod-2911-cube-01(config)#voice-card 0
vpod-2911-cube-01(config-voicecard)#dsp services dspfarm
vpod-2911-cube-01(config-voicecard)#exit

! Create a secure transcoder

vpod-2911-cube-01(config)#dspfarm profile 11 transcode ?


security Enable security for the dspfarm service
universal Profile type Transcoding
<cr>

vpod-2911-cube-01(config)#dspfarm profile 11 transcode security


vpod-2911-cube-01(config-dspfarm-profile)#associate application CUBE
vpod-2911-cube-01(config-dspfarm-profile)#maximum sessions 2
vpod-2911-cube-01(config-dspfarm-profile)#no shutdown
vpod-2911-cube-01(config-dspfarm-profile)#exit
vpod-2911-cube-01(config)#

147 | P a g e
Final configuration of the dial-peers and the dspfarm profile configured in this
section is displayed below

voice-card 0
dsp services dspfarm
!
dspfarm profile 11 transcode security
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
maximum sessions 2
associate application CUBE
!
dial-peer voice 100 voip
description *** Inbound LAN dial-peer. From CUCM to CUBE ***
session protocol sipv2
session transport tcp tls
incoming called-number 8T
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
srtp fallback
codec g711ulaw
no vad
!
dial-peer voice 101 voip
description *** Outbound LAN dial-peer. From CUBE to CUCM ***
translation-profile outgoing CUBE_to_CUCM
destination-pattern +1408944....$
session protocol sipv2
session target ipv4:[Link]
session transport tcp tls
voice-class sip options-keepalive up-interval 10 down-interval 5 retry 2
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
srtp fallback
codec g711ulaw
no vad

148 | P a g e
D. Configure secure SIP trunk on CUCM towards CUBE
As part of Module 1, we already have a SIP Trunk from CUCM to the CUBE. We will just
update that trunk to enable security on it.

1. Navigate to Cisco Unified CM Administration portal of CUCM. Go to System 


Security  SIP trunk Security Profile. Click Add New

149 | P a g e
2. Add a new SIP Trunk Security profile as shown below. In the X.509 Subject Name
enter the Common Name (CN) used in our CUBE certificate as part of Section B,
step 2 of this Module. That name required to be the hostname plus the IP domain
name of the router. “vpod-2911-cube-01”. Click Save

150 | P a g e
3. Next we will update the SIP Trunk from CUCM to CUBE created in Module 1.
Navigate to Device  Trunk and click Find. Click on the SIP Trunk called CUBE
as shown below.

151 | P a g e
4. The existing SIP Trunk between CUCM and CUBE will be secured by

a. Selecting SRTP Allowed under the Device information as shown below

152 | P a g e
b. Applying the Secure SIP Trunk Profile we have created above, and
c. Changing the Destination Port to 5061.

d. Click Save and then Reset the Trunk

153 | P a g e
Verification

At this stage, PSTN Calls (Inbound and Outbound) should be encrypted between CUBE and
CUCM/Jabber Softphone. We will place an Outbound PSTN call to a NANP long distance
number, +1-678-701-3003 and see various CLI outputs on CUBE to verify a secure call.

1. We placed a call from CSFMCHENG (Monica Cheng’s Jabber Softphone) by


dialing 816787013003. Once the call was answered from the PSTN phone, we can
see the lock icon on the Jabber client, indicating that both the signaling between
CUCM and CUBE and the media between Jabber and CUBE are secure for this call.

154 | P a g e
2. Issue show call active voice brief on CUBE and verify that the leg between CUBE
and CUCM has SRTP turned on and the rx/tx are incrementing. The leg between
CUBE and ITSP will be unencrypted.
3. Additionally a transcoder is being used for SRTP-RTP interworking and we will
verify that as well

CUBE#show call active voice brief

! Leg between CUCM and CUBE – SRTP is on

0 : 45499 254072350ms.1 (11:28:18.098 PDT Sun Jun 3 2018) +11470 pid:100


Answer 4089447700 connected
dur 00:17:42 tx:53145/8715780 rx:53141/8715124 dscp:0 media:0 audio tos:0xB8
video tos:0x0
IP [Link]:22360 SRTP: on rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: Yes ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:000016b400105000a000005056acffc8
RemoteUUID:9473eb47a8135c9990af438fef0e288f
VRF: NA

! Leg between CUBE and ITSP – SRTP is off


0 : 45500 254072350ms.2 (11:28:18.098 PDT Sun Jun 3 2018) +11470 pid:201
Originate 816787013003 connected
dur 00:17:42 tx:53141/8502560 rx:53593/8574880 dscp:0 media:0 audio tos:0xB8
video tos:0x0
IP [Link]:17218 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: Yes ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:9473eb47a8135c9990af438fef0e288f
RemoteUUID:000016b400105000a000005056acffc8
VRF: NA

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

155 | P a g e
! show call active voice brief shows “Transcoded: Yes”. Let’s look at the transcoder CLI in detail

vpod-2911-cube-01#show dspfarm all

! Profile ID 3 was created in Module 3 of this lab

Dspfarm Profile Configuration

Profile ID = 3, Service = TRANSCODING, Resource ID = 1


Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Total Number of Resources Configured : 2
Total Number of Resources Available : 2
Total Number of Resources Out of Service : 0
Total Number of Resources Active : 0
Codec Configuration: num_of_codecs:5
Codec : g729r8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
Dspfarm Profile Configuration

! Profile ID 11 created for this Module. s-xcode indicates an sRTP session


Profile ID = 11, Service = TRANSCODING, Resource ID = 2
Profile Service Mode : secure
TLS Version : v1.0
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Total Number of Resources Configured : 2
Total Number of Resources Available : 1
Total Number of Resources Out of Service : 0
Total Number of Resources Active : 1
Codec Configuration: num_of_codecs:4
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
TLS : ENABLED

SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 46.2.4 UP 1 USED s-xcode 2 1713 4326 4337


0 1 46.2.4 UP 1 USED s-xcode 2 1712 4330 4326
0 1 46.2.4 UP N/A FREE xcode 1 - - -
0 1 46.2.4 UP N/A FREE xcode 1 - - -
0 1 46.2.4 UP N/A FREE s-xcode 2 - - -

Total number of DSPFARM DSP channel(s) 4

156 | P a g e
4. Let’s look at the abbreviated debug ccsip message output to see SIP TLS/sRTP
indications

! Incoming INVITE from CUCM with TLS on port 5061


017402: Jun 3 19:16:20.484: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:816787013003@[Link]:5061 SIP/2.0
Via: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK60a71f8ed88
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=11347~72443a9a-
68a6-49b2-8a3d-9533cc415eaa-21732499
To: <sip:816787013003@[Link]>
Date: Sun, 03 Jun 2018 19:16:20 GMT
Call-ID: 9769df80-b1413e84-5f1-38512c6@[Link]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM11.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:[Link]:5061>;method="NOTIFY;Event=telephone-
event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-
class=DESKTOP
Session-ID:
0000164f00105000a000005056acffc8;remote=00000000000000000000000000000000
Cisco-Guid: 2540298112-0000065536-0000000006-0059052742
Session-Expires: 1800
P-Asserted-Identity: "Monica Cheng" <sip:4089447700@[Link]>
Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
Contact:
<sip:4089447700@[Link]:5061;transport=tls>;video;audio;+[Link]!devi
[Link]="CSFMCHENG";bfcp;DeviceName="CSFMCHENG"
Max-Forwards: 69
Content-Length: 0

! INVITE sent from CUBE to ITSP


017403: Jun 3 19:16:20.500:
//46080/9769DF800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:816787013003@[Link]:5060 SIP/2.0
Via: SIP/2.0/UDP [Link];branch=z9hG4bKB4681BA3
Remote-Party-ID: "Monica Cheng"
<sip:4089447700@[Link]>;party=calling;screen=yes;privacy=off
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=F50D174-26AF
To: <sip:816787013003@[Link]>
Date: Sun, 03 Jun 2018 19:16:20 GMT
Call-ID: 6E83E085-669911E8-B4F0941E-48173748@[Link]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2540298112-0000065536-0000000006-0059052742
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M2

157 | P a g e
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1528053380
Contact: <sip:4089447700@[Link]>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-ID:
0000164f00105000a000005056acffc8;remote=00000000000000000000000000000000
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241

v=0
o=CiscoSystemsSIP-GW-UserAgent 8440 2053 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16660 RTP/AVP 0 101
c=IN IP4 [Link]
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

158 | P a g e
! 200 OK sent to CUCM from CUBE with crypto attributes in the SDP
017415: Jun 3 19:16:31.872:
//46079/9769DF800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK60a71f8ed88
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=11347~72443a9a-
68a6-49b2-8a3d-9533cc415eaa-21732499
To: <sip:816787013003@[Link]>;tag=F50D944-535
Date: Sun, 03 Jun 2018 19:16:20 GMT
Call-ID: 9769df80-b1413e84-5f1-38512c6@[Link]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID:
<sip:16787013003@[Link]>;party=called;screen=no;privacy=off
Contact: <sip:816787013003@[Link]:5061;transport=tls>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.7.3.M2
Session-ID:
bb8b578248125c379998f8ab9f0e1969;remote=0000164f00105000a000005056acffc8
Session-Expires: 1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 335

v=0
o=CiscoSystemsSIP-GW-UserAgent 3334 8238 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
t=0 0
m=audio 16658 RTP/SAVP 0 101
c=IN IP4 [Link]
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:B7WCMoNdvREcB9RbqQkvhYw4tdwUkQGAN7LK5S/9
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

159 | P a g e
! ACK received from CUCM with media attributes for encryption
017417: Jun 3 19:16:31.880:
//46079/9769DF800000/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:816787013003@[Link]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK60b73812e93
From: "Monica Cheng" <sip:4089447700@[Link]>;tag=11347~72443a9a-
68a6-49b2-8a3d-9533cc415eaa-21732499
To: <sip:816787013003@[Link]>;tag=F50D944-535
Date: Sun, 03 Jun 2018 19:16:20 GMT
Call-ID: 9769df80-b1413e84-5f1-38512c6@[Link]
User-Agent: Cisco-CUCM11.5
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Session-ID:
0000164f00105000a000005056acffc8;remote=bb8b578248125c379998f8ab9f0e1969
Content-Type: application/sdp
Content-Length: 310

v=0
o=CiscoSystemsCCM-SIP 11347 1 IN IP4 [Link]
s=SIP Call
c=IN IP4 [Link]
b=TIAS:64000
b=AS:64
t=0 0
m=audio 19722 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:5Q5kG0CJXlj2pWE4goC1wtL2czWtUpoVBCWpwpVN
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

vpod-2911-cube-01#

160 | P a g e
Module 12 – CUBE + SIP SRST Co-location and
Multi-tenancy
Prior to attempting this Module, ensure Module 1 has been completed.

Introduction

Cisco Unified SIP SRST provides backup to an external SIP call control (IP-PBX) by
providing basic registrar and redirect server or back-to-back user agent (B2BUA) services.
These services are used by a SIP IP phone in the event of a WAN connection outage when
the SIP phone is unable to communicate with its primary SIP proxy.

This module covers co-location of CUBE and SRST along with multi-tenant SIP trunks. It
describes configuration recommendations and details on the various line side and SIP
trunking features on Unified SRST. Co-location of CUBE and Unified SRST was
introduced in Cisco IOS XE Fuji 16.7.1 [CUBE 12.0.0, SRST 12.1] which allows deploying
product instances of CUBE and SRST (only for SIP) on the same Cisco 4000 Series
Integrated Services Router.

In an enterprise deployment, IP phones register with Cisco Unified Communications


Manager (CUCM) during normal operations. In the event of phone losing connectivity to
CUCM for situations such as WAN disruption, they fall back on Unified SRST - phones
registered to SRST router can place or receive PSTN calls through CUBE’s SIP trunk to
ITSP.

161 | P a g e
162 | P a g e
Collocating CUBE and Unified SIP SRST has some configuration and
design requirements as listed in Task 1 below

Task:

1. Familiarize yourself with the design and configuration requirements for collocating
CUBE and SIP SRST.
2. Configure Cisco Unified SIP SRST on our CUBE router to support SRST fallback for
our Jabber SoftPhones (CSFMCHENG and CSFKONEAL)

Note: CUBE + SRST co-location for SIP endpoints has only been validated for the 7800
and 8800 series IP Phones and ISR4000 series platforms only. Future SRST releases will
support additional endpoints including SCCP endpoints. In this lab we are using an ISR2900
and Jabber to just demonstrate the concept and related configuration.

163 | P a g e
Task 1: CUBE + SIP SRST Co-location Design and Configuration requirements

Move ITSP SIP trunk specific configuration under a voice class tenant and apply
the tenant to Outbound WAN dial-peers (dial-peers 201 and 211 from Module 1). This is
required to avoid line-side (SRST) and trunk side (ITSP) SIP configuration conflict. The
voice class tenant feature allows for grouping and configuring of SIP trunk parameters
otherwise done under voice service voip and sip-ua. When a tenant is configured and
applied under a dial-peer, the IOS/IOS-XE configurations are applied in the following order
of preference:

 Dial-peer configuration
 Tenant configuration
 Global configuration (voice service voip / sip-ua)

Do not use the Destination Dial-peer Group feature (Module 6) on an incoming WAN dial-
peer (dial-peer 200 in Module 1) as there will be no active Outbound LAN dial-peers (dial-
peer 101) when the platform falls back to SRST mode, resulting in call failures.

Configure and apply SIP OPTIONS ping keepalives to Outbound LAN dial-peers (dial-peer
101 in Module 1, Section G) to monitor reachability towards Unified Communications
Manager.

Do not configure “incoming called-number .T” on an inbound LAN dial-peer. Match


inbound call legs from ITSP to CUBE using URI based matching. This is how we have
configured inbound WAN dial-peer (dial-peer 200) in Module 1.

The following will be done as part of Task 2 including voice class tenant configuration

For phones (line-side devices) that fall back and register with the Unified SRST router,
dynamic dial-peers are created which can only inherit SIP global configuration parameters
(under voice service voip/sip and sip-ua.)

Move all the CLI commands related to SIP Bind feature under voice class tenant
configuration mode and apply the tenant to respective WAN dial-peers (dial-peers 200 and
201 in Module 1). For example, it is recommended to have the CLI commands voice-class
sip bind control, and voice-class sip bind media, under voice class tenant configuration
mode.

If dial-peers are using voice class codec, configure the same voice class codec under voice
register pool.

164 | P a g e
Task 2: Configure Cisco Unified SIP SRST on our CUBE router to support SRST
fallback for our Jabber SoftPhones (CSFMCHENG and CSFKONEAL)

As part of this task, we need to first configure CUCM for SRST and then CUBE for SRST
colocation. Let’s start with CUCM.

CUCM Configuration

1. Add a new SRST Reference and apply it to the Device Pool.

a. From Cisco Unified CM Administration portal, click on System and then select
SRST from the drop-down menu

165 | P a g e
b. Click on Add New, and fill out the following values in the SRST Reference
Configuration:
i. Name – CUBE-SRST
ii. IP Address* – [Link]

This is the LAN IP (Gig 0/0) address of the CUBE router

iii. SIP Network/IP Address – [Link]

Leave the Port values to default and click Save.

166 | P a g e
c. Navigate to System  Device Pool. Click Find and then click the Default device
pool as shown below

167 | P a g e
d. Apply the SRST Reference created above to this Device Pool. Navigate to Roaming
Sensitive Settings of this Device Pool. Set the SRST Reference* value to CUBE-
SRST by selecting it from the drop down options.

e. Click Save, Apply Config, and then Reset.

168 | P a g e
CUBE/IOS Configuration for Unified SRST

1. Using PuTTY, telnet to CUBE ([Link]), Username- cisco, Password- Cu8ELab!

a. Configure SIP Registrar on CUBE to accept incoming SIP registration requests:

CUBE#conf t
CUBE(config)#voice service voip
CUBE(conf-voi-serv)#sip
CUBE(conf-serv-sip)#registrar server expires max 120 min 60
CUBE(conf-serv-sip)#end

b. Configure global parameters for supported SIP phones:

CUBE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CUBE(config)#voice register global
CUBE(config-register-global)# max-dn 2
CUBE(config-register-global)#max-pool 2
CUBE(config-register-global)#end

Note: If prompted, please accept the cme-srst license agreement by entering Yes.

c. Configure phone specific parameters (registration permission control and dynamic


dial-peer parameters)

CUBE#conf t
CUBE(config)#voice register pool 1

! Define the IP network of the phone sending the REGISTER request to this platform

CUBE(config-register-pool)#id network [Link] mask


[Link]
CUBE(config-register-pool)#dtmf-relay rtp-nte
CUBE(config-register-pool)#codec g711ulaw
CUBE(config-register-pool)#no vad
CUBE(config-register-pool)#end

169 | P a g e
2. Introduction to Multi-tenancy configurations for ITSP SIP trunk

Prior to release IOS 15.6(2)T / IOS-XE 16.3.1, CUBE supported only single tenancy, with
SIP-specific attributes configured either globally or under a dial-peer. With the introduction
of multi-tenancy support on CUBE, the SIP-specific attributes can now be configured on a
per tenant basis in addition to the existing global or dial-peer levels. Each Registrar/User
Agent/ITSP trunk connected to CUBE can be treated as a tenant.

CUBE's multi-tenant feature enables specific global configurations for multiple tenants on
SIP trunks that allow differentiated services for tenants. Each tenant can have their own
individual configurations such as timers, credentials, bind requests, and other parameters
which are available under sip-ua and voice service voip/sip configurations.

Unified SRST co-located on a CUBE router leverages the multi-tenant feature to segregate
trunk-side (ITSP, CUCM) and line-side (IP Phones) SIP-specific configuration.

To configure a tenant on CUBE, voice class tenant <tag> command is used that allows
SIP-specific attributes to be configured on a per tenant basis. The command (voice class
tenant) can then be applied to individual dial-peers, thereby associating them to a particular
tenant.

For this lab we will create a tenant for ITSP SIP trunk and associate it with WAN-side dial-
peers (dial-peers 200 and 201) created in Module 1. Dynamic dialpeers that are created
when phones fallback to SRST mode and register with the CUBE+SRST router, will inherit
sip configuration from the global mode (voice service voip/sip, sip-ua)

a. Create a new tenant on CUBE as shown below.

CUBE#conf t
CUBE(config)#voice class tenant 12
CUBE(config-class)#bind control source-interface Gig0/1
CUBE(config-class)#bind media source-interface Gig0/1
CUBE(config-class)#early-offer forced
CUBE(config-class)#session transport udp
CUBE(config-class)#end
CUBE#

170 | P a g e
b. Modify WAN dialpeers to use the tenant created above.

In Module 1, Section-E we configured WAN dial-peers 200 and 201 to handle calls
to/from ITSP SIP trunk as shown below:

dial-peer voice 200 voip


description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

dial-peer voice 201 voip


description *Outbound WAN dial-peer. Long distance from CUBE to SP*
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
session transport udp
voice-class sip options-keepalive profile 200
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711ulaw
no vad

c. Remove the session transport, SIP signaling and media interface bind statements as
shown below:

CUBE#conf t
CUBE(config)#dial-peer voice 200
CUBE(config-dial-peer)#no voice-class sip bind control
CUBE(config-dial-peer)#no voice-class sip bind media
CUBE(config-dial-peer)#no session transport udp

CUBE(config-dial-peer)#dial-peer voice 201


CUBE(config-dial-peer)#no voice-class sip bind control
CUBE(config-dial-peer)#no voice-class sip bind media
CUBE(config-dial-peer)#no session transport udp
CUBE(config-dial-peer)#end

171 | P a g e
The dial-peers should now look as below

CUBEsh run dial-peer voice 200


Current configuration:
!
dial-peer voice 200 voip
description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
end

CUBE#sh run dial-peer voice 201


Current configuration:
!
dial-peer voice 201 voip
description *Outbound WAN dial-peer. Long distance from CUBE to SP*
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
voice-class sip options-keepalive profile 200
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
End

d. Apply voice class class tenant 12 created above to these dial-peers so


that they inherit SIP parameters (signal/media binding and transport) from the
tenant:

CUBE#conf t
CUBE(config)#dial-peer voice 200 voip
CUBE(config-dial-peer)#voice-class sip tenant 12

CUBE(config-dial-peer)#dial-peer voice 201 voip


CUBE(config-dial-peer)#voice-class sip tenant 12
CUBE(config-dial-peer)#end

172 | P a g e
The final dial-peers 200 and 201 should look like below

dial-peer voice 200 voip


description ***WAN [Link] Provider to CUBE***
session protocol sipv2
incoming uri via 200
voice-class sip tenant 12
no voice-class sip error-code-override total-calls failure
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 201 voip
description *Outbound WAN dial-peer. Long distance from
CUBE to SP*
translation-profile outgoing 786
destination-pattern 81[2-9]..[2-9]......$
session protocol sipv2
session target ipv4:[Link]
voice-class sip tenant 12
voice-class sip options-keepalive profile 200
dtmf-relay rtp-nte
codec g711ulaw
no vad

173 | P a g e
e. As per Module 1, Section-B, Task 2, the calling number display for Outbound
PSTN calls on the called party’s phone should appear as “4089447700”. To achieve
this request, we configured a Calling Party Transformation Mask within the
Route Pattern as shown below

Now that the Jabber SoftPhones will not be utilizing the Route Pattern for
Outbound PSTN calls when in the SRST mode, we must fullfil this requirement
through CUBE/SRST router with a voice translation rule/profile.

174 | P a g e
Proceed as shown below to configure the outbound PSTN calling number display

CUBE#conf t

! Create the below translation-rule to convert any number to 4089447700

CUBE(config)#voice translation-rule 12
CUBE(cfg-translation-rule)#rule 1 /.*/ /4089447700/
CUBE(cfg-translation-rule)#exit

! Create a translation-profile that utilizes translation-rule 12 on calling numbers. We


! are calling it SRST-Outbound-DP201

CUBE(config)#voice translation-profile SRST-Outbound-DP201


CUBE(cfg-translation-profile)#translate calling 12
CUBE(cfg-translation-profile)#exit

! Apply the above translation-profile on the Outbound WAN dial-peer 201 for
! outbound PSTN calling, to convert any calling number to 4089447700

CUBE(config)#dial-peer voice 201


CUBE(config-dial-peer)#translation-profile outgoing SRST-
Outbound-DP201
CUBE(config-dial-peer)#exit

Verification

a. Telnet to CUBE and enable debug ccsip message and clear log as we
have done throughout the lab
b. Simulate WAN failure

To simulate WAN failure where Jabber device is not able to reach CUCM, we are going to
temporarily stop Cisco CallManager service.

Note: This is for lab demo purposes only and not recommended for actual
deployment.

Navigate to Cisco Unified Serviceability portal and enter the credentials to login
[administrator/dCloud123!] if required. Go to Tools  Control Center – Feature Services
and select CUCM ([Link]).

175 | P a g e
Select the CallManager service and click Stop. Click OK to confirm. Wait for a few
minutes and you should see SIP registration request coming into the CUBE router from
Jabber SoftPhone [CSFMCHENG – [Link]]. Request from CSFKONEAL –
[Link]] may come to CUBE if CSFKONEAL is logged into the Jabber Client.

176 | P a g e
Let’s take a look at the debug output from CUBE.

CUBE#show log

! Incoming REGISTER from CSFKONEAL - [Link]

Jun 8 2018 00:22:30.737 UTC: //-


1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK00007108
From:
<sip:+14085551074@[Link]>;tag=005056b87f960baf00007386-
00006e21
To: <sip:+14085551074@[Link]>
Call-ID: 005056b8-7f96004d-00007e13-00005db8@[Link]
Max-Forwards: 70
Date: Fri, 08 Jun 2018 00:22:21 GMT
CSeq: 2986 REGISTER
User-Agent: Cisco-CSF
Contact: <sip:a852e66a-4d6a-3587-624e-
5fb7c3c33161@[Link]:5060;transport=udp>;+[Link]="<ur
n:uuid:00000000-0000-0000-0000-
005056b87f96>";+[Link]![Link]="CSFKONEAL";+[Link]
![Link]="503";video;bfcp
Supported: extended-refer,norefersub,X-cisco-srtp-fallback,X-
cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Reason: SIP;cause=200;text="cisco-alarm:17 Name=CSFKONEAL
ActiveLoad=Jabber_for_Windows-11.8.2.50390
InactiveLoad=Jabber_for_Windows-11.8.2.50390 Last=reg-timeout"
Expires: 3600

! SRST mode has been turned on. CSFKONEAL has registered to Cisco Unified SRST

Jun 8 2018 00:22:30.745 UTC: VOICE REGISTER POOL-1 has


registered. Name: IP:[Link] DeviceType:Phone

Jun 8 00:22:30.749: %SIPPHONE-6-REGISTER: VOICE REGISTER POOL-1


has registered. Name: IP:[Link] DeviceType:Phone

! SRST Router sending 200 OK, thereby registering CSFKONEAL

Jun 8 2018 00:22:30.749 UTC:


//68958/DDAFB9B08E89/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK00007108
From:
<sip:+14085551074@[Link]>;tag=005056b87f960baf00007386-
00006e21
To: <sip:+14085551074@[Link]>;tag=143EBAD4-2254

177 | P a g e
Date: Fri, 08 Jun 2018 00:22:30 GMT
Call-ID: 005056b8-7f96004d-00007e13-00005db8@[Link]
Server: Cisco-SIPGateway/IOS-15.7.3.M2
CSeq: 2986 REGISTER
Supported: X-cisco-srst-sis-1.0.0
Supported: X-cisco-srtp-fallback
Contact: <sip:+14085551074@[Link]:5060>;expires=120;x-
cisco-newreg
Expires: 120
Content-Length: 0

! Due to OPTIONS ping configured on our Outbound LAN dial-peer 101, it has
! been busied out since CUCM is not reachable

Jun 8 00:22:34.697: %SIP-5-DIALPEER_STATUS: VoIP dial-Peer <101>


is Busied out

! Incoming REGISTER from CSFMCHENG - [Link]

Jun 8 2018 00:23:59.641 UTC: //-


1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK00000130
From:
<sip:+14085557700@[Link]>;tag=005056acffc80c19000079a9-
0000077c
To: <sip:+14085557700@[Link]>
Call-ID: 005056ac-ffc8004a-00000e53-00001962@[Link]
Max-Forwards: 70
Date: Fri, 08 Jun 2018 00:23:50 GMT
CSeq: 3069 REGISTER
User-Agent: Cisco-CSF
Contact: <sip:74a82a1b-3132-301b-ab98-
ce2f2c21db5c@[Link]:5060;transport=udp>;+[Link]="<ur
n:uuid:00000000-0000-0000-0000-
005056acffc8>";+[Link]![Link]="CSFMCHENG";+[Link]
![Link]="503";video;bfcp
Supported: extended-refer,norefersub,X-cisco-srtp-fallback,X-
cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Reason: SIP;cause=200;text="cisco-alarm:17 Name=CSFMCHENG
ActiveLoad=Jabber_for_Windows-11.8.2.50390
InactiveLoad=Jabber_for_Windows-11.8.2.50390 Last=reg-timeout"
Expires: 3600

Jun 8 2018 00:23:59.645 UTC:


//68987/12ACD53A8EA7/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK00000130

178 | P a g e
From:
<sip:+14085557700@[Link]>;tag=005056acffc80c19000079a9-
0000077c
To: <sip:+14085557700@[Link]>;tag=14401618-1D22
Date: Fri, 08 Jun 2018 00:23:59 GMT
Call-ID: 005056ac-ffc8004a-00000e53-00001962@[Link]
Server: Cisco-SIPGateway/IOS-15.7.3.M2
CSeq: 3069 REGISTER
Supported: X-cisco-srst-sis-1.0.0
Supported: X-cisco-srtp-fallback
Contact: <sip:+14085557700@[Link]:5060>;expires=120;x-
cisco-newreg
Expires: 120
Content-Length: 0

179 | P a g e
Let’s view show voice register all

CUBE#show voice register all


VOICE REGISTER GLOBAL
=====================
CONFIG [Version=12.0]
========================
Version 12.0
Mode is srst
Max-pool is 2
Max-dn is 2
Outbound-proxy is enabled and will use global configured value
Security Policy: DEVICE-DEFAULT
Allow-hash-in-dn is disabled
Forced Authorization Code Refer is enabled
timeout interdigit 10
timeout transfer recall 0
network-locale[0] US (This is the default network locale for this box)
network-locale[1] US
network-locale[2] US
network-locale[3] US
network-locale[4] US
user-locale[0] US (This is the default user locale for this box)
user-locale[1] US
user-locale[2] US
user-locale[3] US
user-locale[4] US
MWI unsolicited notify is disabled
Active registrations : 2

Total SIP phones registered: 2


Total Registration Statistics
Registration requests : 8
Registration success : 8
Registration failed : 0
unRegister requests : 6
unRegister success : 6
unRegister failed : 0
Auto-Register requests : 0
Attempts to register
after last unregister : 0
Last register request time : 17:23:59.645 PDT Thu Jun 7 2018
Last unregister request time : 11:17:42.843 PDT Thu Jun 7 2018
Register success time : 17:23:59.645 PDT Thu Jun 7 2018
Unregister success time : 11:17:42.846 PDT Thu Jun 7 2018

180 | P a g e
VOICE REGISTER DN
=================

VOICE REGISTER POOL


===================
Pool Tag 1
Config:
Network address is [Link], Mask is [Link]
Proxy Ip address is [Link]
DTMF Relay is enabled, rtp-nte
kpml signal is enabled
Lpcor Type is none

paging-dn: config 0 [multicast] effective 0 [multicast]

Dialpeers created:

Dial-peers for Pool 1:

dial-peer voice 40001 voip


destination-pattern +14085551074$
redirect ip2ip
session target ipv4:[Link]:5060
session protocol sipv2
dtmf-relay rtp-nte
digit collect kpml
codec g711ulaw bytes 160
no vad
after-hours-exempt FALSE

dial-peer voice 40002 voip


destination-pattern +14085557700$
redirect ip2ip
session target ipv4:[Link]:5060
session protocol sipv2
dtmf-relay rtp-nte
digit collect kpml
codec g711ulaw bytes 160
no vad
after-hours-exempt FALSE

Statistics:
Active registrations : 2

Total SIP phones registered: 2


Total Registration Statistics
Registration requests : 8
Registration success : 8
Registration failed : 0
unRegister requests : 6
unRegister success : 6

181 | P a g e
unRegister failed : 0
Auto-Register requests : 0
Attempts to register
after last unregister : 0
Last register request time : 17:23:59.645 PDT Thu Jun 7 2018
Last unregister request time : 11:17:42.843 PDT Thu Jun 7 2018
Register success time : 17:23:59.645 PDT Thu Jun 7 2018
Unregister success time : 11:17:42.850 PDT Thu Jun 7 2018

SIP SRST creates dynamic virtual voip dial-peers (voice register dn <tag>) beginning with
40XXX TAG for SRST endpoints

CUBE#show dial-peer voice summary


dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF
100 voip up up 0 syst NA
101 voip up up +1408944....$ 0 syst ipv4:[Link] busyout NA
200 voip up up 0 syst NA
201 voip up up 81[2-9]..[2-9]..- 0 syst ipv4:[Link] active NA
....$
211 voip up up 8011T 0syst ipv4:[Link] active NA
81800 voip up up 0syst NA
81800- voip up up 81..........$ 0syst ipv4:[Link] NA
553
800 voip down down 0 syst NA
901 voip down down map:800 0 syst SESS-SVR-GRP: 9 NA
1050 voip up up 999 0 syst ipv4:[Link] NA
40001 voip up up +14085551074$ 0 syst ipv4:[Link]:5 NA
40002 voip up up +14085557700$ 0 syst ipv4:[Link]:5 NA
For server-grp details please execute command:show voice classserver-group <tag_id>
To see complete session target for ipv6 use 'sh running config | section dial-peer <tag>

182 | P a g e
Lastly place an outbound PSTN call by dialing 8-1-XXX-XXX-XXXX (8+1+10 digits of
the NANP) and view show call active voice brief. We are placing the call from
CSFMCHENG, which is virtual dial-peer 40002 above and will show up as pid 40002. Due
to the translation profile we created in Step e. of this section, on your called PSTN phone,
the display will show up as +14089447700.

CUBE#show call active voice brief

2A68 : 71487 350093190ms.1 (20:16:28.584 PDT Thu Jun 7 2018) +10680 pid:40002 Answer +14085557700 active
dur 00:00:13 tx:1063/170080 rx:1060/169600 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP [Link]:16528 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:0000024900105000a000005056acffc8
RemoteUUID:fba17a2be6ef5b95a51b53f53b3e89ff
VRF: NA

2A68 : 71488 350093200ms.1 (20:16:28.594 PDT Thu Jun 7 2018) +10660 pid:201 Originate 816787013003 active
dur 00:00:13 tx:1060/169600 rx:1063/170080 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP [Link]:20388 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: 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
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:fba17a2be6ef5b95a51b53f53b3e89ff
RemoteUUID:0000024900105000a000005056acffc8
VRF: NA

183 | P a g e

You might also like