In this example, a calling user goes off-hook and dials 1100. On collecting the final digit of the dialed digit string, CallManager selects exactly one route pattern and offers the call to the associated destination.

When the user goes off-hook, CallManager begins its routing process. The current set of dialed digits is empty. The set of current matches, currentMatches, is empty. Every route pattern in the table is a potential match at this point, so the condition of having potential matches, potentialMatches, is true. Table 2-3 shows the current set of potential matches. As long as potentialMatches holds true, CallManager must wait for more digits.

When the user dials 1, the state of affairs does not change. No current match exists, and every route pattern in the table is a potential match.

Dialing another 1 eliminates many route patterns as possible matches. The patterns 1200, 120X, 130, 1300, and 13! are no longer potential matches for the dialed digit string. The only route pattern that remains in contention is 1100. However, currentMatches is still empty and potentialMatches still holds true. Even though 1100 is the only route pattern that the user could dial that might result in a match, CallManager must wait until the user does, in fact, dial the full string. Table 2-4 shows the current set of potential matches.

The next 0 does not change the situation.

When the user dials the final 0, currentMatches contains route pattern 1100. Furthermore, as further digits would not result in a different route pattern matching, potentialMatches does not hold true. CallManager extends the call to the device associated with route pattern 1100. Table 2-5 shows the final set of potential matches.

In this example, a calling user goes off-hook and dials 1200. On collecting the final digit of the dialed digit string, CallManager determines that two route patterns match the dialed digit string and uses the closest matching routing algorithm to select which route pattern is awarded the call.

The closest match for a dialed digit string is simply the route pattern that matches the fewest number of digit strings of equal length to the dialed digit string. For example, though the route pattern 1000 matches exactly one dialed digit string, the route pattern 1XXX, which matches any dialed digit string in the range 1000 to 1999, matches 1000 possible dialed digit strings. In any comparison between route patterns 1000 and 1XXX, the closest match routing algorithm gives route pattern 1000 precedence.

The qualification “of equal length to the dialed digit string” in the preceding paragraph handles cases in which one or more of the route patterns being examined contains a wildcard that matches multiple dialed digits. For example, route pattern 1! matches any dialed digit string beginning with 1, and route pattern 13! matches any dialed digit string beginning with 13. The ! wildcard in these route patterns might match one, two, or more digits. As a result, the number of dialed digit strings that match either of these route patterns is infinite.

To decide among them, CallManager restricts the calculation of number of potentially matching dialed digit strings to only those of the same length as the dialed digit string itself. For instance, given the route patterns 1! and 13! and a dialed digit string of 13000, CallManager determines how many five-digit dialed digit strings could potentially match both route patterns. Thus, 13!, which matches 1000 five-digit strings, takes precedence over 1!, which matches 10,000 possible five-digit strings.

Returning to the example, when the user goes off-hook, CallManager begins its routing process. The current set of dialed digits is empty. The set of current matches, currentMatches, is empty. Every route pattern in the table is a potential match at this point, so the condition of having potential matches, potentialMatches, is true. As long as potentialMatches holds true, CallManager must wait for more digits. Table 2-6 shows the current set of potential matches.

When the user dials 1, the situation does not change. No current match exists, and every route pattern in the table is a potential match.

Dialing 2 eliminates route patterns 1100, 130, 1300, and 13! as possible matches. The patterns 1200 and 120X are the only route patterns that can match. Table 2-7 shows the current set of potential matches.

The next 0 does not change the situation.

When the user dials the final 0, currentMatches contains both route pattern 1200 and route pattern 120X. Furthermore, as further digits would not result in a different route pattern matching, potentialMatches does not hold true and CallManager must select a destination. Because 1200 is a closer match than 120X, CallManager extends the call to the device that owns route pattern 1200. Table 2-8 shows the final set of potential matches.

When a route pattern contains a wildcard that matches multiple digits, CallManager often must wait for an interdigit timeout to expire before it can route the call. This situation occurs because even if the route pattern containing the wildcard already matches, the user might intend to dial more digits. The most trivial example of this behavior is the route pattern !, which matches one or more occurrence of any number of digits. If a user dials 123 and matches the route pattern !, CallManager must continue to wait, because it has no assurances that the user is not planning to dial 1234. Routing the call prematurely might cause CallManager to send an incomplete dialed digit string to an adjacent network.

In the following example, a calling user goes off-hook and dials 1300. The route pattern 13! ensures that condition potentialMatches always holds true. Even if CallManager finds that route pattern 13! is the best match out of set currentMatches, CallManager must continue to wait, because it has no way of knowing if the user is really finished dialing.

In this example, when the user goes off-hook, CallManager begins its routing process. The current set of dialed digits is empty. The set of current matches, currentMatches, is empty. Every route pattern in the table is a potential match at this point, so the condition of having potential matches, potentialMatches, is true. As long as potentialMatches holds true, CallManager must wait for more digits. Table 2-9 shows the current set of potential matches.

When the user dials 1, the situation does not change. No current match exists, and every route pattern in the table is a potential match.

Dialing 3 eliminates route patterns 1100, 1200, and 120X as possible matches; however, 130, 1300, and 13! are still possible matches. Table 2-10 shows the current set of potential matches.

The next 0 causes currentMatches to contain route patterns 130 and 13!. However, potentialMatches holds true, because the user’s next digit might allow the same (13!) or a different (1300) route pattern to match. Table 2-11 shows the current set of potential matches.

The fact that route pattern 13! shows up in both the list of current matches and the list of potential matches needs explaining. When a route pattern ends with a multiple match wildcard (!, range expressions ending with ? such as [1-5]?, or range expressions ending with + such as [1-5]+), CallManager recognizes that even though the current dialed number matches the route pattern, the user might intend to dial more digits.

