ATT DEFINITY Communications System Generic 3 Instructions Manual

							Uniform Dial Plan (UDP)
Issue  3   March 1996
3-1185
nUDPCode — Conversion to AAR with given location c o de, further 
conversion suppressed
nAARCode — Conversion to AAR with given location code,  further 
conversion allowed
nENPCode — Conversion to private network number (via “ENP”  form), route 
to given node number routing
nTemp OOS — Temporarily out of service, give reorder
nIntrcpt — Invalid, give intercept treatment
nblank — This extension code does not apply
Whenever a UDP is used to route a call, the number it outputs is in the form of 
RNX plus XXXX. This always needs to be taken into account so that the correct 
d i git deletion and/or insertion can be specified within the routing pattern so that 
the receiving switch gets digits in the format it expects.
To understand the function of a UDP, look at the next figure. In this figure, a 
five-d igit UDP is used in an ETN. Three switches are included in the UDP. Each 
switch has an assigned RNX and a prefix code (discussed later). Each switch 
has also been assigned a list of PBX codes with an RNX assigned to each PBX 
code. Assume that the following PBX codes and associated RNXs have been 
assigned:
UDP allows access, via an extension numb er to extensions on any switch in a 
UDP network. This is accomplished by converting the extension to a 7-digit 
private network number, in UDP this is  XXX-XXX X a n d  i s  routed on the location 
code. In ENP, this is XXX-XXXX and is routed via a location independent 
destination node number.
If the user at extension 41000 wants to call extension 61234, he or she has two 
choices of how to d o this. The user at extension 41000 can either dial ‘‘61234’’ or, 
if AAR is provided, the user can dial the AAR access code followed by 
‘‘222-1234.’’ If 61234 is dialed, the system recognizes 61 as a PBX code, 
determines the associated RNX (222), and uses AAR to route the call to 
222-1234. If the AAR a ccess code and 222-1234 are d ialed, the system finds the 
routing p attern for RNX 222 and routes the call to the PBX associated with that 
RNX.PBX CODE  RNX
41 224
51 223
52  223
60  222
61 222 
						

							Feature Descriptions
3-1186Issue  3   March 1996 
If AAR is active on the network, then subnet trunking can be used to insert the 
AAR feature access code on the originating end, or digit insertion may b e used 
to insert it on the incoming end. On the destination switch, AAR conversion is 
administered to convert 222 with 7 digits to an extension by deleting 3 digits and 
inserting a ‘6’. If AAR is not active, then Subnet Trunking must b e used on the 
source switch to delete the XXX and insert the digit ‘6’ at the b eginning of the 
extension number so that the receiving switch can continue to route correctly.
If the user at extension 51234 on Switch C dials extension 61234, the call must 
first go through Switch A before proceeding to Switch B. When 61234 is dialed, 
the system recognizes 61 as a PBX code, determines the associate d RNX (222), 
and uses AAR to route the call. The call will first be routed to Switch A, where 
Switch A will then recognize the RNX 222 as a remote switch and route the call to 
Switch B and  extension 61234. This same type of call routing occurs when an 
extension at Switch B calls an extension at Switch C.
If extension 61234 on Switch B calls extension 61235, the system recognizes 61 
as a PBX code with an RNX that is local to the switch, and the call is routed 
directly to extension 61235. See Figure 3-30 below.
Figure 3-30. UDP Example
For  G3vsV1/G3sV1 and G3iV1 only, once a certain PBX c o de is assigned to a 
switch, no other switch within the UDP can use that same PBX c o de.
For  G3vsV1/G3sV1 and G3iV1, when a user at a switch that is includ e d in a UDP 
dials an extension, the system checks to see if the first digit(s) of the extension is 
an assigned PBX c o de. If the first d igit(s) is not an assigned PBX c o de, the call is 
routed via the regular, non-UDP, dial plan. If the first d i git(s) is an assigned PBX 
SWITCH A
DIAL PLAN FOR EXTENSIONS
RNX = 224 EXT.
41000
DIAL PLAN FOR EXTENSIONSSWITCH B
RNX = 222
EXT.
60123 61234EXT.
DIAL PLAN FOR EXTENSIONS
EXT. EXT.
SWITCH C
RNX = 22351234
52000
IS: 41XXX  IS: 60XXX AND 61XXX
IS: 51XXX AND 52XXX 
						

							Uniform Dial Plan (UDP)
