Miscellaneous Solutions

This section contains some miscellaneous solutions that did not fit well in any other section of this chapter. The solutions discussed here are as follows:

• "Insertion of Access Codes in the Placed Calls menu of Cisco IP Phones" describes how to keep a user's dialed digit string intact so that the user can use the Dial softkey to redial previously placed calls.
• "Automatic Rerouting of Calls when Call Admission Control Fails: describes the use of Automated Alternate Routing (AAR) to direct a caller to a different destination when there's no bandwidth available to place a call to a branch office served by a Centralized CallManager deployment model.
• "One-to-One Station-to-Trunk Mapping" describes a common small PBX requirement, mapping calling users to specific outbound analog trunks, and vice versa.
• "Fallback Routing to Another PBX" describes a way to ease migration of users from an existing phone system to CallManager.
• "Multiple Call Appearances" describes how you can emulate a traditional PBX feature in which the same directory number appears on multiple lines.
• "Enhanced 911 Support" describes considerations for providing the proper calling number for emergency services in North America.

Insertion of Access Codes in the Placed Calls Menu of Cisco IP Phones

The Placed Calls menu of Cisco IP Phones such as 7905, 7912, 7920, 7940, 7941, 7960, 7961, 7970, and 7971 permits a user to quickly redial numbers that the user has previously dialed from the phone. However, the number that the phone stores is not always exactly the number that the user has dialed, because the phone stores the number after the call routing component has applied dialing transformations.

Typically, this means that the numbers in the Placed Calls menu lack any enterprise outside access code that you have provisioned, because the called party transformations on the route pattern usually strip off outside access codes.

Users who employ the Placed Calls menu can use the Edit Dial softkey to edit the stored number before placing the call, but users find this process cumbersome.

You can retain the access code for placed calls, however, by deferring your application of called party transformations until later in the call routing process. Instead of applying called party transformations in the Route Pattern Configuration page, assign your outbound gateways to a route group and perform the called party transformations there. This configuration hides the called party transformations from the calling phone and ensures that the Placed Calls menu contains the untransformed number. (Note, however, that the CDRs that CallManager logs will contain the access code, as well.)

Automatic Rerouting of Calls when Call Admission Control Fails

The centralized CallManager deployment model offers administrators significant benefits in that it allows them to administer branch offices of an enterprise from a single IP-PBX. This model relies on hosting all CallManagers in a central campus site and hosting only phones and local access gateways in the branch office. Through IP, the remote devices receive the call signaling and media control they need from the centralized CallManagers. Cisco Survivable Remote Site Telephony (SRST) can take control of the phones should the IP WAN fail.

Often, branch offices don't have extraordinarily high-speed links to the main campus. As a result, the IP WAN is sometimes able to accommodate only a limited number of calls. When this is the case, the use of CallManager locations-based call admission control can ensure that you don't oversaturate the bandwidth and degrade the voice quality of all calls traversing the link.

However, when call admission control denies a call, it's a shame to give the caller a reorder signal when the call could potentially reach the called party via the gateway in the branch office. The Automated Alternate Routing (AAR) feature solves this problem.

AAR essentially does what a normal user might try to do upon getting a reorder signal from a call to a branch office. If a user were to hear reorder from dialing an internal directory number, the user might instead try to dial the full external number for the extension in the branch office, thus routing the call though a PSTN gateway near the caller, through the PSTN, and into a PSTN gateway near the called party. This manual dialing bypasses the network congestion.

While a user probably knows what to dial if the call to the directory number is deniedthe user can look up the remote number in a directory for instanceCallManager doesn't know unless you tell it. Therefore, the AAR feature allows you to configure a set of transformation rules that convert the internal extension number into a full E.164 number.

Configuring AAR relies upon four steps:

One-to-One Station-to-Trunk Mapping

Small PBXs associate calling stations to specific analog trunks, and vice versa. The service parameter Matching Calling Party With Attendant Flag (see the section "Dialing Transformations") provides a quick way to ensure that a given calling station's external calls route over a specific analog trunk.

However, if you have several analog gateways, to ensure that the calling user's call is presented to the correct gateway, you must put all of your analog gateways in a route list to successfully use the Matching Calling Party With Attendant Flag. If you have more than a few gateways, this configuration is not efficient, because CallManager attempts to offer external calls to each analog interface one at a time until CallManager finds the analog interface with an Attendant DN that matches the calling number.

Calling search spaces and partitions offer a solution, if a cumbersome one. For inbound calls, you can use the same field as the gateways with analog interfaces do: configure the associated phone's directory number as the Attendant DN setting for the analog port.

For external dialing, however, provision each external trunk with its own @ pattern (or other external dialing pattern) and then assign each route pattern a unique partition. A calling user includes one of the unique partitions in the calling search space, which causes the calling user's outbound calls always to route to one specific trunk.

For example, assume you have two users, Alice, with directory number 1000, and Bill, with directory number 2000. In addition, you have an MGCP gateway with two loop start trunks. Inbound calls from the first trunk route to Alice, and Alice's outbound calls route out the first trunk. Inbound calls from the second trunk route to Bill, and Bill's outbound calls route out the second trunk.

