ATT DEFINITY Communications System Generic 3 Instructions Manual

							Class of Restriction (COR)
Issue  3   March 1996
3-537
Partitioned Group Number (PGN)
When AAR and ARS services are to be partitioned among different groups of 
users within a single system, all users in a specific group must share the same 
PGN. A PGN is assigned to each COR. The PGN is not a restriction, but a means 
used to indicate the choice of route tables to b e used on a particular call.
If the Time of Day Routing feature is assigned, this field is replaced with a “ Time 
of Day Plan Numb er”  field.  This field is used to assign each COR one of eight 
Time of Day Routing Plans to be used when routing AAR and ARS  calls.  Time of 
Day Routing  provides the most economical routing of AAR and ARS calls based 
on the time of day or week that each call is made.  For more information on Time 
of Day Routing, see the Time of Day Routin g feature elsewhere in this chapter.
Service Observing
Service Observing allows a specified user, such as a s plit supervisor, to observe 
a call that involves other users while the call is in progress. For a user to observe 
calls, they must be assigned a COR that allows them to b e a service observer. 
For someone to have their calls observed, they must be assigned a COR that 
allows them to be service observed. If the user wishes to observe VDNs or use 
vector initiated service observing, VDNs must also be assigned appropriate 
CORS.
When activation of Service Observing occurs through a sequence of multiple 
entities, for example several VDNs, Remote A ccess Barrier Codes, or 
Authorization Codes, the COR of the last entity is use d to determine observer 
permissions. When Service Observing is activated by Remote Access Barrier 
Code or Authorization Code, the c o de must have a COR that allows the user to 
be a service observer.
For more information, see the Service Observing feature d esc ription elsewhere 
in this chapter.
VDN of Origin Announcement
VDN of Origin Announcement (VOA) is a feature that provides a brief message 
for a gents to know a caller’s city of origin or requested service, based on the 
vector processing that directed the call to the agent. VOA is COR-dependent. 
Users who have a COR that allows VOA can receive the VDN of Origin 
messages. Users who have a COR that denies VOA are not able to receive the 
VDN of Origin messages.
Priority Queuing
Priority Queuing allows calls with increased priority to be queued (at hunt 
groups) ahead of calls with normal priority. If a COR is a dministered as having 
Priority Queuing, calls made by a user with that COR are q ueued ahead of 
non-priority calls and are answered sooner. VDN of Origin Announcement is only 
available with G3V3 and later releases. 
						

							Feature Descriptions
3-538Issue  3   March 1996 
For intraflowed calls from one hunt group to another to be given p riority queuing 
treatment, ACD software must b e activate d.
DAC
The “Direct Agent Calling” field on the COR form indicates whether the user can 
originate and receive Direct Ag ent calls through an adjunct.  If either the 
originating or the d estination party of a Direct Ag ent call does not have the 
proper COR, the call is denied.
Direct Agent Calling allows an adjunct to transfer a call to a particular agent and 
have the call treated as a call to a sp lit. For more information on DAC, see the 
Automatic Call Distribution (ACD) and Inbound Call Management (ICM) 
features elsewhere in this chapter.
Facility Access Trunk Test
This field on the COR form is used to g rant a user permission to make Facility 
Test Calls to access trunks. A y in this field allows users with this COR to make 
these calls. An n in this field causes users with this COR to receive intercept 
treatment when they attempt to make these calls. For more information on Facility 
Test Calls, see the Facility Test Calls (with Security Measures) feature 
elsewhere in this chapter.
Fully Restricted Service (G3i-Global, G3rV1, 
and G3V2 and later)
Denies the specified voice terminal access to public network trunks for either 
incoming or outgoing completion.  Note that Restriction Override should be set to 
“none.” See below.
Restriction Override (3-way COR calling)
The Restriction Override feature (available only with G3i-Global and G3V2 and 
later releases) determines whether or not there is a 3-way COR check made on 
Conference and Transfer calls. If a Conference or Transfer is denied because of 
the 3-way COR check, a further check is made to see if Restriction Override is 
possible. The COR causing the denial is checked to see if Restriction Override is 
assigned to be other than “none.” If the override type is “attendant” or “all,” the 
third (or controlling) p arty is c he cked to see if it belongs to the restricition 
override class of 
user. If so, the call is allowed. If the controlling party is not of the 
matching type or the restriction override is set to “none,” the call is denied.
Restricted Call List
A Restricted Call List is assigned to the system by the System Manager. This call 
list is made up of specific digit strings which cannot b e dialed from facilities that 
are restricted by the call list.  The “Restricted Call List” field on the COR form is 
used to determine which facilities are restricted by this call list.  If a COR has this  
						

							Class of Restriction (COR)
