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.

Table 2-54. Executive Access Route Pattern Information

Field	Value
Partition	Executives
Route pattern	9.@
Route filter
Digit discarding instructions	PreDot
Route This Pattern

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.

Table 2-55. Office Personnel Access Route Pattern Information

Field	Value
Partition	OfficePersonnel
Route pattern	9.@
Route filter	InternationalCalls (INTERNATIONAL-ACCESS DOES-NOT-EXIST)
Digit discarding instructions	PreDot
Route This Pattern
Partition	OfficePersonnel
Route pattern	9.@
Route filter	900Numbers (AREA-CODE == 900)
Digit discarding instructions	PreDot
Block This Pattern

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.

Table 2-56. Lobby Phone Access Route Pattern Information

Field	Value
Partition	LobbyPhones
Route pattern	9.@
Route filter	911Calls (SERVICE == 911)
Digit discarding instructions	PreDot
Route This Pattern

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.

Table 2-57. Partitions for User-Restriction Example

Partition Name	Description
ABC	Contains all phones within the enterprise
LobbyPhones	Contains gateway route patterns that provide access solely to emergency services
OfficePersonnel	Contains gateway route patterns that provide access to noninternational and non-900-number calls
Executive	Contains gateway route patterns that provide access to all external numbers

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

Table 2-58. Calling Search Spaces for User-Restriction Example

Calling Search Space	Partitions Contained Within
Executives	ABC, Executives
OfficePersonnel	ABC, OfficePersonnel
LobbyPhones	ABC, LobbyPhones
Gateway	ABC

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.

Table 2-59. Routing Preferences for Geographical Routing Example

Calls from San Jose...
...to a San Jose extension...	...route directly to the extension
...to a Dallas extension...	...route directly to the extension
...to emergency numbers...	...route out the San Jose gateway only
...to local numbers...	...route out the San Jose gateway only
...to Dallas local numbers...	...route out the Dallas gateway, but fall back to the San Jose gateway as a long distance call if the Dallas gateway is busy or not available
...to long distance numbers...	...route out the San Jose gateway, but fall back to the Dallas gateway if the San Jose gateway is busy or not available
...to international numbers...	...route out the San Jose gateway, but fall back to the Dallas gateway if the San Jose gateway is busy or not available
Calls from Dallas...
...to a San Jose extension...	...route directly to the extension
...to a Dallas extension...	...route directly to the extension
...to emergency numbers...	...route out the Dallas gateway only
...to local numbers...	...route out the Dallas gateway only
...to San Jose local numbers...	...route out the San Jose gateway, but fall back to the Dallas gateway as a long distance call if the San Jose gateway is busy or not available
Calls from Dallas...
...to long distance numbers...	...route out the Dallas gateway, but fall back to the San Jose gateway if the Dallas gateway is busy or not available
...to international numbers...	...route out the Dallas gateway, but fall back to the San Jose gateway if the Dallas gateway is busy or not available

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.

Table 2-60. Route List Requirements

Calls from San Jose...	Description
...to emergency numbers route out the San Jose route group only ...to local numbers route out the San Jose route group only	These calls require no route-specific transformations. Action: Create route list SanJoseLocal, which contains only the San Jose route group.
...to Dallas local numbers route out the Dallas route group, but fall back to the San Jose route group as a long distance call if the Dallas route group is busy or not available	This call requires route-specific transformations. When a user dials an 11-digit Dallas number, the call must be converted to a local call before it routes out the Dallas gateway, but if it falls back to the San Jose gateway, all 11 digits must be sent. In addition, if a toll bypass call from a San Jose calling number routes out a Dallas gateway, it is sometimes necessary to provide a Dallas calling number so that the local carrier does not reject the call. The Dallas attendant number can serve this purpose. Action: Create route list TollBypassToDallas, which contains the Dallas route group followed by the San Jose route group.
...to long distance numbers route out the San Jose route group, but fall back to the Dallas route group if the San Jose route group is busy or not available ...to international numbers route out the San Jose route group, but fall back to the Dallas route group if the San Jose route group is busy or not available	These calls require route-specific transformations. If a long distance call from a San Jose calling number routes out a Dallas gateway, it is sometimes necessary to provide a Dallas calling number so that the local carrier does not reject the call. The Dallas attendant number can serve this purpose. Action: Create route list SanJoseLongDistance, which contains the San Jose route group followed by the Dallas route group.
Calls from Dallas...	Description
...to emergency numbers route out the Dallas route group only ...to local numbers route out the Dallas route group only	These calls require no route-specific transformations. Action: Create route list DallasLocal, which contains only the Dallas route group.
...to San Jose local numbers route out the San Jose route group, but fall back to the Dallas route group as a long distance call if the San Jose route group is busy or not available	This call requires route-specific transformations. When a user dials a seven-digit San Jose number, the call must be converted to a local call before it routes out the San Jose gateway, but if it falls back to the Dallas gateway, CallManager must convert the dialed number to 11 digits to route the call across the PSTN. In addition, if a toll bypass call from a Dallas calling number routes out a San Jose gateway, it is sometimes necessary to provide a San Jose calling number so that the local carrier does not reject the call. The San Jose attendant number can serve this purpose. Action: Create route list TollBypassToSanJose, which contains the San Jose route group followed by the Dallas route group.
...to long distance numbers route out the Dallas route group, but fall back to the San Jose route group if the Dallas route group is busy or not available ...to international numbers route out the Dallas route group, but fall back to the San Jose route group if the Dallas route group is busy or not available	These calls require route-specific transformations. If a long distance call from a Dallas calling number routes out a San Jose gateway, it is sometimes necessary to provide a San Jose calling number so that the San Jose local carrier does not reject the call. The San Jose attendant number can serve this purpose. Action: Create route list DallasLongDistance, which contains the Dallas route group followed by the San Jose route group.

 

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.