The final 0 eliminates route pattern 130 as a possible match. CurrentMatches contains route patterns 1300 and 13!. CallManager cannot attempt a closest match routing determination, however, because route pattern 13! not only matches the current digit string (1300), but also matches a longer digit string (13000). The ! wildcard at the end of a route pattern means that condition potentialMatches always holds true. Table 2-12 shows the current set of potential matches.

In such a case, the only event that allows CallManager to select a destination is an interdigit timeout. On receiving an interdigit timeout, CallManager knows that no more digits are forthcoming and can make a routing selection. In this example, after the timeout, CallManager selects route pattern 1300 using closest match routing rules. Table 2-13 shows the final list of potential matches.

CallManager uses two timers to manage the system interdigit timeout as described in the following paragraphs.

Because users who go off-hook might need to spend extra time to locate the address they want to dial (on a crowded directory lookup web page or in a printed directory), CallManager uses one timer to dictate how long it waits for users to dial an initial digit upon going off-hook. The service parameter Off-hook to First Digit Timer (msec) defines the duration of the initial digit timer in milliseconds. The default for this timer is 15,000 milliseconds.

Subsequent digits are controlled with the CallManager service parameter T302 Timer (msec). T302 Timer (msec) defines the duration of the interdigit timer in milliseconds. The default for this timer is also 15,000 milliseconds.

One feature of CallManager that can be surprising to administrators familiar with other call agents is that CallManager does not assign special significance to the * or # characters. CallManager treats these characters just as any other digit. On other systems, # is sometimes used as an explicit cancellation of the interdigit timeout.

For instance, when users are dialing international numbers, call agents typically cannot detect when the user has fully composed the dialed number, because doing so would require that the call agent have full understanding of every national dial plan in the entire world. When users of these systems (and CallManager) dial the international access code for the country they’re in (011 for the United States, 00 in many European countries), the system generally must rely on an interdigit timer to expire before routing the call.

Some systems treat the # key specifically as an indication from the user that the system should immediately route the call based on the digits the user has already provided.

In contrast, CallManager treats the # just like any other digit. On one hand, doing this permits you to use it at the beginning of dial patterns, to represent special abbreviated dialing sequences or access codes. On the other hand, it means that to replicate the use of # as an interdigit timer you might have to configure additional patterns.

The pattern 9.011! is a very typical pattern that a North American administrator would use to direct international calls to a PSTN gateway. This pattern matches digit strings beginning with 9011 and followed by at least one more digit 0 to 9. Because of the digit analysis rules described in section “Dialing Behavior,” CallManager routes the call only after the interdigit timer expires. CallManager must refresh the timer after each digit, because CallManager doesn’t know whether the user intends to continue dialing.

If the user dials #, according to the dialing rules, CallManager must apply reorder, because the ! wildcard specifically excludes the * and # digits from its list of matched digits. This behavior is similar to the treatment you receive if you define a pattern such as 12[1-4] (which matches the digit strings 121, 122, 123, and 124) and instead dial 125. 125 is not a digit string that is encompassed by 12[1-4], so CallManager rejects the call.

So, if you want to support the ability to use # as an interdigit timer, what can you do? Simply, you take advantage of CallManager’s standard dialing behavior, which treats # just like any other digit. If, in addition to 9011!, you define the pattern 9011!#, you can support not only cases where the user dials 9011+international number and waits for timeout but also cases in which the user terminates the dialed digit string with #.

This works because as long as the user is dialing digits after 9011, both provisioned patterns consist as potential matches. For instance, if the dialed digit string is 9 011 33 12 34 56 78 90, CallManager considers that pattern 9011! matches the currently provided digits but that it must also keep waiting because the user might dial another digit. On the other hand, while pattern 9011!# is not a current match, if the user were to provide another digit, this pattern might match.

If the user provides no further digits before the interdigit timer expires, CallManager routes the call based on pattern 9011!. Instead, if the user dials 9 011 33 12 34 56 78 90 #, the digits the user provides cease to match pattern 9011! (because ! doesn’t include the # character among its matching characters), but pattern 9011!# does match. Furthermore, because all other potential matches are removed from contention and because the final character of the pattern does not leave open the possibility that the user might provide more digits, CallManager routes the call immediately, which is exactly the behavior you desired when you added pattern 9011!#.

The previous section demonstrates that when you end a route pattern with a wildcard that matches multiple digits (! or range expressions ending in + or ?), CallManager must wait for the system interdigit timeout to expire before it can route the call. So why would you ever end a route pattern with a wildcard that matches multiple digits?

Many countries have variable-length national dialing plans. Unlike North America, in which the length of a public telephone number is fixed at 10 digits, countries with variable-length dial plans require users to dial a varying number of digits to identify a number in the PSTN. For instance, in Finland, a numbering area equivalent to a North American area code is called a telealue (TLA). Some TLAs are a single digit (2, 3, 5, 6, 9), while other TLAs are two digits (13, 14, 15, 16, 17, 18, 19). Within a TLA, different carriers own different number blocks, which range from three to five digits long. For instance, one carrier controls block 422 in TLA 19, while another carrier controls block 4251 in TLA 19. In other words, one carrier handles calls made from within Finland that begin with the six digits 019422; the other handles calls from within Finland that begin with the seven digits 0194251. (Users within Finland dial 0 before dialing the TLA.) Finally, subscriber numbers range from three to five digits long. As a result, the number of a Finnish resident is of an indeterminate length (in practice, eight or nine digits, but this value does not reflect mobile numbers or service numbers).

Because the number of digits in countries with variable-length numbering plans is so dependent on the particular digits dialed, such countries rely on overlapped sending in the PSTN to figure out how many digits to collect and where to route the call.

