Translation Patterns

Translation Patterns Versus Dialing Transformations

CallManager also uses a concept called translation patterns (described in section "Translation Patterns"), and indeed, translation patterns rely heavily on dialing transformations to operate. But translation patterns and dialing transformations are separate concepts. Dialing transformations is a generic concept that refers to any setting in CallManager that can change the calling number or dialed digits. Dialing transformations appear not only on the Translation Pattern Configuration page, but also on the Route Pattern Configuration page, numerous gateway configuration pages, and in service parameters.

Calling party transformations affect the calling number but not the calling name of a call. For example, when one Cisco IP Phone calls another, normally the called phone sees two pieces of information: the directory number of the calling phone and the any display name that you have entered on the Directory Number Configuration page for the calling phone. Figure 2-7 depicts the display of a Cisco IP Phone that is receiving a call.

Figure 2-7. Calling Number and Name During Call Presentation

The Display (Internal Caller ID) field in the Directory Number Configuration page has limited scope. When a user places a call, CallManager provides this name to all ringing devices for station-to-station calls within the cluster. While all stations are ringing, CallManager displays the contents of the Alerting Name field on the caller's station, but when a ringing device answers, CallManager ensures that this name is displayed on the caller's IP phone.

When a call leaves the private network, there is often no provision in the network protocol to provide calling party name information to the PSTN or alerting and connected name information from the PSTN to the caller. Some protocols, notably QSIG and DMS versions of Primary Rate Interface (PRI), however, do provide for transmission of the calling number, the connected number, the calling name, the alerting name, and the connected name, and CallManager transmits this information whenever the protocol permits.

You usually need calling party transformations only for display purposes. For instance, enterprises very commonly require that the central switchboard number for an organization be provided as the calling number for all external calls. Even when you want to actually transmit the calling party's direct inward dial (DID) number, however, you still must configure some sort of calling party transformation. The PSTN usually wants to see the number of the calling user's address from the PSTN's point of view rather than the internal directory number you have assigned your user; unless the internal directory numbers are fully qualified PSTN numbers, a transformation is needed to adapt to the PSTN's expected numbering scheme. Calling party transformations are not limited to calls to the PSTN, though. If you so choose, you can apply them to calls between your users.

Called party transformations modify the digits the calling user actually dials. Strictly speaking, they do not affect which destination CallManager selects because the selection is based on the digits that the calling user dials, not the transformed called number; however, the transformed called number is often reanalyzed by translation patterns or by other systems to subsequently route the call.

The transformation just modifies those digits before CallManager sends them to a selected device. However, if the selected device looks at the dialed digits to further route the call, the transformation can indeed affect which device ultimately receives the call. This sort of steering occurs most often when CallManager offers a call with a modified called number to a gateway connected to an adjacent network.

This section discusses the transformations permitted at different stages of the transformation process. It covers the following topics:

• "When CallManager Can Apply Dialing Transformations" discusses five opportunities during the call routing process that CallManager has to apply dialing transformations.
• "About Device Types That CallManager Supports" provides an overview of the types of station and trunk devices that CallManager supports, because routing settings are often particular to only certain types of devices.
• "About Masks" discusses masking, an operation that commonly occurs during many stages of the call routing process.
• "About Name and Line Presentation" discusses the options CallManager provides for keeping the names and numbers of callers and called parties private from each other.
• "Dialing Transformation-Related Service Parameters" discusses some CallManager service parameters that relate to calling and called party transformations. The transformations these settings provide are somewhat inconsistent. Some apply to inbound calls, while others apply to outbound calls. Most settings take effect for only some of the devices that CallManager supports.
• "Transformations on the Originating Device" discusses the first opportunity that CallManager has to transform calling and called numbers, at the point where CallManager first receives a call. These transformations are highly device-dependent.
• "Transformations in Translation Patterns, Route Patterns, and Route Lists" discusses the second, third, and fourth opportunities where CallManager can transform calling and called numbers. These transformations are very regular, and thus, this section can discuss them as a group.
• "Transformations on the Terminating Device" discusses the fifth and final opportunity where CallManager can transform calling and called numbers, just before CallManager offers the call to the destination. Just like the transformation on the originating device, transformations on the terminating device are highly device-dependent.

When CallManager Can Apply Dialing Transformations

Calling and called party transformations can occur in five stages during CallManager's routing process. These stages occur in order, although not all of them need to occur. For instance, if the number that the user dials does not correspond to a translation pattern or route list, no translation-pattern-based or route-list-based transformations occur. The five stages, in order, are as follows:

1. At the originating device
2. As part of translation pattern
3. As part a route pattern
4. As part of a route list's operation
5. At the terminating device

A Detour to Discuss the Stages of Call Routing

To fully understand the stages of call routing means understanding a little of what goes on in the internal logic of CallManager. CallManager consists of a large number of independent logical components that interact in a complex manner. Each logical component has very limited responsibilities to reduce the complexity of any individual component. For example, to each Cisco IP Phone, CallManager assigns one component whose responsibility is to serve as a control point for actions (going off-hook, pressing buttons, and so on) that a user performs. But when a Cisco IP Phone places a call, CallManager dynamically creates a component that understands how to perform the functions of a call. Other components handle the high-level concepts of "call transfer" or "two-party call" or "route pattern lookup." To process a simple station-to-station call, CallManager passes messages among at least 40 components.

When this section talks about a transformation occurring at the originating device, it does not mean that the physical device itself or even the software embedded within it is applying a dialing transformation. Rather, it means that the logical component in CallManager that represents the originating device is applying a dialing transformation.

This is not to say that devices themselves never have call routing capabilities of their own. Cisco IOS gateways, in particular, have very robust dialing transformation capabilities, but those capabilities are outside the scope of this book.

First, CallManager settings for the originating device can modify the dialed digits before control of the call passes the digits to the call routing component. This process happens, for instance, when a call from the PSTN comes into CallManager. Depending on what digits the PSTN sends, you might find it necessary to convert the address from a PSTN address to a local directory number.

Second, if the destination selected is a translation pattern, CallManager applies the calling and called party transformations associated with the translation pattern to change the calling and called numbers. After CallManager applies the dialing transformation, digit analysis uses the resulting called number to select another destination. Sometimes, the transformed digits cause CallManager to match a new translation pattern. In such a case, CallManager applies the calling and called party transformations of the newly selected translation pattern to select a new destination. CallManager breaks such chains of translation patterns after ten iterations to prevent infinite routing loops. The section "Translation Patterns" contains further information about translation patterns.

The third opportunity that the call routing component has to apply dialing transformations is when the dialed digits match a route pattern or directory number. When the dialed digits select a route pattern, CallManager applies the calling and called party transformations configured on the Route Pattern Configuration page.

Fourth, after any translation patterns have been analyzed, if the destination is a route list (described in the section "Call Hunting Constructs"), CallManager applies any calling and called party transformations specified on the route between the route list and individual route groups within the route list. Unlike other transformations in this sequence, transformations on a route list override the ones that the route pattern or translation pattern applies. In all other cases, the changes that CallManager applies are cumulative. For instance, if CallManager prepends the digit 9 to a dialed number of 1000 at the originating device, and the terminating device subsequently prepends an 8, the resulting called number is 891000. On the other hand, if a called party transformation on the route pattern prepends the digit 9 to the dialed number 1000, but a called party transformation on the route between the route list and an individual route group prepends an 8, the resulting called number is 81000, not 981000. The settings on the route list's route group details undo the transformations that the route pattern applies. This behavior allows you to define transformations on a route pattern that are correct for most cases, but that you want to supersede for calls out particular route groups.

When you add calling and called party transformations to a route pattern or translation pattern, CallManager logs the transformed numbers in the CDRs and renders the transformed numbers on the display of the calling phone. CallManager does not insert transformations specified on the route list's route group details (or applied by an individual egress gateway) in the CDRs or render them on the calling device.

Fifth, CallManager can modify the calling and called parties just before handing the call to the associated device (such transformations exist exclusively on trunk devices).

Figure 2-8 shows a picture of the transformation process. A Cisco IP Phone places a call. When CallManager passes the call request to call control, CallManager modifies the digits according to any dialing transformations configured for the phone. If the digits provided match a translation pattern, CallManager applies the dialing transformations configured for the translation pattern. At some point, CallManager selects a destination and applies any dialing transformations configured for the route pattern or directory number selected. If a route list is the target of the call, CallManager applies any dialing transformations on specific routes selected. Finally, CallManager applies any dialing transformations configured on the terminating device. All of these opportunities to transform the calling number and called number means that they can differ quite dramatically by the time CallManager has routed a call.

Figure 2-8. Locations Where Transformations Occur

 

About Device Types That CallManager Supports

Although CallManager can transform the calling and called numbers at the originating and terminating devices, the dialing transformations available are often quite protocol-dependent. For instance, the dialing transformations that you can configure for an analog phone connected to the Cisco VG200, which uses the MGCP, are not the same as those that you can configure for the Cisco 2600 router, which uses the H.323 protocol.

Chapter 4, "Trunk Devices," and Chapter 3, "Station Devices," go into great detail about the specific gateway and station devices that CallManager supports.

About Masks

CallManager uses a common operation called masking throughout the transformation process, so it is worthwhile to discuss it before continuing.

Mask operations allow you to suppress leading digits, to change existing digits while leaving others unmodified, and to insert leading digits. A mask operation requires two pieces of information, the number to be masked and the mask itself.

In the mask operator, the number is overlaid by the mask, aligned so that the last character of the mask overlays the last digit of the number. Where the mask contains a digit, the mask's digit supersedes the number's digit. Where the mask contains an X, the corresponding digit of the number is used. And if the number is longer than the mask, the mask obscures the extra digits, as if the stencil were opaque at that point. Figure 2-9 shows some examples.

