Cisco VoIP

Restricting calls on CME: COR

 

 

 

 

 

 

Understanding COR lists:

In this post I’ll show you how to restrict extensions on CME from placing calls to not allowed numbers. CME has a great tool called Class Of Restriction (COR) which allows us to establish a very granular control over the calls made in our CME based telephony system. For this post we will restrict some extensions from placing calls to local numbers except those manually defined for the network administrator.

COR is just a way to classify and group dial-peers on lists, playing with sets and sub-sets. After we assign these lists to end ephones to provide permissions. A COR list has this aspect:

COR list <user-national>
 member: emergency
 member: internal
 member: national
 member: authorized

We can read the list as, “ephones belonging to the user-national COR list are allowed to place calls to other internal extensions, emergency services, national numbers and a group of manually authorized destinations”

After, if we set up another restricted group like this:

COR list <user-restricted>
 member: emergency
 member: internal
 member: authorized

Ephones belonging to this group will not be able to call to national peers except those explicity allowed on the authorized group.

Now we understand the nomenclature, the complete configuration would be:

dial-peer cor custom
   name internal
   name emergency
   name national
   name authorized
dial-peer cor list call-internal
   member internal
dial-peer cor list call-national
   member national
dial-peer cor list call-emergency
   member emergency
dial-peer cor list call-authorized
   member authorized
dial-peer cor list user-national
   member internal
   member national
   member emergency
   member authorized
dial-peer cor list user-authorized
   member internal
   member emergency
   member authorized

Briefly, first we modify the default custom list adding those name lists we will need later. After we create sets of members, where a set defines the allowed destinations.

Defining allowed peers:

How we define these authorized peers? Now it’s time to play with dial-peers. We just need to manually specify these numbers that we want to give permission, for instance:

dial-peer voice 5000 pots
   corlist outgoing call-authorized
   description AuthorizedNumber1
   destination-pattern 0987654321

*Note I didn’t specify any trunk or translation-profile since is out of scope for this post.

Dial-peer 5000 classifies the destination 0987654321 as a member of the authorized group. Notice the outgoing direction is from the stand of the CME, that is, exiting calls.

 Classifying extensions:

Last step is putting each extension where we want. Suppose extension 316 is a restricted phone and 317 a fully capable phone:

ephone-dn 16 dual-line
   number 316
   name Operator
   corlist incoming user-authorized
ephone-dn 17 dual-line
   number 317
   name Manager
   corlist incoming user-national

As the calls starts at the phone and arrive to the CME, the corlist direction is incoming.

If the COR applied on an incoming dial-peer (for incoming calls) is a super set or equal to the COR applied to the   outgoing dial-peer (for outgoing calls), the call goes through. Incoming and outgoing are terms used with respect to the “voice ports”. COR is often described as a lock and key mechanism. Locks are assigned to dial peers with an outgoing COR list. Keys are assigned to dial peers with an incoming COR list.

At this moment, if we try to make a local call to a non-defined peer in the authorized list from the 316 extension, a busy tone will be played.

 

Related Posts

No Comments

Leave a Reply