ATT DEFINITY Communications System Generic 3 Instructions Manual

							Hold - Automatic
Issue  3   March 1996
3-767
Automatic Hold call is treated the same as an attendant call placed in Hold by 
the depression of the HOLD button.
The Automatic Hold feature operates in conjunction with the START key or 
Automatic Start feature of an attendant console. The START key/Automatic Start 
operation has p recedence over the Automatic Hold feature. Any feature that uses 
the Start  key/Automatic Start o peration places the call on the active loop on 
Soft-Hold.
Interactions
As mentioned earlier, the Automatic Hold feature is identical to the action 
generated when an MFDT places a call on hold using the HOLD button and then 
selecting the (another) inactive call a p pearance. The features, therefore, work 
identically, except for the saving of a button push. The Automatic Hold feature is 
implemented as an equivalent to pressing the HOLD button. A call placed in 
Automatic Hold is in Hard-Hold, as with the d epression of the HOLD button.
Therefore, Automatic Hold, when invoked by the methods already mentioned, 
operates identically to the HOLD feature and its interactions. See the Hold  
feature for additional information.
Automatic Hold interacts with DCS and Centralized Attendant Service (CAS). It 
operates transparently with DCS and CAS. Note that the Auto-Hold feature is 
administered separately for each node in a DCS network.
Administration
Automatic Hold is administrable on a system-wide basis only by persons whose 
administration ID provides access to system parameters. Administration of the 
auto hold feature takes place on the System-Parameters Feature Form.
Hardware/Software Requirements
No sp ecial hardware is required. 
						

							Feature Descriptions
3-768Issue  3   March 1996 
Hot Line Service
Feature Availability
Hot Line Service is available with all Generic 3 releases.
Description
Allows single-line voice terminal users, by simply lifting the handset, to 
automatically place a call to a preassigned extension number, public or private 
network telephone number, or feature access code.
The Hot Line Service d estination numb er is stored in an Ab breviated Dialing List.  
When the Hot Line Service user lifts the handset, the system automatically routes 
the call to the stored number and the call comp letes as though it had been 
manually  dialed.  If the appropriate feature access code is prefixed to the stored 
number,  AAR, ARS, Data Privacy, or Priority Calling can be used on the call. 
Also, if the Public or Private Network Access code is the stored number, the 
voice terminal user  is connected to an outg oing trunk and can dial the outside 
number.
A Hot Line Service voice terminal receives calls allowed by its COR.  Call 
reception is not affected by Hot Line Service.  Likewise, the Hot Line Service 
destination is not affected by Hot Line Service.
A DDC, a  UCD, a TEG extension number, or any individual extension number 
within any of the groups can be a Hot Line Service destination.  Also, any 
extension number within a DDC group, UDC group, or TEG can have the Hot 
Line Service feature assigned.
Considerations
The Hot Line Service feature is useful in any a pplication where very fast service is 
required.  Also, if a voice terminal is used only for accessing a certain facility, it 
can be assigned to Hot Line Service. The Hot Line Service voice terminal user 
simply lifts the handset and is connected to that facility.
The number of voice terminals that can be assigned Hot Line Service is not 
limited, and the number of voice terminals that can be assigned the same 
destination is not limited.  The limit, if any, would be on the numb er of entries that 
can be stored in the Ab breviated Dialing lists. 
						

							Hot Line Service
Issue  3   March 1996
3-769
Interactions
A Hot Line Service user cannot activate any feature unless the a c cess code is, or 
is part of, the destination number.
nBrid ged Call Ap pearance  — Single-Line Voice Terminal 
If a single-line voice terminal is administered for Hot Line Service, brid ged 
appearances of that voice terminal’s extension also places a hot line call 
automatically when a user g oes off-hook on that bridged appearance.
nLoudspeaker Paging Access
Loudspeaker Paging Ac c ess can be used with Hot Line Service to provide 
automatic access to paging equipment.
nRingback Queuin g
If a Hot Line Service call accesses a trunk group with Ringback Queuing 
assigned, the call can queue unless the voice terminal is termination 
restricted by its COR. Queuing, when a p plicable, is automatic on 
single-line voice terminals; dialing is not required.
Administration
Hot Line Service is administered on a per-voice terminal basis by the System 
Manager.  The following items require administration:
nAbbreviated Dialing Lists
nHot Line Destination Number
Hardware and Software Requirements
No a d ditional hardware or software is required. 
						

							Feature Descriptions