Issue  3   March 1996
3-539
field administered as y, facilities with that COR cannot be used to dial a number 
that matches one of the digit strings in the Restricted Call List.
Unrestricted Call List
Ten Unrestricted Call Lists are assigned to the system by the System Manager. 
Each Unrestricted Call List is made up of specific digit strings which can be 
dialed from facilities associated with the call list.  The “ Unrestricte d Call List”  
fields on the “COR” form are used to determine which facilities have access to 
each of the ten call lists.  If a COR has any of these ten fields a dministered with 
an Unrestricted Call List numb er, facilities with that COR can call any numbers 
contained in the assigned list(s) (unless the number is included in the Restricted 
Call List, which overrides the Unrestricted Call List).
Selective Denial of Public Network Calling Through a CCSA or EPSCS 
Network (APLT)
Public network calling via the private CCSA or EPSCS network (commonly 
referred to as off-network calling) is optional on a per-private network basis.  If 
off-network calling is not provided, then the “ APLT”  field can be ignored.  If 
off-network calling is provided, then permission or denial to access the 
off-network capability is set via the “ APLT”  field.  Users assigned a COR that has 
APLT set to n (no) can use off-network calling. Users assigned a COR that has 
APLT set to y (yes) cannot.  If there is a need for both yes and no choices in a 
system, separate CORs must be assigned to reflect this.
Looking at the screen used to administer CORs, the “APLT” field is preset as y. 
This means that a facility with this COR is not allowed to access CCSA or EPSCS 
off-network capabilities for p ublic network calling.  An n in this field would 
indicate that the facility can access CCSA or EPSCS off-network c a pabilities.
ARS/AAR FRL for Control of Call Routing
If the system does not use AAR or ARS to d etermine the most preferred routing of 
calls, then the “ FRL”  field can be ignored.  If AAR or ARS  is used, then an FRL is 
used to either allow or d eny access to certain routes. The FRL for the outgoing 
(trunk) side of the call is provided in the AAR/ARS Routing Pattern.  Although 
each outgoing trunk group has a COR and  each COR has an FRL, this FRL is not 
used unless the trunk group is the originator of the call.  Call routing is 
determined by a comparison of the FRLs in the AAR/ARS Routing Pattern and the 
FRL in the COR of the call originator (typically, a voice terminal user).
The “ FRL”  field is preset to 7. However, this field c an have a value of 0 through 7.  
An originating FRL of 0 has the least calling privileges, whereas an originating 
FRL of 7 has the most calling privileges. Each route (For number of routes, see, 
Appendix A, System Parameters) in each of the   ARS/AAR Routing Patterns 
also has an FRL.  These route FRLs c an also have a value of 0 through 7. A route 
FRL of 0 is the least restrictive, whereas a route FRL of 7 is the most restrictive. 
An  FRL of 0 is checked before the other routes in a given ARS routing pattern.  
To access a route, the originating FRL must be greater than or equal to the route 
FRL.  Determination of appropriate FRL values must be made with respect to the  
						

							Feature Descriptions
3-540Issue  3   March 1996 
outgoing routes from a sp ecific system and the desired levels of calling 
privileges. This is part of AAR/ARS customization. The FRL of the call originator is 
contained in the COR assigned.  The “ FRL”  field in a COR assigned to an 
outgoing trunk group is never checked and should be ignored.
Assuming AAR and/or ARS has been customized for a system, the System 
Manager must establish unique CORs for each of the up to eight levels of ARS 
calling privileges that is used in the system.  However, these CORs must 
maintain the desired restrictions d ictated by the other fields on the sc reen form.  
The simplest case is a COR specifying no restriction.  Ordinarily, this COR can 
be assigned to all unrestricted users.  However, if some subset(s) of these users 
requires different FRLs, separate CORs must be established for each different 
FRL required.
For a  detailed description of Automatic Alternate Routing (AAR),  Automatic 
Route Selection (ARS), and Facility Restriction Levels (FRL s) a n d  Traveling 
Class Marks (TCMs), refer to the individual feature descriptions given elsewhere 
in this chapter.
Miscellaneous Restriction Groups
Misc ellaneous Trunk and Miscellaneous Terminal Restriction groups restrict 
access to a terminal, module, zone, attendant console, or group. This is 
accomplished via the COR assigned to the calling and the  called facilities.  
When a COR is a dministered, access by that COR to each of the CORs is either 
allowed or denied.  Since a given COR can be assigned to both calling and 
called facilities, calling to one’s own COR can be restricted. This is fully 
explained in the following paragraphs.
The simplest way to understand miscellaneous restrictions is to look at the 
screen used during implementation. When a COR is established, the assigned 
number is entered in the “ COR Number” field. If this COR is assigned to a facility 
that originates a call, such as a voice terminal, the calls to CORs associated with 
terminating facilities can be prohibited.  The Miscellaneous Restriction group 
information is found in the “Calling Permission”  field.  A “y” entry in this field 
indicates that the COR specified at the top of the form can  call the COR numb ers 
that contain a “y.” If an “n” is entered, the s pecified COR cannot be called by the 
COR number at the top of the form.  On the screen form no restrictions apply 
because all CORs are specified as “y.”
Misc ellaneous restrictions are checked on the initial call termination and on 
redirection.
Misc ellaneous Restriction groups apply on a per-COR basis.  However, the same 
COR can be assigned to more than one facility.  Facilities with the same COR 
may be like facilities (such as two voice terminals) or d ifferent facilities (such as a 
voice terminal and a trunk group).  In either case, the same restrictions a pply to 
both facilities. 
						

							Class of Restriction (COR)