Figure 2-9. Transformation Mask Operation

 

About Name and Line Presentation

Grouped among the calling and called party transformation settings are presentation settings. Strictly speaking, presentation settings do not modify the calling or called names or numbers but instead dictate whether the users involved in a call are permitted to view the calling or called name or number. Calling line ID presentation settings control whether the called party can view the caller's number or name and whether the destination party can view the forwarded party's numbers or names in call diversions. Connected line ID presentation settings control whether the calling party can view the number or name of the called party while the called party's phone is ringing or after it has answered.

Calling line ID presentation settings exist not only on route and translation patterns, but also on all trunk devices (including intercluster trunks, H.323 trunks, and SIP trunks), QSIG gateways, and MGCP gateways containing PRI trunks. H.323 gateways include the similar field Calling Party Presentation. Valid values for the Calling line ID, Calling name ID, Connected line ID, and Connected name ID fields are Default, Allowed, and Restricted.

Name and line presentation is cumulativethe last node to apply a presentation setting to a call takes precedence. The settings Allowed and Restricted (whether on translation patterns, route patterns or directly on the gateways themselves) overwrite whatever presentation setting comes in; however, Default simply carries forward the current setting in the call. By default, calls from Cisco IP Phones allow presentation of calling name, calling line ID, connected name, and connected line ID, and the Default setting on a translation or route pattern carries these permissions forward unless you specifically override them (with a Restricted value on a route or translation pattern).

For instance, assume you have three CallManager clusters. A set of IP phones in the numbering range 1000 to 1999 is hosted by cluster 3, and route patterns are set up to route calls from other phones in cluster 1 through cluster 2 to cluster 3.

CallManager cluster 1 sets the following settings for route pattern 1XXX, which directs calls to cluster 3 via cluster 2:

• Calling name: Allowed
• Calling line: Allowed
• Connected name: Restricted
• Connected line: Restricted

CallManager cluster 2 sets the following settings in route pattern 1XXX, which directs inbound calls from cluster 1 to cluster 3:

• Calling name: Default
• Calling line: Default
• Connected name: Default
• Connected line: Default

CallManager cluster 3 sets the following settings for translation pattern 1XXX, which directs calls to directory numbers in cluster 3 in the range 1000 to 1999:

• Calling name: Restricted
• Calling line: Restricted
• Connected name: Allowed
• Connected line: Allowed

The number of the caller is presented to the called party in the initial call offering. As a result, the last calling presentation setting to take effect on the call is the setting in cluster 3. Thus, the caller's name and number are not presented to any phones in cluster 3 because the calling name and line presentation in cluster 3 is set to Restricted.

The number of the called party is presented to the caller in the initial ringing message and presented again when the called party answers. These messages start from the called party and head towards the caller. As a result, the last connected presentation setting to take effect on the call is the setting in cluster 1. Thus, the connected party's name and line are not presented to any phones in cluster 1, because the connected name and line presentation in cluster 1 is set to Restricted for calls the caller places in the 1000 to 1999 range.

On the Phone Configuration page, Cisco IP Phones also present a check box called Ignore Presentation Restriction (internal calls only). When checked, Cisco IP Phones always display the name and line, when they are available, of any party they're conversing with, even if the party has requested that the name or number be restricted. This setting is appropriate for authorized users such as hotel receptionists, because it allows you to otherwise configure calls between rooms as private calls while permitting the receptionist to see the identity of a calling room.

Note

The presentation restriction example in this section uses a multiple-cluster scenario because it most clearly illustrates the way that presentation indicators override each other. However, you can still use presentation indicators within a cluster through the use of translation patterns in conjunction with calling search spaces and partitions.

For example, assume that you're running a hotel and want prevent the name and number from being displayed on room-to-room calls. Assume that your room numbers consist of four-digit numbers in the range 1000 to 1999.

First, you would assign all room IP phones to a partition such as RoomPhones. In a traditional environment, each phone would include this partition in its own calling search space in order to permit direct calls between phones. However, in this case, you instead want room to room calls to first route through a translation pattern that forces the calling and connected names and line IDs to be restricted.

Therefore, you define pattern 1XXX in partition RoomToRoom and ensure that partition RoomToRoom is in the calling search space of all the room phones. On this translation pattern, you set the presentation indicators to Restricted and specify a calling search space that includes partition RoomPhones. When a room phone dials a number like 1010, CallManager matches the translation pattern 1XXX, marks the call with restriction indicators, and then re-offers the call to the phones in partition RoomPhones. Using the Ignore Presentation Restriction (internal calls only) flag, you could even permit certain phones in the RoomPhones partition to see the name and number of another calling phone, despite the restrictions that the translation pattern applies.

If this seems like gobbledygook, it is probably because this chapter has not yet discussed the calling search spaces and partitions concepts. See the section "Calling Search Spaces and Partitions" for more information.

 

Dialing Transformation-Related Service Parameters

Numerous CallManager settings related to call routing exist as service parameters.

When service parameters take effect for a particular gateway type, the settings apply to all gateways that your CallManager controls and not individual gateways. For instance, if you configure the Strip # Sign from Called Party Number service parameter, all gateways modify the dialed digits in accordance with the Strip # Sign from Called Party Number service parameter. The service parameter does not permit you to use the Strip # Sign from Called Party Number option for one particular gateway connected to CallManager while other gateways connected to CallManager ignore the service parameter.

Furthermore, CallManager service parameters related to routing do not always apply to all gateway protocols. The section "About Device Types That CallManager Supports" describes the device types that CallManager supports.

Service parameters are a vestige of the call routing settings that existed in the scm.ini file before release 3.0. Although CallManager 3.1 and later provides alternative ways to achieve the functions that most of these settings provide, these settings still are effective. Table 2-38 shows the list of routing-related service parameters and a checklist of which protocols for which the settings take effect.

Table 2-38. Supported Service Parameter Dialing Transformations by Device Type

Service Parameter Dialing Transformation	SCCP Station Devices	MGCP Station Devices	H.323 Station Devices	SCCP Trunk Devices	MGCP Trunk Devices	H.323 and SIP Trunk Devices
Calling Party Number Screening Indicator
Matching Calling Party Number With Attendant Flag				[2]	[2]
Overlap Receiving Flag For PRI					[1]
Strip # From Called Party Number
Unknown Caller ID
Unknown Caller ID Flag
Unknown Caller ID Text
Numbering Plan Info					[1]
National Number Prefix					[1]
International Number Prefix					[1]
Subscriber Number Prefix					[1]
Unknown Number Prefix					[1]

[2] FXO interfaces only

[1] T1-PRI and E1-PRI interfaces only

Calling Party Number Screening Indicator

Calling Party Number Screening Indicator affects calls that CallManager routes out MGCP digital gateways. The setting allows you to specify the value of the screening indicator field in the calling party number information element of the Integrated Services Digital Network (ISDN) protocol. This element indicates to the attached ISDN network whether CallManager scrutinized the calling number it provides. Note that CallManager never actually screens the number. When calls are placed from Cisco IP Phones, CallManager always provides the calling number configured for the phone. When calls arrive at CallManager via trunk interfaces, these interfaces might provide a calling number. Setting the Calling Party Number Screening Indicator service parameter does not actually cause CallManager to compare such calling numbers against any of CallManager's configured destinations, but rather simply allows CallManager to spoof an appropriate setting for an attached network that might otherwise have a problem with an unscreened number.

Table 2-39 shows the values the setting takes, along with a description of the meaning that the ISDN protocol assigns to these settings.

Table 2-39. Values of Calling Party Number Screening Indicator

Value	Description
Calling number not screened	User provided, not screened: The user device provides the value in the calling number. The setting indicates that CallManager did not scrutinize it.
Calling number screened and passed	User provided, verified, and passed: The user device provides the value in the calling number. The setting indicates that CallManager has checked it against a list of acceptable numbers and declared it acceptable, although CallManager performs no such screening.
Calling number screened and failed	User provided, verified, and failed: The calling user device provides the value in the calling number. The setting indicates that CallManager has checked it against a list of acceptable numbers and that it is not valid. Again, CallManager doesn't actually perform screening; this setting simply affects what CallManager reports to the attached network.
CallManager provides calling number	Network provided: CallManager provides the calling number.
Default setting	Default: CallManager sets up its default value for the screening indicatoruser provided, not screened.

Only change this setting if the attached ISDN network rejects your outbound calls because it finds the value of the screening indicator unacceptable. (Determining this fact requires detailed debugging of the trace file.) However, the value you set has no effect on the tasks CallManager actually performs in relation to the calling number. In other words, CallManager performs no actual screening and verification of the calling number. Rather, it simply changes the value of the ISDN field it provides to the ISDN network to provide flexibility in interworking with different varieties of ISDN.

Matching Calling Party Number With Attendant Flag

This setting provides a simple way to emulate the functionality of a small PBX or key system. Small PBXs typically associate inbound analog trunks on a one-for-one basis with user stations. The PBX offers incoming calls over an analog trunk to the corresponding station, and conversely, outbound calls from the station select the corresponding analog trunk. This allows a small business to provide internal users with unique external directory numbers but still to use low-cost analog loop start trunks.

An analog loop start trunk is just like the analog phone line that most people have at home. Analog loop start trunks have limited ability to communicate calling and called party information. When a user places a call from a private network to the PSTN, no way exists for the private network to indicate to the PSTN the public phone number of the calling user. Rather, the PSTN uses the number assigned to the loop start trunk as the calling number. Similarly, when the PSTN offers the call to the private network, the PSTN has no way to provide the actual digits the calling user dialed; rather, it assumes that the inbound call directly terminates on the appropriate phone.

