3.14 Globalized Call Routing Examples

This topic describes sample scenarios of globalized call routing.

Emergency Dialing Example

  • Note local emergency numbers (for example, 112 in the European Union, 999 in the United Kingdom, 000 in Australia).
  • Introduce a corporate emergency number (for example, 888) that can be used at all sites (globalized emergency number).
  • Allow local emergency numbers besides corporate emergency number:
    1. Per site: Only the local emergency number is permitted (for example, 112 can be used in the European Union, 999 can be used only in the United Kingdom, and so on).
    2. Globally: All local emergency numbers are permitted at all sites (roaming users can use their home emergency number).
  • Local emergency numbers are globalized to the corporate emergency number (for example, 888) at call ingress by translation patterns.
  • Corporate emergency number is localized at the egress gateway by called-party transformation CSS (for example, 888 is changed to 112 at EU gateway, to 999 at UK gateway, and to 000 at Australian gateway).

In a multisite deployment with centralized call processing, it might be desirable to simplify emergency dialing by introducing a globalized emergency number (or one globalized emergency number for each emergency service).

Having a globalized emergency number allows roaming users who might not be aware of the local emergency dial rules to use a corporate emergency number that is accessible from all sites.

In addition, however, localized emergency dialing should still be supported, so that a user can dial either the locally relevant emergency number or the corporate emergency number.

Here is how to implement such a solution:

  • Introduce one or more corporate emergency numbers.
  • Also, allow localized emergency dialing. It can be limited to local emergency dialing rules per site (for example, an Austrian emergency number can be dialed only from phones that are located in Austria), or you can globally enable all possible local emergency numbers.

    Making all possible local emergency numbers available to all users has the advantage that a roaming user can use the emergency number that is local to the site where the user is located, or the emergency number that the user knows from the home location of the user (for example, a U.K. user dials 999 while roaming in Austria), or the corporate emergency number.

    Note

    Making all possible local emergency numbers available to all users may not be possible because of overlapping dial plans. For example, the emergency number of one country may be identical with the first digits of a valid local PSTN number.

  • If a user dials a localized emergency number, that number is first normalized (that is, translated) to the global corporate emergency number. A route pattern exists only for this corporate emergency number, and you configure the corresponding route list to use the local route group.
  • At the gateway that is used to process the call, you localize the corporate emergency number (the globalized emergency number) by using called-party number transformations at the gateway. This localization ensures that, regardless of which emergency number is dialed, the gateway that sends out the emergency call uses the correct number as expected at this site.
    Note

    In deployments with more complex emergency calls, like in the United States with E911, such a solution is not applicable because there are additional requirements for emergency calls. In such a scenario, the emergency call is routed via a dedicated appliance (Cisco Emergency Responder) that provides additional services such as location awareness.

Emergency Dialing Example (Cont.)

In the example, a corporate emergency number of 888 has been established. In addition, Australian, E.U., and U.K. emergency numbers are supported at all sites of the enterprise. The appropriate numbers (000, 112, and 999) are translated (normalized) to the corporate (global) emergency number 888. A route pattern, 888, exists, which refers to a route list that has been configured to use the local route group. You will consider two sites in this example: one in the European Union and one in the United Kingdom. Each site has its own PSTN gateway (or “GW” in the figure); phones at each site are configured with a site-specific device pool. The device pool of each site has its local route group that is set to a site-specific route group.

You will examine four emergency calls:

  • A U.K. user dials 999 (U.K. emergency number): The dialed U.K. emergency number, 999, is translated to the corporate emergency number, 888. After translation, the 888 route pattern is matched. The route list of the route pattern refers to the local route group. Because the emergency call was placed from a U.K. phone, the local route group in the device pool of the phone refers to the U.K. gateway. At that gateway, a global transformation of the called number (from 888 to 999) is configured. Therefore, the call exits the U.K. gateway with a destination number of 999, which is the appropriate emergency number to be used in the United Kingdom.
  • Any user who is located in the United Kingdom dials 888 (corporate emergency number): Because no local emergency number was dialed except the corporate emergency number, 888, no translation is required. The call immediately matches route pattern 888. The route list of the route pattern refers to the local route group. Because the emergency call was placed from a U.K. phone, the local route group in the device pool of the phone refers to the U.K. gateway. At that gateway, a global transformation of the called number (from 888 to 999) is configured. Therefore, the call exits the U.K. gateway with a destination number of 999, which is the appropriate emergency number to be used in the United Kingdom.
  • An E.U. user dials 112 (E.U. emergency number): The dialed E.U. emergency number, 112, is translated to the corporate emergency number, 888. After translation, the 888 route pattern is matched. The route list of the route pattern refers to the local route group. Because the emergency call was placed from an E.U. phone, the local route group in the device pool of the phone refers to the E.U. gateway. At that gateway, a global transformation of the called number (from 888 to 112) is configured. Therefore, the call exits the E.U. gateway with a destination number of 112, which is the appropriate emergency number to be used in the E.U.
  • An Australian user, currently located at an E.U. site, dials 000 (Australian emergency number): The dialed Australian emergency number, 000, is translated to the corporate emergency number, 888. After translation, the 888 route pattern is matched. The route list of the route pattern refers to the local route group. Because the emergency call was placed from an E.U. phone, the local route group in the device pool of the phone refers to the E.U. gateway. At that gateway, a global transformation of the called number (from 888 to 112) is configured. Therefore, the call exits the E.U. gateway with a destination number of 112, which is the emergency number in the European Union.
    Note

    The Australian user can use an E.U. phone (with an E.U. extension), or use their own device with device mobility enabled, or use an E.U. phone with their own extension (by using Cisco Extension Mobility). In all three scenarios, the emergency call would work fine as described earlier. The reason is that the device pool of the phone will be the E.U. device pool in all three scenarios (with device mobility enabled, the home device pool would be replaced by the roaming device pool), and therefore the local route group is always the EU-GW.

    The only problem would be if the Australian user were using their own device with device mobility disabled. In this case, the local route group would refer to the Australian gateway, and therefore the call would be sent through the Australian gateway instead of through the local E.U. gateway. The localized egress number would be appropriate for an Australian gateway (transformed to 000), so that the user would be connected to an Australian emergency service.

Globalized Call Routing Example: TEHO

The figure shows an example of TEHO when globalized call routing is used.

At the call ingress side, there are three different PSTN dial rules: E.U., U.K., and U.S. The egress gateways also have different requirements. They all require different digit manipulation when you are sending calls to the PSTN.

As long as users are allowed to roam between sites, and TEHO with local backup is in place, users can dial each PSTN destination differently at each site. In addition, if the TEHO path is not available, the local gateway (which, again, can be any of the three) is used for backup. With globalized call routing, you do not have to consider all possible combinations of ingress and egress, but you consider call ingress and call egress independent of each other.

All that you need to configure is translation patterns for each of the PSTN dial rules (E.U., U.K., and U.S.). Then you create TEHO route patterns that refer to the TEHO gateway as the first choice, and to the local gateway as the backup, using the local route group feature. At the egress gateways, you configure the called-party and calling-party transformations, where you do not have to match on all possible input formats again, but on a globalized format only.

Advertisements