Lab Configuration Part 5 – Configure the CUBE for a Call

Up to this point, nearly the entire lab is configured. Our CIPC phone is installed and configured with a calling search space that has a route pattern for outbound calls pointing to the route list we built, which has a single route group that includes our SIP trunk to the CUBE. Our SIP trunk is up and running, but yet, when we try to make a call to an external number, it won’t go through. Why is this?

Well there are a few components here that we need to address. First and foremost, we need to register our CUBE to our ITSP. I’m not going to go into the side in this post, but your ITSP, regardless of who you choose to go with, will provide you with a SIP Realm, a username, and a password. There are technically two sets of credentials, and depending on your ITSP they could be different, or they could be the same. With, they are the same.

First, you have a SIP Authentication. These credentials are to build the SIP trunk between your CUBE and the ITSP. Next you have Authorization credentials that are used to validate each call you send. We have to configure both the authentication and the authorizations.

Configure the SIP-UA (User Authentication)

config t
// Going back into the configuration terminal

// We need to configure the CUBE as a client for the ITSP. If you’re not familiar with SIP, this is a good learning point. In SIP, you have a User Agent Client (UAC) and a User Agent Server (UAS). To simplify, you always have a client and a server. So with a SIP phone, your phone is the client, and CUCM is your server. Our CUBE, both with our ITSP and with CUCM, is the client.

credentials username [USERNAME] password [PASSWORD] realm [ITSP URL]
// This is your SIP ITSP credentials. This is not the same as what you log into their website with, these credentials are what they provide you for this SIP trunk specifically.

authentication username [USERNAME] password [PASSWORD] realm [ITSP URL]
// The authentication command is formatted just like the credentials, but this one is for authenticating each call. You will see when you debug ccsip messages that when a call is made, you first see the INVITE, but then you will receive a 401 unauthorized. Once you have received that, your CUBE will send back a second INVITE that includes the authorization with yo8ur username, password, and realm.

registrar 1 dns:[ITSP URL] expires 120
// This is the registration URL, same as the SIP realm, that you are authenticating to. You also have to instruct the CUBE how often this registration should expire and reauthenticate. Right now I have mine set to 120 seconds, but in a production environment, it would be wise to set that to a higher number, maybe around 5 to 10 minutes.

retry invite 3
// This command I got from a TAC engineer one day when troubleshooting an issue. I found that when my CUCM subscriber went down, my CUBE just kept resending the INVITES and never failed over to backup CUCM. TAC gave me this command to limit the amount of times it will retry before consdering the call failed. This isn’t really necessary right now since we don’t have a failover ITSP or CUCM, but in a production environment, you will want this command!

Configuring Voice Classes

It’s true that this part isn’t really REQUIRED for this lab, but it’s one of those learning things that you need to know for a production environment.

The voice class is really just a classification. This classification is then assigned to your dial-peer to tell it what to identify in the call and where to send it.

We will match based on our SIP INVITE messages. So first, I’m going to test an inbound call so I can get that initial INVITE and then match everything up to that.

I’ve highlighted above the Via and To headers. This is where we will identify our voice classes.