Issue  3   March 1996
3-541
Certain facilities, such as voice terminals, can originate and receive calls.  Call 
origination and termination restrictions are specified via a single COR.  
Misc ellaneous Restrictions can prevent calling any COR, including one’s own 
COR. 
When a COR is administered, the allowance or denial of access from that COR to 
each of the CORs applies only to the COR b eing administered. For example, if 
COR 6 is administered with access denied to COR 3, this only specifies that COR 
3 cannot receive a call from COR 6.  Whether or not COR 3 can be accessed by 
any other COR (for example, COR 7) is determined when that COR (COR 7) is 
administered.  From this, it follows that a single COR cannot be used to provide 
both unrestricted service and miscellaneous restrictions.
COR Examples
The examples given here are d esigned to help in the understanding of CORs 
and to illustrate some of the p ractical aspects of CORs.  These are, however, only 
examples.  In reality, each system must b e administered to meet its individual 
needs.
Example Using Miscellaneous Restrictions
As an illustration of miscellaneous restrictions, assume a system installation 
provides the following:
nCentral office trunks
nWA TS
nFX trunks
nData mo dules
nAttendant service
nVoice terminals
nDID trunks
nRemote Access
In an unrestricted environment, each of the above facilities could have the same 
COR.  However, suppose the following requirements exist:
nAttendants cannot make d ata calls.
nRemote Access can be used for data calls only.
nDID cannot be used for data calls except through Remote Access
(A dedicated Remote Access trunk group is not required, although one or 
more could b e provid e d.  This examp le assumes all Remote Access is
via DID.)
nThere are three classes of voice terminals:
— Those that can call anywhere, any time. 
						

							Feature Descriptions
3-542Issue  3   March 1996 
— Those that can place local central office and in-house calls only.
— Those that can place local central office, FX, and in-house calls 
only.
To implement the a bove requirements, a COR must be assigned to each facility 
or group of facilities.  For simplicity, each can have a unique COR.  The CORs 
are arb itrarily assigned as follows:
nCOR 30 — Local central office trunks
nCOR 31 — WATS trunks
nCOR 32 — FX trunks
nCOR 33 — Data modules
nCOR 34 — Attendant group
nCOR 35 — Unrestricted voice terminals
nCOR 36 — Voice terminals that c an place in-house and local central office 
calls only (no FX or WATS calls)
nCOR 37 — Voice terminals that can place in-house, local central office, 
and FX calls only (no WATS calls)
nCOR 38 — DID trunk group
nCOR 39 — One of the remote access barrier codes (can be up to 10)
With the CORs defined, it should be individually determined which CORs cannot 
call other CORs.  This is d one as follows:
nCOR 30 (local CO trunks) — No restrictions were specified for these 
trunks.  The default values on the screen form  are sufficient.  No action is 
required, except to specify a COR number of 30.
nCOR 31 (WATS) — CORs that cannot use WATS are specified as they are 
encountered.  WATS itself is an outgoing service without any calling 
capabilities.  Thus, Miscellaneous Restrictions are not specified on this 
form.  The Calling Party Restriction should be ‘‘none’’ (although this 
restriction does not really have any meaning for an outgoing facility).  
Similarly, the Called Party Restriction a pplies to facilities capable of 
answering a call.  Since this is not the case with WATS, ‘‘none’’ should be 
specified.  Again, the default values are sufficient, so only the COR 
number needs to be sp ecified.
nCOR 32 (FX) — According to the requirements for this example, no 
restrictions apply. Reasons are the same as for WATS.  Only the COR 
number needs to be sp ecified.
nCOR 33 (data mo dules) — No restrictions a p ply for reasons similar to the 
reasons why no restrictions were assigned for WATS.  Only the COR 
number needs to be sp ecified. 
						

							Class of Restriction (COR)