Overlapped sending is kind of like a bucket brigade. Figure 2-4 shows the principle under which overlapped sending works. Figure 2-4 depicts a network of four nodes (A, B, C, and D) and three users (1, 2, and 3). User 1 wants to call User 3, whose number is 0123333, composed of a one-digit region identifier (0), a three-digit node identifier (123), and a three-digit subscriber number (333). User 2’s number is 01244444, composed of a one-digit region identifier (0), a three-digit node identifier (124), and a four-digit subscriber number (4444).

Figure 2-4. Overlapped Sending in a Simple Network

In Figure 2-4, no single node in the network understands the complete dialing plan. Node A understands that when a user attached to node A dials 0, it should send the call to node B. When node B receives the call, it recognizes that it needs more digits to determine the final destination and asks node A to pass on any digits that node A receives from User 1.

Node B understands that it must collect three digits before it can route the call further. If the digits are 123, it routes the call to node C. If the digits are 124, it routes the call to node D.

Nodes C and D, in turn, manage their portions of the numbering plan. Node C understands that it must collect three digits to select a subscriber, while node D requires four digits to select a subscriber. When User 1 dials 0123, node B offers the call to node C.

Node C performs the same steps that node B does when it receives a call. Node C recognizes that it requires three digits to make a routing selection and asks node B to pass on any digits that node B receives from node A (which, in turn, receives them from User 1). When node C receives the last three digits, it routes the call to User 3. Thus, in the manner that water buckets pass from hand to hand in a bucket brigade until they reach the fire, digits pass from node to node until they reach the spot that needs them.

Versions of CallManager before release 3.1 do not support overlapped sending, but rather require that you provision knowledge of your entire network’s numbering plan as route patterns. This requirement is acceptable for numbers within your network and for public numbers in a fixed numbering plan (because, for example, you can just configure a pattern like 9.XXXXXXXXXX to handle all patterns in the North American numbering plan). But variable-length numbering plans require the configuration of large numbers of such patterns just to provide network access.

Hence, in CallManager releases 3.0 and earlier, if you were an administrator in a country with variable-length numbering plans, you had three options.

At the time of this writing, most administrators choose the third option, but also configure a few specific route patterns to handle numbers that their users often dial, relying on closest match routing to eliminate the interdigit timeout. Users strongly dislike long interdigit timeouts, because while CallManager is waiting for the timeout to expire, users think that something is wrong with the system. One approach to eliminate interdigit timeout is to use # as an interdigit timeout character. For example, assume that your external access code to a variable-length dialing plan is 0. If you configure 0!, when users dial any digit sequence beginning with 0, CallManager waits for interdigit timeout and then ships all dialed digits to the PSTN.

However, if you also configure 0!#, users who have been trained to terminate all external dialed number sequences with # can avoid the interdigit timeout. Because the ! wildcard matches only the digits 0 through 9, dialing # removes the 0! route pattern from contention, leaving only 0!#.

Because 0!# is not terminated with a wildcard that matches multiple dialed digits, condition potentialMatches ceases holding true and CallManager can route the call immediately. Pressing # is analogous to pressing the SEND button on a call made from a cell phone.

The good news is that CallManager release 3.1 and later supports overlapped dialing, rendering much of the advice in this section obsolete. If your PSTN supports overlapped sending, simply configure your route patterns with the steering code alone (without the trailing ! wildcard); when CallManager offers the call to the associated gateway or route list, the PSTN prompts CallManager to pass any further digits along.

The bad news is that CallManager supports overlapped dialing only for gateways with digital interfaces that use the Media Gateway Control Protocol (MGCP) protocol. If your network uses Cisco H.323 gateways for access to the PSTN, and your country uses a variable-length numbering plan, you must still choose from one of the three options this section presents.

Overlapped sending is built in to CallManager, but you must specifically indicate which patterns are candidates for overlapped sending. The route pattern setting Allow Overlap Sending tells CallManager whether it should consider the pattern as overlap-sending-capable.

Pre-4.0 versions of CallManager simply assumed that all patterns were overlap-sending-capable, but, as it turns out, this caused several problems. So long as digits arrived one at a time, it didn’t really matter, because when CallManager matched the locally-configured pattern, it would simply offer the call to the destination gateway. If the destination gateway required more digits, it would simply request them. In the meantime, CallManager would queue up any dialed digits.

But problems arose with creative dial plans. For instance, examine the patterns 1234, as associated with an IP phone and the pattern 1XXXXXX, as associated with a gateway that could support overlapped signaling.

Before CallManager 3.1, if you provided the dial string 1234567 to the call routing component of CallManager, CallManager would match pattern 1XXXXXX instead of pattern 1234, because too many digits had been provided to match 1234.

When CallManager implemented automatic overlap sending, it had to start queuing up any additional digits—just in case the destination happened to ask for more. So, after this automatic overlap sending behavior was implemented, dial plans started to break. When 1234567 was dialed, CallManager would assume that the digits 1234 more closely matched the IP phone and digits 567 should be queued up.

In practice, an IP phone would never ask for more digits to be sent to it for routing purposes. As a result, a series of fixes was phased in over releases to first exclude IP phones from participating in overlapped dialing and, then, because the problem could manifest across different gateways, to require you to specifically configure which gateways might ask for more digits and which ones will never ask for more digits.

As the preceding section mentions, when CallManager receives digits from the user, it waits to route the call until it is sure that it needs no more digits. A case in point is route patterns that end in a wildcard that matches multiple digits. CallManager must wait for the interdigit timeout to expire before it offers the call to the selected destination.

But if you need a call to route the very moment that a user provides sufficient dialed digits, you can use the Urgent Priority check box on the Route Pattern Configuration page to short-circuit the dialing procedure.

