CUBE Lab Guide
CUBE Lab Guide
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
Interworking – Various SIP and H323 Stack Interoperability, SIP Normalization, DTMF,
Transcoding, Transrating, Codec Filtering
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.
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.
vpod-2911-cube-01#wr
Building configuration...
[OK]
5|Page
Lab Setup
1. Components
Network Diagram
This lab uses the network setup as shown in the diagram below for all PODs:
[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.
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]
Phone Number
DID Number +1 408-944-29DN2
Jabber Phone Extension on WKST 3 - +14085557700
CSFMCHENG
Jabber User ID mcheng
Jabber 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
8|Page
3. Pre-Setup
Once VPN’d in, connect to the following workstation using the local RDP client on
your laptop.
Once connected to WKST3, launch the Cisco Jabber for Windows client by double-
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.
11 | P a g e
A. Adding a SIP Trunk to CUCM
Task :
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.
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.
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
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:
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
“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-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.
2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711
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)
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.
25 | P a g e
Explanation of commands used above:
“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.
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
2 SIP Trunk Port number (Destination port number for INVITES) 5060
3 SIP Trunk Transport Layer (UDP or TCP) UDP
4 Codecs supported G711
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
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:
“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:
“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
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.
Verification:
To verify how voice translation-rule 7700 works, issue the following commands. This rule
converts +14089440000 to +14085557700 as shown below
32 | P a g e
The final dial-peer voice 101 voip should look like below:
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
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.
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
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.
The following debugs will assist in troubleshooting call failures for this lab:
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.
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
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.
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:
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
• down-interval: OPTIONS
keepalive timer interval for a
busied-out dial-peer. Default is 30
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
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.
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:
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
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.
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
While the dial-peer is busied out, an OPTION is sent every 5 second (500
msec added for processing)
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#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.
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
! Let’s monitor the status of the OPTIONS keepalive group 200. Dial-peers 201 and 211
! can be seen in Active state below
------------------------------------------------------
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.
! Wait for about 10 seconds and issue the following command. The dial-peers can
! be seen in busyout state
------------------------------------------------------
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
50 | P a g e
! Incoming INVITE from CUCM for an outbound PSTN call
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
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.
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.
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:
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;
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
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.
55 | P a g e
Debugs prior to application of SIP Profile 1, showing SIP INVITE from CUBE to
ITSP.
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”.
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
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.
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
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
64 is the debug category code for SIP-Profile feature within the CUBE SIP Info debugs.
Rest of the category codes are shown below:
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:
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]
CUBE(config)#voice-card 0
CUBE(config-voicecard)#dsp services dspfarm
CUBE(config-voicecard)#
63 | P a g e
2. Dspfarm profile configuration
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:
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
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:
2. To verify the dspfarm profile configuration, issue the following command on CUBE
with the call up;
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
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
For the rest of the lab, let’s change the codecs on dial-peers 100 and 101 back to G.711
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:
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:
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.
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
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.
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.
For example, the following command configures a threshold based on total number of calls
traversing CUBE
70 | P a g e
Verification:
Call threshold status can be verified by issuing the following command on CUBE:
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
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.
Dial-peer level configuration: Update dial-peer 200 with the following CLI as highlighted
below:
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”
74 | P a g e
3. Apply SIP profile to the inbound WAN dial-peer (dial-peer 200)
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.
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
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
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:
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.
3. Create Outbound WAN dial-peer to allow delivering of the above call leg towards ITSP.
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.
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.
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.
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
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
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
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
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
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.
2. Issue the global config mode CLI voice sip sip-profiles upgrade to convert the
above into the new syntax.
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
! 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
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.
90 | P a g e
2. Multiple incoming called or calling numbers under the same inbound dial-peer
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:
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].
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.
Verification:
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.
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.
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.
Verification:
Test:
Before testing the call let’s shut down all dial-peers we originally created in Module 1:
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.
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
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.
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.
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.
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.
98 | P a g e
Relevant debug snippet. PSTN Party Number in this example : 678-555-5555
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
Jun 1 17:13:23.058:
//9447/EC62D722A85A/CCAPI/ccIFCallSetupRequestPrivate:
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing
Dial-peer=101, Call Count On=FALSE,
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
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,
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.
101 | P a g e
Output of show voip rtp connections showing 4 RTP streams, with two streams going
towards MediaSense.
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
AnchorLeg Details:
Call ID: 9448
Forking Stream type: voice-nearend
Participant: +14085557700
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>
! 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
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
107 | P a g e
--uniqueBoundary
Content-Type: application/rs-metadata+xml
Content-Disposition: recording-session
<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.
109 | P a g e
Disable SIPREC triggering on dial-peer 101 as shown below before proceeding to the next
section.
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
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]
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.
115 | P a g e
4. Enable recording of all calls made to and from Katelyn O’Neal’s Cisco Jabber
Softphone, CSFKONEAL
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.
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.
CUBE#conf t
CUBE(config)#uc wsapi
CUBE(config-uc-wsapi)#source-address [Link]
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]
119 | P a g e
Let’s verify the application (CUCM) registration to the XMF Provider
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.
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
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.
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.
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:
124 | P a g e
A. Pre-Configured tasks
No Configuration is needed in this section. Just go through the steps listed here.
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
CUCM
132 | P a g e
7. Ensure CUBE router has the correct security license(s) to generate certificates
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.
2. Create a PKI trustpoint using the key pair above to hold CUBE’s self-signed
certificate.
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
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.
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
! Copy only the “Self-signed CA certificate” and copy starting with the -----BEGIN
! CERTIFICATE------ and end with -------END CERTIFICATE---------------
% 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.
139 | P a g e
12. Select the CUCM as shown below
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.
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
! 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
! 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
-----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
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
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.
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
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.
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
152 | P a g e
b. Applying the Secure SIP Trunk Profile we have created above, and
c. Changing the Destination Port to 5061.
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.
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
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
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED
156 | P a g e
4. Let’s look at the abbreviated debug ccsip message output to see SIP TLS/sRTP
indications
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.
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.
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
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]
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.
168 | P a g e
CUBE/IOS Configuration for Unified SRST
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
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.
CUBE#conf t
CUBE(config)#voice register pool 1
! Define the IP network of the phone sending the REGISTER request to this platform
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)
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:
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
171 | P a g e
The dial-peers should now look as below
CUBE#conf t
CUBE(config)#dial-peer voice 200 voip
CUBE(config-dial-peer)#voice-class sip tenant 12
172 | P a g e
The final dial-peers 200 and 201 should look like below
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
CUBE(config)#voice translation-rule 12
CUBE(cfg-translation-rule)#rule 1 /.*/ /4089447700/
CUBE(cfg-translation-rule)#exit
! Apply the above translation-profile on the Outbound WAN dial-peer 201 for
! outbound PSTN calling, to convert any calling number to 4089447700
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
! SRST mode has been turned on. CSFKONEAL has registered to Cisco Unified SRST
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
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
180 | P a g e
VOICE REGISTER DN
=================
Dialpeers created:
Statistics:
Active registrations : 2
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
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.
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