Case Studies

This section of the document describes how all the components described in this chapterroute patterns, route filters, calling and called party transformations, translation patterns, calling search spaces, and partitionswork together to allow you to configure complex routing.

This section covers the following topics:

• "Routing by Class of Calling User" discusses routing by class of calling user. This section shows you how to define three different degrees of external access so that your most trusted users can place all classes of calls, your average users can place a more restrictive class of calls, and your untrusted users can place only the most restrictive calls.
• "Routing by Geographic Location (or What the External Route Plan Wizard Builds)" discusses routing by geographic location in a geographically distributed area. It describes both toll restriction and scenarios where toll-restriction calls must fall back to the PSTN because of fully utilized or nonfunctional gateways.

Routing by Class of Calling User

A common requirement in telephone networks is to be able to restrict the types of calls that users can make. For example, a company executive might have unrestricted dialing privileges: emergency, local, long distance, and international calls are equally accessible. On the other hand, a phone in a lobby might be able to call only internal extensions and emergency numbers. In between these extremes are those phones that you want to prevent from accessing Caribbean area codes and toll services (such as 900 services).

Configuring calling user restrictions uses several of the concepts this chapter introduces:

• Naturally, user restrictions require route patterns.
• Typically, the numbers that you want to restrict are those in the PSTN. This requirement means that the call routing component must be able to distinguish between types of calls to the PSTN, which, in turn, indicates the use of route filters.
• If you want to apply different restrictions to different users, you must use calling search spaces and partitions.

Figure 2-30 provides a representative example that you can refer to when configuring your dial plan to deny certain types of calls to certain users. It concerns itself solely with calls to the PSTN.

Figure 2-30. User Restrictions

Company ABC requires three levels of outside calling privileges. Executives have no restrictions on calls they can place. Office personnel can place calls to emergency numbers, local numbers, and long distance numbers, but they cannot place international calls or calls to 900 numbers. Lobby phones can place calls only to emergency numbers.

Company ABC also has a single gateway, which employees of all levels use for outside calls. This gateway is not in a route list. The access code for calls to the PSTN is 9, and CallManager strips this access code before offering the call to the PSTN.

User-Restriction Configuration Process

The first step in configuring the user restrictions is to define route pattern and filter combinations for the different levels of PSTN access.

Executives have the simplest route pattern configuration, because they can call all PSTN numbers. The route pattern is 9.@ (which matches 9 followed by any valid number in the North American numbering plan). You must strip the initial 9 before CallManager offers the call to the gateway, so associate digit discarding instructions of PreDot with the route pattern. Assign this route pattern to partition Executives. Table 2-54 shows the route pattern configuration information for an executive's PSTN access.

Office personnel have a more complex route pattern configuration. Office personnel can call some but not all PSTN numbers. This restriction requires the use of route filters.

Office personnel cannot dial two types of numbers. The first type, international numbers, is easy to deal with. Defining the route filter NonInternationalCalls with value INTERNATIONAL-ACCESS DOES-NOT-EXIST and associating it with route pattern 9.@ instructs CallManager to route all PSTN calls that do not contain the North American international access code of 011. This route pattern is assigned to partition OfficePersonnel.

Preventing office personnel from dialing numbers with the area code 900 is trickier. Defining a route filter with value AREA-CODE == 900 does the exact opposite of what is intended: Users can dial only those PSTN numbers where the area code is 900. But there is no not-equals operator, so how does one block 900 numbers?

The solution lies in closest match routing. Rather than attempting to configure a single route pattern and filter that accomplishes all of the restrictions, you can define an additional route pattern and route filter to give restricted numbers special treatment. In this case, if you define the route filter 900Numbers with value AREA-CODE == 9XX, associate it with route pattern 9.@ in partition OfficePersonnel, and then check the Block This Pattern check box, when an office member dials a number with an area code of 900, closest match routing will cause the restrictive route pattern (9.@ where AREA-CODE == 900) to match in preference to the more general route pattern (which does not constrain AREA-CODE at all). As a result, CallManager applies the blocked treatment. Calls to other area codes, however, do not match the restrictive route pattern at all, so those calls go through just fine. Table 2-55 shows the route pattern configuration information for an office member's PSTN access.

Lobby phones have the most restrictive routing restrictions of all; they can call only 911. Defining the route filter 911Calls with value SERVICE == 911 and associating it with route pattern 9.@ instructs CallManager to route all PSTN calls that are specifically intended for 911. You must strip the initial 9 before CallManager offers the call to the gateway, so associate digit discarding instructions of PreDot with the route pattern. Assign the route pattern to partition LobbyPhones. Table 2-56 shows the route pattern configuration information for a lobby phone's public access.