Issue  3   March 1996
3-543
nCOR 34 (attendant group) — The attendant group cannot call COR 33 
(data modules).  Specify an n beside COR 33 in the “CALLING 
PERMISSION” field.  Specify 34 in the “COR Number” field.
nCOR 35 (unrestricted voice terminals) — Since no restrictions were 
specified, only the COR number needs to be entered.
nCOR 36 (no FX or WATS calls) — This COR cannot call COR 32 (FX) or 
COR 31 (WATS).  Sp e cify an n beside CORs 32 and 31 in the “ CALLING 
PERMISSION” field.  Specify 36 in the “COR Number” field.
nCOR 37 (no WATS calls) — This COR cannot call COR 31 (WATS).  
Specify an n beside COR 31 in the “CALLING PERMISSION” field.  
Specify 37 in the “ COR Number” field.
nCOR 38 (DID) — This COR cannot call COR 33 (data modules).  Specify n 
beside COR 33 in the “CALLING PERMISSION” field.  Enter 38 in the 
“ COR Numb e r”  fie l d.
nCOR 39 (Remote Access barrier code) — This COR can be used for data 
calls only.  Thus, this COR c an call COR 33, b ut not CORs 30 (local central 
office), 31 (WATS), 32 (FX), 34 (attendant group), 35, 36, or 37 (voice 
terminals).  Specify an n beside CORs 30, 31, 32, 34, 35, 36, and 37 in the 
“ CALLING PERMISSION”  field.  Enter 39 in the “ COR Number”  field.  (The 
CORs listed in the “CALLING PERMISSION” field can be viewed as 
terminating or screening CORs that can or cannot be called by the 
originating COR.  Since COR 38 [DID] is neither a terminating nor a 
screening COR, it  does not have to b e considered when assigning the 
barrier code COR.)
Example Using Calling Party Restrictions, Called Party Restrictions, and 
Miscellaneous Restrictions
To illustrate the use of both Calling and Called Party restrictions, and 
Misc ellaneous restrictions, assume a system installation provides the following:
nCentral office trunks (outgoing)
nWA TS
nFX trunks (outgoing)
nVoice terminals
nData mo dules
nTerminating Extension  Groups
nLoudspeaker Paging
Suppose that the following requirements exist:
nOnly the attendant can access loudspeaker paging.
nTerminating Extension  Groups can only accept calls from internal voice 
terminals.
nThere are six classes of voice terminals: 
						

							Feature Descriptions
3-544Issue  3   March 1996 
— Those that are toll restricted
— Those that cannot call outside to a public network (outward 
restricted)
— Those that can receive calls only from an attendant
— Those that can call anywhere, any time
— Those that cannot place FX or WATS calls
— Those that cannot place WATS calls
To implement the a bove requirements, a COR must be assigned to each facility 
or group of facilities.  For simplicity, each can have a unique COR.  The CORs 
are arb itrarily assigned as follows:
nCOR 40 — Local central office trunks
nCOR 41 — WATS trunks
nCOR 42 — FX trunks
nCOR 43 — Attendant group
nCOR 44 — Data modules
nCOR 45 — Terminating Extension  Groups
nCOR 46 — Loudspeaker Paging Access Zones
nCOR 47 — Unrestricted voice terminals
nCOR 48 — Voice terminals that are toll restricted
nCOR 49 — Voice terminals that are outward restricted
nCOR 50 — Voice terminals that can only receive calls from an attendant
nCOR 51 — Voice terminals that cannot place FX or WATS calls
nCOR 52 — Voice terminals that cannot place WATS calls
With the CORs defined, it should be determined individually which CORs cannot 
call other CORs. This is done as follows:
nCOR 40 (local CO trunks) — Restrictions that prohibit access to this COR 
are assigned when the originating CORs are considered.  Only the COR 
number has to be specified on this form.
nCOR 41 (WATS) — This is the same case as described in the previous 
configuration examp le.  Only the COR number needs to be specified.
nCOR 42 (FX) — Again, only the COR number needs to be sp ecified.
nCOR 43 (attendant group) — No restrictions were stated, so only the COR 
number needs to be sp ecified.
nCOR 44 (data mo dules) — No restrictions were stated, so only the COR 
number needs to be sp ecified. 
						

							Class of Restriction (COR)