Table 2-61. Route Filters for Geographical Routing Example

Route Filter	Value	Description
Emergency	SERVICE EXISTS	Network services such as information (411) and emergency services (911)
SanJoseLocal	OFFICE-CODE EXISTS AND LOCAL-AREA-CODE-DOES-NOT-EXIST AND AREA-CODE DOES-NOT-EXIST	Seven-digit calls, which represent local calls in the San Jose area
DallasLocal	LOCAL-AREA-CODE == 972 OR LOCAL-AREA-CODE == 214	10-digit calls to area codes 214 and 972, which are local calls in the Dallas area
TollBypassToDallas	AREA-CODE == 972 OR AREA-CODE == 214	Long distance calls to area codes 214 and 972
TollBypassToSanJose	AREA-CODE == 408	Long distance calls to area code 408
LongDistance	AREA-CODE EXISTS	Long distance calls to area codes that no gateways in the enterprise network serve
International	INTERNATIONAL-ACCESS EXISTS	Calls to international destinations

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.

Table 2-62. Partitions for Geographical Routing Example

Partition	Description
ABC	This partition contains the directory numbers of internal extensions.
SanJoseEmergency	This partition contains the route pattern that San Jose users access for their emergency calls.
SanJoseLocalAndLongDistance	This partition contains the route patterns that San Jose users access for local, toll-bypass, and long distance calls.
SanJoseInternational	This partition contains the route patterns that San Jose users access for international calls.
DallasEmergency	This partition contains the route pattern that Dallas users access for their emergency calls.
DallasLocalAndLongDistance	This partition contains the route patterns that Dallas users access for local, toll-bypass, and long distance calls.
DallasInternational	This partition contains the route patterns that Dallas users access for international calls.

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.

Table 2-63. Route Pattern and Filter to Route Lists for Geographical Routing Example

Partition	Pattern	Filter	Route List
SanJoseEmergency	9.@	Emergency	SanJoseLocal
SanJoseLocalAndLongDistance	9.@	SanJoseLocal	SanJoseLocal
SanJoseLocalAndLongDistance	9.@	TollBypassToDallas	TollBypassToDallas
SanJoseLocalAndLongDistance	9.@	LongDistance	SanJoseLongDistance
SanJoseInternational	9.@	International	SanJoseInternational
DallasEmergency	9.@	Emergency	DallasLocal
DallasLocalAndLongDistance	9.@	DallasLocal	DallasLocal
DallasLocalAndLongDistance	9.@	TollBypassToSanJose	TollBypassToSanJose
DallasLocalAndLongDistance	9.@	LongDistance	DallasLongDistance
DallasInternational	9.@	International	DallasInternational

 

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.

Table 2-64. Non-Route-Specific Transformations

Partition	Route Pattern	Route Filter	Digit Discarding Instruction
SanJoseEmergency	9.@	SERVICE EXISTS	PreDot
SanJoseLocal	9.@	OFFICE-CODE EXISTS AND LOCAL-AREA-CODE-DOES-NOT-EXIST AND AREA-CODE DOES-NOT-EXIST	PreDot
DallasEmergency	9.@	SERVICE EXISTS	PreDot
DallasLocal	9.@	AREA-CODE == 972 OR AREA-CODE ==214	PreDot

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.

