Route Patterns and Route Filters

This section introduces the basic building blocks of call routingroute patterns and route filters.

A route pattern is an address, much like your mailing address. When a user dials a number, CallManager tries to figure out to which destination to deliver the call. It performs this function by looking at all the route patterns you have configured and then figuring out which route pattern is the best fit for the number the user has dialed. CallManager then attempts to offer the call to the endpoint that you have associated with the route pattern.

Do not confuse the concept of route pattern that this section discusses with the Route Pattern Configuration page in CallManager Administration. The Route Pattern Configuration page allows you to associate an address with a destination and contains other settings that let you modify the calling and called numbers. One of the fields on the Route Pattern Configuration page takes a route pattern as input; so does one of the fields on the Translation Pattern Configuration page, as does the Hunt Pilot Configuration page. Figure 2-3 shows the field on the Translation Pattern Configuration page that takes a route pattern as input.

Figure 2-3. Route Pattern Field in the Translation Pattern Configuration Page

Many different CallManager Administration pages allow you to enter route patterns. For example, the directory numbers you assign to phones are actually route patterns, as are Meet-Me conference numbers, message waiting on/off numbers, call park numbers, call pickup group numbers, translation patterns, and hunt pilots.

A route pattern is a sequence of digits and other alphanumeric characters. When the digits are all numeric, as is usually the case with directory numbers, CallManager rings the device with which you have associated the route pattern only when a user dials the exact numerical sequence. By including non-numeric characters called wildcards in a route pattern, you tell CallManager to ring the associated device for a range of dialed numbers. For instance, if you assign the route pattern 8XXX to a device, CallManager rings the device when users dial numbers in the range from 8000 to 8999.

Route filters are a special range-refining mechanism. You use route filters with route patterns that contain the special @ wildcard. The @ wildcard allows you to represent the PSTN with a single route pattern. When you must limit the types of PSTN calls (such as emergency, local, long distance, and international) that users can place, route filters limit the scope of the @ wildcard.

This section discusses the following topics:

• "Wildcards" describes the building blocks out of which you build route patterns.
• "Dialing Behavior" describes how CallManager processes digits from a calling user and selects a destination.
• "Dialing Behavior Refinements" elaborates on the basic procedure discussed in the section "Dialing Behavior" by introducing the Urgent Priority check box and explaining the logic that underlies outside dial tone.
• "Other Wildcards (@ and .)" revisits some complex wildcards that the section "Wildcards" introduces but only glosses over.
• "Route Filters" introduces a mechanism by which you can narrow the scope of the @ wildcard.

Wildcards

A house address is a specific sequence of digits and alphabetic characters that allows the postal service to identify a package's destination. A route pattern is like a house address for a callable endpoint; unlike a house address, however, the addresses that a telephone system uses must provide a means by which the administrator can specify a range of addresses. You can enter individual addresses for every phone your network manages, but if users need to dial out of a gateway to the PSTN, the number of individual addresses becomes too vast to configure. Clearly, requiring the configuration of every single telephone number in the PSTN is not reasonable.

Route patterns use wildcards, which are digit placeholders that permit you to specify quickly a range of matching digits. For example, instead of configuring every individual number from 7000 to 7999 to route a call across a gateway to another network, by configuring 7XXX, you can tell CallManager to send all calls that begin with the digit 7 and are followed by three digits (in the range 0 to 9) to the gateway.

There is more to it, but first look at the basic wildcards, which Table 2-1 summarizes.

Dialing Behavior

The call routing component's behavior is sometimes counterintuitive, so a better understanding of the process it uses to select a destination can allow you to better troubleshoot problems.

In collecting a user's digits, the call routing component goes through the following steps:

Examples can best explain this process. The following sections present three examples:

• "Example 1: Simple Call Routing" presents an example in which exactly one route pattern ultimately matches.
• "Example 2: Closest Match Routing" presents an example in which multiple route patterns match and CallManager uses the closest match routing algorithm to select a route pattern.
• "Example 3: Wildcards That Match Multiple Digits" presents an example that demonstrates the effect of wildcards that match multiple digits.