An urgent route pattern only has an observable effect if your dial plan contains overlapping route patterns. Your call routing plan contains overlapping route patterns if it is possible to dial a sequence of digits so that the call routing component can select a current match but must continue to wait for more digits because there are also potential matches. For example, if you assign directory number 99110 to a phone and also configure a gateway with route pattern 9.911 (for emergency services in North America), you create a dial plan with overlapping route patterns.

When a user in an emergency situation dials 9911, CallManager waits for the interdigit timeout to expire before routing the call, because CallManager does not know whether the user intends to dial 0 to complete a call to the station instead of the emergency response center.

You can use the Urgent Priority check box to protect yourself from this sort of configuration. By marking the 9.911 route pattern as urgent, you tell CallManager to route the call to the emergency center the instant that a user dials 9911. (Note, however, that in the example provided, marking the 9.911 route pattern as urgent has the side effect of preventing any user from dialing the phone with directory number 99110.)

Another common usage of the Urgent Priority check box comes into play for administrators in countries with variable-length numbering plans. The simplest configuration for countries with variable-length numbering plans is to configure a gateway with an outside access code (for example, 0) followed by the ! wildcard. However, this configuration introduces interdigit timeout into all external numbers that users dial. By configuring specific route patterns for numbers that their users commonly dial, administrators can eliminate the interdigit timeout for the commonly dialed patterns. Table 2-14 provides a sample configuration and explanation of a U.K. dialing plan.

Two points about urgent route patterns to note especially:

Another subject that the call routing procedure described in section “Dialing Behavior” omits is providing outside dial tone. Outside dial tone is an indication that users expect when CallManager routes their calls off of the local network. To apply outside dial tone, check the Provide Outside Dial Tone check box on the Route Pattern or Translation Pattern Configuration pages for each route pattern that you consider to be off-network. For dialed digit strings that can match those patterns, the call routing component then applies outside dial tone at some point during the dial sequence.

You cannot explicitly configure the point in the dialing sequence when CallManager applies outside dial tone. In addition, the decision to apply outside dial tone is completely independent of whether or where the route pattern contains a “.” wildcard (described in the section “. Wildcard”). Rather, the call routing component applies outside dial tone at the point when all potential matches for a dialed digit string have had their Provide Outside Dial Tone box checked.

For example, consider the route patterns 9000 and 91XXXXXXX. 91XXXXXXX belongs to a trunk device and has had its Provide Outside Dial Tone box checked. Table 2-15 shows these route patterns.

When a user goes off-hook, CallManager applies inside dial tone. Table 2-16 depicts the current dialing state.

The user dials 9 and CallManager turns off inside dial tone. At this point, CallManager cannot tell whether the user intends to dial the on-network number 9000 or the off-network number 91XXXXXXX, so it waits for the next digit. Table 2-17 depicts the current dialing state.

If the user then dials 1, CallManager eliminates the route pattern 9000 from its list of potential matches. At this point, all remaining candidates have had their Provide Outside Dial Tone box checked, and the call routing component chooses this moment to apply outside dial tone (see Table 2-18).

Now assume that an additional route pattern, 9124, has been configured. This route pattern could be a station device, call park, or Meet-Me conference code. Table 2-19 depicts this configuration.

The steps that CallManager takes when the user goes off-hook and dials 9 are identical to those in Example 1. However, Table 2-20 shows that when the user dials the subsequent 1, CallManager waits, because at least one of the route patterns that can still match does not require outside dial tone.

As long as what the user dials keeps the route pattern 9124 in contention as a possible match, CallManager defers applying outside dial tone. For example, if the user continues by dialing 2 (yielding currently dialed digits of 912), CallManager continues to defer application of outside dial tone. However, if instead of dialing 2, the user dials 7 (yielding currently dialed digits of 917), the route pattern 9124 can no longer match, and CallManager applies outside dial tone, because all potentially matching route patterns have had their Provide Outside Dial Tone box checked.

If your system plays outside dial tone later in a dial string than you expect, be sure to look for route patterns that overlap with the route patterns for which you are expecting to hear outside dial tone, but for which you have not checked the Provide Outside Dial Tone box. These conflicting route patterns might be Meet-Me conference or call park ranges, in which case you need to change these ranges so that they do not conflict with the off-network route pattern in question.

On the other hand, if you receive outside dial tone sooner than expected (usually because you want to use access codes that are longer than a single digit), introduce a new route pattern that is identical to your access code, but do not check the Provide Outside Dial Tone box. (You can assign this route pattern to the same gateway or route list to which the full route pattern connects.) CallManager suppresses outside dial tone until the user dials the last digit of the access code. Table 2-21 presents an example in which the access code for external numbers is 999.

Just as in the previous examples, CallManager applies inside dial tone when the user goes off-hook and turns off inside dial tone after the user dials 9. Table 2-22 depicts the dialing state when the user dials 99.

CallManager continues suppressing outside dial tone because route pattern 999 might still match the user’s dialed digits. Table 2-23 presents the dialing state when the user dials another 9 (yielding dialed digits of 999).

Adding the route pattern 999 thus suppresses outside dial tone until the moment that you want it applied.

While the Provide Outside Dial Tone check box dictates whether a caller hears outside dial tone at some point during dialing, it doesn’t necessarily mean the call is an outside call. To actually classify a call as an outside call, use the Call Classification list box on the Route Pattern Configuration page. OffNet indicates that a given call is leaving your network (and may generate a charge); OnNet indicates that a given call is staying on your network.

The Call Classification list box also exists on CallManager gateway pages as well. It indicates how CallManager should classify calls arriving through the gateway, and it takes on the values OffNet, OnNet, or Use System Default. The Use System Default setting tells CallManager to classify calls according to the service parameter Call Classification.