Issue  3   March 1996
3-1187
code, the system translates the PBX code into the administered RNX. (This is in 
reverse for G3r.) If the PBX code indicates that the called extension is on the 
same switch, the call is routed to the local extension. If the PBX c o de indicates 
that the called extension is at another switch within the UDP, AAR uses the 
associated RNX to route the call to the correct switch within the private network. 
(The necessary subset of AAR is provided with the UDP software.) If the PBX 
code is not assigned a corresponding RNX, the user receives intercept 
treatment. For G3rV1, G3V2, and later releases, when a user at a switch that is 
included in a UDP  dials an extension, the system first checks to see if the 
extension is assigned to a local station on that switch.  If so, the call is routed to 
the station, and UDP is not invoked.  If the extension is not found locally, the 
system checks to see if the extension matches an assigned extension code. If 
the extension matches an assigned extension c o de, the system performs the 
specified conversion into a private network number and routes the call as 
specified. (The necessary subset of AAR is provided with the UDP software.) If 
more than one extension code matches, the ‘‘best’’ match (most explicit digits) is 
used. For examp le, ‘‘1234x’’ will be chosen over ‘‘123xx’’ if ‘‘12345’’ is dialed (but 
‘‘123xx’’ will be chosen if ‘‘12355’’ is dialed). If no matching extension c o de is 
found, the user receives interc ept treatment, or, if enabled, the call will route via 
ETA .
The UDP allows a user to c all other extensions within a p rivate network by d ialing 
a 4- or 5-digit number. However, if AAR is provided, a user can also call other 
extensions by dialing the AAR access c o de, the RNX of the switch to b e called, 
and then the desired extension number. For example, if a user on switch A wants 
to call extension 3797 on switch B, the user can either dial 3797 or dial the AAR 
access code followed by RNX 3797. When the user dials RNX 3797, AAR will 
route the call to the correct switch and extension.
The following a p plies only if AAR is not implemented. If a five-digit UDP is used, 
the routing pattern of each RNX must be administered so that it inserts a prefix 
d i git at the b eginning of the extension. For example, as shown in the earlier 
figure, if a user on switch A wants to call extension 61234 on switch B, the user 
could dial 222-3797. Then, the routing pattern assigned to the dialed RNX would 
insert the prefix 6 at the beginning of the extension and route the call to the 
desired extension.
Considerations
The UDP feature enables a terminal user at any switch to call any other terminal 
on any switch in the UDP complex, using only the 4- or 5-digit extension number.
Since extensions beginning with 0 may be routed by some switches to the 
attendant in a network environment, administrators are discouraged from using 
this numb er as the leading digit when assigning extensions.
When calling an extension on another switch, there is a slight delay before call 
progress tones are applied. This delay is due to the trunk signaling necessary to 
complete the call to the remote switch. 
						

							Feature Descriptions
3-1188Issue  3   March 1996 
For G3i only, it is possible that the first one, two, three, or four digits (PBX code) 
of the 4- or 5-digit extension numb er could be the same as a local extension 
number. In this case, the UDP PBX code overrides the extension number at the 
local switch. Problems can be avoided by assuring that the PBX code does not 
match an extension number.
The list of PBX codes for a switch can contain PBX codes of varying lengths. For 
example, a switch may be assigned both 2-digit and 3-digit PBX codes. It is also 
possible that one PBX c o de may be included in another. For example, a switch 
may be assigned both 61 and 612 as PBX c odes. In this case, all calls beginning 
with 61, except those beginning with 612, are route d according to the RNX 
assigned to PBX code 61. Calls beginning with 612 are routed according to the 
RNX for PBX c o de 612. (The system always looks at the first four digits before 
routing the call.)
For G3r, if AAR is active in the system, tandem tie trunks may be used to send a 
traveling class mark, or FRL, along with the private network number. UDPCode 
and AARCode conversions use the FRL assigned to the caller. ENPNode 
conversion always raise the FRL to the maximum (7).   When a user attempts to 
make a call where the originating user’s FRL is insufficient to access the facilities, 
the user is denied access and is not prompted for an authorization code even if 
authorization codes are enabled and administered.  Instead, denial is 
automatically administered to the originating user (typically an intercept tone).  If 
AAR is not enabled in the system, tandem tie trunks should never be used to 
transport UDP numb ers (the TCM will not be recognized as such following the 
extension received at the receiving switch).
Interactions
The following features interact with the UDP feature.
nAAR 
After the system determines the RNX of the switch being called, AAR 
routes the call to the correct switch. The required subset of AAR is 
provided with the UDP software. If the AAR feature is provid e d in addition 
to the UDP, then the seven-digit AAR number will provide the exa ct same 
routing as the UDP.
nDID 
DID calls to five-digit UDP extension numbers require that the DID trunk 
group insert enough digits to make a five-digit extension number.
nDial Plan
All of the extension numb ers on a switch are not necessarily part of the 
UDP. Any that do not belong to the UDP are handled by a regular, 
non-UDP dial p lan associated with the local switch. In G3i only, when 
administering the dial plan and designating a g roup of extensions as UDP 
non-local, you can specify on the “ Dialplan” form whether you want to 
search for local extensions first or last. This allows some flexibility in the  
						

							Uniform Dial Plan (UDP)