For purposes of the examples, assume that CallManager has been configured with the route patterns in Table 2-2.

Example 1: Simple Call Routing

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.

Example 2: Closest Match Routing

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.

Example 3: Wildcards That Match Multiple Digits

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!#.

Overlapped Sending and Non-North American Numbering Plans

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.

• Configure very specific route patterns on your trunk interfaces, in effect encoding the national network's knowledge of the national numbering plan into the database. This option requires a significant knowledge of your country's numbering plan, the patience to enter all of the route patterns, and constant monitoring of changes to the national numbering plan so that you can update your route patterns.
• Replace CallManager's knowledge of the North American numbering plan with your country's numbering plan. Like the first option, this option requires extensive knowledge of your country's numbering plan, but it is a better solution because it means you can use the @ wildcard to represent your country's numbering plan. (For more information about the @ wildcard, see the section "Other Wildcards [@ and .].") However, the Cisco Technical Assistance Center (TAC) will not support any unofficial changes you make to the way the system uses the "@" route pattern, under CallManager version 3.0 and earlier.
• Configure gateways with steering codes followed with the ! wildcard (which matches multiple digits). For example, imagine that in the sample network depicted in Figure 2-4, Node A was CallManager, the remaining nodes were the PSTN, and you associated the route pattern 0! with the gateway to node B. When User 1 dials 0, CallManager continues collecting digits from User 1 until the interdigit timeout expires, whereupon CallManager offers the complete number to the PSTN.

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

Dialing Behavior Refinements

The section "Dialing Behavior," for purposes of clarity, describes a simplified version of CallManager's call routing logic. The actual process is more involved. This section discusses six refinements to the basic dialing procedure:

• "Urgent Route Patterns" describes route pattern urgency, which can interrupt interdigit timing when CallManager must route a call immediately.
• "Outside Dial Tone" describes the logic that determines when CallManager applies outside dial tone.
• "Call Classification" talks about categorization of calls as either being OnNet or OffNet.
• "The Route/Block Flag" describes a specific option on route and translation patterns that permits you to block as well as route calls.
• "MLPP Precedence" defines the use of route patterns to classify calls according to call priority.
• "Forced Authorization Codes and Client Matter Codes" describes a feature that can cause callers to enter a second phase of dialing in which they must enter a password or account code in order to proceed with a call.

Urgent Route Patterns

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:

• First, an urgent route pattern only takes effect if it is the best match at the time. If you define an urgent route pattern XXXX, a normal route pattern 8XXX, and a normal route pattern 80000, when users dial 8000, CallManager continues to wait for more digits, because the normal route pattern 8XXX is the best match.
• Second, defining an urgent route pattern limits the total number of route patterns you can usefully assign. If you define the route pattern 999 as an urgent route pattern, users can never dial longer digit sequences that begin with 999, because the urgent route pattern always takes priority.

Outside Dial Tone

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.

Note

Outside dial tone is normally a different cadence from the tone provided when a user goes off-hook. However, by setting the service parameter Always Use Inside Dial Tone to True, you can cause the secondary tone played to sound exactly like the initial dial tone the user hears. This parameter does not otherwise affect CallManager's application of dial tone; CallManager still applies a secondary tone when its route configuration indicates that only patterns that require outside dial tone are candidate matches.

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.

Call Classification

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 callingat 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:

• Never allows the conference to persist until all parties have dropped out.
• When Conference Creator Drops Out causes the conference to end when the person who created the conference leaves it. This value setting can be inconvenient if the creator accidentally hangs up on a conference call.
• When No OnNet Parties Remain in the Conference relies on call classification. If only OffNet parties remain in the conference, CallManager clears the conference if this value is set.

MLPP Precedence

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:

1. Default
2. Routine
3. Priority
4. Immediate
5. Flash
6. Flash Override
7. Executive Override

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.

