If you want to sign up for VoIP.ms, you can get $10 worth of credits for free by clicking this link. Setting up a DID and making test calls is less than $10, so it would essentially be free for you by using my referral link! https://voip.ms/en/invite/MjY1NTkz
There are a few things we need to configure before we can start making phone calls. Let’s start with the CUCM side.
Before we get into the actual configurations, here are a few tips:
- Be sure to turn on services in the serviceability page.
- Naviagte to System > Enterprise Parameters and set Enable Dependency Records to True. This will allow you to view dependencies in call manager. I’m not sure why this isn’t just the default behavior, you would think it would be. But oh well, now you have it turned on.
Time to configure CUCM for a call
I’ll try to explain as much as possible for each section here in case you’re new, but feel free to comment if you have any confusions (or corrections) and I’ll respond as quickly as I can.
Device Pool: A device pool is a logical grouping of devices. It allows you to give specific configurations to a device or group of devices. We won’t deep dive into the device pool right now, but there’s a good amount you can do with it. First let’s get the device pool made. Navigate to System > Device Pool and click Add New. We will give it the name HomeLab_DP and click set everything else to default for now. Click save, and that’s all we’re going to do for now with the Device Pool.
Partitions: Next let’s create our partitions. Partitions are logical groupings of directory numbers. For example, you want a partition for your internal extensions that will hold only them. Then another partition of external routes, possibly even multiple external route partitions depending on how you want to configure your system to manage control of who can call who. As you can see in the diagram at the top, we are only going to make two partitions, an internal and an external. This will probably change in the future, but for now it works to get the lab started.
Navigate to Call Routing > Class of Control > Partition and click on the Add New button. I’m going to deviate slightly from my original plan and just make an internal and external partition. That will suffice for now. Obviously, in the real world, you will have more partitions to separate your levels of calling search spaces (i.e. department, internal, local, long distance, international, unrestricted), but for now all we need is a partition for phones and other internal routes, and then a partition for external facing route patterns.
Calling Search Space: Next we will use these partitions to create two Calling Search Spaces. A calling search space is how we give a device permission to make a call. We add partitions to the calling search space, in hierarchical order, to let the system know what that device can dial. The top most partition in a calling search space gets checked first, and then so on down the list. If you have two exact matches, the one in the higher partition gets selected.
Navigate to Call Route > Class of Control > Calling Search Space, and click Add New. First let’s create the internal calling search space. This will only contain the internal partition so that the devices assigned this calling search space can only call other internal directory numbers. Assign the name, then select the Internal partition in the Available Partitions list, click the down arrow, and it will fall down to the Selected Partitions list. Easy as that, click save.
You will see Add Successful. So go ahead and click the Copy button this time and we will build our external calling search space. Once we have hit the copy button, change the name and then drop down the external partition, but do not delete the internal partition. For good house keeping, lets keep this in the right order and put Internal first, and External second.
Route Pattern: Note, we could go straight to building our Route Pattern and not build a route group or route list and just assign our SIP trunk directly to the route pattern… but for learning sake, let’s go ahead and build all that. So we will revisit route patterns soon.
Keep in mind, at this point, we should have our route path, in this case a SIP Trunk to the CUBE but could also be a PRI or even a simply POTS coming out of an FXO port, already built. So if you haven’t gotten there yet, jump over to the post about configuring the CUBE and get that set up!
Route Group: A route group is a logical grouping of call paths, referred to as Devices in CUCM. These call paths are your SIP trunks, PRI’s, BRI’s, FXO’s, FXS’s, or anything to that nature. Navigate to Call Routing > Route/Hunt > Route Group and click Add New. Go ahead and give your Route Group a name, something descriptive. I’ll go with HomeLab_SIP_RG. You have two options for Distribution Algorithm, Top Down or Circular. These are pretty self explanatory, but top down means it starts at the top of the list for every call and will only go down the list if there is a failure at a higher prioritized device. Circular means it will start at the top of the list, and then each call will move to the next group member. Nine times out of ten you will use Top Down. As of right now we only have a single available device, and that’s our SIP trunk that we built in the CUBE post, so let’s select that and click Add to Route Group, then click save.
Route List: The Route List is the list of route groups. This is useful because often times you will have multiple route groups that need to be assigned to a route pattern, so the route list facilitates that. Navigate to Call Routing > Route/Hunt > Route List and click Add New. You will first be asked to give the Route list a name and Cisco Unified Communications Manager Group (CUCMG). We don’t have a CUCMG yet, and have no need for one at the moment, so we will just set it to the Default, then click save.
Now we need to add our route group, so go ahead and click on the “Add Route Group” button and you will be taken to another page to select your route group. Simply click the Route Group dropdown list and select your SIP trunk, then click save to go back to the route list configuration. Once you see it in the Selected Groups list, click save. If you haven’t built your SIP trunk already, you should probably go back to my post about building the CUBE<–>CUCM SIP trunk.
Route Pattern: Seriously this time. Earlier we built our external partition. There will be exactly one number in this external partition, and that is our external route pattern, and you’re going to be surprised how simple it’s going to be. Go ahead and navigate to Call Routing > Route/Hunt > Route Pattern, and as always, click Add New.
Ok, are you ready for this? Here is our SUPER complex Route Pattern…. wait for it……………… @.
No seriously, that’s it! The @ symbol is a wildcard in CUCM that represents nearly any north american number plan route pattern. It’s the equivalent of your standard 7 or 10 digit phone number.
Now generally in a business setting, you would preface this with a nine and a period and then set it to strip away everything before the dot so that you can control outbound calls, but since this is a home lab, I’m going to bypass that little bit and just give it straight dialing. I don’t really feel like I need to dial 9 to call out.
So go ahead and throw in your @ symbol for route pattern. Lets put it in the external partition, give it a description, and then define the numbering plan as NANP. Next we will assign the route list we just built for the Gateway/Route List field, select the dial for Route this Pattern (of course?) and then give it the Call Classification for OffNet. We want to set this call classification to ensure external calls have restrictions, such as specific call transfers, so that you can’t transfer an external call to another external call, thereby facilitating and processing a call that no longer has anything to do with your system except using processing resources. Finally…. you guessed it, click save.
Now we have our CUCM side for an outbound call, but we aren’t done yet. We still need to configure our CUBE to be able to process the call and we have to configure our inbound call, too. Luckily the inbound part is much easier. Let’s go ahead and take a quick look at the inbound side on CUCM.
We are going to use a translation pattern to… well… translate the inbound called number into one our extension, or better yet, it could be even multiple extensions. But I’ll take about that more in a bit.
Translation Pattern: As the name suggests, the translation pattern will translate the inbound called number to a number within the system. We could avoid this step if we just wanted to assign the full 10 digit phone number to our phone, so in this case 618-714-1234 would be assigned directly to my phone, and then the SIP trunks calling search space would have the partition where line 1 (6187141234) is. But for the sake of learning, let’s just build a translation pattern.
Navigate to Call Routing > Translation Patterns and click Add New. We will put our full 10 digit DID number assigned by Voip.ms as the translation pattern. This is telling CUCM that this is the number to expect to receive as the called number. We will place this in our internal partition. Often times in a real environment, you will put your translation pattern in it’s own partition, but this is a lab and is meant to be simple. Set your calling search space to internal_css (we don’t want to mistakenly send this call back out to the PSTN at any point), select the Route this pattern radio dial, and then finally under Called Party Transformations we are going to set our Called Party Transformation Mask, which is the internal extension we want this DID to translate to. Referencing the link from earlier, you can configure wildcards in both the translation pattern and transformation mask, but we are just going to do a 1-for-1 transformation for now, so that this DN only comes into my CIPC phone.
Now we have CUCM configured for both inbound and outbound calls!