Issue  3   March 1996
3-1189
changing of extensions from local to non-local. However, after the dial 
plan is changed to make an extension UDP, nothing can be administered 
with these extensions on the local switch.
nDCS 
UDP is required when DCS is provided. The necessary UDP software is 
provided with the DCS software.
nENP
For G3rV1, G3V2, and later releases, if an extension code is administered 
to use ENP node routing, ENP routes the call to the correct switch. If the 
AAR feature is provided in addition to UDP, then the seven-digit AAR 
number provides the exact same routing a s the UDP (that is, via ENP).
Administration
The UDP is administered by the System Manager. The following items require 
administration:
nWhether UDP has 4- or 5-d igit extension numbers PBX Codes (expands 
first one, two, three, or four d igits of dialed extension to an RNX)  
(G3vsV1/G3sV1, and G3iV1)
nAAR Analysis Table (used by AAR to route calls to the correct switch)
nRouting Patterns
nNode Number Routing (used to route ENP calls) (G3r)
nExtension Codes and type(s) of conversion (G3r, G3V2, and later 
releases)
nAAR Digit Conversion (to define conversions for AAR Code extensions or 
to define home location codes) (G3rV1, G3V2, and later releases)
NOTE:
If the user changes the “Uniform Dialing Plan”  field  value from a ‘‘y’’ to a 
‘‘n,’’ then a warning message is generated to inform them that this action 
causes all UDP extension c o des to be lost. The same warning message is 
a p plied if the “ Plan Length”  field value is changed from a ‘‘4’’ to a ‘‘5’’ or 
from a ‘‘5’’ to a ‘‘4.’’
Hardware and Software Requirements
A Processor Interface circuit p a ck is required for DCS applications. DCS or UDP 
software is required. 
						

							Feature Descriptions
3-1190Issue  3   March 1996 
VDN of Origin Announcement (VOA)
Feature Availability
This feature is available with Generic 3 Version 3 and later releases. The  Call 
Vectoring and VDN of Origin Announcements features must b e optioned.
Feature History
The VDN of Origin Announcements feature was first available in the System 85 
R2V4/Generic 2 releases. In these releases, the feature was known as 
‘‘City-of-Origin’’ and ‘‘Queue-of-Origin’’ announcements.
Description
VDN of Origin Announcements provide a short voice message when an agent 
answers a VDN call. The message informs the agent of the city of origin of the 
caller or of the service requested by the caller, b ased on the VDN used to 
process the call. The message begins as soon as the agent answers the call. 
While the agent can hear both the message and the caller, the caller is not able 
to hear the message. 
If the a gent’s terminal is connected to a DEFINITY G3V3, the caller can hear the 
agent if the agent speaks during the message. If the agent’s voice terminal is in 
Auto Answer mode, when the call reaches the voice terminal, the system applies 
a zip tone to the call. The p layback of the announcement begins when the zip 
tone ends. The agent does not need to wait for the message to complete before 
speaking to the caller.
If the a gent’s voice terminal is connected to a DEFINITY G3V4 (and later 
releases), the caller cannot hear the agent if the agent speaks during the 
message since the agent is not connected to the caller until after the message is 
finished. If the agent’s voice terminal is configured in Auto Answer mode, the 
agent hears a zip tone b efore the message. The playback of the message begins 
when the zip tone ends.
With G3V4 a n d later releases it is p ossible to administer the system so that the 
agent also hears zip tone after the VOA completes. In this way, the agent knows 
that the announcement is completed and a caller is now connected. The  agent 
must wait until after the second zip tone before speaking to the caller.
For G3V4 and  later releases, if the agent is log ged in at a multi-line terminal, the 
call-appearance button for an incoming call c ontinues to flash until after the VDN 
of Origin message is completed. The agent can shorten the VOA message 
playb ack for the incoming call by pressing the flashing call-appearance button 
while the message is being heard. Also, if the a gent is logged in at a terminal with  
						

							VDN of Origin Announcement (VOA)
