Setting Guidelines for Who Can Make Calls

Imagine a visitor walking into the lobby of your company. The visitor checks in with the receptionist, and while they're waiting in the lobby, they decide to make a few calls using the phone sitting next to the couch. Unfortunately, they make long-distance calls, running up your company's phone bill. In addition to avoiding this situation, perhaps you don't want to allow certain employees to make long-distance calls.

PBXs restrict such unwanted calls using class of service settings. For example, when I worked at a university, we configured our PBX extensions with four different classes of service, as shown in Table 4-3.

Table 4-3. University Class of Service Example
Class of Service	Allowed Destinations
2	On-campus calls only (A calling card was required to call off-campus.)
3	On-campus calls Local calls
8	On-campus calls Local calls Long-distance calls
20	On-campus calls Local calls Long-distance calls International calls

At the university, we assigned a class of service of 2 to student phones in residence halls, and a class of service of 3 to most faculty and staff. Managers received a class of service of 8, and only a few designated phones in the telecommunications department received a class of service of 20.

The Cisco CallManager environment offers a similar solution to controlling which phones can call which destinations. The CCM environment uses partitions and calling search spaces to restrict calls.

Partition A partition defines a set of route patterns and/or directory numbers. Phones that can reach one route pattern within a partition can reach all route patterns within the partition.
Calling Search Space A calling search space is a list of partitions in which a device (for example, an IP phone) is allowed to look when matching dialed digits.

Visualize a partition as a "cookie jar." Different cookie jars represent different categories of destinations we can call. For example, imagine that you have four cookie jars, labeled Internal, Local, Long-Distance, and International, as shown in Figure 4-9.

Figure 4-9. Partitions are "Cookie Jars"

These "cookie jars" contain numbers (or number patterns) callers can dial. For example, the Internal partition might contain a pattern representing all four-digit internal extensions ranging from 2000 through 5999, while the Local partition contains seven-digit numbers beginning with the local office code of 624. The Long-Distance partition contains ten-digit numbers, and the International partition contains numbers of any length (because different countries might use country codes of different lengths), as shown in Figure 4-10.

Figure 4-10. Partitions Contain Destination Numbers

Partitions by themselves do not restrict calls, however. We use partitions in conjunction with Calling Search Spaces (CSSs). A calling search space is a list of partitions in which a particular extension is allowed to look when it tries to find the dialed number. In our example, you might have a Lobby CCS and an Executive CCS. The Lobby CCS might contain the Internal partition, and the Executive CCS might contain the Internal, Local, Long-Distance, and International partitions, as shown in Figure 4-11.

Figure 4-11. Calling Search Spaces

After defining calling search spaces, we assign these CSSs to extension numbers on specific IP phones. For example, if a lobby phone uses directory number 2020, we assign the Lobby calling search space to the directory number 2020.

When a visitor wanders into the lobby and picks up the lobby phone, they only have permission to call internal numbers (and of course 911 for emergency situations). Meanwhile, executives might call anywhere in the world using their IP phones because their directory numbers have the Executive CCS assigned.

note

All partitions, even those being used to restrict calls to internal extension numbers, should allow 911 calls.

Partitions and calling search spaces also offer the ability to route calls by the geographic location of a phone (for example, to help prevent a 911 call from being routed to an incorrect location). Consider the challenge with 911 emergency services. Let's say your company deployed a centralized call processing model across three cities. Louisville serves as the headquarters, and Cincinnati and Lexington act as branch offices. In this centralized model, the IP phones located in the Lexington and Cincinnati offices connect back to a centralized CCM cluster in Louisville. However, by default, if someone in Lexington or Cincinnati dialed 911, the Louisville location would forward the call to the Louisville 911 service, and the emergency response personnel would show up at the wrong location!

Partitions and calling search spaces can help prevent such a scenario. For example, if you install one or more Foreign Exchange Office (FXO) ports into the Lexington router and connect those ports to local phone lines coming from the Lexington central office (CO), as shown in Figure 4-12, 911 calls placed from Lexington could be forwarded out to the local 911 authorities. In this example, let's say you create a partition named Lex_911, which contained a dial pattern that pointed 911 calls out a local FXO port. We then assign the Lex_911 partition to each of the Lexington's calling search spaces (for example, Lex_Internal, Lex_Local, Lex_Long-Distance, and Lex_International), which are then assigned to IP phones. You configure the Cincinnati and Louisville locations similarly. As a result, when a caller in the Lexington office dials 911, the 911 call goes to the Lexington 911 authorities. Similarly, when a caller in Cincinnati dials 911, the call goes to the Cincinnati 911 authorities.

Figure 4-12. 911 Services Using Partitions and Calling Search Spaces Example

For larger environments, we might want to implement the Cisco Emergency Responder (CER) software, as opposed to using partitions and calling search spaces to direct 911 calls. CER synchronizes the CCM cluster's phone database with the 911 Public Safety Answering Point (PSAP), which can identify the caller's approximate physical location.

One of the major benefits of IP phones is the ability to move those phones from location to location. However, if we move a phone to another location, we need the CER to still know where the phone is located. The challenge is how to locate an IP phone that might be moved from location to location.

The Cisco endpoint location technologies can locate an IP phone even though we unplug it from one switch and plug it into another switch on another floor or in another building. Here's the logic. Although your IP phone is portable, Catalyst switches are not typically moved. So, if your IP phone connects to a Catalyst switch known to be on the second floor of Building A, your IP phone (that is, your current location) can be assumed to also be on the second floor of Building A. These Ethernet switches learn the Media Access Control (MAC) address of devices connected to them. A MAC address is a 48-bit address physically burned into the circuitry in a network interface. Therefore, an Ethernet switch learns the MAC addresses of IP phones connecting to that switch. The CER software communicates with the switches to determine which MAC addresses are connected to which switch. Because the CER software knows the phones associated with these IP phone MAC addresses, and because it knows where each switch is physically located (for example, in the third floor wiring closet in a building at a certain address), the CER software can provide the approximate location of each IP phone to 911 authorities.