Call classification works in conjunction with two service parameters (Block OffNet To OffNet Transfer and Drop Ad Hoc Conference) that attempt to control toll fraud. Toll fraud can occur, for instance, if someone within your organization places a call to an international destination, places the answering party on hold, calls another international party, and then transfers the parties together. Voilà! Free international calling—at least for the called parties; unfortunately, you’re paying the bill. A similar scenario is possible using the conference feature.

When you set Block OffNet To OffNet Transfer to False, CallManager permits all transfers. When you set Block OffNet To OffNet Transfer to True, CallManager looks at the call classification of the parties being transferred together before allowing the user to complete the transfer.

Call classification isn’t really call classification; it’s party classification. When a party places a call, he is classified according to the type of device from which he is calling. For instance, Cisco IP Phones are always considered OnNet devices (by the CallManager cluster to which they are registered). On the other hand, some gateways might attach to purely internal destinations (such as a legacy PBX in your network), while others may represent connections to the PSTN. CallManager has no way to tell the difference, so it relies on you to set the Call Classification box to define calls arriving through the gateway as OnNet or OffNet.

The party that receives a call is classified according to the call classification associated with his pattern or directory number. As with placed calls, the directory numbers associated with Cisco IP Phones are automatically classified as OnNet. Calls to gateway destinations must route through a route pattern, and they take their classification from the call classification you specify on the Route Pattern Configuration page.

So when an IP phone calls an IP phone, the calling party is classified as OnNet by virtue of her IP phone’s implicit device setting and the called party is classified as OnNet by virtue of his IP phone’s implicit directory number setting. When an IP phone calls out a gateway, the calling party is classified as OnNet by virtue of her IP phone’s implicit device setting and the called party is classified according to what you’ve set on the Route Pattern Configuration page. For instance, even if the call goes to the PSTN, you might want to classify numbers that terminate within your local calling region as OnNet anyway. When a gateway calls an IP phone, the calling gateway is classified according to what you’ve set on the gateway configuration page and the called party is OnNet by virtue of being an IP phone.

When deciding whether to complete a transfer, the transfer feature looks at the classification of the parties on the call. If both are OffNet and the service parameter Block OffNet to OffNet Transfer is set to True, CallManager denies the transfer attempt and displays a message to the transferring party.

The conference setting works similarly, but instead of preventing the conference, it dictates under what conditions the conference should survive. The Drop Ad Hoc Conference setting takes the following values:

Multilevel Priority and Preemption (MLPP) is a feature primarily used by military installations that want to provide a way for important personnel to be able to preempt lower-priority calls on a given phone.

MLPP relies on a standard form of addressing in which the precedence level of a call is indicated by an initial set of digits (01 to 04) on a dialed digit string. CallManager does not include such hard-coded rules in its call routing component; rather, it simply allows you to associate a precedence level with any matching string. For instance, digit strings beginning with 01 typically denote calls of priority flash override; by defining pattern 01XXXX and associating the Precedence Level Flash Override to it, you can conform to the military specifications. However, this approach also leaves you free to define number formats of your own if, for example, you want to have a number to break into your coworkers’ calls at lunchtime to arrange vital details such as at which local restaurant to eat. Precedence level follows the call, and, if the call encounters an MLPP-enabled phone or gateway, the precedence level affects the how the call is treated. In the case of phones, it prompts the user and requires him to hang up on any lower-priority calls; in the case of gateways, it can force calls to clear if all circuits on the gateway are in use. Appendix A, “Feature List,” provides additional information about MLPP.

The Route Pattern Configuration page and Translation Pattern Configuration page simply allow you to associate priority values with a call when the associated pattern matches. CallManager supports the following values, listed in order from lowest to highest priority:

Unlike the other settings, the Default setting simply indicates that CallManager should not modify the precedence of a call when the associated route or translation pattern is selected. For instance, a call might arrive from another system prioritized as Immediate. If the provided digits match a local pattern with a Precedence Level of Default, the call remains Immediate. Setting any other value causes the selected value to overwrite whatever value the call already had.

When a given pattern matches, the default behavior that applies is to route the associated call. However, CallManager specifically permits to you block calls when a given pattern is matched. The Route Option field on the Translation Pattern Configuration and Route Pattern Configuration pages permits you to block a call: When you specify Block this pattern, CallManager rejects the call if the blocked pattern happens to be the best match for the dialed string. The rejection of the call is done with the cause value you select from the following list:

If the call came from a different system, through an ISDN or H.323 trunk, the cause value is returned as the Cause Information Element (IE) in Q.931 signaling. The system where the call originated can then apply different outcomes for the call, based on the cause that is returned. For instance, if you choose “unallocated number” as the cause for a blocked pattern, the calling system will be able to abort any further attempts to reroute the call through a different network, avoiding trying another path to reach a destination that is nonexistent. The section “Miscellaneous Solutions” later in the chapter provides some examples of the use of the Route Option field.

Forced Authorization Codes and Client Matter Codes provide a twist to CallManager’s digit collection process or, to be more precise, a postscript. Both of these features kick in after CallManager finds the closest match for a set of dialed digits. They can be thought of as a second phase of digit collection.

You create forced authorization codes (FAC) and client matter codes (CMC) from the Feature menu in CallManager Administration. Forced authorization codes and client matter codes can consist of any string of numeric digits up to 16 digits long. Forced account codes also have an associated authorization level that takes values from 1 to 255. Higher numeric values correspond to higher authorization levels.

The purpose of forced authorization codes is to require users who place calls to certain destinations—most often long distance or international calls—to enter an authorization code to prove to CallManager that it should route the call.