Issue  3   March 1996
3-1191
an alphanumeric  display, no incoming call information is displayed until after the 
VOA message is completed.
After listening to the announcement, the agent can appropriately respond to the 
caller. For exam ple, if a user has two 800 numb ers, one for placing orders and 
one for technical support, they can administer two VDNs to route the calls to the 
same agents. When a call enters the system and is sent to a VDN, the VDN can 
have a VDN of Origin announcement assigned to it.  The VDN directs the call to a 
vector, and as a result of vector processing, the call can wait in one or more 
queues until an agent is available. When an agent answers a call, they hear the 
appropriate recording for the VDN (for example, ‘‘new  order’’ or ‘‘tech help’’). 
The agent then greets the caller.
If a non-ACD agent is in Automatic Answer mo de, when a  call reaches the voice 
terminal, the system applies a call ID tone. The message b egins when the call ID 
tone ends. If the  agent is in Manual Answer mode, when a call reaches the  
voice terminal, the system applies a ringing signal. The message  begins when 
the agent answers the call. Note that in each case,  the message begins at the 
same time the agent is connected to the call.
If an agent needs to hear a message again, and if the a gent’s voice terminal is 
administered with a VOA Repeat feature button, the agent can press the VOA 
Repeat button. The VOA Repeat button lamp  stays lit while the announcement 
plays. The VOA Repeat button lamp  also remains lit if the system needs to q ueue 
the request for the announcement. The lamp  lights with a broken flutter if the 
agent presses the VOA Repeat b utton but the resources to p lay the 
announcement are not available within two to three seconds. For G3V3, if the 
agent presses the VOA Repeat b utton when the lamp is lit, the lamp flutters to 
indicate that the subsequent request has been ignored. For G3V4, if the a gent 
presses the VOA Repeat b utton when the lamp is lit, the playback of the 
announcement is immediately stopped. If there is no VOA assigned, the VOA 
Repeat button lamp flutters immediately when the call is answered or when a 
user presses the button.
Announcements are assigned on a per-VDN basis. However, the VDN of Origin 
announcement applies to a class of restriction (COR). This means you must 
administer a COR for all agents who will be expecting or are expected to receive 
the VDN of Origin announcements. Note that in G3V3 and later releases, the 
COR feature is u pgraded to enable or d isable an agent’s ability to receive VDN of 
Origin announcements.
You can set up VDN of Origin announcements in four different ways. You can use 
any or all of these arrangements, which are: 
						

							Feature Descriptions
3-1192Issue  3   March 1996 
nThe agent can hear a unique announcement based on the d ialed number 
identification service (DNIS) received from the service end office or c arrier 
switch. Each DNIS is assigned as the VDN of a vector. The announcement 
associated with the VDN  announces the services asso ciated with the 
DNIS.
NOTE:
The specific announcement associated with the current VDN only 
plays if the “VDN Override” field of the previous VDN is marked ‘‘y’’ 
(yes). If the “ VDN Override” field associated with the p revious VDN is 
set to ‘‘n’’ (no), the announcement of the previous VDN does not 
play.
nVector ste ps can route (using a route-to ste p) the call to a VDN. Or, a 
response to an integrated prompting or converse-on step can route the 
call to a VDN. The announcement associated with the VDN announces the 
service the caller requested or can announce a condition that caused the 
call to route-to the VDN.
nAn incoming call routes to a voice response system, possibly through a 
vector. Voice prompting directs the caller to enter a touchtone response, 
and the call is then route d to a specific VDN based on the caller’s 
response. The announcement associated with the VDN indicates the 
service selected by the caller.
nIf the agent requires a call’s city of origin, the trunk group is assigned to a 
particular VDN. The announcement associated with the VDN  provides the 
location of the origin of the trunk group. Subsequent VDNs can be used to 
handle the call, or multiple VDNs can be assigned to a single vector.
NOTE:
VDN Override applies to VOA in the same way that VDN Override a pplies to 
disp lay information. If a VDN with a VOA has VDN Override enabled, the 
system overrides the original VOA with VOAs in subsequent VDNs to which 
the call may b e route d.
Considerations
Because of the nature of the VDN of Origin announcements (the customer can b e 
waiting while the message plays), the messages should be kept very brief, no 
more  than 1.5 seconds in length. 
Because the announcements should be very brief, agents receiving the 
messages should be using a speakerphone or headset. This way, they d o not 
miss the message while they are picking up the handset. If the agents cannot 
use a speakerphone  or headset, you can administer the voice terminals with a 
VOA Repeat button that allows them to repeat the message.
The agent who receives the announcement and takes the call must be on the 
same switch as the VDN of Origin Announcement. 
						

							VDN of Origin Announcement (VOA)