Tip

Although it might seem a natural fit, Cisco recommends that you not use MLPP as a way to provide emergency calls higher priority than normal calls but rather recommends that you set aside dedicated trunks to the PSTN to be used for emergency calls.

This recommendation exists for a few good reasons. One issue is that emergency response centers often have limited trunk capacity. Certain emergencies might generate a high call volume, and, although using preemption might guarantee that each emergency call routes off your enterprise network, it doesn't guarantee (past the first few calls) that the emergency response center will receive all these calls. At some point, all the preemption logic accomplishes is the disruption of valid nonemergency calls without allowing redundant emergency callers to reach the emergency response center.

Among the nominally nonemergency calls that might be preempted are calls that, while nominally nonemergency, actually are part of your enterprise's emergency policies. Even worse, some of these nominally nonemergency calls might be calls from the emergency response center back into your enterprise. Some laws regarding 911 compliance require that the emergency response center be provided a caller ID that can be used by the emergency response center to dial back into the enterprise should an emergency caller somehow be disconnected.

Thus, by simply reserving some facilities specifically for 911 calls, you ensure that enough capacity exists for emergency callers to reach the emergency response center without running the risk of preempting equally vital calls that happen not to be specifically to 911.

The Route/Block Flag

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:

• No Error
• Unallocated Number
• Call Rejected
• Number Changed
• Invalid Number Format
• Precedence Level Exceeded

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

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 destinationsmost often long distance or international callsto 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.

Other Wildcards (@ and .)

The section "Route Patterns and Route Filters" deliberately glosses over some of the most common wildcards you use: the @ and . wildcards.

@ Wildcard

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

. Wildcard

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

Route Filters

As described, the @ wildcard is an all-or-nothing affair. When present, it matches all of the valid numbers for the national numbering plan specified, even those you would prefer your users did not dial.

Route filters are the mechanism by which you can cause CallManager to add only a subset of the route patterns for a given numbering plan. For example, using route filters, you can cause an @ pattern to match only the national emergency numbers. You can also use route filters to distinguish local calls from long distance calls or to limit access to toll services.

Route filters are a test that CallManager applies to individual route patterns in a numbering plan included by the @ wildcard. CallManager examines each valid route pattern in the numbering plan and applies the test. If a particular route pattern passes the test, CallManager adds it into its routing tables, and users are able to dial numbers that match the route pattern. If a particular route pattern fails the test, CallManager skips over it, and users are unable to dial numbers that match the route pattern. Route filters work by allowing CallManager to add only the subset of a numbering plan whose tags fulfill the constraints that operators impose.

Tags

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

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

There are four operators:

• EXISTS, whose test is passed if the route pattern under inspection contains the specified tag.
• DOES-NOT-EXIST, whose test is passed if the route pattern under inspection does not contain the specified tag.
• == , whose test is met if 1) the route pattern under inspection contains the tag and 2) a nonempty intersection exists for the set of route patterns that the pattern expression in matches and the set of route patterns that the pattern expression associated with tag matches.
• NOT-SELECTED, whose test is passed under all conditions. The NOT-SELECTED operator is a value that exists only in CallManager Administration to represent that you have not selected an operator for a particular tag. It simply means "none of the above."

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 200999, while route pattern [1-3]XX matches all dialed digit strings in the range 100399. The intersection of these sets is all dialed digit strings in the range 200399. 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.

Route Filter Operation

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.

Useful Route Filters for the North American Numbering Plan

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:

• Block calls where the user has selected a long distance carrier
• Block international calls
• Route just local numbers
• Route just toll-free numbers
• Eliminate interdigit timing between 7-digit and 10-digit route patterns
• Block 900 numbers

Block Calls Where the User Has Selected a Long Distance Carrier

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.

Block International Calls

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.

Route Just Local Numbers

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.

Seven-Digit Dialing

