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:

Step 1.	Configuring the external phone number mask for phones in your enterprise. The external phone number mask essentially defines the raw public network number for a phone. For instance, in North America, a phone might have the number 214 555 1212 on the public network.
Step 2.	Enterprises most often rely on external access codes to route calls to the PSTN (for example, 9 is used to route a call throughout the PSTN in most North American PBXs). As a result, prefix digits often need to be added to route the caller's automated redial attempt out to the public network. Therefore, you must define AAR groups to define these transformation rules. AAR groups operate as a matrix. When a reroute is required, CallManager looks at the AAR group associated with the caller and the AAR group associated with the called party. For each unique ordered pair of groups, you define which digits must be prepended for CallManager to modify the number to something that routes to the public network. For instance, in a country with a completely uniform numbering plan, you might put all your phones and gateways in a single AAR group with the single prefix digit 9, to allow the redial call to prepend your PSTN access digit. All phones are deemed to be part of the same dialing domain when they all are addressed with the same structure on the PSTN (for example, NPA NXX XXXX in North America).   Note The combination of the external phone number mask with the AAR group normalizes all AAR calls within North America to a structure of 9 1 NPA NXX XXXX, and relies on the locally significant AAR calling search spaces to adapt the string in cases where the destination is reachable using a 7-digit or 10-digit local dialing pattern. Local variations can be accommodated by the AAR calling search space of the calling device. For instance, a New York number may be called by dialing 9 1 212 555 1234 from California (in fact, from probably anywhere in North America except New York), but if the same destination is called from a phone within the same seven-digit local calling area in New York, only 9 555 1234 is required. The solution is to insert a translation pattern in the AAR calling search space of all phones within the same local seven-digit calling area: The translation pattern would need to be 91212.555XXXX, and would strip digits PreDot, followed by the prepending of 9. If phones are situated in different dialing domains, you must configure different AAR groups. For instance, if an enterprise has phones from the same cluster in both North America and England, a New York number might be reachable from another North American site by prepending 91 to the number contained in the external phone number mask (212 555 1234), but you might need 001 prepended to call this same number from the site in England. AAR groups allow you to define unique prepending rules for each pair of source-destination dialing domains.
Step 3.	After you've configured the AAR group matrix under Route Plan > AAR Group, assign the AAR groups to the appropriate devices. Assignment of AAR groups is always on the respective device page.
Step 4.	Because the AAR calling search space is invoked only when a call to an on-net destination has been denied by call admission control, it is okay to include toll-call route patterns even if the regular calling search space of the calling phone is not allowed toll calls. Remember that the AAR calling search space is invoked only if the original call is to an OnNet destination and that destination is part of the calling phone's permitted destinations. A very permissive AAR calling search space does not allow for calls to unauthorized destinations resulting in toll fraud.

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.

Table 2-70. Partitions for Multiple Call Appearances

Partition	Description
Standard	Assigned to the first call appearance of the IP phone, this partition represents the partition to which you normally assign your phone users
Line2	Assigned to the second call appearance of the IP phone
Line3	Assigned to the third call appearance of the IP phone

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.

Table 2-71. Calling Search Spaces for Multiple Call Appearances

Calling Search Spaces	Partitions	Description
Standard	Varies	This calling search space includes whatever partitions the users need to place their day-to-day calls. At the very least, this calling search space typically includes the ability to call other internal extensions, emergency services, and voice mail.
Line2	Line2	This calling search space permits a user to call any call appearance assigned to the Line2 partition.
Line3	Line3	This calling search space permits a user to call any call appearance assigned to the Line3 partition.

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

Table 2-72. Directory Number Configuration Pages for Multiple Call Appearances

First Call Appearance
Setting	Value		Description
Directory Number	5000
Partition	Line1
Calling Search Space	Standard		Provides access to all numbers the user is permitted to dial
Call Forward Busy	Destination	Calling Search Space	Forwards the call to line 2 when line 1 is busy
	5000	Line2
Call Forward No Answer	Destination	Calling Search Space	Forwards the call to voice mail when line 1 does not answer
	5050	Standard
Second Call Appearance
Setting	Value		Description
Directory Number	5000
Partition	Line2
Calling Search Space	Standard		Provides access to all numbers the user is permitted to dial
Call Forward Busy	Destination	Calling Search Space	Forwards the call to line 3 when line 2 is busy
	5000	Line3
Call Forward No Answer	Destination	Calling Search Space	Forwards the call to voice mail when line 2 does not answer
	5050	Standard
Third Call Appearance
Setting	Value		Description
Directory Number	5000
Partition	Line3
Calling Search Space	Standard		Provides access to all numbers the user is permitted to dial
Call Forward Busy	Destination	Calling Search Space	Forwards the call to voice mail when line 3 is busy
	5050	Standard
Call Forward No Answer	Destination	Calling Search Space	Forwards the call to voice mail when line 3 does not answer
	5050	Standard

 

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.

Table 2-73. Route Groups for 911 Routing

Route Group Name	Gateways Contained
DallasGateways	DallasGateway
RichardsonGateways	RichardsonGateway

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.

Table 2-74. Route Lists for 911 Routing

Route List Name	Route Groups Contained
Richardson911Calls	RichardsonGateways
Dallas911Calls	DallasGateways
PSTNCalls	DallasGateways, RichardsonGateways

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.

Table 2-75. Route Filter for 911 Routing

Route Filter Name	Value
911Calls	SERVICE == 911

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.

Table 2-76. Partitions for 911 Routing

Partition Name	Description
PSTNCalls	Contains route patterns that grant PSTN access to all enterprise users
Dallas911	Contains the route pattern that grants 911 access to Dallas users
Richardson911	Contains the route pattern that grants 911 access to Richardson users

Table 2-77. Calling Search Spaces for 911 Routing

Calling Search Space	Contains Partitions	Description
DallasUsers	Dallas911, PSTNCalls	Provides customized PSTN access for Dallas users
RichardsonUsers	Richardson911, PSTNCalls	Provides customized PSTN access for Richardson users

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

Table 2-78. Route Patterns for 911 Routing

Route Pattern	Description
Partition: PSTNCalls Route Pattern: 9.@ Route List: PSTNCalls Use External Phone Number Mask: Yes Digit Discarding Instructions: PreDot	Provides general access to the PSTN. CallManager strips the 9 from the called number before extending the call to the PSTN. CallManager uses the external phone number mask that you configure on the calling user's Directory Number Configuration page as the calling number.
Partition: PSTNCalls Route Pattern: 9.@ Route Filter: 911Calls Route List: Richardson911Calls Use External Phone Number Mask: No Calling Party Transformation Mask: 9725551212 Digit Discarding Instructions: PreDot	Contains the route pattern that grants 911 access to Richardson users. Closest match routing rules ensure CallManager selects this route pattern when a Richardson user dials 911. CallManager strips the 9 from the called number and substitutes the Richardson attendant's number for that of the caller.
Partition: PSTNCalls Route Pattern: 9.@ Route Filter: 911Calls Route List: Dallas911Calls Use External Phone Number Mask: No Calling Party Transformation Mask: 2145551212 Digit Discarding Instructions: PreDot	Contains the route pattern that grants 911 access to Dallas users. Closest match routing rules ensure CallManager selects this route pattern when a Dallas user dials 911. CallManager strips the 9 from the called number and substitutes the Dallas attendant's number for that of the caller.

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.