Issue  3   March 1996
3-1193
The system maintains a separate logical queue for the VDN of Origin 
Announcements when you use the TN750 circuit board  for  integrated 
announcements. If, because of traffic considerations or inoperative equipment, 
the VDN of Origin Announcement cannot be given to the agent within 0 to 1 
second, the system stops an attemp t to p rovide the announcement.
NOTE:
VOA announcements receive higher priority than other announcements on 
the TN750. A burst  of VDN of Origin Announcements can cause other 
announcements (such as Forced First Announcements) to be delayed. 
Therefore, it is recommended that non-VDN of Origin Announcements be 
recorded as auxiliary or analog.
Auxiliary announcements are connected for a  duration of 1 to 2 seconds on a 
barge-in basis, immediately after the agent  answers (or is assigned the call for 
auto-answer) and the incoming call is extended to the agent. Integrated and 
non-barge-in auxiliary announcements are connected for the duration of the 
announcement. This switch does not ensure that the integrated announcement is  
shorter than the allowed playback time.
The VOA feature supports Auxiliary Trunk (aux-trunk) announcement typ es. You 
can use aux-trunk with barge-in, queue, or without queue. For aux-trunk with or 
without queue, when a VDN  call needs the VDN of Origin announcement and the 
trunk is  idle, the call seizes the trunk to start the announcement and the system 
plays the entire announcement (not just 1 to 2 seconds). However, if the 
announcement is busy and if aux-trunk has b arge-in, the c all does not q ueue but 
bridges on to the  announcement for the 1 to 2 seconds needed. When the 
announcement reaches its end, it causes the trunk to be released along with the 
listeners; the next call needing the announcement starts the process over again. 
For this reason, your aux-trunk  announcements should consist of one short 
announcement repeating over and over for the length of the full announcement 
time. For example, you might want to record ‘‘New Order’’ over and over as many 
times as possible, so that when a call bridges to the announcement, the agent 
hears ‘‘New Order’’ no matter where the agent bridges into the announcement.
Also, if you use aux-trunk or integrated announcement without queue, and a port 
is b usy when a VDN calls comes in, the system cannot play an announcement.  If 
you use aux-trunk or integrated announcement with queue, the system plays the 
current  announcement for an agent and then connects the next a gent in the 
queue. 
Interactions
nASAI Adjunct Routing
If a vector step calls for Adjunct Routing, the VDN of Origin announcement 
is played for the agent to which the call is routed. 
						

							Feature Descriptions
3-1194Issue  3   March 1996 
nAgent Call Handling
Answering Options
— Automatic Answer
An ACD agent set u p for Automatic Answer receives zip tone 
instead of ringing. The VDN of Origin Announcement begins 
immediately after the zip tone ends. A non-ACD agent set u p for 
Automatic Answer hears an incoming call ID tone when a call 
comes in. Through the use of a route-to vector step, non-ACD 
agents can receive a VDN of Origin Announcement. The 
announcement begins when the incoming  call ID tone ends. For 
G3V4 and later releases, the agent also hears a second zip tone 
after the announcement indicating connection of caller to agent.
— Manual Answer
If an agent is set up for Manual Answer and is not using a headset 
or speakerphone, that a gent can miss the message while p icking 
up the call. Therefore, it is a good idea to p rovide a headset or 
speakerphone to a gents on Manual Answer.
nAttendant Console
An attendant’s voice terminal, as all other voice terminals, may have only 
one VOA Repeat button. An attendant can use the VOA Re peat to replay 
the message for the active call.
nAuto-Available Splits  (AAS)
AAS provides a way for memb ers of an ACD split to be in a continuous 
Auto-In work mo de. Ag ent positions with this feature are automatically put 
in the Auto-In mode after a system restart. This feature is intended to be 
used for splits containing only nonhuman adjuncts (such as AUDIX or 
Conversant), however, VDN of Origin  announcements can be directed to 
Auto-Available splits.
nCall Forwarding
VDN of Origin announcements apply to forwarded calls, including those 
forward ed to a hunt group. The answering station must be on the same 
switch. If a VDN of Origin announcement is forwarded to another 
extension, the message is p layed only if the destination extension is 
administered with a COR that allows VDN of Origin announcements.
nCall Hold
An agent cannot use the VOA Repeat button if the agent’s calls are all on 
hold. The VOA Repeat b utton only a p plies to active calls.
nCall Pickup
Call Pickup allows an agent to pick up a ringing call on another extension. 
If the p ick-up phone has COR p ermissions for VOA, the p erson picking up 
the call receives the VOA.