You can use CORs to restrict communication between point A and point B. For example, a user tries to establish a communication path between point A and point B. The system checks whether the CORs have permission to communicate with one another. If the CORs have permission, the system completes the call. If the CORs do not have permission, the system does not complete the call. You control the level of restriction that the COR provides.

CORs also have other applications. You can apply administration settings to a COR, and then assign that COR to objects or facilities in the system. This use of CORs makes it easier to administer functions across a wide range of objects. CORs are assigned to a variety of objects, such as:

• Telephones

• Trunks

• Agent login IDs

• Data modules

Finally, you can set up CORs that are service observing and service observed. You can assign a COR to be a service observer. Then you identify what other CORs that the user can observe. You can also set up a COR to be serviced observed.

Many objects can share the same COR number. You must administer a COR for the following objects:

• Agent login IDs

• Access endpoints

• Announcements and audio sources

• Attendant consoles

• Authorization codes

• Console parameters

• Hunt groups

• Loudspeaker paging

• Data modules

• Remote access (each barrier code has a COR)

• Telephones

• Terminating Extension Groups (TEGs)

• Trunk groups

• Vector Directory Numbers (VDNs