This setting works with analog gateways running the Skinny Gateway Control Protocol and with Cisco MGCP gateways. The gateway setting Attendant DN described in the section "Attendant DN" automatically routes incoming calls from an analog trunk to the specified directory number. This behavior is exactly what is required to handle the trunk-to-station behavior of a small PBX.

The setting Matching Calling Party Number With Attendant Flag handles the station-to-trunk calls. When this value is set to True, CallManager makes sure that the trunk selected for a station's outbound call is the same as that it uses to handle the station's inbound calls. To perform this function, it routes the outbound call out the trunk whose Attendant DN is the directory number of the calling station.

This setting works best if you have a single gateway for external calls, because you can assign a single route pattern such as 9.@ to the gateway and ensure that CallManager presents all users' external calls to this gateway. If you have several gateways, to ensure that CallManager presents a given user's external call to the associated gateway, you need either to place all of your gateways in a route list (see the section "Call Hunting Constructs" for more information) or to use calling search spaces and partitions to route the calling user to the appropriate gateway (see the section "Calling Search Spaces and Partitions").

Overlap Receiving Flag for PRI

This value enables overlapped receiving. Many countries implement national numbering plans that use variable-length subscriber numbers. Complicated tables of area codes or city codes determine the actual length of a subscriber. Unless a telephone system intimately understands the country's numbering plan, efficiently giving calls to and receiving calls from such networks requires providing or receiving digits one at a time. Receiving digits one at a time from the network is called overlapped receiving. By default, overlapped receiving is enabled and the sending complete indicator is disabled.

If your route plan contains route patterns that begin with similar digit strings (for instance, 9XXX and 9XXXX), leaving overlapped receiving enabled can cause routing delays when CallManager receives calls over trunks that use these settings. Disable this capability by changing the Overlap Receiving Flag For PRI to False.

Strip # from Called Party Number