3-770Issue  3   March 1996 
Hunting
Feature Availability
Hunting is available with all Generic 3 releases.
Description
Checks for the active or idle status of extension numbers in one or more ordered 
groups.  If all members of a group are active, the call can route to another group 
through Call Coverage or can wait in a q ueue for an available group member, if a 
queue is provided.
Hunting is accomplished through the ACD, Call Coverage, DDC, and UCD 
features.  The order of hunting is defined under each individual feature.
Considerations
Hunting is useful whenever a group of voice terminal users receives a high 
volume of calls.  It minimizes call completion time and attendant assistance is not 
required.
Agents should not be used for hunt group calls when they are used for ACD sp lit 
calls. This is because all ACD calls are answered before hunt group calls. That 
is, no hunt group calls are answered until all ACD calls are answered.
The oldest c all waiting termination is only supported for agents who are servicing 
ACD calls only.
Interactions
Individual attendant extensions can b e in hunt g roups. However, attendant return 
call features do not work for these types of calls.
Administration
Hunting is administered through the Automatic Call Distribution (ACD), Call 
Coverage, Direct Department Calling (DDC) and Uniform Call Distribution 
(UCD) features.  Administration of each of these features is discussed under that 
feature elsewhere in this chapter. 
						

							Hunting
Issue  3   March 1996
3-771
Hardware and Software Requirements
No a d ditional hardware or software is required for Call Coverage, DDC, and 
UCD. ACD requires ACD software. Call Vectoring is also required for 
vector-controlled splits. 
						

							Feature Descriptions
3-772Issue  3   March 1996 
3
Inbound Call Management (ICM)
Feature Availability
Applications running an Inbound Call Management (ICM) application can be 
connected to any DEFINITY  swi t c h  t hat  c a n  b e  provisioned with the necessary 
CallVisor ASAI interface. The G3vs and G3s ABP models cannot be equipped 
with a CallVisor ASAI interface.
Planners must consider the ICM traffic, rated switch c a pacity, CallVisor ASAI 
interface traffic, and rated capacity of the adjunct application processor when 
planning an ICM installation. AT&T’s Technical Design Center can provide 
consulting services to assist in such planning.
Description
ICM improves the handling of inbound calls in such applications as 
telemarketing, claims processing, etc. An application on a host processor is 
integrated with switch features such as Automatic Call Distribution (ACD), Call 
Vectoring, and Call Promp ting to provide enhanced features and improve 
efficiency. The host process may be a CallVisor/PC, CONVERSANT voice 
system, Telephony Services Server (running Novell NetWare(R)) serving a local 
area network, or a processor from one of AT&T’s CallVisor ASAI vendor partners. 
The CallVisor ASAI Planning Guide provides information on the various vendor 
partners.
The CallVisor ASAI link is a two-way interface that lets a p plications receive 
information about calling parties, promp ted digits, called number, etc. The 
applications can request that the switch route calls, transfer calls, etc. A variety 
of q ueries and notification c a pabilities are also available.
The following are some typical ICM applications:
nThe DEFI NI TY s yst em  passes calling party information (ISDN CPN/BN) 
and the call outcomes to a host a p plication for screen pop, and possible 
(later) supervisory transfers (with screen duplication).
nThe DEFI NI TY s yst em  provides the host application with caller and 
prompter information a bout all incoming calls to a selected number. The 
host application consults a d atabase and then tells the switch where to 
route the calls (preferred agent, 
best customer treatment, accounts 
receivable, etc).
nThe DEFI NI TY s yst em  uses the Call Promp ting feature to obtain a 
customer account number and then passes this information to the host for 
call routing or screen pop. 
						

							Inbound Call Management (ICM)