If your region has seven-digit dialing and you want to permit users to dial only seven-digit numbers, defining the route filter SERVICE DOES-NOT-EXIST AND LOCAL-AREA-CODE DOES-NOT-EXIST AND AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST should suffice. Filtering against SERVICE DOES-NOT-EXIST blocks calls to information and emergency services, LOCAL-AREA-CODE blocks 10-digit calls, AREA-CODE DOES-NOT-EXIST blocks 11-digit long distance calls, and INTERNATIONAL-ACCESS blocks international calls.

If you want to, say, permit calls to services, long distance calls, or international calls, you simply exclude the appropriate operator expression from the proposed route filter.

The LOCAL-AREA-CODE section of the defined route filter deserves some more explanation. You might have noticed that in some cases, a proposed route filter uses the tag AREA-CODE and in other cases it uses the tag LOCAL-AREA-CODE. The tag LOCAL-AREA-CODE represents the area code as it appears in 10-digit numbers.

Some metropolitan regions of North America require users to dial 10 digits for all of their local calls. This means that CallManager must include both 7-digit patterns and 10-digit patterns in its expansion of the North American numbering plan, because you can deploy CallManager in different geographic regions. Because of CallManager's analysis process, however, unless you explicitly exclude the 10-digit pattern when you are in a 7-digit dialing region, CallManager will wait for the interdigit timer to expire before offering your 7-digit calls to the PSTN.

On the other hand, the AREA-CODE tag represents the area code as it appears in 11-digit numbers (typically direct-dial and calling-card long distance calls) in the North American numbering plan. Using two different tag names for essentially the same subsection of a North American number assists those administrators in 10-digit dialing regions who want to permit 10-digit local calls while blocking 11-digit toll calls. By specifying the filter AREA-CODE DOES-NOT-EXIST, such administrators can screen out all of the toll calls while leaving the 10-digit calls untouched. The section "Eliminate Interdigit Timing Between 7-Digit and 10-Digit Patterns" expands on this wrinkle of CallManager's North American numbering plan.

Metro Dialing

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:

LOCAL-AREA-CODE DOES-NOT-EXIST AND AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST

OR

LOCAL-AREA-CODE == 214

OR

LOCAL-AREA-CODE == 817

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.

10-Digit Dialing

A 10-digit dialing route filter is like a metro dialing routing filter, but you need not include the route filter for 7-digit dialing. For instance, in the Dallas-Fort Worth area in 2000, the following route filter provides general 10-digit dialing access:

LOCAL-AREA-CODE == 214

OR

LOCAL-AREA-CODE == 817

OR

LOCAL-AREA-CODE == 972

OR

LOCAL-AREA-CODE == 940

Again, you can add exceptional cases (11-digit local calls) as additional clauses or as separate route patterns.

Route Toll-Free Numbers

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:

AREA-CODE == 800

OR

AREA-CODE == 877

OR

AREA-CODE == 888

Eliminate Interdigit Timing Between 7-Digit and 10-Digit Patterns

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.

Note

Actually, the route pattern set that CallManager uses to implement 7- and 10-digit patterns in the North American numbering plan is rather more complex. CallManager represents 7- and 10- digit patterns using 4 patterns:

• [2-9][02-9]X XXXX
• [2-9]X[02-9] XXXX
• [2-9][02-9]X [2-9]XX XXXX
• [2-9]X[0-29] [2-9]XX XXXX

The patterns are constructed in this matter in order not to create overlap between service patterns such as [2-9]11. A digit string such as 911 doesn't match patterns 1 or 3, because the second wildcard in these patterns doesn't match the second 1 in the digit string, and 911 doesn't match patterns 2 or 4 because the third wildcard in these patterns doesn't match the third 1 in the digit string.

But the simpler patterns [2-9]XX XXXX and [2-9]XX XXX XXXX demonstrate the principles that this section is communicating without complicating the issue with the addition of more confusing patterns.

You can discover exactly what patterns CallManager loads for any given dial plan by inspecting the files stored in the dialPlans subdirectory of the CallManager installation directory.

Block 900 Numbers

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.