Table 2-65. Route-Specific Transformations

Route List	Route Group	Digit Discarding Instructions	Calling Party Transform Mask	Use External Phone Number Mask
TollBypassToDallas	DallasGateways	PreDot 11D->10D	972 555 0000	No
TollBypassToDallas	SanJoseGateways	PreDot		Yes
TollBypassToSanJose	SanJoseGateways	PreDot 11D->7D	408 555 0000	No
TollBypassToSanJose	DallasGateways	PreDot		Yes
SanJoseLongDistance	SanJoseGateways	PreDot		Yes
SanJoseLongDistance	DallasGateways	PreDot	972 555 0000	No
DallasLongDistance	DallasGateways	PreDot		Yes
DallasLongDistance	SanJoseGateways	PreDot	408 555 0000	No

 

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.

Table 2-66. Outbound Calling Search Spaces for Geographical Routing Example

Calling Search Space	Contains Partitions	Description
SanJoseLobbyPhone	ABC, SanJoseEmergency	Provides access to internal extensions and PSTN services only
SanJoseOfficePersonnel	ABC, SanJoseEmergency, SanJoseLocalAndLongDistance	Provides access to internal extensions, PSTN services, and local, toll-bypass, and long distance calls
SanJoseManager	ABC, SanJoseEmergency, SanJoseLocalAndLongDistance, SanJoseInternational	Provides access to internal extensions and all PSTN numbers
DallasLobbyPhone	ABC, DallasEmergency	Provides access to internal extensions and PSTN services only
DallasOfficePersonnel	ABC, DallasEmergency, DallasLocalAndLongDistance	Provides access to internal extensions, PSTN services, and local, toll-bypass, and long distance calls
DallasManager	ABC, DallasEmergency, DallasLocalAndLongDistance, DallasInternational	Provides access to internal extensions and all PSTN numbers

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.

Table 2-67. Assignment of Calling Search Spaces

Extension	Calling Search Space	External Phone Number Mask
San Jose Phones
30000	SanJoseOfficePersonnel	408 555 5XXX
31000	SanJoseLobbyPhone	408 555 5XXX
31100	SanJoseOfficePersonnel	408 555 5XXX
31200	SanJoseManager	408 555 5XXX
Dallas Phones
40000	DallasOfficePersonnel	972 555 2XXX
41050	DallasLobbyPhone	972 555 2XXX
41150	DallasOfficePersonnel	972 555 2XXX
41250	DallasManager	972 555 2XXX

 

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.

Table 2-68. Translation Patterns

Partition	Translation Pattern	Translation Partition	Called Party Transformation Mask
SanJoseTranslations	408 555 5XXX	ABC	31XXX
DallasTranslations	972 555 2XXX	ABC	41XXX

 

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.

Table 2-69. Inbound Calling Search Spaces for Geographical Routing Example

Calling Search Space	Contains Partitions	Description
SanJoseTranslations	SanJoseTranslations	Provides access to the extension mapping tables when the PSTN offers calls to CallManager over San Jose gateways
DallasTranslations	DallasTranslations	Provides access to the extension mapping tables when the PSTN offers calls to CallManager over Dallas gateways

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:

Step 1.	Think about the users in your network and how you want CallManager to treat their calls. What types of calls are permitted? Do you want toll restriction? What types of fallback routing do you want to permit?
Step 2.	Configure your outbound dialing:   Provision your gateways. Define route groups to contain gateways that connect to the same network. Create one route list for each unique route group search pattern that your network needs. Assign route groups to each route list appropriately. Define route filters that properly describe the levels of external access you want to permit. Provide outside access by narrowly tailoring these route lists to permit just one class of external call. For instance, if your network provides two levels of outside access, national numbers and unlimited access, define one route filter that defines access to national numbers only and another that defines access to international numbers only. By providing your most privileged users access to route patterns with both route filters, you give them unlimited access. Define partitions for each unique level of external access you want to provide. Define a partition for internal extensions. Assign partitions, route patterns, and route filters with the appropriate route lists. Set up the appropriate dialing transformations. This means using a combination of dialing transformations on the route pattern and dialing transformations on the routes themselves, when fallback or toll restriction means that certain route groups must receive a specific set of called digits. Build calling search spaces for each level of external access and assign them to the phones in your enterprise.
Step 3.	Configure your inbound dialing:   Define translation patterns that map the external number ranges that the PSTN assigns you to the internal ranges that your network requires. Define calling search spaces for the gateways in each of your geographic locations and assign them to the gateways in these locations.