The configuration is not completed. Although the route patterns on the gateway have been configured properly, the calling users have not. You must define calling search spaces for the calling users. Furthermore, it is a good idea to put your phones' extensions within their own partition. For this purpose, define partition ABC for the phones within the enterprise. Table 2-57 lists all defined partitions and a short description of the types of route patterns each contains.

To complete the configuration, you must define the calling search spaces defined in Table 2-58.

Calling search space Executives contains partitions ABC and Executives, which permit executive phones to call internal extensions and all PSTN numbers; calling search space OfficePersonnel contains partitions ABC and OfficePersonnel, which permits access to internal extensions and noninternational, nontoll PSTN numbers; calling search space LobbyPhones contains partitions ABC and LobbyPhones, which permits access to internal extensions and emergency PSTN numbers. Finally, it is important not to forget the gateway, which needs to be able to offer PSTN calls to the users. Calling search space Gateway provides access to internal extensions. Assigning the appropriate partition and calling search space to each phone and to the gateway completes the configuration and provides each user with the appropriate level of PSTN access. Figure 2-31 presents a representation of the final configuration.

Figure 2-31. User Restriction Configuration Diagram

For explanatory purposes, this section uses a naming convention for the gateway partitions designed to indicate which users can call which route patterns. The section "Routing by Geographic Location (or What the External Route Plan Wizard Builds)" presents a different naming convention that indicates type of call permitted that is more flexible in the long run.

Routing by Geographic Location (or What the External Route Plan Wizard Builds)

A major advantage of routing voice over an IP network is that it allows users served by one Local Access and Transport Area (LATA) to access gateways in a different LATA without actually having to make a call through the PSTN. This can allow you to manage the costs of your telephone network by bypassing the PSTN when possible.

The External Route Plan Wizard is an automated tool that allows you to set up a toll-bypass configuration in North America more easily. It is ideal if you have a distributed enterprise connected by a very high bandwidth, very redundant data network with gateways in different call routing areas.

The External Route Plan Wizard asks you about the locations in which your gateways reside and asks you to describe what area codes are local to each gateway. It also asks you general questions about how you want calls to be routed. Given this information, it organizes your gateways into route groups and puts the route groups into many different route lists. With each route list, the External Route Plan Wizard associates a narrow range of calls, for instance, emergency calls or international calls. Then, the External Route Plan Wizard sets up six levels of user access per routing area in your enterprise: emergency calls only; emergency and internal calls only; emergency, internal, and local calls only; emergency, internal, local and toll-bypass calls only; emergency, internal, local, and long distance calls only; all calls, including international. Once the External Route Plan Wizard finishes, you can browse to each phone in your enterprise, assign the appropriate calling search space, and expect calls from your phones to route appropriately.

The chief drawback of the External Route Plan Wizard is that it generates immense amounts of data. Each gateway in your organization gets its own route group, each location generates six route lists, and each location generates seven partitions and six calling search spaces.

This section simply describes what the External Route Plan Wizard does to set up a toll-bypass configuration. If you are unable to use the External Route Plan Wizard because you run a non-North American site, if you simply want to create a leaner, meaner version of a geographically aware routing plan, if you run a site that manages multiple tenants, or if you simply want an explanation of the prodigious output that the External Route Plan Wizard generates, then keep reading.

A toll-bypass configuration draws on almost every one of the components described in this chapter:

• Naturally, a toll-bypass configuration requires route patterns.
• A toll-bypass configuration requires the dial plan to be able to distinguish types of outside calling. For instance, emergency calls must route out only those gateways local to the calling user. Local calls should preferentially route out gateways local to the calling user. On the other hand, calls to other LATAs where you manage gateways need to route preferentially to those remote gateways. Finally, long distance and international calls can route out any gateway in the network. The need to distinguish between types of PSTN call requires the use of route filters.
• When a user dials a long distance number that routes to a remote gateway, usually the number the user dialed is not a valid number when dialed from the remote gateway itself. From the user's point of view, the number is a long distance number, so CallManager should accommodate a long distance numbering format. For instance, North American users typically dial 11 digits when dialing another geographic region. But the same destination as dialed by a user in the remote location is either seven or ten digits. Allowing the call to route properly once it reaches a remote location requires using called party transformations.
• Calling number is also an issue when a call crosses LATA boundaries. If a user in Boston places a toll-bypass call through a gateway in Orlando, how should CallManager represent the calling number? If it presents a Boston calling number, the Orlando central office may complain, because it does not recognize the number of the caller. It is often necessary either to transform the calling number to an attendant number in the remote location or to alias the calling number to a number that is valid in the remote location. These modifications require the use of calling party transformations.
• If locations contain more than one gateway, route lists provide a way to maximize gateway usage.
• Users in different locations need to reach different locations, even if they dial the same digit strings. For instance, a user in Dallas who dials 911 needs to reach Dallas emergency services, while a Boston user needs to reach Boston emergency services. Giving different users different views of the same network requires the use of calling search spaces and partitions.

