When deploying a multisite with centralized call processing across multiple countries, the digit manipulation can be complex, in this scenario US Site as HQ, GE Site in Germany and AU Site in Australia use different dial plan.
We need to unified the dial plan in a globalized format +164 so that the employees when they move between Sites (Countries), they still use the dial plan of their country or the (+) as the international code.
Globalization is there to unify the dial plan in order to improve the user experience and simplify the dial plan, troubleshooting and management for the administrator with a single route pattern \+!.
To call the Phone located in UK, a user should use different format of the PSTN Number, depending the cluster where the user is located, because each country use its own PSTN Access Code and International Code for example:
Countries in EUROPE, users should dial a “0” for PSTN Access Code, followed by “00” for an international call.
In USA, users should dial a “9” for PSTN Access Code, followed by “011” for an international call.
In Australia, users should dial a “0” for PSTN Access Code, followed by “0011” for an international call.
In this example:
From Cluster USA, user should dial 9-011-441519988776
From Cluster EU GE, user should dial 0-00-441519988776
From Cluster AUS, user should dial 0-0011-441519988776
With traditional dial plan approach, in each cluster you need the appropriate and different route pattern for international calls.
In the Cluster USA:
We need a route pattern as follow
Route Pattern 9.011! pointed to the local Gateway.
In the Cluster AUS
We need a route pattern as follow
Route Pattern 0.0011! pointed to the local Gateway.
In the Cluster EU GE
We need a route pattern as follow
Route Pattern 0.00! pointed to the local Gateway.
The conclusion is that you need a separate route patterns in each site and country.
Now if you have multiple sites distributed over different countries, you will get a different international access codes, also to cover the overall numbering plan within a single country, you may need more route pattern.
Some countries have complex numbering plan, Australia is a great example, let’s say if you estimate 10 routes patterns to cover the numbering plan of given country, then for 100 sites in single cluster, you need 1000 route patterns.
This result is a VERY large dial plan with hundreds or thousands of route patterns, route lists, and route groups to deal with all the variations.
This is not good.
The solution is to use the concept of Globalization based on the E.164 numbering plan as the main dial plan format. E.164 is the global numbering plan. It defines the unique country codes for all countries and specifies that if a number starts
with the “+” sign, then what is expected to follow is a valid country code, followed by a number that defines an individual user within that country.
If we come back to our example, When using globalization, a user dials +441519988776 to reach the Phone in UK, regardless the location of the user, from USA, from EU GE or AUS, all what you need is single Route Pattern: \+!
You obtain a simplification of you dial plan, compared to the traditional dial approach.
From the users s’perspective, the globalization should be transparent.
How a dialed digits like 9-011-441519988776, 0-00-441519988776 or 0-0011-441519988776 can match the single Route Pattern \+! ?, if you dont use a tool like the translation pattern, the previously dialed digits will never match the globalized Route Pattern.
Here comes the Translation Pattern in rescue, the Translation Pattern will be used to accommodate local dialed digits and translating them in a form so it matches our magic \+! Route Pattern.
Just an example.
In the Cluster US
The translation Pattern is like this:
Pattern: 9011.!
Called Party Transformation
Discard Digits: PreDot
Prefix Digits: +
The call flow is as follow:
User in USA dials 9-011-441519988776, the CUCM find a matched translation pattern 9011.!, the translation pattern is checked first before the route pattern, the system performs Called Party Transformation, it strips the number 9011 because the PreDot, and prefix “+” sign to the resulting number because the Prefix Digits: +, the result is +441519988776.
The transformation from 9-011-441519988776 to +441519988776 is called GLOBALIZATION. Now the new dialed digits match the globalized Route Pattern \+! because the “+” sign.
PSTN does not recognize the “+” sign. For PSTN to accept the call we need another transformation after the call routing decision, here another powerfull tool comes to rescue, we call it Transformation Pattern.
Transformation Pattern is like Translation Pattern, it is used for Digit Manipulations for the Called Party or Calling Party, but the difference is magic!
Translation Pattern is applied before the call routing decision through Route Pattern, while the Transformation Pattern is applied after the call routing decision, in the Gateway configuration of the CUCM, it seems logic because a call routing decision is made, this means a Gateway or a Trunk SIP is selected, here under the Gateway or the Trunk SIP the Transformation Pattern is applied through CSS and Partition.
Our Called Transformation Pattern looks like this:
Called-Party Transformation Pattern
Pattern: \+.!
Partition: From-US-PT
Called Party Transformation
Discard Digits: PreDot
Prefix Digits: 9011
The resulting of the Transformation Pattern is:
The system strips the “+” sign because the Discard Digits PreDot from the number +441519988776, we get 441519988776, then the System prefix 9011 because the Prefix Digits 9011.
The resulting is 9011441519988776.
That’s magic, the user dials 9011441519988776 then the System Globalizes the dialed digits using the Translation Pattern to obtain +441519988776, the resulting pattern will match our magic Route Pattern \+!, then select the local gateway and the
Transformation Pattern will transform this number to the origin dialed digits so that the call can be routed through PSTN.
Translation Pattern is applied to globalize the number so that the call can be routed internally in the system.
Transformation Pattern is applied to localize the number so that the call can be routed externally in the PSTN.
Still the call to 9011441519988776 cannot be routed in the PSTN because the Access Code 9!, the manipulation is simple, if your local Gateway is an H323 gateway, you just use the default digit strip under the dial peer that routes the PSTN Calls 9T.
Globalization also simplify features such as device mobility, AAR (Automated Alternate Routing), TEHO (Tail Hop End Off) and Class Of Service.
Device Mobility:
With Globalization, line CSS of US phones provides access to translation patterns that convert localized call at the US phone (American format) to global +E.164 format. UK phones have access to translation patterns that convert European numbers to global +E.164 format.
A single PSTN route pattern (\+!) is configured; it is in a partition System that is accessible by all translation patterns CSS System.
When a US user roams to the UK Site, the line CSS is not modified; the device CSS is configured at the phone but the line CSS takes precedence. The device mobility groups are set.
As a result, there is effectively no change in matching the translation patterns.
When the US user roams to UK Site, he still uses American dial rules (like at home) 901161270109999. The number is converted to international format by translation patterns +61270109999 and matches the GLOBALIZED PSTN route pattern (\+!). The route pattern refers to a route list that is configured to use the default local route group. The default local route group is taken from the roaming device pool. Therefore, if the phone is physically located in the US Site, the local route group is US-RG that points to US Gateway; if the phone is roaming to the UK Site, the local route group is UK-RG that points to UK Gateway. As a result, the local gateway is always used for a PSTN call without forcing the users to adapt to a dial plan for each country.
The US user dials always 901161270109999 regardless its physical location either in US Site or UK Site and uses the local Gateways US Gateway and UK Gateway respectively.
The same logic for UK user, if the phone is physically located in the UK Site, the local route group is UK-RG that points to UK Gateway; if the phone is roaming to the US Site, the local route group is US-RG that points to US Gateway. As a result, the local gateway is always used for a PSTN call without forcing the users to adapt to a dial plan for each country.
The UK user dials always 00061270109999 regardless its physical location either in UK Site or US Site and uses the local Gateways UK Gateway and US Gateway respectively.
Automated Alternate Routing AAR:
AAR allows calls to be rerouted through the PSTN by using an alternate number when Cisco Unified Communications Manager blocks a call due to insufficient location bandwidth caused by CAC. With AAR, the caller does not need to hang up and redial the called party. Without AAR, the user would get a reorder tone and the IP phone would display “Not enough bandwidth.”
AAR applies to centralized call-processing deployments. For instance, if a telephone in a company HQ calls a telephone in branch and the available bandwidth for the WAN link between the branches is insufficient (as computed by the CAC mechanism), AAR can reroute the call through the PSTN. The audio path of the call would be IP-based from the calling phone to its local (HQ Router) PSTN gateway, TDM-based from that gateway through the PSTN to the Branch Router gateway, and IP-based from the Branch Routergateway to the destination IP phone.
AAR is transparent to users. It can be configured so that users dial only the on-net (for example, four-digit) directory number of the called phone. (No additional user input is required to reach the destination through an alternate network such as the PSTN.)
The CUCM manipulates the called party with the AAR Group using either the External Phone Number Mask or AAR Destination Mask combined with the dial prefix defined under the AAA Group and reroute the call through the PSTN.
To route the call from AAR group HQ-Group to AAR group BR-Group, Cisco CUCM needs to know the digit(s) to dial out to the PSTN and the full PSTN digit string since the digits “4002” will not be recognized by the PSTN, this is retrieved from AAR Prefix Digit and External Phone Number Mask respectively.
In summary, this scenario with two sites located in two different countries requires two route patterns in different partitions, two AAR CSSs, and two AAR groups. In a large multisite deployment across multiple countries, each country has a different numbering plan, the configuration of AAR groups can be relatively fastidious.
Without local route groups, the AAR CSS of US Phones has access to the route pattern 9.011! in partition US-INT-PT that refers to a site-specific route list RL-US, site-specific route group RG-US and local gateway HQ-US.
In the same way, The AAR CSS of UK Phones has access to the route pattern 0.00! in partition UK-INT-PT that refers to a site-specific route list RL-UK, site-specific route group RG-UK and local gateway BR-UK.
With globalization, Cisco CUCM can route international calls to the PSTN in +E.164 format using a + prefix instead of the international code. When you configure the external phone
number mask in this format, no Digit prefixes are required for AAR group and no worries about the international code that should be prefixed. To localize the called party numbers so that the + prefix will be replaced with the appropriate international code, for example for US Phone the + prefix is transformed to 011, for UK Phone the + prefix is replaced by 00, this is done by implementing Called Party Transformation Pattern for each egress PSTN gateway.
When local route group and globalization are implemented, the egress gateway does not need to be selected by site-specific AAR CSS, because the egress gateway is determined by the local route group feature through device pool.
To summarize, when you are using globalization with local route groups, AAR implementation is very simple, you need only a single AAR CSS to route international call through a single route pattern \+! and AAR group without prefix digits are required and applied to all phones, regardless of their physical location.
TEHO Tail Hop End Off:
TEHO is a feature where CUCM uses the PSTN gateway that is closest to the destination as the egress gateway to save PSTN costs, for example we want the calls destined to US PSTN destination to go through the US gateway instead of the UK gateway, TEHO is the solution, we just need to change the dial plan, the call will go through the WAN from the UK Site
to US Site then routed out through the US gateway.
From UK Phone if we call 00014082347788, this PSTN number simulate a PSTN phone in San Jose. The Line 3 : 14082347788 (National-SJ) will ring.
The international call from the UK phone is going through the US gateway US-GW.
The translation pattern 000.! Matches the called number 00014082347788, translates the Called Party Number from 00014082347788 to +14082347788, the translated Called Number matches the route pattern \+1!, this route pattern points to the route list RL-TEHO-RP.
The route list RL-TEHO-US refers to the route group RG-US first then to Standard Local Route Group. The route group RG-US is used as the first choice and points to the US Gateway, as a result the call is routed out through the US Gateway US-GW instead of the UK Gateway UK-GW. At the gateway level, the Called Transformation Pattern \+1.! Strips the the (+) sign and the National Code 1 because the PreDot and Prefix 1 and finally the called number is transformed to 14082347788.
Without the TEHO feature, the international call from the UK Phone to US PSTN (National-SJ) is more expensive because it is routed through the local gateway UK-GW, the call is subject to international charges, with TEHO the UK Phone placed a call to National-SJ is routed through the US Gateway US-GW, the call appears as national and therefore less expensive.
When implementing TEHO across multiple countries with different dial plan, for example US UK and AU in this case, the configuration of TEHO is complex without globalization. With globalized call routing, the TEHO implementation is simplified.
In this scenario, we implement TEHO from UK and AU Sites to US PSTN destinations, the primary path will be the US Gateway and the local gateways UK-GW/AU-GW will be used as a backup if an issues such as IP connectivity via WAN or the CAC is met.
With the Globalization, we have already translation patterns that globalize the Called Party Number to +164 format, a route group and a gateway per site, each route group is already associated to the appropriate device pool and each gateway is configured with a Called Party Transformation Pattern to localize the Called Party Number.
Class Of Service:
Starting from CUCM 10.X, Translation Patterns can use Originator’s Calling Search Space.
It gives the administrators more granularities when implementing Unified Dial Plan with Globalized Call Routing.
By definition the translation pattern is used to match the dialed digits before matching a route pattern, before the CUCM 10X, traditionally the Translation Pattern as the source of call needs a CSS to access the partition of a route pattern for call routing. This means the originating devices or lines CSS is lost and not taken into consideration after digit modification is performed at the translation pattern. The disapointing result is that you lost the caller’s calling privilegeres.With this Option, administrators can control and make sure that the original caller’s calling privileges are maintained after digit manipulation by the translation pattern, the “Use Originator’s Calling Seach Space” check boxes means that the Call Control CUCM will apply the Devices or Lines CSS to determine if the caller can access the route pattern’s partition such as the route pattern for international dialing.
When you use the Globalized Call Routing. This option helps the administrator to configure fewer patterns and makes the scalability very easy.
Class of Service can be implemented in different ways, using the Class of Service with a Globalized Call routing is easy to implement and more scalable using the existence Translation Patterns that globalize the inputs. Translation Patterns can use Originator’s Calling Search Space. It gives the administrators more granularities when implementing Unified Dial Plan with Globalized Call Routing.
When you use the Globalized Call Routing. This option helps the administrator to configure fewer patterns and makes the scalability very easy.
If the translation pattern CSS include the blocked partition of route pattern or it didnt include the blocked partition. The Phones CSS (it does not matter if it includes the blocked partition route pattern) will be replaced by the translation pattern CSS so all phones are treated equally in term of calling privileges.
Using the Originator’s CSS at the translation level, the same translation pattern can be used by all calling parties and the Phones CSS that determines the calling privileges are inherited as a result if Phone 1 has a CSS that includes the blocked partition route pattern, the call is blocked and if phone 2 has a CSS that does not include the blocked partition route pattern, the call is allowed.
Using the Class of Service in a Globalized Call Routing with the Originator’s CSS at the translation level, you can implement granular classes of services easily, you create a specific blocked route patterns, you put them into a partition, then you create a new CSS that includes this partition and the rest of partitions the user can dials, and apply the CSS to appropriate users. As a result regardless how the number is dialed, the translation pattern will globalize the localized user input at the call ingress with the option to use the Originator’s CSS.
For example in a globalized call routing, we want to block one specific country Australia for some users. We need a class of service that does not allow calls to Australia (61) and another class of service that allows calls to all countries.
We can create two routes patterns as follow to exclude call to +61 as follow:
The two route patterns below matche all international numbers except \+61!.
Route Pattern: \+[^6]! in Partiton PSTN-Exclude-AU-PT.
Route Pattern: \+6[^1]! in Partition PSTN-Exclude-AU-PT.
The route pattern below matches calls to Australia.
Route Pattern: \+61! in Partition Australia-PT
Note: these route patterns should be configured with “Route This Pattern” Option.
At the translation pattern we check the Use Originator’s CSS option.
If Phone 1 is allowed to dial all international numbers, it needs a CSS PSTN-CSS that includes both partitions PSTN-Exclude-AU-PT and Australia-PT.
If Phone 2 is allowed to dial all international numbers except Australia country, it needs a CSS PSTN-Exclude-AU-CSS that includes partition PSTN-Exclude-AU-PT.
In a complex deployement with different classes of service, configuring such route patterns is not easy to read. To make it simple, we create a specific blocked route pattern \+61! with “Block This Pattern” option, and we put this route pattern into a partition Block-to-AUSTRALIA-and-SJ-1-PT and we create a CSS Jabber-Limited-CSS that includes this partition.
We have to make sure that the translation patterns that globalizes the user input has the Use originator’ s Calling Search Space checked so that the originating CSS Jabber-Limited-CSS that matches the blocked route pattern is not replaced by the the Translation Pattern’s CSS.
Finally the blocked route pattern should be in +E.164 format. For example to block calls to Australia, we need to use \+61! instead of 901161! because the use can place a call to Australia by dialing +61 instead of 901161!, dialing +61 will match the globalized route pattern \+! that all calls to PSTN.
What if we want to block calls to specific subscriber number 14082347788, using this approach, we can achieve this goal easily, we create a specific route pattern \+14082347788 with “Block This Pattern” option checked (similar with the example block calls to Australia with route pattern \+61! with “Block This Pattern” option checked), and we put it in the same partition Block-to-AUSTRALIA-and-SJ-1-PT as \+61! or in different partition, depending to the requirements.
