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

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.

[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.

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.

[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.

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.

[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.