To route the inbound calls correctly, you must simply assign Alice's directory number (1000) as the Attendant DN of the first port and Bill's directory number (2000) as the Attendant DN of the second port.

Routing outbound calls requires that you use calling search spaces and partitions. Create two partitions, CallsFromAlice and CallsFromBill. Create the route pattern 9.@ in partition CallsFromAlice and associate it with the first trunk. Then create the route pattern 9.@ in partition CallsFromBill and associate it with the second trunk. Finally, assign Alice a calling search space that includes partition CallsFromAlice and assign Bill a calling search space that includes partition CallsFromBill.

When Alice dials an external number such as 9 1 408 555 1212, her dialed digit string matches the 9.@ pattern associated with the first trunk, because her analysis request can only see the route patterns defined in partition CallsFromAlice. On the other hand, when Bill dials an external number, his dialed digit string matches the 9.@ pattern associated with the second trunk. Figure 2-33 presents this behavior.

Figure 2-33. One-to-One Trunk-to-Station Mapping

Fallback Routing to Another PBX

If you migrate users from another telephone system to CallManager, which is connected to the other telephone system by a gateway, you might want to maintain the directory numbers of those users who have moved.

When you migrate users from one system to another, directory numbers within a directory number range are often spread between both systems. For example, if your directory number range is 8000 to 8999, CallManager might serve directory numbers 8101, 8301, and 8425, while the other telephone system serves all other extensions in the range.

Maintaining the routing between the two systems would be a very difficult task if you had to enter all of the extensions that the other phone system manages into the CallManager database one by one.

Using closest match routing, you can define a pattern, such as 8XXX, on the gateway to the other system. When a user that CallManager serves dials an extension that CallManager also serves, closest match routing causes specific pattern to match; however, if a user dials a number that CallManager does not control, route pattern XXXX sends the call to the other system.

For example, assume CallManager serves directory numbers 8101, 8301, and 8425. Route pattern XXXX corresponds to the gateway to the other phone system. If a user dials 8101, CallManager offers the call to the phone it controls, but if a user dials 8500, CallManager routes the call to the gateway to the other phone system.

If that was all there was to it, this configuration would not deserve its own section. However, what if the other phone system does not control any phone with directory number 8500? If the other phone system is configured to route unknown directory numbers to CallManager, the two systems will play table tennis with the call. The call forwards from system to system until it consumes all trunk resources between the systems. The call clears at that point, but the situation ties up all of the trunks temporarily. If the systems are connected by nonphysical resources such as intercluster trunks, CallManager bounces the calls between the systems indefinitely.

Calling search spaces and partitions allow you to break the routing loop. If you put the fallback pattern XXXX in a partition that is not included in the gateway's calling search space, when the other telephone system routes the outgoing call to 8500 back into CallManager, CallManager does not find any matches for the dialed number and rejects the call before the routing loop consumes all the gateway resources.

Multiple Call Appearances

Traditional PBX phones provide users with a one- or two-line display and rows of buttons next to LEDs. The limited user interface means that providing complex user features is quite a challenge.

Users of PBX phones, especially administrative assistants, require the ability to take numerous calls at a single number. In addition, users need to be able to transfer individual calls to other destinations, no matter how many calls currently terminate on the line. Traditional PBX phones accomplish this by permitting multiple appearances of the same directory number to appear on a single phone. These multiple appearances are termed call appearances. As new calls arrive at a phone with multiple call appearances, traditional PBXs offer them to unoccupied call appearances. By selecting different call appearances, a user at a phone can move from call to call and transfer individual users.

CallManager does not support multiple call appearances. If you assign a particular directory number to a line on a particular IP phone, CallManager Administration will not allow you to assign it to another line on that phone. However, using calling search spaces and partitions, you can emulate traditional call appearances very closely. Figure 2-34 shows an IP phone configured with multiple call appearances.

Figure 2-34. Multiple Call Appearances on an IP Phone

This functionality relies on the fact that, to CallManager, identical directory numbers in different partitions are different destinations. Because partition names do not show up on IP phone displays, to the user at 5000, it appears that there are three call appearances of directory number 5000.

Assume that you want to configure a phone with directory number 5000 with three line appearances. Create the partitions in Table 2-70.

When a call arrives for directory number 5000, if the first call appearance is busy, you want CallManager to forward the call to the second call appearance; likewise, if the second call appearance is busy, you want CallManager to forward the call to the third line appearance. Finally, if the third call appearance is busy, CallManager forwards the call to voice mail. Assume that the voice mail pilot number is 5050.

If the user is not present at the phone, CallManager rings the phone until the call forward no answer timer expires. Whether the call is ringing at the first, second, or third call appearance, if the user does not answer, CallManager should forward the call to voice mail.

Making the call forward from line appearance to line appearance means using some call forward calling search spaces. Configure the calling search spaces in Table 2-71.

Given these calling search spaces and partitions, you can configure phone 5000 according to Table 2-72.

Enhanced 911 Support