Issue  3   March 1996
3-773
nThe DEFI NI TY s yst em  c a n send CPN/BN and DNIS to a voice response 
unit (VRU), connect the caller to the voice response unit, and let the VRU 
interact with the user to d etermine handling for the call. Such a system can 
verify callers’ identity and provide access to database information (claims 
status, account balance, etc).
nA host ap p lication can transfer a call to an ACD and have the call treate d 
(and tracked on CMS) as an ACD call. This is known as ‘‘Direct Agent 
Calling.’’
nA host ap p lication can attach application-specific information to an ICM 
call using “User-to-User Information” fields. If the host then transfers the 
call to another DEFI NI TY swi t c h  over primary rate interface (PRI) facilities, 
a CallVisor ASAI application at the receiving switch receives the 
application-sp ecific information. Therefore, if an ICM a p plication at one 
switch has determined a caller’s account number, claim number, etc., the 
information could be passed to a sp ecial list (for example) on another 
switch where the a p plication may have to transfer the call.
The CallVisor ASAI Technical Reference describes additional a p plication 
scenarios in greater detail.
Data Screen Delivery
Passing incoming call information (CPN/BN, DNIS, Lookahead Interflow 
information, digits collected from Call Prompting, agent selected) to a 
CONVERSANT voice system can be used to deliver the appropriate data screen 
when the voice call is delivered to an agent. Data screens can also be 
transferred or duplicated by the CONVE RSA NT voice system for transferred or 
conferenced calls. A sim plified configuration of this type of ap plication is shown 
in  Figure 3-17. CONVERSANT VIS is referenced for illustrative purposes only, 
indicating both switch and  CONVERSANT c ap a bilities; other adjunct processors 
have similar capabilities but should be verified for  a p articular ap p lication.
In this ap p lication, the CONVERSANT voice system or host requests notification 
for events (call offered, call ended,  call connected, call dropped, call transfer, 
alerting, and so on). The switch notifies the CONVERSANT voice system using 
event reports when the call arrives, when the agent answers, when the call 
drops, and so on. The CONVERSANT then passes the appropriate information to 
the host so it can send that data sc reen to the agent’s data terminal. Knowing a 
call drops prior to being answered, the CONVERSANT voice system can track 
abandoned calls or use CPN/BN information for call b a cks. 
						

							Feature Descriptions
3-774Issue  3   March 1996 
Figure 3-17. Simplified ICM Configuration for Data Screen 
Delivery
The ASAI interface could also b e shown above d irect to the host. CONVERSANT. 
does not have to be in the middle if the host supports ASAI.
Integration With Speech Processing Adjuncts
ICM can be used to provide integration with Voice Response Units (VRUs).  The 
advantages of using ICM with the CallVisor ASAI in ad dition to tip/ring interfaces 
are as follows:
nData screen integration is provid e d on transferred calls.
nNotification of answer is provided on internal calls (CallVisor ASAI 
capabilities let you know what happens with the call).
nDelivery of ISDN network information such as CPN/BN/DNIS is provid e d 
(instead of having to promp t for this information).
A simplified configuration of this application is shown in  Figure 3-18. In this 
application, the CallVisor ASAI link is used by the switch to pass incoming call  
information to the CONVER SA N T  voice system. The call is distributed b y the 
switch ACD to an available voice line. After collecting digits via a DTMF keypad, 
the CONVERSANT voice system transfers the call back to an ACD split or 
specific agent on the switch via CallVisor ASAI messages.  If the call is 
transferred to a split agent, the CallVisor ASAI link is used by the switch to p ass 
an event report containing which agent in the sp lit receives the call.  The 
CONVERSANT voice system forwards the agent identification to the host for 
delivery of the associated data screen to the agent selected to handle the call.
Digits collected by the CONVERSANT voice system are not passed to the switch 
to display on the agent’s voice terminals but can be disp layed on the agent’s 
SWITCHASAI
AGENT
VOICE
TERMINALAGENT
DATA
TERMINALHOSTCONVERSANT INCOMING
CALLS
(ISDN-PRI) 
						

							Inbound Call Management (ICM)
