Chapter 12. Configuring Class of Restrictions
Chapter 9, “Dial Plans,” listed the five components of a dial plan. This chapter focuses on implementing calling privileges. The calling privileges component of building a dial plan in a voice gateway is accomplished using Class of Restrictions (COR). COR is typically used in conjunction with Survivable Remote Site Telephony (SRST) or CallManager Express, but you can apply it to any dial peer on a voice gateway to restrict access.
This chapter helps you to do the following:
• Understand how COR operates.
• Use COR to restrict outbound and inbound calls in an SRST gateway.
• Use COR to restrict outbound and inbound calls in a CallManager Express gateway.
• Describe best practices for implementing COR.
COR Overview
Calling privileges describe the types of calls that a phone, or a class of phones, is able to place. For example, you might not want your lobby phones to be able to place long-distance calls, or you might want to restrict some employees from placing international calls. The call processing system typically controls these types of restrictions. When the router is the call processing system, running either SRST or CallManager Express, you implement calling privileges using COR.
COR is required only when you want to restrict some phones from making certain types of calls while allowing other phones to place those calls. If you do not want to allow any phones to call 1-900 “premium” calls in the United States, you can build your dial peers to prevent these calls. This is much simpler than implementing COR to restrict all phones from placing 1-900 calls.
COR is often described as a lock and key mechanism. Locks are assigned to dial peers using an outgoing COR list. Keys are assigned to dial peers using an incoming COR list. For a call to succeed, the inbound dial peer must have the key for each of the locks that is assigned to the outbound dial peer.
Assume that you want to allow users in Dept. A to make international calls, but users in Dept. B should not be allowed to call internationally. In that case, you would assign an International outgoing COR list containing a lock called ”International” to the outgoing dial peer. You would assign an incoming COR list that contains “International” (and possibly other types of calls) to the incoming dial peers associated with Dept. A. The incoming dial peers that are associated with Dept. B would not include “International.” Figure 12-1 illustrates the concept of incoming and outgoing COR lists.
Figure 12-1. Incoming and Outgoing COR Lists
As always, some exceptions cause the lock and key analogy to break down. The most important exception is when no incoming COR list is assigned to the inbound dial peer. In this case, the call succeeds even if an outgoing COR list is assigned to the outbound dial peer.
COR Operation
Two definitions are critical to understanding COR operation. In mathematics, a set is a list of numbers or labels. A subset is a set whose members are wholly contained in another set. Applying these concepts makes understanding COR operation simple. Calls succeed as long as the outgoing COR list is a subset of the incoming COR list. Table 12-1 shows the relationship between incoming and outgoing COR lists.
Note
If either the incoming dial peer or the outgoing dial peer does not have a COR list applied, the call succeeds.
Implementing COR
The commands to implement COR are straightforward, but getting the logic correct takes some practice. Always remember that for the call to fail, both an incoming and an outgoing COR list must exist, and the outgoing COR list must be a superset of the incoming COR list.
Four steps are required to implement COR:
Step 1. Define COR labels using the dial-peer cor custom name label command.
This step is analogous to defining variables when writing a program. You are creating a series of placeholders to be used to create the COR logic.
The COR labels that you define here will be the members of the COR lists, or permissions groups, that you define in the next step. The labels define the types of calls that you can make. A typical set of labels includes local, long-distance, and international calls. The following example shows the creation of four labels: Local, LongDistance, Mobile, and International.
Leeds(config)#dial-peer cor custom
Leeds(config-dp-cor)#name Local
Leeds(config-dp-cor)#name LongDistance
Leeds(config-dp-cor)#name Mobile
Leeds(config-dp-cor)#name International
You need to define call types only if some phones will be restricted from making those calls. For example, if all phones should be able to call emergency services, you do not need to define a COR label for emergency calls, because you will not be restricting calls to this dial peer using an outgoing COR list.
Step 2. Build the permissions groups using the dial-peer cor list list-name member label command.
Because a call is restricted only when the outgoing COR list is not a subset of the incoming COR list, you have a great deal of flexibility in the way you build your permissions groups. However, this flexibility can make this step confusing. To keep your COR implementation simple and reproducible, you should follow these two guidelines:
—All outgoing COR lists should have a single member.
—Incoming COR lists should contain a member for each call type that the phone should be able to place.
If you follow these two rules, your COR implementation will be similar to Partitions and Calling Search Spaces in Cisco CallManager. The outgoing COR list is analogous to a partition. You place the outbound dial peer into a single permissions group just like you would assign a partition to a gateway. The incoming COR list contains all the “partitions” that the inbound dial peer can call. This is analogous to assigning a calling search space to a device. This is especially useful in SRST mode because you can easily duplicate the calling privileges that Cisco CallManager grants. The following example shows how to build permission groups by defining outgoing and incoming COR lists. Notice that the outgoing lists have only one member, whereas the incoming ones might have several.
! OUTGOING COR LISTS
!
Leeds(config)#dial-peer cor list LocalCalls
Leeds(config-dp-corlist)#member Local
!
Leeds(config)#dial-peer cor list LDCalls
Leeds(config-dp-corlist)#member LongDistance
!
Leeds(config)#dial-peer cor list MobileCalls
Leeds(config-dp-corlist)#member Mobile
!
Leeds(config)#dial-peer cor list InternationalCalls
Leeds(config-dp-corlist)#member International
! INCOMING COR LISTS
!
Leeds(config)#dial-peer cor list LobbyPhones
Leeds(config-dp-corlist)#member Local
!
Leeds(config)#dial-peer cor list Employees
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
!
Leeds(config)#dial-peer cor list Managers
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
Leeds(config-dp-corlist)#member LongDistance
!
Leeds(config)#dial-peer cor list Executives
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
Leeds(config-dp-corlist)#member LongDistance
Leeds(config-dp-corlist)#member International
This configuration defines the four call types described in Step 1 (LocalCalls, LDCalls, MobileCalls, and InternationalCalls.) It also defines four COR lists that are used to group phones (LobbyPhones, Employees, Managers, and Executives) and states which type of calls each group is permitted to make.
Step 3. Apply COR lists to the outgoing dial peers using the corlist outgoing list-name command. Only one outgoing COR list is supported per dial peer.
The following example shows assignment of an outgoing COR list to each dial peer so that you can permit or deny calls appropriately. The example is based on a partial implementation of the UK National numbering plan that was described in Chapter 9.
Leeds(config)#dial-peer voice 7 pots
Leeds(config-dial-peer)#description Local calls within Leeds
Leeds(config-dial-peer)#destination-pattern [2-9]......
Leeds(config-dial-peer)#corlist outgoing LocalCalls
Leeds(config-dial-peer)#port 1/0/0:15
!
Leeds(config)#dial-peer voice 77 pots
Leeds(config-dial-peer)#description Calls to Mobile phones
Leeds(config-dial-peer)#destination-pattern 07[7-9]........
Leeds(config-dial-peer)#corlist outgoing MobileCalls
Leeds(config-dial-peer)#port 1/0/0:15
!
Leeds(config)#dial-peer voice 11 pots
Leeds(config-dial-peer)#description Long Distance Calls
Leeds(config-dial-peer)#destination-pattern 0[1-3].........
Leeds(config-dial-peer)#corlist outgoing LDCalls
Leeds(config-dial-peer)#port 1/0/0:15
!
Leeds(config)#dial-peer voice 100 pots
Leeds(config-dial-peer)#description International Calls
Leeds(config-dial-peer)#destination-pattern 00T
Leeds(config-dial-peer)#corlist outgoing InternationalCalls
Leeds(config-dial-peer)#port 1/0/0:15
Step 4. Apply COR lists to the incoming dial peers using the corlist incoming list-name command.
The method that you use to assign incoming COR lists depends on whether you are running Cisco CallManager Express, SRST or want to restrict inbound plain old telephone service (POTS) calls. Cisco CallManager Express and SRST are discussed in the next sections. You can assign an incoming COR list to any inbound POTS or Voice over IP (VoIP) dial peer. This allows you to control calling privileges for all call flows through a gateway. The following example demonstrates how to configure an analog phone that is connected to a Foreign Exchange Station (FXS) port to allow only local calling.
Leeds(config)#dial-peer voice 4001 pots
Leeds(config-dial-peer)#description Leeds Main Lobby Phone
Leeds(config-dial-peer)#destination-pattern 4001
Leeds(config-dial-peer)#corlist incoming LobbyPhone
Leeds(config-dial-peer)#port 2/0/0
Assigning COR Lists with SRST
When you are running SRST, you assign COR lists to your IP phones under the callmanager fallback configuration. You are limited to 20 incoming and 20 outgoing COR lists in SRST mode, but you can assign ranges of numbers to a list. If you plan your number assignments carefully, you should be able to accommodate all of your calling permissions.
You can also assign a default COR list in SRST mode. Any number that is not explicitly assigned to a COR list will be assigned to the default COR list. If the majority of your users will have the same privileges, you can assign them the same COR list even if the numbers are not consecutive.
In Example 12-1, IP phones with extensions 4005 through 4009 are assigned to the Employees COR list that is defined in Step 2 of the “Implementing COR” section, so employees will be able to make calls to local numbers and to mobile numbers. Extension 4010 is assigned to the Managers COR list created in Step 2 of the “Implementing COR” section, so managers will be able to make calls to local, mobile, and long-distance numbers. Extension 4050 is assigned to the Executives COR list, so executives will be able to make calls to local, mobile, long-distance, and international numbers. All other SRST phones will be assigned the default LobbyPhones COR list, which allows only local calls.
Example 12-1. Assigning Incoming COR Lists in SRST
Leeds(config)#call-manager-fallback
Leeds(config-cm-fallback)#ip source address 10.1.1.1 port 2000
Leeds(config-cm-fallback)#max-phones 8
Leeds(config-cm-fallback)#max-dns 16
Leeds(config-cm-fallback)#cor incoming LobbyPhones default
Leeds(config-cm-fallback)#cor incoming Employees 1 4005 - 4009
Leeds(config-cm-fallback)#cor incoming Managers 2 4010
Leeds(config-cm-fallback)#cor incoming Executives 3 4050
Assigning COR Lists with Cisco CallManager Express
In CallManager Express, you add an IP phone in two steps:
Step 1. You add the physical IP phone using the ephone configuration mode. In this step, you define the physical attributes of the phone so that it can register with CallManager Express. Each IP phone, or ephone, can have multiple lines.
Step 2. You define the lines using the ephone-dn configuration. In this step, you assign the extension that is associated with the line. In CallManager Express, lines, or extensions, are often referred to as ephone-dns.
When you are running Cisco CallManager Express, you assign incoming COR lists to your IP phones under the ephone-dn configuration. Because the COR lists are assigned to the ephone-dn, you can configure different calling privileges on a single IP phone. Example 12-2 illustrates how to assign incoming COR lists to ephone-dns.
Example 12-2. Assigning Incoming COR Lists in Cisco CallManager Express
Leeds(config)#ephone-dn 1
Leeds(config-ephone-dn)#description Leeds Admin
Leeds(config-ephone-dn)#number 4005
Leeds(config-ephone-dn)#cor incoming Employees
!
Leeds(config)#ephone-dn 2
Leeds(config-ephone-dn)#description Leeds Manager
Leeds(config-ephone-dn)#number 4010
Leeds(config-ephone-dn)#cor incoming Managers
!
Leeds(config)#ephone-dn 3
Leeds(config-ephone-dn)#description Leeds Executive
Leeds(config-ephone-dn)#number 4050
Leeds(config-ephone-dn)#cor incoming Executives
You can also assign outgoing COR lists to an ephone-dn to restrict who can call an IP phone. This requires additional labels to maintain compliance with the guidelines for configuring COR. The section “Restricting Inbound Calls” discusses this in more detail.
Assigning COR Lists to SIP Phones with CallManager Express
CallManager Express 3.4 added support for SIP phones. SIP phones are defined using the voice register dn dn-tag and the voice register pool pool-tag commands. You can assign incoming and outgoing COR lists under the voice register pool configuration. Assigning COR lists to SIP phones is similar to assigning COR lists to SRST phones. You can assign COR lists to a single SIP directory number or to a range of numbers using the following command:
cor {incoming | outgoing} cor-list-name {cor-list-number starting-number [- ending-number] | default}
Example 12-3 illustrates how to assign COR lists to SIP phones in CallManager Express.
Example 12-3. Assigning COR Lists to SIP Phones in CallManager Express
Leeds(config)#voice register pool 1
Leeds(config-register-pool)#id mac 000D.ED22.ED33
Leeds(config-register-pool)#type 7960-7940
Leeds(config-register-pool)#number 1 dn 1
Leeds(config-register-pool)#cor incoming Executives 1 4060
Restricting Inbound Calls
Restricting inbound calls adds a little complexity to your COR configuration. Reusing existing COR lists that are built to restrict outbound calls is usually possible, but your list names are not likely to be meaningful, and the logic might be difficult to follow.
In Example 12-4, calls from the PSTN to the lobby phone that is connected to port 2/0/0 are restricted. (Recall from Step 4 of the “Implementing COR” section that the lobby phone is an analog telephone.) Calls from the PSTN to IP phones are not restricted, as illustrated in Figure 12-2. To accomplish this, two new labels are added and assigned to a COR list with the same name:
• InToLobby—Assigned as an incoming COR list on the inbound dial peer from the PSTN
• OutToLobby—Assigned as an outgoing COR list on the dial peer that is associated with the lobby phone
Figure 12-2. Restricting Inbound Calls
Example 12-4. Restricting Inbound Calls
Leeds(config)#dial-peer cor custom
Leeds(config-dp-cor)#name Local
Leeds(config-dp-cor)#name LongDistance
Leeds(config-dp-cor)#name Mobile
Leeds(config-dp-cor)#name International
! additional label for inbound COR list
Leeds(config-dp-cor)#name InToLobby
! additional label for outbound COR list
Leeds(config-dp-cor)#name OutToLobby
!
! INCOMING COR LISTS
Leeds(config)#dial-peer cor list LocalCalls
Leeds(config-dp-corlist)#member Local
!
Leeds(config)#dial-peer cor list LDCalls
Leeds(config-dp-corlist)#member LongDistance
!
Leeds(config)#dial-peer cor list MobileCalls
Leeds(config-dp-corlist)#member Mobile
!
Leeds(config)#dial-peer cor list InternationalCalls
Leeds(config-dp-corlist)#member International
!
Leeds(config)#dial-peer cor list LobbyPhones
Leeds(config-dp-corlist)#member Local
!
Leeds(config)#dial-peer cor list InToLobby
Leeds(config-dp-corlist)#member InToLobby
!
Leeds(config)#dial-peer cor list OutToLobby
Leeds(config-dp-corlist)#member OutToLobby
!
! OUTGOING COR LISTS
!
Leeds(config)#dial-peer cor list Employees
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
Leeds(config-dp-corlist)#member OutToLobby
!
Leeds(config)#dial-peer cor list Managers
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
Leeds(config-dp-corlist)#member LongDistance
Leeds(config-dp-corlist)#member OutToLobby
!
Leeds(config)#dial-peer cor list Executives
Leeds(config-dp-corlist)#member Local
Leeds(config-dp-corlist)#member Mobile
Leeds(config-dp-corlist)#member International
Leeds(config-dp-corlist)#member OutToLobby
!
! ASSIGNING COR LISTS TO DIAL PEERS
!
Leeds(config)#dial-peer voice 1 pots
Leeds(config-dp-corlist)#description Inbound From PSTN
Leeds(config-dp-corlist)#incoming called-number .
Leeds(config-dp-corlist)#corlist incoming InToLobby
Leeds(config-dp-corlist)#port 1/0/0:15
!
Leeds(config)#dial-peer voice 4001 pots
Leeds(config-dp-corlist)#description Main Lobby Phone
Leeds(config-dp-corlist)#destination-pattern 4001
Leeds(config-dp-corlist)#corlist incoming LobbyPhone
Leeds(config-dp-corlist)#corlist outgoing OutToLobby
Leeds(config-dp-corlist)#port 2/0/0
Because the inbound COR list is not a subset of the outbound COR list, the goal of restricting PSTN calls to the lobby phone has been met. For the IP phones to call the lobby phone, you must add the OutToLobby label to the Employees, Managers, and Executives incoming COR lists. Because no outgoing COR lists are assigned to the IP phones, calls from the PSTN to IP phones will still be completed.
Case Study: Implementing COR for Miami
The gateway at the Miami location routes all toll calls to the New York gateway to take advantage of volume discounts, as shown in Figure 12-3. A recent audit has uncovered numerous calls to international numbers, and senior management has instructed you that only the Miami branch manager should be able to make international calls. The Cisco CallManager server was reconfigured to handle this restriction during normal operation. You must reconfigure the gateway with COR to maintain the restriction when its CallManager server is unavailable.
Figure 12-3. Restricting International Calls from Miami
The Miami branch manager is assigned extension 150. The configuration in Example 12-5 allows only extension 150 to place international calls when the gateway is operating in SRST mode.
Example 12-5. Configuring COR in the Miami Gateway
Miami#show configuration
Building configuration...
Current configuration : 3077 bytes
!
! Unnecessary Output Omitted...
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.25
encapsulation dot1Q 25
ip address 10.10.25.1 255.255.255.0
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 10.10.50.1 255.255.255.0
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
controller T1 0/3/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-12 type e&m-fgd
ds0-group 2 timeslots 13-24 type fgd-eana
!
ip classless
!
!
!
voice-port 0/0/0
!
voice-port 0/0/1
!
voice-port 0/1/0
!
voice-port 0/1/1
!
voice-port 0/3/0:1
!
voice-port 0/3/0:2
!
!Define COR Labels
!
dial-peer cor custom
name International
name NoInternational
!
!Create Outgoing COR List
!
dial-peer cor list International
member International
!
! Create Incoming COR List To DENY International Calls
!
dial-peer cor list Employee
member NoInternational
!
! Create Incoming COR List To PERMIT International Calls
!
dial-peer cor list Manager
member International
!
!
dial-peer voice 1 pots
description Inbound Calls from PSTN
incoming called-number .
port 0/3/0:1
!
dial-peer voice 911 pots
description Emergency Calls
destination-pattern 911
port 0/3/0:2
prefix 911
!
dial-peer voice 9911 pots
description Emergency Calls
destination-pattern 9911
port 0/3/0:2
prefix 911
!
dial-peer voice 7 pots
description Local Calls
destination-pattern 9[2-9]......
port 0/3/0:2
!
dial-peer voice 11 voip
description Long Distance via NY Gateway
destination-pattern 91[2-9]..[2-9]......
session target ipv4:10.1.50.1
preference 1
!
dial-peer voice 112 pots
description Long Distance
destination-pattern 91[2-9]..[2-9]......
port 0/3/0:2
prefix 1
preferenece 2
!
dial-peer voice 9011 voip
Description International Calls via NY Gateway
corlist outgoing International
destination-pattern 9011T
session target ipv4:10.1.50.1
preference 1
dial-peer voice 90112 pots
description International Calls
corlist outgoing International
destination-pattern 9011T
port 0/3/0:2
prefix 011
preference 2
!
dial-peer voice 900 pots
description Block 1-900 Calls
destination-pattern 91900.......
!
dial-peer voice 976 pots
description Block 1-976 Calls
destination-pattern 91976....
!
call-manager-fallback
max-conferences 8
ip source-address 10.10.50.1 port 2000
max-ephones 64
max-dn 192
!
! Deny International Calls By Default
!
cor incoming Employee default
!
! Permit International Calls for Ext 150
!
cor incoming Manager 1 150
!
To restrict international calls to just the branch manager, you need to create an outgoing COR list and two incoming COR lists. The outgoing COR list is applied to the international dial peers and contains a single member, International. The branch manager is assigned an incoming COR list that also contains International. All other extensions are assigned an incoming COR list with NoInternational. You could also meet the requirements with a single incoming COR list assigned to all extensions except extension 150. If extension 150 is not assigned an incoming COR list, it is not restricted from outbound dial peers. To use this approach, you would have to assign the incoming COR list to each of the other extensions—you could not use the default keyword—which will most likely result in additional configuration and might exhaust the number of COR lists that you can assign. Explicitly defining the incoming COR lists also makes the configuration more intuitive to understand.
Review Questions
1 What conditions must exist for COR to restrict a call?
2 An outgoing COR list is analogous to which Cisco CallManager Class of Control setting?
3 An incoming COR list is analogous to which Cisco CallManager Class of Control setting?
4 How many COR lists can you assign in SRST?