When CallManager matches a pattern for which the Required Forced Authorization Code check box has been checked, instead of immediately routing the call, it plays a tone to the caller. The caller must enter a valid authorization code. Entry of digits is terminated either when the caller dials # or when the interdigit timer expires.

Upon collecting a forced authorization code, CallManager compares the authorization level configured with the code against the authorization level configured on the Route Pattern Configuration page. If the level of the code equals or exceeds the level on the pattern, CallManager proceeds with the call.

The purpose of client matter codes is to require users to enter an account number upon placing a call that CallManager logs into the call detail records (CDR) upon call completion. A reporting tool can later extract the account codes from the CDR database and properly bill clients for the time spent by the caller on the account.

Client matter codes operate nearly identically to forced authorization codes. When CallManager selects as closest match a route pattern with the Require Client Matter Code check box checked, it plays a tone to the caller and requires him to enter digits. Digit entry expires when either the caller presses the # key or the interdigit timer expires.

Route patterns support the simultaneous support of both forced authorization and client matter codes. When both are configured, CallManager first prompts for the forced authorization code and then prompts for the client matter code.

Forced authorization codes and client matter codes are not compatible with the Allow Overlap Sending flag. When either the Require Client Matter Code or Require Forced Authorization Code check boxes are checked, CallManager Administration disables the Allow Overlap Sending check box. Similarly, when the Allow Overlap Sending check box is checked, CallManager Administrator disables the Forced Authorization Code and Client Matter Code fields.

Unlike the convenient wildcards X and ! and the range-matching notations, the @ wildcard does not represent any particular set of matching characters. The @ wildcard causes CallManager to add the set of national route patterns for the numbering plan that you specify in the Numbering Plan drop-down list on the Route Pattern or Translation Pattern Configuration pages. One way to think of the @ pattern is that it matches any number that you can dial from a residential phone in the country associated with the selected numbering plan. For example, specifying the @ pattern along with the North American numbering plan allows users to dial 911 and 555 1212 and 1 800 555 1212 and 011 33 12 34 56 78 90.

The @ pattern is a macro. When you configure it, CallManager looks up a list of route patterns associated with the dialing plan you have specified and adds them individually. This might cause CallManager to appear to violate closest match routing rules.

For instance, different individual route patterns in the North American numbering plan match the four dialing strings 911 and 555 1212 and 1 800 555 1212 and 011 33 12 34 56 78 90. Table 2-24 shows some sample route patterns.

Assume that you associate the route pattern @ with a gateway that you want to use for all of your outbound calls. You have another gateway that you prefer to use for seven-digit local calls, so you configure the route pattern XXX XXXX on it. But when you dial 555 1212, your calls route out the first gateway. What is happening?

From your point of view, you configured the route patterns in Table 2-25.

The specific route pattern XXX XXXX definitely appears to match fewer route patterns than the @ pattern. However, CallManager interprets @ as a macro expansion and actually treats your configuration as shown in Table 2-26.

When a user dials 555 1212, both [2-9]XX XXXX and XXX XXXX match. [2-9]XX XXXX is the more specific, and thus the call routes to gateway 1.

To avoid this situation, when you configure route patterns that you want to take precedence over the @ pattern, either be as specific as possible in describing your route patterns, or preferably, use route filters (described in the section “Route Filters”).

The . wildcard is unlike other wildcards in that it does not match digits at all. Rather, the call routing component uses the . wildcard to fulfill its secondary responsibility of address translation.

The . wildcard functions solely as a delimiter. When it appears in a route pattern, it divides the dial string into PreDot and PostDot sections. This has no effect on what digit strings the route pattern matches. Rather, you use the . wildcard in conjunction with digit discarding instructions.

Digit discarding instructions are one way to tell the call routing component which dialed digits should be kept before the call is offered to the selected device. Most digit discarding instructions can be used only in conjunction with route patterns that contain the @ wildcard. However, some digit discarding instructions rely on the PreDot section that the . wildcard defines. Further details about digit discarding instructions (and other transformations) are in the section “Digit Discarding Instructions.”

Tags are named substrings of individual route patterns for a given national numbering plan.

For instance, the route pattern 1 [2-9]XX [2-9]XX XXXX exists in the North American numbering plan. It is composed of four sections. The first section, 1, denotes the call as a toll call. The second section matches an area code. The office code and the subscriber follow. The numbering plan file for the North American numbering plan encodes this knowledge as the tags LONG-DISTANCE-DIRECT-DIAL, AREA-CODE, OFFICE-CODE, and SUBSCRIBER. In contrast, the route pattern [2-9]XX XXXX contains only the OFFICE-CODE and SUBSCRIBER tags.

Table 2-27 shows the tags that the North American numbering plan contains, and it provides representative digit strings for each tag. Bold type in Table 2-27 indicates the section of the example number that corresponds to the listed tag.

Operators are the functions that determine whether a given route pattern passes the tests you specify.

There are four operators:

An example might help clarify the tortured description of the == operator. One route pattern defined in the North American numbering plan is [2-9]XX XXXX (see Figure 2-5). This pattern consists of an office code and a subscriber. The first section of the route pattern, [2-9]XX, corresponds to the tag OFFICE-CODE.

Figure 2-5. Pattern [2-9]XX XXXX in the North American Numbering Plan

Assume that you specify OFFICE-CODE == [1-3]XX in a route filter. When determining whether to add the pattern [2-9]XX XXXX into the routing tables, CallManager intersects the route pattern [2-9]XX from the numbering plan with the route pattern [1-3]XX in the route filter. [2-9]XX matches all dialed digit strings in the range 200–999, while route pattern [1-3]XX matches all dialed digit strings in the range 100–399. The intersection of these sets is all dialed digit strings in the range 200–399. As a result, CallManager determines that the route pattern under inspection matches the filter’s test. It inserts into the internal routing tables the route pattern that represents the intersection of the value you specified and the entry in the numbering plan, namely, [23]XX XXXX. Figure 2-6 depicts the application of the route filter.