Administrators who manage call routing for countries with variable-length numbering plans for which CallManager support does not yet exist must configure route patterns such as 0! to get CallManager to provide the proper number of digits to the PSTN. Because route patterns ending in the ! wildcard introduce interdigit timing on all calls, such administrators often also configure equivalent route patterns (in this case, 0!#) so that knowledgeable users who terminate their outbound calls with a # need not wait for the interdigit timeout to expire.

Before such calls enter the PSTN, the dialed # must be stripped. This setting is enabled by default. When set to True, CallManager strips the final # (if it exists) of a dialed digit string before CallManager routes the call out the gateway.

Unknown Caller ID, UnknownCallerIDFlag, and UnknownCallerIDText

Unknown Caller ID, Unknown Caller ID Flag, and Unknown Caller ID Text affect calls that originate from a gateway. When calls arrive from the PSTN, often caller ID is not available. Setting the Unknown Caller ID Flag to True tells CallManager to provide a calling number and name for inbound calls that do not contain such information. The contents of Unknown Caller ID Text become the calling name, and the contents of Unknown Caller ID become the calling number.

Numbering Plan Info

Calls to ISDN and H.323 networks include information that attempts to classify the number dialed. The section "Called Party IE Number Type" discusses this information in more detail. This information, however, tends to be rather troublesome in practice, because many networks are particular about the manner in which the information is encoded. The Numbering Plan Info service parameter provides a way to tweak this information if your system is having difficulty communicating with a connected system. The Numbering Plan Info service parameter takes the following values:

• 0 disables the setting, which causes CallManager to format the numbering plan information according to the call routing component's best judgment and the settings on the terminating device.
• 1 causes CallManager to encode the numbering plan field of the called party information element to Unknown, if the type of number field of the called party information element, as determined by CallManager, is also Unknown.
• 2 causes CallManager to encode the numbering plan field of the called party information element as Private, and the type of number field of the called party information element as Unknown.

If the system you have connected CallManager to is complaining about the encoding of the called numbera fact you can determine only through detailed analysis of the call rejection messages the connected system returnschanging this setting might resolve the problem.

Transformations on the Originating Device

This section describes the first opportunity CallManager has to transform the calling or called numberswhen the component that controls the caller's device offers the call to the call control component. These dialing transformations vary from device type to device type. The section "About Device Types That CallManager Supports" describes the device types that CallManager supports.

Table 2-40 provides an overview of the different kinds of originating device dialing transformations, along with a checklist of which protocols support which transformations.

Table 2-40. Supported Originating Device Dialing Transformation by Device Type

Originating Device Dialing Transformation	SCCP Station Devices	MGCP Station Devices	H.323 Station Devices	SCCP Trunk Devices	MGCP Trunk Devices	H.323 and SIP Trunk Devices
External Phone Number Mask
Prefix Digits		[1]			[2]	[1]
Num Digits					[5]	[5]
Expected Digits					[5]	[5]
Attendant DN					[4]
Significant Digits					[3]
Redirecting Number IE DeliveryInbound					[3]

[1] Called Prefix DN

[2] On T1-PRI and E1-PRI interfaces, it is called Prefix DN; on T1-CAS, Prefix Digits; not supported on other interfaces

[5] On T1-CAS only

[4] On FXO interfaces only

[3] On T1-PRI and E1-PRI interfaces only

External Phone Number Mask

All station devices use the Directory Number Configuration page. This page contains a field that is important in transformations, the External Phone Number Mask. Although the external phone number mask does not, in itself, effect any transformations, it allows you to configure a line's number from the PSTN's point of viewthe line's external number. When you configure a value in this field, the value also shows up in the top line of the Cisco IP Phones 7905, 7912, 7940, 7941, 7960, 7961, 7970, and 7971 as the phone's external phone number.

For station-to-station calls, the calling line's directory number shows up as the calling number. However, for station-to-trunk calls, you can configure the destination route pattern so that it instead uses the line's external number as the calling number.

The external phone number mask is truly a mask (see the section "About Masks"). If you are fortunate enough to be able to map the final digits of a phone's external number directly to its internal extension, and if you are using auto-registration, you can use a mask value in this field instead of an individual number, and it saves you some data entry. (For information about auto-registration, see Chapter 3.)

For example, assume your system uses four-digit directory numbers. Furthermore, your site does not require overlapping dial plans (as might be required for multiple tenants) and it is small enough that it is served by a single area code and office code (say, 214 and 555, respectively). When you specify the mask 214555XXXX under the Auto-registration Information section on the Cisco CallManager Configuration page, when a new device registers, CallManager automatically assigns it the external phone number mask 214555XXXX. When it receives its directory number (say, 1212), this configuration tells CallManager that the newly registered line's external phone number is 2145551212. If you also check the Use External Phone Number Mask check box for the route pattern that routes calls to the PSTN, CallManager presents your users' full external numbers to the PSTN when they place calls.

The external phone number mask also provides you with a means by which you can hide the external phone number of your users when they place external phone calls. If you set a phone's external phone number mask to your switchboard number and then check the Use External Phone Number Mask check box on the route pattern you use for routing external calls, CallManager presents the switchboard number as the calling phone's calling number.

Prefix Digits

These fields crop up under slightly different names in many of the devices. You can usually find these fields by clicking specific ports in the gateway configuration page.

Prefix Digits can contain a sequence of digits (*, #, 0 through 9). CallManager Administration also calls this field Prefix DN. Prefix Digits can contain a sequence of digits (*, #, 0 through 9). When a gateway configured with prefix digits receives a call from an associated gateway, CallManager modifies the dialed digits by prepending the digits you specify to the dialed number. For example, if a gateway provides the dialed digits 1000 and you specify prefix digits of 3, CallManager modifies the dialed digits to 31000.

Some subtleties exist about how prefix digits operate with different types of gateways. When CallManager connects to a gateway using a digital telephony protocol such as H.323 or ISDN, inbound calls from these gateways usually provide all the digits the calling user dialed in the call setup attempt. This type of dialing is called enbloc dialing.

When CallManager connects to a gateway using an analog protocol or by a digital protocol such as MGCP, particularly when a POTS phone is connected to the gateway, the digits the user dials arrive from the gateway one by one. This type of digit collection is called overlapped dialing. When you configure prefix digits in conjunction with a gateway controlling a POTS station, CallManager immediately attempts to route the call based on the configured prefix digits. In the usual case, the prefix digits you specify are not sufficient for CallManager to select a destination, and CallManager waits for more digits from the calling user.

However, you can implement a hotline or Private Line Automatic Ringdown (PLAR) function with POTS phones by relying on CallManager's treatment of Prefix Digits. PLAR is a feature whereby CallManager can ring a specified extension the moment that a user places a call from a particular station.

PLAR works when the Prefix Digits you specify are sufficient to permit CallManager to immediately select a destination. In this case, CallManager immediately offers the call to the specified destination. For instance, if your enterprise has a security desk with number 61111, by configuring prefix digits of 61111 for an analog gateway with an attached analog phone, you cause CallManager to immediately ring the security desk when a user picks up the POTS phone.

Tip

The section "Hotline Functionality" describes a different way that you can configure PLAR, one that works with all devices but which requires a slightly more complicated configuration.

 

Expected Digits and Num Digits

The gateway settings Expected Digits and Num Digits work in tandem. Expected Digits tells CallManager how many digits you expect the calling user to be dialing. Num Digits tells CallManager how many of those digits are significant to selecting a destination.

Num Digits is the easier of these settings to explain. Its heritage is the trunk interfaces, where you can often predict which digits a connected network sends. On a trunk interface, these settings tell CallManager to expect to receive n digits, the last m of which are significant for routing purposes. For instance, the central office might provide seven digits as the called number, but because the first three digits are always the office code, you just want to use the last four digits to route the call. Configuring 7 for Expected Digits and 4 for Num Digits causes CallManager to ignore the first three digits sent by the central office. If your dial plan is reasonably simple, as is often the case if your enterprise is smaller than 1000 users, using Num Digits provides you a simple way to maintain a four- or five-digit dial plan for your internal phones. (If your enterprise needs to support a large number of users whose external numbers are connected to a large number of telephone exchanges, Num Digits is often not powerful enough to handle the routing of your inbound calls. The section "Extension Mapping from the Public to the Private Network" describes how you can use translation patterns to route your inbound calls.)

Although the Num Digits setting tells CallManager how many digits you want to keep, the Expected Digits setting tells CallManager how many digits the PSTN is going to send. When the gateway to which CallManager is connected uses enbloc dialing, the Expected Digits setting is superfluous; because the call setup attempt contains all of the digits the calling user dialed, CallManager can immediately use the Num Digits setting to extract the digits that you want to route with. Expected Digits is a setting applicable to gateways connected to CallManager by protocols that use overlapped dialing. In such instances, CallManager needs to know how many digits to collect before using the Num Digits setting to extract the digits you want to route with.

When you configure these settings for a station device, they behave identically to this setting on a trunk device. CallManager ignores the first few digits that the user dials and uses subsequent digits to route the call.

Attendant DN

Analog trunks are just like the analog phone lines that run into most people's houses. On an analog phone line, when a user goes off-hook, the phone closes the circuit from the central office to permit current to flow, and the central office prepares to place a call. In the case of tone dialing, the central office connects your line to a tone detector, which listens to the stream of tones that emanate as you dial your phone and converts them to dialed digits.

When you configure an analog gateway as an FXO analog port, CallManager plays the part of the central office. As a result, when CallManager detects that the trunk has been taken off-hook, it must dial a preconfigured number. This number is the Attendant DN. Attendant DN is a setting that is much like Prefix Digits, which is described in the section "Prefix Digits"; when a call comes in over the gateway, CallManager automatically provides the specified digits to the call routing component. If you do not provide such a number, Cisco IOS gateways play a dial tone for the caller so that the user can provide digits.

Significant Digits

Digital trunk devices support variants of the ISDN signaling protocol. ISDN differs from analog protocols in that ISDN endpoints interpret the voltage levels on the trunk as either on or off values. This interpretation allows CallManager to assign meanings to particular patterns of on and off values and receive information, such as the calling and called party, directly in the call attempt. Unlike the analog gateways, which must dial a preconfigured number, digital gateways receive called party information directly in the call setup message. CallManager can transform this information by using settings on the Gateway Configuration page for circuit-switched gateways and the Trunk Configuration page for IP trunk interfaces.

PRIs have no setting that corresponds to the Expected Digits settings because the call setup request usually encodes all the digits of the called number.

For PRI interfaces, the Num Digits setting (see the section "Expected Digits and Num Digits" earlier in the chapter) is actually configured using the Significant Digits field. The Significant Digits field presents you with options to select any number from 0 to 32 as well as the setting All. If you select All, CallManager processes all digits of the called number. However, if you specify any other setting, the number in the Significant Digits setting indicates how many of the final digits of the dialed number that CallManager should use to route the call. For example, if the Significant Digits is set to 4, when CallManager receives a call for 9725551212, CallManager truncates all but the last four digits and routes using the digits 1212.

When used in conjunction with overlapped receiving (see the section "SendingCompleteIndicator and OverlapReceivingForPriFlag"), the Significant Digits field might not operate as you expect. The Significant Digits setting operates only on the first batch of digits the calling gateway provides to CallManager. In overlapped receiving, the gateway does not provide all of the digits at once. In fact, the first message that the gateway sends to CallManager often contains no digits at all. As a result, CallManager probably will not suppress any of the digits coming in from the gateway.

For example, assume you have set Significant Digits to 4 and the gateway provides the digits 9725551212 one digit at a time. The first digit (9) arrives and CallManager applies the Significant Digits setting to it. Because the Significant Digits setting specifies to keep four of the initial digits, CallManager keeps the first digit. Then CallManager passes through all of the subsequent digits without complaint. Had all of the digits arrived in the call setup, CallManager would have truncated 9725551212 to 1212. When using overlapped receiving, unless you know that the initial setup that the gateway sends to CallManager contains more digits than the Significant Digits setting, do not use the Significant Digits setting.

Transformations in Translation Patterns, Route Patterns, and Route Lists

This section describes the second through fourth opportunities during which CallManager can apply transformations as part of the routing process. The second opportunity occurs if the dialed digits match a translation pattern, the third occurs when a route pattern is ultimately selected, and the fourth occurs if the selected destination is a route list.

The section "Translation Patterns" describes translation patterns, and the section "Call Hunting Constructs" describes route lists. However, it is worth noting here that the transformations associated with a route list override those that the route pattern applies. That is, although other dialing transformations you apply have a cumulative effect, the transformations you specify on a route between a route list and a route group undo any transformations that the Route Pattern Configuration page applies. This capability allows you to define default dialing transformations on the route pattern, which you selectively override if a call goes out a particular set of gateways. For instance, in North America, long distance carriers expect to receive ten digits for calls to the PSTN. However, local carriers expect the digit 1 to precede long distance calls. Typically, to save costs, enterprises prefer their long distance calls to route directly to a long distance carrier. However, if all gateways to the long distance carrier are busy, by using a route list, you can route the call to a gateway connected to a local carrier as an alternate choice. In such a case, you could define dialing transformations on the route pattern to throw away the access code and long distance 1 that the user dials so that calls to the long distance carrier consist only of 10 digits. If the route list determines that all gateways to the long distance carrier are busy, however, by setting different dialing transformations on the route group containing gateways to the local carrier, you can cause CallManager to discard only the access code and keep the initial 1 on the long distance call.

To prevent a particular route group from overriding the transformations you associate with a route pattern, leave the transformation mask fields of the route group empty and be sure to select rather than NoDigits for digit discarding instructions.

Called Party Transformations

Three types of called party transformations can be configured in the call routing component and on route lists. They are as follows:

• Digit discarding instructions, which you use primarily with the @ wildcard and allow you to discard meaningful subsections of numbers in the national network. They are critical for implementing toll-bypass solutions, where the long distance number that the calling user has dialed must be converted into a local number from which CallManager passes the digits to the PSTN.
• Called party transformation mask, which allows you to suppress leading digits, change existing digits while leaving others unmodified, and insert leading digits.
• Prefix digits, which allow you to prepend one or more digits to the called number.

CallManager applies the transformations in the order listed.

Digit Discarding Instructions

Digit discarding instructions allow you perform conversions of a dialed number specific to a national numbering plan. For the North American numbering plan, you can strip access codes, suppress long distance carrier selection, convert numbers to achieve toll-bypass operations, and strip trailing # from international number sequences. Because digit discarding instructions are dial-plan specific, this section describes only those digit discarding instructions that apply to the North American numbering plan.

In general, digit discarding instructions apply only to route patterns that contain the @ wildcard. However, you can use the digit discarding instruction PreDot with route patterns that use the . wildcard even if they do not contain the @ wildcard.

Digit discarding instructions consist of one or more of the following identifiers grouped into three sections. The access code section lets you remove initial digits from a dialed string. The toll- bypass section allows you to turn dial strings that represent long distance calls into dial strings that represent local calls. Finally, the trailing-# instruction lets you strip a dialed end-of-dialing terminator from international calls to prevent it from going to an adjacent network (which might have trouble processing it).

Digit discarding instruction identifiers are additive, so the digit discarding instruction PreDot 10- 10-Dialing combines the effects of each individual identifier. If you do not want to discard any digits, select NoDigits.

Table 2-41 describes the groups and identifiers and provides sample dialed digit strings. Substrings in bold denote which digits CallManager discards.

Table 2-41. Digit Discarding Instructions Groups and Identifiers

Instructions	Discarded Digits (for Route Pattern 9.8@)	Used For
Access Code
PreDot	98 1 214 555 1212	Stripping access codes
PreAt	98 1 214 555 1212	Stripping access codes
Toll Bypass
11/10D->7D	98 1010321 1 214 555 1212	Toll bypass to a seven-digit dialing region
11D->10D	98 1010321 1 214 555 1212	Toll bypass to a 10-digit dialing region
IntlAccess IntlDirect Dial	98 011 33 0123456789 #	Removal of international access codes for routing by globally significant number
IntlTollBypass	98 011 33 0123456789#	Toll bypass from country to country
10-10-Dialing	98 1010321 1 214 555 1212	Long distance carrier code suppression
Trailing-#
Trailing-#	98 011 33 0123456789 #	Suppression of end-of-dialing character

 

Called Party Transformation Mask

Values in this field can truncate or expand the dialed digit string and change individual digits before CallManager sends the digits to a connected network or device. The section "About Masks" discusses mask operation.

Prefix Digits

This field can contain *, #, or digits 0 through 9. CallManager prepends this field to the called number before it is sent to the next stage of the routing process.

Calling Party Transformations

Three types of calling party transformations can be configured in the call routing component and on route lists:

• Use External Phone Number Mask check box, which instructs the call routing component to use a calling station's external phone number rather than its directory number as the calling number
• Calling party transformation mask, which allows you to suppress leading digits, change existing digits, leave other digits unmodified, and insert leading digits
• Prefix digits, which allow you to prepend the specified digits to the calling number

CallManager applies the transformations in the order listed.

Use External Phone Number Mask Check Box

Setting this flag sets the calling number to the external phone number mask configured on the calling line, rather than the directory number of a calling line. See the section "About Masks" for details about the ways that masks work and the section "External Phone Number Mask" for more details about the external phone number mask.

If no external phone number mask is configured on the calling line, or if the call originates from a device that does not have an external phone number mask setting, the call routing component uses the directory number (in the case of calling user devices) or the provided calling number (in the case of calling trunk devices) instead.

Calling Party Transformation Mask

Values in this field can truncate or expand the calling number and change individual digits before CallManager sends the calling number to a connected switch or device. The section "About Masks" discusses mask operation.

The section "External Phone Number Mask" describes one method by which you can cause PSTN users to see your company switchboard's number as the calling number, rather than the direct number of your users when they place calls to the PSTN. Calling party transformation masks provide another method. By specifying your switchboard's number as a calling party transformation mask in the Route Pattern Configuration page, you cause CallManager to replace the calling user's calling number with that of the company switchboard. Alternatively, providing a mask value such as 972813XXXX can permit you to present a fully qualified national number (such as 9728131000) to the PSTN when a directory number (such as 1000) places a call.

Prefix Digits

This field can contain *, #, or digits 0 through 9. CallManager prepends this field to the calling number before sending it to the next stage of the routing process. Prepending digits can permit you to fully qualify the calling numbers CallManager presents to the PSTN or add access codes to calls you present to connected PBXs.

Transformations on the Terminating Device

Trunk devices have settings that relate to the calling and called numbers. The settings described in this section correspond to the fifth and final place in CallManager where transformations can occur in the call routing process. Table 2-42 describes the dialing transformations and provides a checklist of which settings affect which gateways.

Table 2-42. Supported Terminating Device Dialing Transformations by Device Type

Terminating Device Dialing Transformation	SCCP Station Devices	MGCP Station Devices	H.323 Station Devices	SCCP Trunk Devices	MGCP Trunk Devices	H.323 Trunk Devices
Caller ID DN					[1]
Calling Party Selection					[1]
Calling Line ID Presentation					[1]
Called Party IE Number Type					[1]
Calling Party IE Number Type					[1]
Called Numbering Plan					[1]
Calling Numbering Plan					[1]
Number of Digits to Strip					[1]
Display IE Delivery					[1]
Redirecting Number IE Delivery Outbound					[1]
Send Calling Name in Facility IE					[2]
Connected Line ID Presentation					[1]

[1] T1-PRI and E1-PRI interfaces only

[2] T1-PRI interfaces only

Caller ID DN

Caller ID DN provides a mechanism to set the calling number of calls that CallManager extends to a gateway. It is a mask value (see the section "About Masks"). Values set in this field operate on the calling number that previous transformation steps generate.

Calling Party Selection

Calling Party Selection has one of three values:

• Originator
• First Redirect Number
• Last Redirect Number

This setting determines what number is presented as the calling number when call forwarding occurs.

If no forwarding at all has occurred, all three values contain the calling number of the originator. If CallManager has forwarded the call once, both the first redirect number and last redirect number are the calling number of the forwarding phone, while the originator is the calling number of the originator. If CallManager has forwarded the call twice, the originator is the calling number of the calling user, the first redirect number is the calling number of the first forwarding phone, and the last redirect number is the calling number of the last forwarding phone. If the call forwards more than once, the last redirect number reflects the calling number of the last device to forward the call.

Why would you set this field? If the system that the gateway is connected to is in charge of maintaining the billing records for calls from CallManager, you might want to bill not the actual originator of a call, but the party that caused the call to forward out the gateway. If the adjacent system uses the calling number to determine who to bill, this setting effectively allows you to control the billing.

Calling Line ID Presentation

This setting has values of None, Allowed, and Restricted. If set to None or Allowed (either value has the same effect), this setting indicates to the attached network that the called party is allowed to see the calling number. If this field is set to Restricted, the called party is prohibited from seeing the calling number.

Called Party IE Number Type

This setting has values of Cisco CallManager, Unknown, National, International, and Subscriber. The setting dictates how CallManager represents the called number to the network to which the gateway provides access.

Calls to ISDN networks include not only the dialed digits but also an indication of what the calling system believes the numbers represent. The Type of number field indicates to the system that receives the call whether the digits provided represent a national number, an international number, or whether the calling system even knows what the nature of the dialed number is. Although this setting was a nice idea on the part of the architects of ISDN, in practice, it (and its brethren, Calling Party IE Number Type, Called Party Numbering Plan, and Calling Party Numbering Plan) usually just causes problems. For example, one setting that the ISDN messages permit is Private, which represents to the called system that the calling system believes the provided digits are a number on a privately owned network. PSTN systems may decide that they do not want to route calls tagged with the type of number Private, even if the actual digits contained in the call setup represent an actual PSTN number. Conversely, if the PSTN is providing you with a Centrex service (in which the PSTN operates as a PBX so that you can network remote offices), the PSTN might require the type of number be encoded as Private for an interoffice call, even if the provided digits are sufficient to allow the PSTN to route the call to a remote office. In summary, even if the digits you provide are correct, the system to which you offer the call might reject the call if the Type of number field is not what it expects. Therefore, CallManager provides settings to permit you to control the Type of number and Numbering plan fields in case the network to which you connect your gateway is particular about the encoding of these fields.

By default, this value is set to Cisco CallManager, which means CallManager fills in this number as best it can. This setting usually works fine. If the pattern the calling user dials matches an @ pattern, CallManager fills in the number as national or international based on the numbering plan (see the section "The North American Numbering Plan"). For non-@ patterns, CallManager punts and encodes the number as Unknown.

If an attached network has problems with the number type that CallManager encodes, changing this setting may resolve the problem. Particularly if you live in a country that does not use the North American numbering plan and you have configured specific route patterns to route calls out gateways, you might find that the PSTN balks at CallManager's encoding of the number type as Unknown. Changing this setting to National can resolve the problem.

Calling Party IE Number Type

This setting has values of Cisco CallManager, Unknown, National, International, and Subscriber. The setting dictates how CallManager represents the calling number to the network to which the gateway provides access.

By default, CallManager encodes the number as Unknown, and this setting works in most cases. If an attached network has problems with the number type that CallManager encodes, changing this setting may resolve the problem.

Called Numbering Plan

ISDN networks expect telephone systems to provide not only the number type of a called number, but also the numbering plan it believes the number applies. This setting has values of Cisco CallManager, ISDN, National Standard, Private, and Unknown.

By default, CallManager encodes the number as ISDN. If an attached network has problems with the default numbering plan that CallManager encodes, changing this setting can resolve the problem.

Calling Numbering Plan

This setting has values of Cisco CallManager, ISDN, National Standard, Private, and Unknown.

By default, CallManager encodes the number as ISDN. If an attached network has problems with the default numbering plan that CallManager encodes, changing this setting can resolve the problem.

Number of Digits to Strip

Setting this value instructs CallManager to strip the specified number of digits from the beginning of all called numbers before passing the call to an adjacent network. If you administer a network in a country with a variable-length dialing plan, you might find this setting useful, because the discarding mechanisms that digit discarding instructions (see the section "Digit Discarding Instructions") provide are not available, and because called party transform masks enable you only to truncate a number to a fixed number of final digits.

Display IE Delivery

This setting controls the delivery of the display information element (IE). The display information element permits a telephone system to ask another system to display the contained information. Many telephone systems use it to communicate the display name of the calling user. When you enable this option for a particular gateway, CallManager places the contents of the Display field (on the Directory Number Configuration page) into the display information element before CallManager extends a call to the attached gateway.

Redirecting Number IE Delivery

This setting controls the delivery of the redirecting number information element. Suppose that a phone on a telephone system calls another phone on the same telephone system, and the call forwards to different telephone system that manages the voice messaging system for the enterprise. The new telephone system needs to know what directory number the caller originally dialed so that the voice messaging system can deliver the caller's voice message to the correct voice messaging box number. The redirecting number information element permits one telephone system to communicate this information to another. Enabling this flag permits CallManager to communicate the original dialed number to the connected network.

Translation patterns are a mechanism that allows you to introduce a level of routing indirection into the call routing process. They allow you to define aliases for the endpoints in your network.

Why do you need to define such aliases? This section discusses a few reasons:

• Security desk and operator functionality
• Hotline functionality
• Extension mapping from the public to your private network
• Insertion of access codes in the Received Calls and Missed Calls menus of Cisco IP Phones
• Multiple-tenant applications

You configure translation patterns almost exactly like route patterns. They have the same calling and called party transformations, and they use the same wildcard notation.

Unlike route patterns, translation patterns do not correspond to a physical or logical destination. Instead, a translation pattern relies on the calling and called party transformations to perform its function. Although route patterns use transformations simply a way to change the presentation of the calling or called parties, translation patterns use the results of called party transformations as a set of digits for a new analysis attempt. CallManager then uses the results of the second analysis attempt to determine which destination to ring.

The second analysis attempt might itself match a translation pattern. In this case, CallManager applies the calling and called party transformations of the matching translation pattern and uses the results as the input for another analysis attempt. To prevent routing loops, CallManager breaks chains of translation patterns after ten iterations.

An example might help to explain. Imagine that you have the translation patterns and route patterns listed in Table 2-43.

Configured Translation and Route Patterns

Translation Pattern: 1XXX

Called Party Transformation Mask: 2XXX

Translation Pattern: 2XXX

Prefix Digits: 8

Route pattern: 8.XXXX

Gateway: Gateway A

 

When a user dials the number 1000, this configuration causes CallManager to offer the user's call to Gateway A with a called number of 82000. This process consists of the following steps:

Step 1.	The dialed digits 1000 match the translation pattern 1XXX. CallManager applies the called party transformation mask 2XXX to the dialed digits 1000, yielding 2000.
Step 2.	CallManager uses the resulting number, 2000, as the input for another analysis attempt. This attempt matches the translation pattern 2XXX. CallManager applies the prefix digit 8 to the digits 2000, yielding 82000.
Step 3.	CallManager uses the resulting number, 82000, as the input for another analysis attempt. This attempt matches the route pattern 8.XXXX. CallManager offers the call to Gateway A, the gateway associated with the route pattern.

One configuration field that appears for translation patterns, but which does not appear for route patterns, is calling search space. When the new analysis is attempted, the analysis is attempted using the calling search space configured for the translation pattern, rather than the calling search space of the originating device. This behavior can allow a user to call a number in a partition that the user's calling search space would not normally permit the user to dial. The section "Calling Search Spaces and Partitions" describes calling search spaces and partitions.

Translation patterns, therefore, differ from route patterns; when route patterns match, CallManager always extends the call to the destination associated with the route pattern. The dialing transformations that CallManager applies have a purely cosmetic effect in that they change the calling number and called number, but do not cause CallManager to select a different destination. (However, if the destination to which CallManager offers the call is a gateway or other CallManager cluster, the gateway or CallManager cluster can use the transformed called number to decide where to route the call.)

On the other hand, translation patterns have no associated destination. The called party number transformations that CallManager applies do directly affect which destination CallManager selects, because CallManager uses the results of the transformation to select a new destination. The new analysis attempt might match a route pattern or directory number, or the attempt may match another translation pattern, in which case CallManager attempts another analysis. Figure 2-10 presents a flowchart of this process.

Figure 2-10. Translation Pattern Flowchart

 

The rest of this section describes different translation pattern configurations:

• "Security Desk and Operator Functionality" discusses a mechanism by which you can associate an easily remembered directory number with an emergency service, while maintaining a fixed-length directory number plan.
• "Hotline Functionality" discusses a mechanism by which you can automatically ring a particular extension when a phone goes off-hook.
• "Extension Mapping from the Public to the Private Network" describes how you can map the discontinuous number ranges that the telephone company might assign you to a contiguous range for internal extensions.
• "Insertion of Access Codes in the Received Calls and Missed Calls Menus of Cisco IP Phones" describes how you can use translation patterns to insert outside access codes for calls that your users receive. Inserting the access codes allows your users to use the Dial softkey on the Received Calls and Missed Calls menus of their IP Phones. Normally, users must use the EditDial softkey to modify the number of a received or missed call in order to return a received or missed call.
• "Multiple-Tenant Applications" discusses a few strategies that use translation patterns to deal with the problems that arise when different organizations with independent dial plans share a single CallManager.

Security Desk and Operator Functionality

The operator or security desk is often just a phone in your network with a standard four- or five- digit extension. However, for the desk to be useful with the least amount of hassle for your users, it is desirable to be able to assign these special extensions a directory number that is out of the ordinary (such as 0) and thus easier for your users to remember in an emergency.

One way to accomplish this task is, of course, to assign unusual directory numbers directly to these stations. However, having unusual directory numbers in a particular number block makes configuration of inbound routing more complex. Inbound calls often route based on the last four or five digits of an externally published number. If you want these special stations to receive inbound calls for other networks, you have to configure special routing to convert very specific extension numbers to your unusual numbers.

Translation patterns allow you to give numbers that are compatible with the rest of your numbering plan to these special stations, but to assign them aliases in the cluster. This allows your users to have easy-to-remember emergency numbers without the pain of configuring all ingresses to the cluster with special routing instructions.

To configure a dialing alias, specify the alias as a translation pattern and make sure that calling users include the partition that contains the translation pattern in their calling search spaces. In the called party transformation mask, enter the extension that you want to be called. In the translation calling search space, enter a calling search space that contains the partition associated with the destination extension. Figure 2-11 shows a security desk example.

Figure 2-11. Security Desk Example

 

The example relies on the provision of the translation and route patterns in Table 2-44.

Table 2-44. Security Desk Example Patterns

Configured Route and Translation Patterns	Comments
Partition: CompanyABC Translation pattern: 0 Translation calling search space: CompanyABC Called party transformation mask: 5123	Translation calling search space CompanyABC contains partition CompanyABC.
Partition: CompanyABC Route pattern: 5123	5123 is a phone with directory number 5123. CallManager considers directory numbers as route patterns, and these can be the destination that a translation pattern selects.

 

When the calling user dials 0, CallManager performs the following steps:

Step 1.	The dialed digit 0 matches the translation pattern 0. CallManager applies the called party transformation mask 5123 to convert the called number to 5123.
Step 2.	CallManager uses the resulting number, 5123, as the input for another analysis attempt. This attempt matches the security phone's directory number. CallManager offers the call to the security phone with dialed digits of 5123.

Hotline Functionality

A hotline or private line automatic ringdown (PLAR) configuration causes a specified destination to ring immediately when the hotline extension goes off-hook. It is simply a special case of an operator configuration.

In an operator configuration, translation patterns cause the operator extension to ring when a single digit is dialed. In a hotline configuration, the specified destination rings before a user dials any digits. By specifying a translation pattern containing no digits, you can cause the transformation and reanalysis to occur immediately after the user takes the phone off-hook.

The only wrinkle is that of interdigit timing. Translation patterns always have urgent priority, which means that as soon as the user enters a digit sequence for which a translation pattern is the best match, the call routing component applies the translation immediately, even if subsequent digits would cause a different route pattern to match. This behavior means that if you configure a hotline translation pattern and group it in the same route partition as all of your other route patterns and directory numbers, whenever any device goes off-hook for any reason, the hotline extension rings. Users never have the opportunity to dial any digits.

To prevent this behavior from occurring, you must put the hotline translation pattern in its own partition and configure the hotline extension's calling search space so that it looks in the hotline partition to resolve its analysis requests. The section "Calling Search Spaces and Partitions" discusses calling search spaces and partitions. Figure 2-12 shows an example of hotline configuration.

Figure 2-12. Hotline Configuration

 

The example relies on the provision of the translation and route patterns in Table 2-45.

Table 2-45. Hotline Configuration Example Route Patterns

Configured Route and Translation Patterns	Comments
Partition: Hotline Translation pattern: Translation calling search space: CompanyABC Called party transformation mask: 5123	Translation calling search space CompanyABC contains partition CompanyABC.
Partition: CompanyABC Route pattern: 5123	5123 is a phone with directory number 5123. CallManager considers directory numbers as route patterns, and these can be the destination that a translation pattern selects.

 

When the calling user whose calling search space includes the Hotline partition goes off-hook, CallManager performs the following steps:

Step 1.	When the user goes off-hook, this provides CallManager with an empty set of dialed digits, which match the translation pattern in the Hotline partition. CallManager applies the called party transformation mask 5123 to convert the called number to 5123.
Step 2.	CallManager uses the resulting number, 5123, as the input for another analysis attempt. The calling search space that CallManager uses for the analysis attempt is the calling search space of the translation pattern, Company ABC. This attempt matches the hotline's directory number. CallManager offers the call to the hotline phone with dialed digits of 5123.

Extension Mapping from the Public to the Private Network

If your campus grows past 1000 users, you might need to use translation patterns to preserve your internal extension numbering scheme. Local phone carriers often sell numbers in blocks of 1000. For example, if a single exchange serves your campus, the phone company might lease you the block of 1000 numbers from 813 5000 to 813 5999.

So long as you do not exceed 1000 users, it is possible to use gateway settings to map the block of 1000 users that the phone company assigns you to your internal numbering scheme. For example, if you prefer your users to be in the numbering range 8000 to 8999, when the PSTN provides 813 5XXX as the called number, you can use dialing transformations on the Gateway Configuration page to strip all but the final three digits and prepend an 8 (see the section "Transformations on the Originating Device").

However, if your network grows past 1000 users, there is no guarantee that the next block of 1000 numbers that the phone company assigns you will be contiguous with your previous range. In fact, even if the same central office serves you, the phone company might assign you a different exchange number. At this point, performing a transformation in the gateway does not work.

For instance, suppose that the phone company has given you two ranges, 555 5XXX and 555 9XXX. You can no longer just keep the last three digits and prepend 8 in the Gateway Configuration page, because a call to 555 5000 and a call to 555 9000 both get transformed to the directory number 8000.

However, if you choose to keep the final four instead of the final three digits, the discontinuity of the numbering range affects your internal numbering plan. A call to 555 5000 is transformed to 5000, while a call to 828 9000 is transformed to 9000. Setting aside for a moment that your existing users (who were in the range 8000 to 8999) can no longer receive calls until you renumber them to the 5000 range, the split numbering range at the central office is now visible to your internal network. If you have previously set up an initial steering digit of 5 for features such as call park or for intercluster calls, the split numbering range might force you to reorganize your numbering plan, probably to the frustration of your users.

On the other hand, anticipating that your campus might grow to beyond 1000 users, if you keep the 7000 to 7999 range open (or better yet, assign users five-digit directory numbers), by using translation patterns, you can map inbound calls in the 555 5XXX range to the internal 8XXX range while directing inbound calls in the 555 9XXX range to the internal 7XXX range.

To configure this setup, perform no transformations at the inbound gateway. Instead, set up two translation patterns in a partition visible only to your inbound gateways (see the section "Calling Search Spaces and Partitions"). Set one translation pattern to 555 5XXX with a called party transformation mask of 8XXX, and set the other translation pattern to 555 9XXX with a called party transformation mask of 7XXX.

When an inbound call arrives in the 555 5XXX range, the corresponding translation pattern matches, and CallManager transforms the called number to 8XXX. Then, because translation patterns cause reanalysis to occur, CallManager uses the transformed digits to select the actual destination to ring. Figure 2-13 shows the behavior that occurs when a call comes in for 555XXXX.

Figure 2-13. Transforming Inbound Calls to Deal with a Discontinuous Numbering Range

 

The example relies on the provision of the translation and route patterns in Table 2-46.

Table 2-46. Patterns for Transforming Inbound Calls to Deal with a Discontinuous Numbering Range

Configured Route and Translation Patterns	Comments
Partition: InboundTranslations Translation pattern: 5555XXX Translation calling search space: CompanyABC Called party transformation mask: 8XXX	Translation calling search space CompanyABC contains partition CompanyABC.
Partition: CompanyABC Route pattern: 8123	8123 is a phone with directory number 8123. CallManager considers directory numbers as route patterns, and these can be the destination that a translation pattern selects.

 

When the PSTN sends a call through the gateway to 5558123, CallManager performs the following steps:

Step 1.	The gateway provides CallManager with the digits 5558123, which matches the translation pattern 8135XXX in the InboundTranslations partition. CallManager applies the called party transformation mask 8XXX to convert the called number to 8123.
Step 2.	CallManager uses the resulting number, 8123, as the input for another analysis attempt. The calling search space that CallManager uses for the analysis attempt is the calling search space of the translation pattern, Company ABC. This attempt matches the phone with directory number 8123. CallManager offers the call to the phone with dialed digits of 8123.

The preceding translation patterns suffice for a company of up to 1000 users. If your network grows past 1000 users and the phone company gives you numbers in the 828 9XXX range, by adding the following translation patterns, you can map the 9XXX range (which probably overlaps with your outside access code) to 7XXX. Table 2-47 shows the translation pattern that maps the new range.

Table 2-47. Translation Pattern for Transforming Inbound Calls to Deal with a Discontinuous Numbering Range

Configured Route and Translation Patterns	Comments
Partition: InboundTranslations Translation pattern: 5559XXX Translation calling search space: CompanyABC Called party transformation mask: 7XXX	Translation calling search space CompanyABC contains partition CompanyABC.

 

Directory Number Lengths and CallManager

CallManager has no particular reliance on four-digit directory numbers. You can use any number of digits for your internal extensions and adjust the translation tables appropriately. For example, if the example network this section presented used 5-digit extensions in the range 50000 to 51999, changing the translation pattern 5555XXX to use a called party transformation of 50XXX maps inbound calls in the 5XXX of the 813 exchange to number ranges 5000050999. Similarly, changing the translation pattern 5559XXX to use a called party transformation of 51XXX maps inbound calls in the 9XXX range of the 555 exchange to number ranges 51000 to 51999.

 

Insertion of Access Codes in the Received Calls and Missed Calls Menus of Cisco IP Phones

Cisco IP Phones 7905, 7912, 7920, 7940, 7941, 7960, 7961, 7970, and 7971 provide users a directories button with several menu items, among them Missed Calls and Received Calls. When a user receives a call, the phone places the calling number in the Missed Calls menu if the user does not answer the call, and the Received Calls menu if the user does answer the call.

These menus also provide two softkeys: Dial and EditDial. Figure 2-14 shows a representation of the Missed Calls menu.

Figure 2-14. Missed Calls Menu of Cisco IP Phone

 

Pressing the Dial softkey causes the phone to place a new call by dialing the digits of the selected missed call entry. Unfortunately, in many cases, CallManager rejects calls placed using the Dial softkey, because a user's calling number is not always the same set of digits that a user must dial to return the call.

For instance, if a phone in the PSTN with number 408 555 1212 calls a phone controlled by CallManager in the Dallas area, the calling number that the Dallas phone receives is 408 555 1212, and thus the Dallas phone records 408 555 1212 in its Missed Calls or Received Calls menu. However, practically every enterprise requires an external access code such as 9 to provide access to an external line. Furthermore, in this example, the Dallas's phone return call is a long distance call, which the North American PSTN requires also to start with a 1. So although the phone receives 408 555 1212 as the calling number, to return the call, the Dallas phone must dial 9 1 408 555 1212.

This situation is complicated by the fact that for other types of calls, the return number needs to have just the access code without the 1. For instance, if phone connected to the Dallas PSTN with number 214 555 1212 calls a Dallas phone controlled by CallManager, to return the call, the Dallas phone must use an access code but omit the 1: 9 214 555 1212.

Finally some calls need neither an access code nor PSTN digits added. For instance, if phone 55123 in the Dallas enterprise calls phone 55004 in the Dallas enterprise, 55123 shows up as the calling number in the Missed Calls or Received Calls menu, and phone 55004 does not need to modify the stored digits at all to return the call.

The IP Phone has no way to predict which digits need to be added for which types of calls, and thus provides an EditDial softkey. When a user presses the EditDial softkey, the Cisco IP Phone allows the user to edit the stored number before it places the call. This permits the user to insert any necessary access codes and PSTN digits before placing the call. Unfortunately, it requires several additional button presses, which users find quite cumbersome.

CallManager provides two ways to deal with this problem. One way is via inbound transformations that always prepend a specific set of prefix digits (such as 91) and a set of outbound translations that strip these digits on a context-sensitive basis (such as rewriting these digits as 9 when the area code of the caller does not require an initial 1, but leaving both 9 and 1 when the area code of the caller must be dialed with a preceding 1). Another, clearly superior way if you can use it is via the following service parameters:

• National Number Prefix
• International Number Prefix
• Subscriber Number Prefix
• Unknown Number Prefix

These service parameters rely on the Type of Number field in the Calling Party Number information element supported by the PRI protocol. Service providers, particularly in Europe, might carefully classify the calling numbers of calls they offer to your enterprise. The following list summarizes the types of numbers:

• National numbers reflect addresses available in the host country's numbering plan.
• International numbers reflect addresses available in other countries' numbering plans.
• Subscriber numbers, in a called number, can represent other extensions served by the same exchange as your enterprise, but might also be used by service providers to indicate calls offered by branch offices connected via tie lines if you've subscribed to a Centrex service.
• Unknown numbers are otherwise unclassified numbers.

The service parameters specified in the preceding list enable you to define type-of-number- specific transformations of a calling party number. For instance, you could define International Number Prefix as 9011 and National Number Prefix as 91, in order to automatically prepend a 9011 to calls from outside of North America and 01 to calls from within the North American numbering plan. Because long distance direct dial digits are sometimes needed and sometimes not and because 10- versus 7-digit dialing can vary from North American city to North American city, this approach might not completely solve the problem, but for the variable-length numbering plans used by many European countries, this approach works fine.

Unfortunately, the only real good way to find out how your service provider is classifying calling numbers is to look at decoded traces. CallManager's CCM trace prints out decoded ISDN messages.

If your service provider isn't consistently classifying calling party numbers, your only recourse for permitting the one-touch redials from the Missed and Received Calls directory is to use a less optimal approach. Translation patterns can allow you to permit one-touch redials from the Missed and Received Calls directory because they give you an opportunity to modify the calling number before CallManager presents a call to an IP Phone. By modifying the calling number, you can insert the appropriate access codes and PSTN digits for calls to IP Phones in your enterprise.

Modifying the calling number does have consequences, though. Modifying the calling number means that when an IP Phone receives an external call, the displayed calling number will contain any access codes and PSTN digits. This solution permits you either to display the pure calling number and require the user to press the EditDial softkey for many calls, or to display a modified calling number and allow the user to press the Dial softkey for calls. Currently, you cannot have it both ways.

Configuring translations on inbound calls requires two separate steps.

First, you must modify the calling number for calls from the PSTN to CallManager, which causes CallManager to insert the appropriate access codes and PSTN digits.

Second, you must modify the called number for calls from CallManager to the PSTN. This step properly handles the insertion of PSTN digits. In the example above, calls from the PSTN come from both 408 555 1212 and 214 555 1212. The PSTN expects that calls dialed to the 408 area require a leading 1, while calls to the 214 area code require no leading digits at all. CallManager requires a leading 9 to distinguish calls to internal destinations from calls to external destinations. Therefore, for calls to the 408 area code, CallManager needs to prefix 91 for the IP Phone to return the call, and for calls to the 214 area code, CallManager needs to prefix just 9 for the IP Phone to return the call. However, both calls come in over the same gateway, and CallManager cannot look at the calling number to decide which digits to prefix. If CallManager prefixes just 9, the return call to 9 1 408 555 1212 fails because of lack of a required PSTN digit. If CallManager prefixes 91, the return call to 9 214 555 1212 fails because of an excess PSTN digit.

Configuring a translation for calls from CallManager to the PSTN permits you to indiscriminately prefix 91 for calls to CallManager. Then, for calls to the PSTN, you can eliminate the extraneous digits when needed for calls that do not require them.

The following example describes this procedure. Figure 2-15 shows the network that this section has already described, with two phones connected to a CallManager in Dallas, one phone connected to the Dallas PSTN, and one phone connected to the San Jose PSTN.

Figure 2-15. Sample Network for Access Code Insertion

 

Handling the translations for calls to a Dallas phone relies on the provision of the translation and route patterns in Table 2-48.

Table 2-48. Patterns for Inserting Access Codes for Calls to a CallManager Phone

Configured Route and Translation Patterns	Comments
Partition: InboundTranslations Translation pattern: 55XXX Translation calling search space: CompanyABC Calling party prefix digits: 91	CallManager inserts 91 before the calling number of calls from the PSTN. The translation calling search space CompanyABC contains the partition CompanyABC.
Partition: CompanyABC Route pattern: 55004	55004 is a phone with directory number 55004. This phone has a calling search space that contains partitions CompanyABC, OutboundTranslations, and PSTNGateways.
Partition: CompanyABC Route pattern: 55123	55123 is a phone with directory number 55123. This phone has a calling search space that contains partitions CompanyABC, OutboundTranslations, and PSTNGateways.
Partition: PSTNGateways Route pattern: 9.@	The gateway to the PSTN is in its own partition, to which phones do not have direct access. The gateway's calling search space contains the partition InboundTranslations. Assume for simplicity that the gateway throws away all but the final 5 digits of the called number that the PSTN provides for calls to CallManager.

 

When IP Phone 55004 dials 55123, CallManager performs the following step:

Step 1.

The digits 55123 match the directory number 55123 in the CompanyABC partition. CallManager delivers the call directly to IP Phone 55123 with 55004 as the calling number.
 

When San Jose phone [phone] dials 214 555 5123, CallManager performs the following steps:

Step 1.	The PSTN gateway throws away all but the last five digits of the number the San Jose user dialed, yielding 55123. The calling number that the PSTN provides is 408 555 1212.
Step 2.	CallManager uses the calling search space of the gateway to analyze the dialed digits. The digits 55123 match the route pattern 55XXX in the InboundTranslations partition. CallManager applies the calling party prefix digits of 91 to convert the calling number from 408 555 1212 to 9 1 408 555 1212. CallManager does not change the called number at all, because no called party transformations are configured for the translation pattern.
Step 3.	CallManager uses the unchanged called number, 55123, for another analysis attempt. This time CallManager uses the calling search space of the translation patternCompany ABCto perform the analysis. The digits 55123 match the directory number 55123 in the CompanyABC partition. CallManager delivers the call to IP Phone 55123 with 9 1 408 555 1212 as the calling number.

When Dallas phone [phone] dials 214 555 5123, CallManager performs the following steps:

Step 1.	The PSTN gateway throws away all but the last five digits of the number that the San Jose user dialed, yielding 55123. The calling number that the PSTN provides is 214 555 1212.
Step 2.	CallManager uses the calling search space of the gateway to analyze the dialed digits. The digits 55123 match the route pattern 55XXX in the InboundTranslations partition. CallManager applies the calling party prefix digits of 91 to convert the calling number from 214 555 1212 to 9 1 214 555 1212. CallManager does not change the called number at all, because no called party transformations are configured for the translation pattern.
Step 3.	CallManager uses the unchanged called number, 55123, for another analysis attempt. This time, CallManager uses the calling search space of the translation patternCompanyABCto perform the analysis. The digits 55123 match the directory number 55123 in the CompanyABC partition. CallManager delivers the call to IP Phone 55123 with 9 1 214 555 1212 as the calling number.

Using the preceding approach to translate outbound calls also enables you to use a hybrid approach for managing the Missed and Received Calls menus. This approach uses the numbering- plan-specific service parameters to translate the calling numbers of inbound calls but uses translation patterns to translate outbound calls. For instance, you could prepend 9011 to international calls and 91 to national calls, even if the return call might not necessarily require the long digit direct dial digit. Configuring outbound translations as in Table 2-49 could permit you to strip the superfluous digit while saving you from having to configure the inbound translations.

Table 2-49. Translation Patterns Used to Remove Excess PSTN Digits for Calls to the PSTN

Configured Route and Translation Patterns	Comments
Partition: OutboundTranslations Translation pattern: 91.214XXXXXXX	CallManager strips the preceding 91 for calls to the 214 area code and then uses the access code 9.
Translation calling search space: PSTNGateways DigitDiscardingInstructions: PreDot Called Party Prefix Digits: 9	Another way to configure this translation pattern uses route pattern 9.@ and a route filter with clause AREA-CODE == 214. The translation pattern then specifies the digit discarding instruction 11D->10D, which throws away the PSTN digit 1 while retaining the access code 9.

 

Figure 2-16 shows the Missed Calls menu that results from IP Phone 55123 receiving the three calls just described.

Figure 2-16. Missed Calls Menu Showing Transformed Numbers

 

Note that the call from IP Phone 55004 has no prefix digits added, although both of the calls from the PSTN have access code 9 and PSTN digit 1 added. In the case of the call from San Jose, the modified number is identical to the number that the user dials to call the San Jose phone. But in the case of the call from Dallas, the modified number includes PSTN digit 1. If the user dials the number as shown, the Dallas PSTN rejects the call because of the extra digits. Configuring an outbound translation eliminates this problem. Table 2-49 shows the translation pattern required to strip the excess PSTN digit from the local call.

When IP Phone 55123 presses the Dial softkey for the call with digits 9 1 408 555 1212, CallManager uses the calling search space of the IP Phone to analyze the dialed digits 9 1 408 555 1212. These digits match the route pattern 9.@ in partition PSTNGateways. CallManager delivers the call to the PSTN gateway with called number 9 1 408 555 1212.

However, when IP Phone presses the Dial softkey for the call with digits 9 1 214 555 1212, CallManager performs the following steps, which remove the extra PSTN digit:

Step 1.

CallManager uses the calling search space of the IP Phone to analyze the dialed digits 9 1 214 555 1212. These digits match both the route pattern 9.@ in partition PSTNGateways and the translation pattern 91.214XXXXXXX in partition OutboundTranslations. CallManager applies the digit discarding instructions of PreDot to convert the number from 9 1 214 555 1212 to 214 555 1212, and then CallManager applies the called party prefix digit of 9, yielding 9 214 555 1212.

Step 2.

CallManager uses the modified called number, 9 214 555 1212, for another analysis attempt. This time, CallManager uses the calling search space of the translation patternPSTNGatewaysto perform the analysis. The digits 9 214 555 1212 match route pattern 9.@ in the PSTNGateways partition. CallManager delivers the call to the PSTN gateway with called number 9 214 555 1212.

Multiple-Tenant Applications

In a multiple-tenant environment, one CallManager or CallManager cluster serves two or more independent organizations, each with its own numbering plan. The scope of responsibility of the person or organization managing the CallManager cluster can vary dramatically. At the small end of the scale is the landlord who provides the phone service for the tenants in the building (either commercial or residential). This type of deployment is termed multitenant. At the large end of the scale is the Internet service provider (ISP) or telephone service provider that manages a network of CallManagers and resells phone services to many companies with separate facilities, who may or may not have PBXs of their own. This type of deployment is called IP Centrex. The difference from a routing point of view is simply in amount of configuration; the basic call routing mechanisms used for both types of deployments are essentially the same. This book uses the term multitenant rather than IP Centrex when describing such deployments, and service provider when referring to the person or organization that provides multitenant services.

In a multitenant deployment, the numbering ranges for each organization might be completely isolated from each other, or they might have numbers in common, such as a security desk. Particularly because gateways are simply resources for placing calls to and receiving calls from other networks, two tenants can share gateways.

Extension Mapping for Multiple Tenants

Everything that applies to extension mapping for a single tenant applies for multiple tenants. If an inbound call arrives over a gateway, you must map the full externally published number to the proper internal extension number. Setting a calling search space on the translation pattern is extremely important here, because identical directory numbers that different tenants own must be treated as separate extensions instead of as a shared line appearance.

For example, assume there is a multiple-tenant environment in which a service provider uses one CallManager to route calls for company ABC and XYZ. Company ABC has an appearance of line 1000 registered in partition ABC, and company XYZ has an appearance of line 1000 in partition XYZ.

Company ABC's line 1000 is reachable from the PSTN as 828 8000, while company XYZ's line 1000 is reachable from the PSTN as 813 5000. The similar configuration to the one described in the previous section allows inbound calls to reach the appropriate station, though the calling search space must be set appropriately.

For example, assume that company ABC's external numbers are all in the 828 8XXX range, while company XYZ's are all in the 813 5XXX range. By eschewing any transformations in the gateways themselves, you can configure two translation patterns in a partition that only the gateway can see.

The first route pattern, 828 8XXX, uses a called party transformation mask of 1XXX. Furthermore, the translation calling search space for the translation pattern must be set to a calling search space that contains partition ABC but not XYZ.

The second route pattern, 813 5XXX, has an associated called party transformation mask of 1XXX. Its translation calling search space is set to a calling search space that contains partition XYZ but not partition ABC.

Figure 2-17 shows this configuration.

Figure 2-17. Extension Mapping for a Multitenant Configuration

 

Calls Between Tenants

A wrinkle of multitenant configurations that is not present for single-tenant configurations is that of calling between tenants. Independent tenants do not call each other using their internal directory numbers. To each tenant, the other tenant should be indistinguishable from a company that the PSTN serves.

This requirement means that not only the called party must be transformed for intertenant calls, but also the calling party must be transformed. Suppose user A at extension 1000 in company ABC calls user B extension 2000 in company XYZ. If the called party's missed calls display shows the call as coming from calling number 1000, when user B tries to call user A back by dialing 1000, user B instead reaches extension 1000 in user B's own company.

One way to handle this issue is not to handle it at all. When user A dials user B, user A dials user B's external number. If user A is allowed to make outbound calls, this call routes out a gateway to the PSTN, which in turn routes the call right back into the CallManager cluster as an external call. If you have configured extension mapping, user B's display reflects the correct information.

Unfortunately, this configuration wastes gateway resources. Furthermore, the PSTN charges you for a call that the CallManager cluster can connect on its own.

Translation patterns can resolve this problem. For calls among tenants of a cluster, one can define for each tenant translation patterns that transform the calling and called numbers appropriately and extend the call directly to the called party.

For example, assume user B's external phone number is 828 2000. User A probably dials this number after first dialing an access code, such as 9. The following steps allow user A's calls to route directly to user B:

Step 1.	Define the translation pattern 9 828 2XXX in a partition that is in user A's calling search space.
Step 2.	Set the called party transform mask to 2XXX.
Step 3.	Set the translation pattern calling search space to a calling search space containing partition XYZ but not ABC.
Step 4.	If you have defined external phone number masks for all of your station devices, check the Use External Phone Number Mask check box for the translation pattern; otherwise, set a calling party transformation mask of 813 XXXX.

When user A dials user B's external number, the dialed number gets transformed to user B's extension in company XYZ's partition. CallManager uses the results of this transformation for the reanalysis and extends the call directly to user B. The calling party transformation ensures that user B's display reflects user A's external rather than internal number.

User B should have a corresponding translation pattern for calls to company ABC. Figure 2-18 shows this configuration.

Figure 2-18. Calls Between Tenants