Geographical Routing Problem Description

Figure 2-32 provides a representative example that you can refer to when configuring your dial plan to handle geographical routing configurations.

Figure 2-32. Geographical Routing Example

Company ABC has two locations, one in Dallas and one in San Jose. A high-bandwidth, highly redundant IP network connects the sites. Each site runs CallManager. CallManagers are clustered. Where the devices register is not relevant for routing purposes; a San Jose phone registered to the Dallas CallManager still physically resides in San Jose and routes as a San Jose phone.

There are three levels of PSTN access. Lobby phones can dial only internal extensions and emergency numbers. Office personnel can dial local and long distance calls, in addition to internal extensions and emergency numbers. Executives can dial all of the aforementioned types of calls, plus international calls.

The San Jose site has many phones, but this example concentrates on just four phones. 30000 is the attendant (who has office member access privileges), 31000 is a lobby phone, 31100 is a office member phone, and 31200 is an executive phone. One gateway in San Jose provides access to the PSTN. The gateway is connected to the 555 exchange in the 408 area code. The PSTN has assigned a range of 5000 to 5999 to the San Jose site. For purposes of this example, users in San Jose dial seven digits to make local calls.

The Dallas site also has many phones, but this example only needs to describe four of them. 40000 is the attendant (who has office personnel access privileges), 41050 is a lobby phone, 41150 is an office member's phone, and 41250 is an executive phone. A gateway in Dallas provides access to the PSTN. The gateway is connected to the 555 exchange in the 972 area code. The PSTN has assigned a range of 2000 to 2999 to the Dallas site. Users in Dallas dial 10 digits to make local calls.

Outbound calls route according to Table 2-59.

Building a toll-bypass configuration occurs in two phases:

• The section "Outbound Dialing" describes how to build the route groups and route lists for external access, how to create route filters for different levels of user access and routing by geographical region, how to transform the calling and called parties, and how to assign calling search spaces.
• The section "Inbound Dialing" describes how to build translation patterns to map external phone numbers to internal extensions and how to assign calling search spaces to control the destinations inbound gateway calls can reach.

Outbound dialing

Configuring outbound dialing consists of the following steps:

• "Route Group and Route List Creation" describes how to assign the gateways to route groups and how to build route lists to provide varied access to the route groups.
• "Route Filter Creation and Route Pattern Assignment" describes the route patterns and filters you must assign to the route lists to ensure that a calling user's call routes out the proper gateways.
• "Applying Calling and Called Party Transformations" describes the transformations you must apply to the calling and called numbers for the PSTN to properly process your calls.
• "Calling Search Space Creation, Calling Search Space Assignment, and Phone Configuration" describes how to assign calling search spaces to each user so that each user has the proper level of external access.

Route Group and Route List Creation

This subsection describes the first step in creating a toll-bypass network: creation of the route groups and route lists that the toll-bypass network uses.

Defining the route groups is simple. One gateway provides access to the San Jose PSTN; the other provides access to the Dallas PSTN. Each needs its own route group. Assign the San Jose gateway to route group SanJoseGateways and the Dallas gateway to route group DallasGateways.

Before defining the route lists, a concept introduced in Table 2-59 must be discussed. Table 2-59 introduces a concept that the External Route Plan Wizard uses, fallback. Fallback is the process of offering a call to a less desirable gateway after all desirable gateways have been exhausted.

The External Route Plan Wizard uses three types of fallback:

• Local call fallback is the strangest of the bunch. The External Route Plan Wizard prefers to route local calls from a given location only out gateways that reside in that location. If local call fallback is enabled, after all local gateways have been tried, CallManager routes local calls to gateways in different geographic locations. This process transforms a local call into a long distance call, potentially an expensive proposition.
• Toll-bypass fallback is more straightforward. If a caller makes a call to a remote geographic location and CallManager can determine that a gateway in the IP network resides in that location, CallManager prefers to route calls over the IP network to the remote gateway, rather than routing calls to a local gateway that must route them through the PSTN. This process is called toll bypass, and it requires turning a long distance call into a local call. But if all remote gateways are busy or not available, toll-bypass fallback tells CallManager to go ahead and route the call out a local gateway.
• Long distance and international fallback extends the External Route Plan Wizard's default option for routing long distance and international calls. The External Route Plan Wizard prefers to route long distance and international calls out a gateway that is local to the calling user. Long distance and international fallback allows CallManager to try gateways in remote locations if the local gateways are busy or not available.