This section describes some aspects of emergency call handling in North America, but it is by no means a complete treatise on the subject. Rather, it informs you of some of the issues you may need to consider when configuring emergency call routing for your enterprise. Furthermore, legal requirements for emergency calls differ from state to state, so the information and example configuration that this section presents may not be valid in your enterprise's locale. At the time of this writing, at least seven states have legal requirements relating to emergency calls: Kentucky, Illinois, Mississippi, Tennessee, Texas, Vermont, and Washington.

In North America, the number for emergency services is 911. Local carriers route 911 calls to Public Safety Answering Points (PSAP). PSAPs are staffed with trained personnel and equipment that can properly handle emergency calls.

The North American PSTN treats calls to 911 very specially. Unlike other calls to the PSTN, after a call reaches the switches owned by the local carrier, calls to 911 usually route over an independent telephone network. Unlike a traditional call, the PSTN routes 911 calls based on the number of the caller, not the dialed digits. Note that different trunk interfaces deliver the calling number in different ways, and some trunk interfaces cannot deliver a calling number at all. For these latter trunk interfaces, the PSTN manages the calling number.

Users directly connected to the PSTN who dial 911 cause the local carrier to perform several database lookups when it handles the call. The piece of information that starts the lookups is the calling number of the user. Using this calling number, the local carrier looks in several databases to find the emergency service number (ESN), which indicates which PSAP needs to handle the call, and the automatic location identification (ALI), which provides a street address associated with the calling user. The PSAP informs the authorities of this address when dispatching medical, police, or fire-safety personnel to aid the caller.

Clearly, it is important to ensure that this address enables officials to actually locate the person in trouble. If your enterprise serves more than a few users, you should take special pains to ensure that the calling number you provide allows the local carrier to return an ALI that locates the caller's position accurately; one approach is to reserve some enterprise numbers specifically for the purpose of providing a calling number for 911 calls that can identify a caller's area to within a few thousand square feet, including building and floor number. (Having such a number is essential for extensions in your enterprise, such as lobby phones, that may not have external phone numbers.) Customizing the ALI database entry for a particular calling number typically requires that you contact the local carrier and public safety authorities.

Complicating the problem is that if the local carrier routes an emergency call to the incorrect PSAP because of incorrect calling number information, the PSAP is usually unable to redirect the call to the appropriate PSAP, because the tandem trunk networks over which 911 calls typically do not directly connect one PSAP to another.

CallManager supports basically two approaches to handling emergency calls:

• First, you can route emergency calls to a dedicated attendant station, along with the extension number of the calling user. In turn, the attendant contacts emergency personnel, usually remaining conferenced in on the call to assist if necessary.
• Second, you can route emergency calls directly to the local carrier by routing the call to a gateway connected to the local carrier and providing the digits 911. You must provide the appropriate calling number to the local carrier so that the carrier can route the call to the correct PSAP and provide the required ALI.

Figure 2-35 presents a small example network that demonstrates a 911 configuration. It depicts a distributed enterprise. One CallManager serves users in Dallas and in Richardson (a Dallas suburb). The enterprise has gateways connected to both the Dallas and the Richardson PSTN. Both the Dallas and the Richardson offices have an attendant whose directory number provides a good calling number to present to the PSTN for 911 calls; the attendant's location is reasonably close to the locations of users in the branch office.

Figure 2-35. Example Network for 911 Routing

The configuration supports three types of calls to the PSTN:

• 911 calls from Richardson users route to the gateway connected to the Richardson PSTN with the calling number of the Richardson attendant.
• 911 calls from Dallas users route to the gateway connected to the Dallas PSTN with the calling number of the Dallas attendant.
• All other calls route to the Dallas gateway first and to the Richardson gateway if the Dallas gateway is unavailable. (Note that despite this example to the contrary, it is an excellent idea to reserve a gateway or at least an interface on a gateway specifically for 911 calls. This way, you can guarantee that a caller in trouble can reach the PSTN.)

The configuration defines three different gateway access methods, which calls for the use of a route list. Assuming that you have already provisioned the gateways, you need to create the route groups in Table 2-73.

You have three different search algorithms. The first, used for 911 calls from Richardson, selects just the gateways connected to the Richardson PSTN. The second, used for 911 calls from Dallas, selects just the gateways connected to the Dallas PSTN. The last, used for all other external calls, selects the Dallas gateways first and the Richardson gateways next. Three search algorithms require three route lists, which Table 2-74 lists.

Distinguishing 911 calls from other calls requires using a route filter. The route filter that Table 2-75 lists selects only 911 calls from the North American numbering plan.

The sample configuration requires individualized routing. CallManager routes calls from Dallas users who dial 911 differently from calls from Richardson users who dial 911. Individualized routing requires the creation of partitions and calling search spaces. Table 2-76 contains the partitions that this example requires, and Table 2-77 contains the calling search spaces that this example requires.

Then, assign route patterns to the route lists. Table 2-78 lists the route patterns to define.

Finally, make sure that you assign the calling search space DallasUsers to phones in Dallas and RichardsonUsers to phones in Richardson, and set up the external phone number mask for each phone.