Issue  3   March 1996
3-545
nCOR 45 (TEG) — This COR can receive internal voice terminal-originated 
calls only.  Since no tie trunks are specified for this examp le, the Inward  
Restriction feature can provide the desired restriction.  Specify ‘‘inward’’ 
as the Called Party Restriction.  If dial repeating tie trunks are provided, 
Misc ellaneous Restrictions could be used to deny trunk access to the 
group. Also, specify 45 as the COR number.
nCOR 46 (Loudspeaker Paging A ccess zones) — Since this COR can be 
accessed by an attendant only, the Manual Terminating Line feature can 
provide the restriction.  Specify ‘‘manual’’ as the Called Party Restriction. 
Specify 46 as the COR number.
nCOR 47 (unrestricted voice terminals) — No restrictions were stated, so 
only the COR numb er needs to be specified.
nCOR 48 (toll restricted voice terminals) — Specify ‘‘tac-toll’’ as the Calling 
Party Restriction.  Specify 48 as the COR number.
nCOR 49 (outward restricted voice terminals) — Sp e cify ‘‘outward’’ as the 
Calling Party Restriction.  Specify 49 as the COR number.
nCOR 50 (voice terminals that can only receive calls from an attendant) — 
Specify ‘‘manual’’ as the Called Party Restriction.  Specify 50 as the COR 
number.
nCOR 51 (voice terminals that cannot place WATS or FX calls) — None of 
the Calling Party Restrictions uniquely prohibit WATS and FX calls, so 
Misc ellaneous Restrictions are use d.  Enter an n b eside COR 41 (WATS) 
and COR 42 (FX) in the “CALLING PERMISSION” field. Leave the “ Calling 
Party Restriction” field as none and specify 51 as the COR number.
nCOR 52 (voice terminals that cannot place WATS calls) — Enter an n 
beside COR 41 (WATS) in the “ CALLING PERMISSION”   field.  Leave the 
“ Calling Party Restriction” field as none and specify 52 as the COR 
number.
Another method to determine COR assignment is to consider the restrictions to 
be assigned.  The requirements given for this example were as follows:
nOnly the attendant can access loudspeaker paging.
nTerminating Extension  Groups can only accept calls from internal voice 
terminals.
nThe six classes of voice terminals are:
— Those that are toll restricted
— Those that cannot call outside to a public network (outward 
restricted)
— Those that can receive calls only from an attendant
— Those that can call anywhere, any time
— Those that cannot place FX or WATS calls
— Those that cannot place WATS calls 
						

							Feature Descriptions
3-546Issue  3   March 1996 
Assignments for these requirements could be made as follows:
nCOR 20 — Manual Terminating Line Restriction
nCOR 21 — Inward  Restriction
nCOR 22 — Toll Restriction
nCOR 23 — Outward Restriction
NOTE:
A new Manual Terminating Line Restriction for voice terminals was 
not established.  COR 20, above, can be assigned.
nCOR 24 — Unrestricted
nCOR 25 — COR for WATS
nCOR 26 — COR for FX
nCOR 27 — Provides Miscellaneous Restrictions for WATS and FX. Enter 
an n beside COR 25 and COR 26 on the form for COR 27.
nCOR 28 — Provides Miscellaneous Restriction for WATS. Enter an n 
beside COR 25 on the form for COR 28.
Now assign the appropriate COR to each physical or screening facility:
nCentral office trunks — COR 24 (unrestricted)
nWATS — COR 25 (WATS C OR)
nFX — COR 26 (FX COR)
nAttendant group — COR 24 (unrestricted)
nVoice terminals — COR 22 (toll), COR 23 (outward), COR 20 (manual), 
COR 24 (unrestricted), COR 27 (WATS and FX miscellaneous), or COR 28 
(WATS misc ellaneous), as required
nData Mo dules — COR 24 (unrestricted)
nTerminating Extension  Group — COR 21 (inward)
nLoudspeaker Paging trunks — COR 20 (manual)
This latter method is probably more difficult to use, b ut it minimizes the number of 
CORs established.  This method required 9 CORs to effect the same restrictions 
as 13 CORs with the previous method.
Considerations
COR provides the means to consolidate assignment and administration of the 
various restriction features available with the system.
All items associated with a COR are distinct and separate.  A unique COR must 
exist for each needed combination of FRLs, CCSA/EPSCS off-network