Table 2-59 describes toll-bypass fallback and long distance and international fallback, but not local fallback. Some calls fall back from Dallas gateways to San Jose gateways, while others fall back from San Jose gateways to Dallas gateways. Other types of calls do not fall back at all.

Each type of fallback selects route groups somewhat differently. Every time that route group selection order must vary, one must create a route list. If different routes need different transformations, more route lists may be required. Table 2-60 shows which route lists need to be created as a result of the fallback strategy.

Route Filter Creation and Route Pattern Assignment

The enterprise rules listed in Table 2-59 describe seven types of calls:

• Emergency calls These are the same whether dialed from San Jose or Dallas.
• Local calls in San Jose These consist of seven-digit calls to the San Jose PSTN.
• Local calls in Dallas These consist of 10-digit calls to the Dallas PSTN.
• Toll-bypass calls to Dallas These consist of 11-digit calls from San Jose to the Dallas area codes.
• Toll-bypass calls to San Jose These consist of 11-digit calls from Dallas to the San Jose area code.
• Long distance calls These are the same whether dialed from San Jose or Dallas.
• International calls These are the same whether dialed from San Jose or Dallas.

Table 2-61 presents the list of route filters to create, their values, and a description of their purposes.

In all cases, the route pattern is 9.@. The enterprise rules define two locations and three levels of outside calling. This argues for six different partitions for outside dialing. An additional partition can handle calls between extensions. Create the following partitions in Table 2-62.

Having created the route filters and partitions, assign the partitions, route patterns, and filters according to Table 2-63. Remember that the route lists control the gateway access order. For example, route list SanJoseLocal selects only those gateways connected directly to the San Jose PSTN, while route list DallasInternational first selects gateways connected to the Dallas PSTN, but then uses gateways connected to the San Jose PSTN if the Dallas gateways are busy or unavailable.

Applying Calling and Called Party Transformations

Having defined the route lists and assigned the route patterns and filters, you must handle route-specific and non-route-specific transformations. Table 2-60 describes which routes require route-specific transformations.

Assign non-route-specific digit discarding instructions according to Table 2-64. Non-route-specific digit discarding instructions belong directly on the route pattern.

Assign route-specific called party transformations according to Table 2-65. To assign route-specific called party transformations, click specific route groups within the context of a given route list.

Calling Search Space Creation, Calling Search Space Assignment, and Phone Configuration

This final stage is simple. You must create the calling search spaces and then assign them to the calling devices. With two locations and three levels of external access, you require six calling search spaces. Create calling search spaces according to Table 2-66.

After defining the calling search spaces, assign them according to Table 2-67. External phone number masks result from the exchange number and phone number range the phone company has assigned Company ABC in San Jose and Dallas. Finally, assign directory numbers for all phones to partition ABC.

Inbound Dialing

For inbound dialing in a toll-bypass scenario, it is theoretically possible to have a phone be reachable by inbound dialing from any gateway in any geographical location. Such a configuration means that every internal number would have several external phone numbers. For example, if station 41050 were dialable from the San Jose gateway, in addition to 41050's Dallas address of 972 555 2050, 41050 would also have a San Jose external address of 408 555 5050. This type of configuration would very quickly consume any spare numbers you bought from the PSTN, and would be rather cumbersome to implement.

As a result, this example concerns itself with making Dallas extensions available from Dallas gateways and San Jose extensions available from San Jose gateways. This problem is therefore not truly related to a toll-bypass configuration, but it does provide some guidance for inbound dialing.

Inbound dialing configuration consists of performing the tasks in the following sections:

• "Define Translation Patterns" recaps how to use translation patterns to map external phone numbers to internal extensions.
• "Define and Assign Inbound Calling Search Spaces" describes how to assign calling search spaces to control the destination's inbound calls through gateways can reach.

Define Translation Patterns

Although this example permits the use of gateway called party transformations to convert an inbound phone number to an extension number, configuring the map using translation patterns saves some reconfiguration effort if you ever purchase another phone number range from the phone company.

San Jose gateways and Dallas gateways need individualized translation patterns. Define the translation patterns defined in Table 2-68.

Define and Assign Inbound Calling Search Spaces

After defining the translation patterns, you must create calling search spaces and assign them to the gateways. Create the calling search spaces Table 2-69.

Assign calling search space SanJoseTranslations to the San Jose gateway and calling search space DallasTranslations to the Dallas gateway.

Note that calling search spaces and partitions, when assigned this way, prevent tandem calls from one gateway to another. However, users can transfer or forward (unless you are also using call forward calling search spaces) inbound calls out gateways.

Geographical Routing Summary

Although configuring CallManager for geographical routing requires a complex configuration, the complexity stems from the fact that the call routing tasks CallManager must perform are themselves complex.

Configuring geographical routing requires the following steps: