Scribd
Upload
243 views4 pages

Simplifying Call Routing with SLRG

This document describes how to use Standard Local Route Groups (SLRGs) in Cisco Unified Communications Manager (CUCM) to simplify call routing to emergency numbers like 911 across multiple sites. An SLRG allows creating a single route pattern and list to route 911 calls to the appropriate local gateway based on the calling device's location, rather than needing separate configurations per site. This is done by associating each site's device pool with its corresponding local route group, which specifies the local gateway. So regardless of the number of sites, a single route pattern can efficiently route 911 calls to the correct local responder based on where the call originates from.

Uploaded by

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

Topics covered

  • Routing Hierarchy,
  • Egress Gateways,
  • Telephony Solutions,
  • Emergency Call Routing,
  • Telecom Systems Integration,
  • Call Flow,
  • System Scalability,
  • Configuration Simplification,
  • Routing Optimization,
  • Telecom Best Practices
243 views4 pages

Simplifying Call Routing with SLRG

This document describes how to use Standard Local Route Groups (SLRGs) in Cisco Unified Communications Manager (CUCM) to simplify call routing to emergency numbers like 911 across multiple sites. An SLRG allows creating a single route pattern and list to route 911 calls to the appropriate local gateway based on the calling device's location, rather than needing separate configurations per site. This is done by associating each site's device pool with its corresponding local route group, which specifies the local gateway. So regardless of the number of sites, a single route pattern can efficiently route 911 calls to the correct local responder based on where the call originates from.

Uploaded by

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

Topics covered

  • Routing Hierarchy,
  • Egress Gateways,
  • Telephony Solutions,
  • Emergency Call Routing,
  • Telecom Systems Integration,
  • Call Flow,
  • System Scalability,
  • Configuration Simplification,
  • Routing Optimization,
  • Telecom Best Practices

Standard Local Route Groups

Scenario: Phones at the HQ/BR1/BR2/BR3 site want to make a call to 911. All
phones are registered to CUCM which sits at the HQ site. How would you achieve
this? (Think before reading ahead)

One of the many solutions that you can devise is:

1. Create a Route Pattern for every site (HQ/BR1/BR2/BR3). The Route Pattern
will point to 911 and each route pattern will be in its own partition.
2. The Route Patterns should eventually point to a local router (i.e. the Route
Pattern for 911 in the HQ partition should point to the HQ router as the
egress gateway. If the Route Pattern is pointing to some other GW as the
egress GW, the police/fire brigade/ambulance will arrive at the other site
instead of the HQ site and the HQ building will burn down ).
3. The phones should have a CSS that contains the correct partition. Hence,
BR1 phones should have access to the Route Pattern created for BR1. The
configuration will look something like this:

RP - - - 911 - - - (HQ partition) - - - Points to RL_HQ


RP - - - 911 - - - (BR1 partition) - - - Points to RL_BR1
RP - - - 911 - - - (BR2 partition) - - - Points to RL_BR2
RP - - - 911 - - - (BR3 partition) - - - Points to RL_BR3

For each Route Pattern, a Route List/Route Group/Endpoint hierarchy is usually


configured. So you have:

RL_HQ - - - RG_HQ - - - HQ_GW


(and so on for the other sites)

HQ phones - - - CSS with HQ partition


BR1 phones - - - CSS with BR1 partition
BR2 phones - - - CSS with BR2 partition
BR3 phones - - - CSS with BR3 partition

Messy isnt it? Imagine that you need to set this up for 200 sites and for multiple
dialling patterns. (i.e. multiple numbers).

This is where Standard Local Route Groups come into the picture. An SLRG
simplifies the way in which you create Route Patterns for strings that are
commonly dialled in a particular phone system. Here is what you would do:
1. Create a Route Group for each site, just like before (RG_HQ, RG_BR1,
RG_BR2 and RG_BR3). Put the corresponding local gateway in the Route
Group.

2. Create a SINGLE Route List (RL_SLRG) and choose the Route Group as
Standard Local Route Group from the drop down.
3. Create a SINGLE Route Pattern for 911 in a partition which all phones that
need to call the number have access to (or leave it in the none partition).

Once done, all you need to do is go to the Device Pools of the sites (DP_HQ,
DP_BR1, DP_BR2, DP_BR3) and associate the Route Group created for the site in
the Local Route Group drop down. (Make sure that the Device Pools are
associated with the correct phones).

You are done!! Now, whether you have 2 sites or 200 sites, it doesnt matter.
There is no need to create more Route Patterns. A single route pattern and a
single route list takes care of the call routing to the 911 number for ALL the sites.
How this works follows:

SCENARIO 1
1.
2.
3.
4.
5.

IP Phone at HQ (in DP_HQ) goes off hook and dials 911


CUCM sees that RP 911 in the <none> partition can be reached
CUCM checks the RL associated with RP 911 (this points to RL_SLRG)
RL_SLRG has Standard Local Route Group selected as the Route Group
CUCM checks the Device Pool of the ORIGINATING device. In this case it is
DP_HQ.
6. DP_HQ has RG_HQ as the Standard Local Route Group and this points to
the HQ_GW.
7. The call goes out the HQ_GW. Police/fire brigade/ambulance arrives at the
HQ site and everyone is saved!!!!!!!! YOU ARE A HERO!

SCENARIO 2
1. IP Phone at BR3 (in DP_BR3) goes off hook and dials 911
2. CUCM sees that RP 911 in the <none> partition can be reached. This is
the same RP used in the previous scenario.
3. CUCM checks the RL associated with RP 911 (this points to RL_SLRG). This
is the same RL used in the previous scenario.
4. RL_SLRG has Standard Local Route Group selected as the Route Group
5. CUCM checks the Device Pool of the ORIGINATING device. In this case it is
DP_BR3.
6. DP_BR3 has RG_BR3 as the Standard Local Route Group and this points
to the BR3_GW.
7. The call goes out the BR3_GW. Police/fire brigade/ambulance arrives at the
BR3 site and everyone is saved!!!!!!!! YOU ARE STILL A HERO!!

SCENARIO 3
1. IP Phone at BR100 (in DP_BR100) goes off hook and dials 911
2. CUCM sees that RP 911 in the <none> partition can be reached. This is
the same RP used in the previous scenarios.
3. CUCM checks the RL associated with RP 911 (this points to RL_SLRG). This
is the same RL used in the previous scenarios.
4. RL_SLRG has Standard Local Route Group selected as the Route Group
5. CUCM checks the Device Pool of the ORIGINATING device. In this case it is
DP_BR100.
6. DP_BR100 has RG_BR100 as the Standard Local Route Group and this
points to the BR100_GW.
7. The call goes out the BR100_GW. Police/fire brigade/ambulance arrives at
the BR100 site and everyone is saved!!!!!!!! EVERYONE IS HAPPY!

Even though we have taken the example of the 911 pattern, this can apply to
any pattern and is extremely helpful in reducing the number Route
Patterns/Route Lists created.

Hope this helps!

You might also like