Last Updated on February 4, 2021 by Jaron Davis
Note: This isn’t a configuration guide to Standard Local Route Groups in your CUCM. This is really more of a document to help you understand how it works. If there is any interest, I may go back and create a document or video showing how to actually build this.
Section 1 – Normal Call Flow
Here is what CUCM call flows look like normally. I’m not going to dig into the nitty gritty, but this is the configurations that you have to set up whenever you set up a new branch office. Generally speaking, you will have 3-5 Calling search spaces. (Branch_A_Local_CSS, Branch_A_LD_CSS, Branch_A_Internal_CSS, Branch_A_International_CSS) Partitions for each CSS. (Branch_A_LD_PT, Branch_A_Local_PT, Branch_A_Emergency_PT, Branch_A_International_PT) Then each partition would contain anywhere from 1 to infinite amounts of Route Patterns. (911, @, 123XXXXXXX, XXXXXXX, 1[2-9]XX[2-9]XXXXXX, etc.) Then each route pattern must reference a route list, which contains route groups that were custom built for each call path needed (sip trunks for main calls and fxo cards for emergency calls if that is how your system is configured), then of course you always have to configure those call paths as well.
Figure 1.1 Normal Call Flow
Section 2 – Understanding the Standard Local Route Group
Utilizing the Standard Local Route Group, we are able to bypass having to build calling search spaces, partitions, route patterns and route lists limiting the amount of configurations in CUCM that have to be built for each individual clinic. We can build one of each of these that references the Standard Local Route Group, and then reuse these over and over and only have to build a Device Pool and 911 Route Group for each branch office. And if you use CER or another e911 solution, you don’t even have to build the 911 route group for each branch office and can include that in your standard local route group.
Here is how the Standard Local Route Group Call Flow works.
Figure 2.1 Standard Local Route Group Call Flow
SLRG Example
Here is a real life example of this working. In this example, all of our branch offices start with the AMG prefix. We are assuming everything is already built and in the device pool, for standard local route group, we have assigned the route group RG_AMG_SLRG_PSTN.
Figure 2.2 SLRG Example Call Flow
Section 3 – Emergency calls utilizing Standard Local Route Group (SLRG)
If you do not currently utilize an e911 solution, and all emergency calls go out of the local gateway via FXO ports, you have to create an additional standard local route group for emergency calls that must also be defined in each Device Pool.
Section 4 – How to configure a new clinic for SLRG
When standing up a new branch office, after building the gateway(s), configuring the FXO ports, and all that fun jazz, configuring the SLRG is easier. We no longer have to build new route patterns, partitions, calling search spaces, and route lists. All we have to do is build a single route group that we will use for emergency calls, build a device pool and assign the standard local route groups, and then assign the phones the new device pool and the already built SLRG calling search space.
Figure 4.1 – Build an emergency Route Group (RG_ClinicName_911)
Figure 4.2 – Build a new Device Pool
- Name the Device Pool.
- Assign it the Default CUCM Group. (Sub-Pub configuration which may change in the future with new subscriber additions)
- Select the branch route group for the Standard Local Route Group.
- Select the 911 Standard Local Route Group for the lrg-emergency-1. (Yours can be named whatever you want)
Figure 4.3 – Assign configurations to clinic phones
- Assign the Device Pool
- Assign the AMG_SLRG_XX_CSS based on user requirements
- Configure phone based on telephone standards documentation
