Information Technology Reference
In-Depth Information
Okay, we've now seen how COR lists deny a call. Let's now follow a call that succeeds
from the employee phone (ephone-dn 2):
1.
An employee picks up her phone and calls 4805551212.
2.
CME immediately assigns the employee phone the 911-LOCAL COR list, which as-
signs the tags 911 and LOCAL.
3.
CME matches the outbound dial peer 11, which is assigned the outgoing COR list
LOCAL-CALL.
4.
The outgoing LOCAL-CALL COR list requires the LOCAL tag.
5.
Because the employee phone is assigned the 911 and LOCAL tags, the call completes
successfully.
Note:
In the previous COR list scenarios, the incoming COR list are applied to ephone-
DNs and the outgoing COR list are applied to dial peers. Although this is the most com-
mon configuration, you can apply incoming and outgoing COR lists to any combination of
calling or called entities. For example, you might apply an incoming COR list to a PSTN
dial peer to restrict which internal extensions a PSTN caller can reach.
That's the foundation of COR lists! Now, with that understanding, there are a couple im-
portant rules of COR lists that you should know:
Key
To p i c
Rule 1: If there is no outgoing COR list applied, the call is always routed.
Rule 2: If there is no incoming COR list applied, the call is always routed.
Typically, Rule 1 usually makes perfect sense. For example, if you created a PSTN dial-
peer that you'd like all phones to access, simply do
not
apply an outgoing COR list. After
that is done, the PSTN dial peer does not require any COR list tags to pass the call
through. Now, regardless of the incoming COR list applied to an ephone-dn (or a com-
plete lack of COR list applied to the ephone-dn), the call to the PSTN dial peer completes
successfully.
On the other hand, Rule 2 seems to make no sense at all. If a calling entity (like an
ephone-dn) does
not
have an incoming COR list, it is able to call any other entity regard-
less of the outgoing COR list assigned. Nonetheless, this is the way the rule works. Think
of it this way: If a calling entity does not have an incoming COR list, no calling restric-
tions are applied to the device. By using this approach, Cisco has lessened the potential of
causing outages when applying COR to your CME router. COR always requires an in-
bound COR list meeting an outbound COR list. If either of those entities is missing, CME
permits the call.
With these two rules in mind, we could make our previous configuration example more
efficient. You might remember that the scenario required the manager phone (ephone-dn
3) to be able to call any of the listed dial-peers. To accomplish this, we created a COR list
called “911-LOCAL-LD” that listed all three COR tags. However, in light of Rule 2, we
could have simply
not
assigned ephone-dn 3 an incoming COR list, and we would have
accomplished the same objective.
