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