First, lets work on calls coming from our ITSP, since that is where this SIP call came from. We will identify calls using the Via header (aka the line starting with Via) which tells us that the last layer 3 hop was this IP address, which belongs to (ipv4:

Incoming from ITSP

So lets go ahead and define our incoming ITSP voice class. We don’t want to match the incoming phone number, right? Because that could be ANYTHING. And we don’t want to accept incoming calls from just any provider, so we don’t want to match based on the user portion. Instead, lets base accepting incoming calls on the host, which as you saw in the debug is

config t
voice class uri FromITSPuri sip

// This simply defined our voice class as a uri, gave it the name FromITSPuri, and then defined it’s sip.

host ipv4:
// This could have been host, and then DNS would have stepped in to save the day, but since it’s coming in as an IP address, let’s just stick with that for now. In production, though, it would be wise to go with the DNS in case the ITSP ever changed the IP address.

Perfect, so we have our incoming ITSP.

Outgoing to CUCM

Now lets define outbound to the CUCM to complete this test call. Once the call comes into the CUBE and is identified as coming from, we need to direct the call to the CUCM. The ITSP doesn’t know who our CUCM is though (and for good reason), so the To field populates DID@CUBEADDRESS. So we can look at sending our call to CUCM by identifying one of two parts of that. Either the user or the host. Initially you might want to stay on course and say everything should be based on hosts, but the problem is that both the ITSP and the CUCM will be sending calls to the CUBE, so you would never get calls to route properly. Instead, let’s route outbound based on the phone number in the SIP URI.

Looking at the debug, we see that the To field is 618-714-1234. That is one of our DID’s, and for this lab our only DID. So we will, for now, route our call based on that DID. Yes, wildcards can be used for voice classes. Page 33 of this document will help you formulate your pattern if you have a DID range.

But for this example, we will just base our call on this one single phone number. So lets get back to it. We are already in the config t.

voice class uri ToCUCMnum sip
// once again defining our voice class on the uri, and giving it a descriptive name of ToCUCMnum, followed by sip.
user-id 6187141234
// We are simply defining that the user-id is what we want to match, and that we are matching exactly the DID 6187141234.

That is all the voice classes we need for the incoming call. We have defined an inbound to the CUBE from the ITSP and an outbound from the CUBE to the CUCM.

Now we need to run another debug ccsip messages but this time our test call will be from our CIPC phone and calling out to an external phone number.

As you can see, this time our Via header, we are receiving the message from our CUCM, and once again the To field is populated with the number we are calling and the CUBE IP address.

Let’s go ahead and define these in our voice classes.

Incoming from CUCM

voice class uri FromCUCMuri sip
host ipv4:

// This is defining our CUCM IPv4 address for the From header in our INVITE message.

Outgoing to ITSP

voice class uri ToITSPnum sip
user-id …..+

// Since we want to match on the phone number, but obviously don’t want to send calls back to the CUCM, we need to identify a generic pattern, since any phone number could be dialed for outbound. We could go into complex dial-plans right now, but that isn’t really the point of this guide. So let’s just make something generic for now. The “.” is a wildcard for any digit, and the “+” is a wildcard for the repetition of the previous digit any amount of times. This means this pattern of 5 periods and a plus sign will match to any string of digits that are at least 5 digits long. For incoming calls from the ITSP, we defined a very specific number, and all patterns will be checked, so the winning class will be whichever pattern most accurately matches the actual phone number. So we don’t have to worry about our incoming calls being routed back out to the ITSP. I decided to match 5 digits first, so that we won’t send any internal extensions to the ITSP in case anything on the CUCM side was configured incorrectly. So if any calls from 4 digit extensions hit the CUBE, it will just kill the call.

Voice Class Results

As you can see in the screenshot above, we now have four voice classes clearly defined. Two voice classes for each direction of call. An inbound to the CUBE from the ITSP, and outbound from the CUBE to the CUCM. And then alternatively, an inbound to the CUBE from the CUCM, and an outbound from the CUBE to the ITSP.

Just like we defined these voice classes, we must keep the same mentality when creating our dial-peers.

Configuring Dial-Peers

Now that the hard work of identifying our SIP INVITES to determine where the call needs to go, as a pre-requisite, is done, we can move on to the suddenly less daunting task of creating our actual dial-peers.

Traditionally, you were required to make a dial-peer for each leg of a call. So just like with our voice classes, you had to make one dial-peer for inbound from the ITSP, and then outbound to the CUCM. Then inbound from the CUCM, and outbound to the ITSP.

We will make this a bit easier on ourselves, though, and keep the configurations a bit cleaner by adding the incoming route to the same dial-peer as our outbound.

I’m going to keep CUCM on one dial-peer and ITSP on another. I find that to be cleaner, but you could also base your dial-peers on the call legs, and have incoming from cucm and outbound to itsp on the same dial-peer. Engineers preference on that one, I guess.

First let’s configure our CUCM side dial-peer.

dial-peer voice 1000 voip
// The number 1000 is just an arbitrarily picked identifier.
description *** INBOUND FROM CUCM *** OUTBOUND TO CUCM ***
session protocol sipv2
// Seems obvious enough what this one is doing.
dtmf-relay rtp-nte sip-kpml

// Determing what DTMF formats are supported
codec transparent

// I set codecs transparent and let my CUCM dictate codecs. But you could dictate what codecs should be used from within the dial-peer.
no vad

// Stands for voice-activity detection. Basically if the CUBE doesn’t recognize voice activity, it would try to cut the media stream. Let’s just avoid this… forever.
incoming uri via FromCUCMuri

// Here is where we define our incoming voice class from the CUCM. We include the term via before our voice class to define that we are looking for that in the Via header.
destination uri ToCUCMnum

// Now we define our outbound voice class to the CUCM. No via command this time because we are matching by the user-id portion.
session target ipv4:

// Finally, if we match our outbound voice class to the CUCM, we need to tell the CUBE where to actually send the call. Keep in mind, our destination ToCUCMnum is based on the DID 618-714-1234, so we have to tell the CUBE where to send calls going to that number.

dial-peer voice 1001 voip
description *** INBOUND FROM ITSP *** OUTBOUND TO ITSP ***
session protocol sipv2
dtmf-relay rtp-nte sip-kpml
codec transparent
no vad
incoming uri via FromITSPuri
destination uri ToITSPnum
session target

// I went ahead and set the session target to my ITSP’s URL, just so that you can see how to format with a domain name rather than an IP address.

Here you can see the results of our dial-peers:

If you’ve been following along, this should be what your voice configurations look like (customized with your IP’s and numbers, of course)


If you’ve been following along building your lab with me, then at this point, the initial lab build is done. We have successfully built a functional CUCM lab with a SIP provider and can send and receive calls across!

It’s not time to sell off the equipment, though. We still have a lot of labbing to do. I plan to post next about using Translator X and the Cisco Collaborations Solution Analyzer online tool to troubleshoot problems. I also plan to make a post about installing Prime Collaboration Deployment, and then another post about using PCD to deploy Cisco Unity, and then configuring Cisco Unity on the lab so that our lab has voicemail capabilities!

Leave a Reply

Your email address will not be published. Required fields are marked *