Figure 2-6. Intersection of Two Pattern Ranges Because of a Route Filter

You can string operators together with the Boolean operators AND and OR. When you string operators together with OR, CallManager includes a route pattern under inspection if either of the specified conditions exist. When you string operators together with AND, CallManager includes a route pattern under inspection only if both of the specified conditions exist.

For example, the route filter AREA-CODE EXISTS OR SERVICE EXISTS causes CallManager to include both the route pattern [2-9]11, which matches information and emergency services in the North American numbering plan, and the route pattern 1 [2-9]XX [2-9]XX XXXX, which matches long distance toll calls in the North American numbering plan. [2-9]11 contains the SERVICE tag, and 1 [2-9]XX [2-9]XX XXXX contains the AREA-CODE tag.

However, the route filter AREA-CODE EXISTS AND SERVICE EXISTS causes CallManager to include absolutely no route patterns, because no number in the North American numbering plan has both an area code and a service number.

When an @ pattern has an associated filter, the filter affects the macro expansion that takes place. Before adding an individual route pattern from the numbering plan to the system, CallManager checks to see whether that particular route pattern passes the tests specified in the route filter. If the route pattern does not qualify, CallManager will not add it, which means that users cannot dial it.

It is important to note that route filters in themselves do not explicitly block calls. They tell CallManager not which patterns to exclude but which patterns to include. A route filter that specifies AREA-CODE == 900 does not eliminate calls to area code 900 (reserved for toll services in the United States); rather, it tells CallManager to include only those route patterns in the North American numbering plan where the area code is 900. In other words, it configures the system so that toll-number calls are the only destination users can dial. (You can block these numbers. See the section “Routing by Class of Calling User” for details.)

The best way to see how route filters operate is to look at some examples. For instructive purposes, these examples use the North American numbering plan and assume that the @ pattern expands only to the route patterns in Table 2-28.

If you specify the route pattern 9.@ with no route filter, CallManager indiscriminately adds each route pattern in Table 2-28, preceded by 9. Thus, users can dial 9 911 and 9 555 1212, as well as 9 1 900 555 1212. Table 2-29 lists the route patterns that CallManager adds.

If instead, you add the same route pattern but use a route filter that specifies SERVICE EXISTS, CallManager adds only those route patterns that contain the SERVICE tag. (In North America, the SERVICE tag matches numbers such as 411 for directory information and 911 for emergency services.) Your users can access network services but no other numbers. Table 2-30 lists the added route patterns.

The route filter COUNTRY-CODE DOES-NOT-EXIST eliminates the international dialing route pattern. Users can access network services and local and long distance numbers. Table 2-31 lists the added route patterns.

The route filter AREA-CODE == [89]00 OR AREA-CODE == 888 OR AREA-CODE == 877 demonstrates the way in which the equal operator can constrain a route pattern. This filter allows users to dial 11-digit numbers to the toll-free ranges 800, 877, or 888 and to the toll-range 900. Table 2-32 lists the added route patterns.

The bold type in the above table shows that the values specified on the equals operator have constrained the area code substring of the North American numbering plan to a particular range. In each case, the generalized substring [2-9]XX, which matches any digit string between 200 and 999, has been modified so that it matches only the intersection between the substring and value specified in the route filter.

This section presents some route filter configurations for the North American numbering plan that you might find useful.

It describes how to use route filters to do the following:

In North America, users can select a long distance carrier by dialing at the beginning of their number the digits 101 followed by a four-digit carrier code. CallManager digit discarding instructions (see the section “Digit Discarding Instructions”) call this type of dialing 10-10- Dialing.

On the North American numbering plan Route Filter page, the tag TRANSIT-NETWORK-ESCAPE filters numbers in which the user has included the 101 carrier selection digits. Configuring a route filter with the value TRANSIT-NETWORK-ESCAPE DOES-NOT-EXIST blocks calls that include the carrier selection code.

The difference between configuring a route filter to block long distance carrier selection and using the digit discarding instructions 10-10-Dialing is that the route filter blocks a user’s call attempt if the user dials the carrier selection code, while the digit discarding instructions permit the call to go through but silently strip out the carrier selection portion of the dialed number.

You can block international calls with the route filter INTERNATIONAL-ACCESS DOES-NOT-EXIST. In the North American numbering plan file, the tag INTERNATIONAL-ACCESS corresponds to the initial 01 of international dialed calls. By specifying a route filter that prevents CallManager from including route patterns beginning with this tag, you prevent CallManager from matching any numbers beginning with 01. You block international calls by never adding them in the first place.

Routing just local numbers typically requires stringing together several route filter clauses joined by OR.

Local calls can vary dramatically by geographical region. Some regions have 7-digit local calls, some metropolitan regions have a mixture of 7- and 10-digit local calls, and other regions have 10- digit local calls.

Some geographical regions have metro dialing. In metro dialing, a user in a home area code needs to dial only 7 digits, but a few neighboring area codes, also local calls, require the user to dial 10 digits. Metro dialing is typically the most problematic, because some 11-digit calls might actually be local calls, while some 10-digit calls might be toll calls. In such cases, you might need to specify criteria down to the office code level to provide full local access. (Another approach is to define an @ pattern to perform general filtering and to define separate specific patterns, such as 972 813 XXXX, to handle the exceptional cases.)

