4.4 Globalized Call Routing & Local Route Group (LRG)

4.4 Globalized Call Routing & Local Route Group (LRG)

In traditional, localized enterprise dial plans, call routing logic is deeply intertwined with physical site geography. Every branch office required dedicated Route Patterns (such as 9.1[2-9]XX[2-9]XXXXXX), custom Route Lists, and unique Partitions to ensure outbound calls egressed that specific site's local gateway. For multi-site enterprises with dozens or hundreds of locations, this model caused an exponential explosion of dial plan objects, fractured Call Detail Records (CDR), and prevented users from redialing missed external numbers from their phone history.

Cisco Globalized Call Routing resolves these scaling challenges by establishing a unified, location-independent dial plan based on the international +E.164 standard, powered by the Standard Local Route Group (SLRG) feature.

---

1. The +E.164 Standardization Framework

ITU-T Recommendation E.164 defines an international public telecommunication numbering plan. In Cisco Globalized Call Routing, every internal Directory Number and external PSTN destination is normalized to full E.164 format with a leading plus sign (+):

$\text{E.164 Format} = \mathbf{+} + [\text{Country Code}] + [\text{National Destination Code / Area Code}] + [\text{Subscriber Number}]$

Examples of Globalized Numbers

• United States (San Jose): +14085550100 (+, Country Code 1, Area Code 408, Local Number 5550100)
• United Kingdom (London): +442079460123 (+, Country Code 44, Area Code 20, Local Number 79460123)
• Germany (Frankfurt): +49691234567 (+, Country Code 49, Area Code 69, Local Number 1234567)
• Australia (Sydney): +61299990123 (+, Country Code 61, Area Code 2, Local Number 99990123)

Core Benefits of Globalized Routing

1. Unified Core Dial Plan: CUCM maintains a single, globalized routing table across all geographic locations, eliminating redundant site-specific patterns.
2. Consistent Call Detail Records (CDR): Billing and reporting systems track uniform +E.164 numbers regardless of which branch placed or received the call.
3. One-Touch Redial / Callback: When an external call arrives, the caller ID is normalized to +E.164 before appearing on the phone screen. When the recipient views missed calls and presses "Call", the phone dials +14085550100 directly, which matches the global routing core without requiring manual digit editing or steering digit prefixes.
4. Linear Multi-Site Scalability: Adding a new remote site requires zero changes to the core route patterns or route lists.

---

2. Standard Local Route Group (SLRG)

In a legacy architecture, if an enterprise operated 50 branch offices, routing outbound PSTN calls required 50 distinct Route Lists (e.g., RL_Site1_PSTN, RL_Site2_PSTN, ..., RL_Site50_PSTN) and 50 distinct Route Patterns in separate site partitions.

Decoupling Patterns from Hardware

The Standard Local Route Group (SLRG) completely decouples dial patterns from physical gateways by introducing a dynamic placeholder into Route Lists:

[Route Pattern: \+!] ---> [Route List: RL_Global_PSTN]
                                     |
                                     v
                       [Standard Local Route Group (Virtual)]
                                     |
                  +------------------+------------------+
                  |                                     |
     (Caller in San Jose DP)                (Caller in London DP)
                  |                                     |
                  v                                     v
      [Resolved Gateway: CUBE_SJ]           [Resolved Gateway: CUBE_LDN]

How SLRG Works at Runtime

1. An administrator creates a single global Route Pattern (e.g., \+! or 9.\+!) pointing to a global Route List named RL_Global_PSTN.
2. Inside RL_Global_PSTN, instead of selecting a specific physical Route Group, the administrator selects the built-in virtual entity: Standard Local Route Group.
3. On each branch's Device Pool (e.g., DP_SanJose, DP_London), the administrator maps the virtual SLRG to that site's actual physical Route Group under the Local Route Group drop-down menu:
   • DP_SanJose: Local Route Group = RG_SanJose_Gateways
   • DP_London: Local Route Group = RG_London_Gateways
4. When an endpoint in San Jose initiates an outbound call to +12125550199, CUCM matches \+!, routes to RL_Global_PSTN, inspects the calling phone's Device Pool, resolves SLRG to RG_SanJose_Gateways, and sends the call out the local San Jose gateway.
5. When an endpoint in London dials the exact same number, CUCM resolves SLRG to RG_London_Gateways and routes out the London gateway.

---

3. Egress Localization

While CUCM processes and routes calls internally using +E.164, external PSTN carriers rarely accept a leading + sign or uniform international formatting for local calls. For example, a local carrier in Dallas may require 10 digits (2145551234), while long-distance requires 11 digits (12145551234), and international requires 011 prefixed before the country code.

Egress Localization transforms globalized +E.164 numbers into carrier-mandated formats at the egress gateway or trunk using Called Party Transformation Patterns.

Localization Configuration via Called Party Transformation CSS

Localization patterns are assigned to partitions and associated with the egress trunk/gateway via a Called Party Transformation CSS:

Because localization transformation patterns reside in site-specific partitions applied to each site's gateway, each branch formats digits to suit its local carrier without impacting other branches.

Emergency numbers are normally not globalized. A dedicated 911 (and 9.911) route pattern with Urgent Priority points to a route list containing the Standard Local Route Group, so the call leaves through the caller's local gateway with the local emergency number intact.

---

4. Inbound Globalization and One-Touch Redial

PSTN carriers deliver incoming calls with disparate number formats depending on circuit type (PRI, SIP, BRI) and the nature of the call (Subscriber, National, International, or Unknown).

Inbound Globalization Mechanics

To achieve true end-to-end globalization, numbers must be converted to +E.164 at the ingress boundary before entering CUCM Digit Analysis:

• Gateway / Trunk Ingress Settings: On SIP trunks or MGCP/H.323 voice gateways, administrators configure prefix rules based on ISDN Numbering Plan Indicator (NPI) and Type of Number (TON), or apply an Inbound Calling Party Transformation CSS.
• Mapping Carrier TON to +E.164:
  • If TON = National (e.g., delivered as 4085550100 in the US): Prefix +1 -> +14085550100.
  • If TON = International (e.g., delivered as 442079460123): Prefix + -> +442079460123.
  • If TON = Subscriber (e.g., delivered as 7-digit 5550100): Prefix +1408 -> +14085550100.

The One-Touch Redial Lifecycle

Inbound globalization and outbound localization create a seamless user experience:

1. An external customer (4085550199) calls an enterprise employee.
2. The ingress gateway globalizes the caller ID to +14085550199.
3. The employee misses the call; the Cisco IP phone Call History logs +14085550199.
4. Later, the employee opens Call History and presses Call.
5. The phone dials +14085550199.
6. CUCM digit analysis matches globalized Route Pattern \+!.
7. The Route Pattern directs the call to RL_Global_PSTN, which evaluates Standard Local Route Group.
8. The employee's Device Pool resolves SLRG to the local branch CUBE.
9. The branch gateway's Called Party Transformation Pattern strips +1 to present 4085550199 to the local carrier.
10. The call connects immediately—requiring zero digit editing by the user.

---

5. End-to-End Call Lifecycle Comparison