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: emergencymember: internalmember: nationalmember: 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: emergencymember: internalmember: 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 customname internalname emergencyname nationalname authorizeddial-peer cor list call-internalmember internaldial-peer cor list call-nationalmember nationaldial-peer cor list call-emergencymember emergencydial-peer cor list call-authorizedmember authorizeddial-peer cor list user-nationalmember internalmember nationalmember emergencymember authorizeddial-peer cor list user-authorizedmember internalmember emergencymember 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 potscorlist outgoing call-authorizeddescription AuthorizedNumber1destination-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.
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-linenumber 316name Operatorcorlist incoming user-authorizedephone-dn 17 dual-linenumber 317name Managercorlist 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.