If your region has metro dialing, define a route filter in which one clause specifies seven-digit dialing and subsequent clauses define the nontoll area codes on an area-code-by-area-code basis. For instance, in the Dallas-Fort Worth area in 1995, the following route filter would provide general metro dialing access from the point of view of a user in the 972 area code:

Because the user in the 972 area code dials seven digits to call other numbers in the 972 area code, the first part of this route filter handles any seven-digit calls that the user in the 972 area code dials. The second part of this route filter handles 10-digit calls starting with 214 that the user dials, and the third part of this route filter handles 10-digit calls starting with 817 that the user dials.

You can add exceptional cases as additional clauses or as separate route patterns.

Note especially the use of the tag LOCAL-AREA-CODE. The LOCAL-AREA-CODE tag represents an area code as dialed as part of a 10-digit North American number (for example, 214 555 1212). The same area code in an 11-digit North American number (0 214 555 1212 and 1 214 555 1212) corresponds to the tag AREA-CODE.

In the North American numbering plan, area codes 800, 866, 877, and 888 are dedicated to toll-free numbers. The following route filter provides access to only these services:

Because some geographical regions use 7-digit dialing and others use 10-digit dialing, the North American numbering plan shipped with CallManager must accommodate both types of dialing. Furthermore, because the IP network permits stations homed to a particular CallManager to be in different geographical locations, CallManager must be able to support both types of dialing simultaneously.

As a result, the North American numbering plan shipped with CallManager includes both route patterns [2-9]XX XXXX and [2-9]XX [2-9]XX XXXX. The problem that occurs is with the 10- digit route pattern in place, users of the 7-digit pattern must wait for the interdigit timeout to expire before CallManager routes their 7-digit calls.

Eliminating the interdigit timeout means configuring CallManager to eliminate the 10-digit route pattern for users of 7-digit dialing. Configure the route filter LOCAL-AREA-CODE DOES-NOT-EXIST to eliminate the [2-9]XX [2-9]XX XXXX pattern from the list of patterns in the North American numbering plan and associate it with your @ pattern.

The previous route filters in this section operate by using inclusion. That is, the clauses provided define a subset of the North American numbering plan that includes only those patterns that you want to be routed and excludes those patterns you want to block.

As long as the restrictions placed use the EXISTS or DOES-NOT-EXIST operators, you can use one route filter to define which patterns should be routed. EXISTS specifies that CallManager should route all valid number ranges for a particular tag, while DOES-NOT-EXIST specifies that CallManager should route no valid number ranges for a particular tag.

When you need to specify only some of the valid number ranges for a particular tag, use the == operator. However, CallManager does not support a != (not-equals) operator. As a result, although you can specify a route filter such as AREA-CODE == 900, rather than blocking 900 numbers, this filter routes 900 numbers and blocks all other types of calls.

However, you can still block 900 numbers with the use of two route patterns. First, configure an @-pattern with the route filter AREA-CODE == 900. On the route pattern, however, click the radio button Block This Pattern. This configuration specifies that CallManager should block all external calls with area code 900.

To make all non-900-numbers route, configure another @-pattern with no route filter at all. Using closest match routing rules (see the section “Example 2: Closest Match Routing”), if a user dials a dialed digit string containing an area code of 900, the route pattern with the route filter AREA-CODE == 900 matches, which causes CallManager to block the call. Because an external call to another area code matches only the unfiltered pattern, CallManager routes the call.

An example can best illustrate the process that occurs. Table 2-33 shows a representative sample of route patterns that CallManager adds when you specify the route pattern 9.@.

When you specify the route filter, AREA-CODE == 900, CallManager includes only those route patterns that have an area code tag. Furthermore, CallManager constrains the route pattern so that the tag can match the number 900 (see Table 2-34).

When you add both route patterns and specify that CallManager should route calls to 9.@ but block calls to 9.@ where AREA-CODE == 900, the routing tables appear as displayed in Table 2-35.

If a user dials 911 or a seven-digit number, it is evident that CallManager routes the call. When a user dials an 11-digit number, however, closest match routing rules ensure that the user’s call is handled properly. Table 2-36 shows that when a user dials 9 1 214 555 1212, CallManager finds a unique match for the 9.@ route pattern and routes the call.

When a user dials 9 1 900 555 1212, on the other hand, CallManager finds two matching route patterns in the routing tables, uses closest match routing rules to select between them, and then applies the appropriate treatment. Table 2-37 shows CallManager selecting the blocked route pattern 9.@ where AREA-CODE == 900 over the more generic route pattern 9.@. As a result, CallManager rejects calls to 900 numbers.

This strategy of configuring a general route pattern to allow most calls through, but then configuring specific route patterns with blocking treatment to screen a very specific small set of calls, recurs often in enterprise deployments.

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.

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”).

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.

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

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:

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

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 view—the 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.

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.

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.

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.

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.

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

CallManager applies the transformations in the order listed.

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.

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.

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.

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

CallManager applies the transformations in the order listed.

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.

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.

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.

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 has one of three values:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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:

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

Line groups permit you to set the following options:

The following list describes these conditions in more detail:

The preceding list describes the conditions for which a hunt list option can be set. The following list describes the available options:

In addition to the call treatment options, line groups allow you to temporarily bring members in and out of service by administratively moving them from the Selected DN/Route Partition list box to the Removed DN/Route Partition list box, and vice versa.

Hunt lists themselves offer no meaningful call distribution algorithms. Hunt lists always offer calls to line groups in sequential order, starting from the first line group listed in the Selected Groups list box and proceeding to the final line group listed.

You can administratively move line groups in and out of service within the displayed hunt list by moving them from the Selected Groups list box to the Removed Groups list box, and vice versa.

Furthermore, you can temporarily enable or disable an entire hunt list by using the Enable this Hunt List check box.