Issue  3   March 1996
3-775
data terminals.   If the digits collected by the CONVERSANT voice system are  
the extension to which the call is to be routed, these routing digits are passed to 
the switch as the destination in the CallVisor ASAI third party make call request. 
The third party make call request is used by the CONVERSANT  voice system to 
set up various types of calls.
Figure 3-18. Simplified ICM Configuration for Speech Processor 
Integration
Host/Adjunct Call Routing
Incoming call information can be used by the host or CONVERSANT voice 
system adjunct to route the call to a split, vector, or particular agent (basically 
any valid extension number).  The call could even be routed off of the switch if 
desired.  The CONVERSANT voice system can also use the incoming call 
information to tell the switch that the call should b e treated as a priority call.  
Routing can be based on the area c o de dialed from, the country code, digits 
collected from the Call Prompting feature, dialed number or service, agent 
availability, or information in a customer database.
To implement adjunct (CONVERSANT voice system) call routing, calls must 
come into a vector which contains an adjunct routing vector command. 
When the adjunct routing vector command is encountered, the switch 
initiates the route CallVisor ASAI c a pability.  Vector processing proceeds with the 
next step (which could  provide ringing, announcements, music, and so on) while 
the c aller waits.  A d efault s plit or answering  position c an also be specified in the 
vector, in case the CONVERSANT voice system does not respond in the 
administered amount of time (determined by the announcement/wait steps). 
Announcement and wait steps are needed to give the host time to respond.
INCOMING
CALLS
(ISDN-PRI)SWITCHASAI
TIP/RING LINES
AGENT
VOICE
TERMINALAGENT
DATA
TERMINALHOSTSPEECH
PROCESSOR 
						

							Feature Descriptions
3-776Issue  3   March 1996 
Direct Agent Calling
DAC is a new function that allows an adjunct to initiate or transfer a call to a 
particular ACD agent and have the call treated as an ACD call.
Calls that originally enter the switch as ACD c alls and are rerouted to a p articular 
agent via adjunct routing, or transferred from a tip/ring agent to a live agent via a 
‘‘third party make call’’ request, are treated as ACD calls for the duration of the 
call.  This is important for a number of reasons:
— The call may queue for the agent.
— Agents need to receive zip tone when these calls are delivered.
— Agents may have After Call Work associated with these calls.
The CMS and BCMS correctly measure these calls as ACD calls.
Direct Agent Calls have the highest priority of any calls.
Adjunct Activation of Direct Agent Calling
CallVisor ASAI third party make calls and route select calls with the direct agent 
call option are treated as direct agent calls.  The receiving agent’s extension 
a p pears as the destination and the split extension in the direct agent call option.
Delivery of DAC
If the a gent receiving the direct agent call is available to answer an ACD call in 
the associated split, the direct agent call is delivered to the agent. Zip tone (480 
Hz for a 1/2 second, not repeated) is applied if the agent is automatic answer.
If the receiving agent is not available to answer an ACD call (for example, the 
agent is busy on a call, in the After Call Work mode, or in the Auxiliary Work 
Mode), the receiving agent is notified with a ring-ping if the a gent has a 
multi-function voice terminal or is on-hook. If the receiving agent has a single-line 
voice terminal and is not available, the receiving agent will hear call waiting tone 
(even when the Call Waiting feature is not assigned) if the agent is off-hook. The 
ring-ping or call waiting tone is given only once per call when the call is queued. 
The active work mode button lamps for the associated split on the receiving 
agent’s voice terminal will do a fast flutter, indicating a direct agent c all is waiting. 
This starts when the first call queues and stops when all direct agent calls leave 
the queue (answered, abandoned, or sent to coverage).
The originating agent hears normal call progress tones and ringback. If the 
originating agent drops from the call, the caller hears call progress tones and 
ringback. A forced first announcements will not b e heard b y the originating a gent 
or caller.
Direct agent  calls are queued and served in a first-in first-out order, before any 
non-DAC.  Therefore, when an agent becomes available, the switch first checks 
for any direct agent calls before serving normal ACD calls in queue.