ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							ANI and II-Digits Routing
7-2Issue  4 September 1995 
ANI (Automatic Number Identification) is b ased on the Calling Party Number 
(CPN). It is not always i dentical to the Billing Number. For example, if the call is 
placed by a user from a Private Branch Exchange (PBX), the CPN can be either 
the PBX billing number or the Station Identification Numb er. 
The ANI routing digit string can contain up to 16 d i gits. This sup ports 
international applications. However, ANI information in North America only 
contains 10 d i gits.
The following calls will have ANI values associated with them:
nI n coming ISDN-PRI c alls that send ANI
nDCS calls
nInternal calls
If ANI is not provided by the network for a call, then it will not be available for 
vector processing on that call.
When an EAS a gent makes a call to a VDN, the agent’s login ID is used as the 
ANI, not the num ber of the p hysical terminal.
When a call is transferred to a VDN the following is true:
nIf the transfer is completed b efore the call reaches the ANI conditional, the 
ANI value of the originator of the call is used.
nIf the transfer is com pleted after the call reaches the ANI conditional, the 
ANI value of the terminal executing the transfer is used.
To ensure that the originator’s ANI is preserved during a transfer, add a filler ste p 
(such as wait with silence) to the beginning of the vector. In this way a transfer 
can complete before the ANI conditional is encountered.
The ANI value specified for a goto ste p can include the “ + ” and/or “?” wildcard. 
The “ + ” represents a group of zero or more d igits and can only be used as the 
first or last  character of the string. The “?”  represents a single digit. Any number 
of them can be used at any position in the di git string.
ANI Routing Example
The following example demonstrates several a p plications of ANI Routing. 
						

							ANI Routin g
Issue  4 September 1995
7-3
Figure 7-1. ANI Routing Example
In Step 2 calls that do not have ANI associated with them are routed to an 
operator. Step 3 routes calls from a specific phone to a specified extension. Step 
4 routes local c alls (those with 7 or fewer digits) to a d ifferent vector. Steps 5 and 
6 route calls from area codes 212 and 202 to a different vector. Calls that are not 
rerouted by the previous steps are then q ueued.
Vector Routing Tables with ANI
You c a n also test ANI against entries in a Vector Routing Table.
Vector Routing Tables contain a list of numbers that c an be used to test a 
g oto...if 
ani 
command. ANI  can be tested to see if it is either in or not-in the specified 
table. Entries  in  the  tables can also include the “+” and/or “?” wildcard.
The following figure gives an example of a Vector Routing Table with ANI values. 
The table contains most of the area codes for the state of California.
       1. wait-time 4 secs hearing silence
       2. goto step 13 if ani = none
3. goto step 12 if ani = 3035367326
4. goto vector 74920 if ani 
						

							ANI and II-Digits Routing
7-4Issue  4 September 1995 
Figure 7-2. Vector Routing Table for ANI Routing
The following vector could be used to route these California area code calls to a 
separate vector.
Figure 7-3. Testing for ANI In Vector Routing Table
In this exam ple, if no ANI is available for the call, it is routed to an operator. If the 
first three numbers match an area c o de from table 6, the call is route d to vector 
8. All other calls are queued.
 
VECTOR ROUTING TABLE
Number: 6  Name: California Sort? n
1: 714+ 17: _______
2: 805+ 18: _______
3: 619+ 19: _______
4: 707+ 20: _______
5: 209+ 21: _______
6: 310+ 22: _______
7: 213+ 23: _______
8: 408+ 24: _______
9: 510+ 25: _______
10: 818+ 26: _______
11: 909+ 27: _______
12: 916+ 28: _______
13: 415+ 29: _______
14: _______ 30: _______
15: _______ 31: _______
16: _______ 32: _______
  1. announcement 45673
       2. goto step 9 if ani = none
3. goto vector 8 if ani in table 6
4. queue-to main split 5 pri l
5. wait-time 10 seconds hearing ringback
6. announcement 2771
7. wait-time 10 seconds hearing music
8. goto step 6 if unconditionally
9. route-to number 0 with cov y if unconditionally 
						

							II-Digits Routin g
Issue  4 September 1995
7-5
II-Digits Routing
II-digits routing allows you to make routing decision based on the typ e of the 
originating line. In this way, calls from pay phones, cellular phones, or motel 
phones for example can receive unique routing. See  II-Digits Routing Example 
later in this section for more information.
II-digits (Information Indicator d i gits) is a 2-d igit string provided for an incoming 
call by ISDN PRI. II-digits delivery is a generally available ISDN PRI AT&T 
Network service. This service is bundled with ANI delivery and tariffed under the 
MEGACOM 800 ®  and MultiQuest 800 ®  INFO-2 feature to provide information 
about the call’s origination. II-digits indicate the type of originating line. 
II-digits routing can be used for example to:
nHelp detect fraudulent orders for catalog sales, travel reservations, money 
transfers, traveler’s checks, and so on.
nAssign priority or special treatment to calls placed from pay phones, 
cellular phones, or other types of lines. For exam ple, s pecial priority could 
be given by an automobile emerg ency road service to calls placed from 
pay phones.
nDetect calls placed from p ay phones when it is the intention of the caller to 
avoid being tracked by collection agencies or dispatching services.
nConvey the typ e of originating line on the a gent display b y routing d ifferent 
type calls to different VDNs. 
The ii-digits routing string can only contain 2 characters. The  string  can  contain 
either the “ +” or “?” wildcard. Leading zeros are significant. The ii-d i gits value 
“02” associated with a call will not match the digit string “2” in a vector step.
As with ANI routing and collected  digit routing, ii-routing digits can be compared 
against entries in a Vector Routing Table.
The following calls will have ii-d igits values associated with them.
nIncoming ISDN PRI calls that include ii-digits
nIncoming ISDN PRI Tie Trunk DCS or non-DCS calls that include ii-digits.
Note that since tandeming of ii-digits is only supported if the trunk facilities 
used are ISDN PRI, traditional DCS will not support ii-digits transport but 
DCS Plus (DCS over PRI) will.
When a call is returned to vector processing as a result of the VDN Return 
Destination feature, the ii-digits are preserved.
When a call is transferred to a VDN the following is true:
nIf the transfer is completed b efore the call reaches the ii-digits conditional, 
the ii-digits value of the originator of the call is used. 
						

							ANI and II-Digits Routing
7-6Issue  4 September 1995 
nIf the transfer is com pleted after the call reaches the ii-digits conditional, 
the ii-digits value of the terminal executing the transfer is used. Under 
normal circumstances, there will be no ii-digits for a terminal executing a 
transfer.
To ensure that the originator’s ii-digits is preserved, add a filler step (such as wait 
with silence) to the beginning of the vector. In this way a transfer can complete 
before the ii-d i gits conditional is encountered.
The following table is a paraphrased summary of currently available II-digits. A 
complete and more descriptive list of II-digits is published quarterly in Section 1 
of the “Local Exc hange Routing Guide” published by Bellcore. 
						

							II-Digits Routin g
Issue  4 September 1995
7-7
II-Digits Routing Example
The following example demonstrates branching calls with d ifferent ii-digits to 
different VDNs. The VDN override is set to “yes” on the called VDN. In this way, 
the VDN name or VDN of Origin Announcement can be used to convey to the 
agent the type of ii-digits associated with the call.
Table 7-2. II-digits Summary
Code Use
00 Id entified line - no special treatment
01 Multiparty - ANI cannot be provided
02 ANI failure
06 Hotel/Motel - DN not accompanied by automatic room ID
07 Sp e cial operator handling required
20 AIOD - Liste d DN of PBX sent
23 Coin or Non-Coin - line status unknown
24 800 Service
27 Coin Call
29 Prison/Inmate Service
30-32 Intercept
34 Telco Operator Handled Call
40-49 Locally determined by carrier
5 2 O u t WATS
60 Telecommunication Relay Service (TRS) - Station Paid
61 Typ e 1 Cellular
62 Typ e 2 Cellular
63 Romer Cellular
66 TRS - From Hotel/Motel
67 TRS - From restricted line
70 Private paystation
93 Private Virtual  Network call 
						

							ANI and II-Digits Routing
7-8Issue  4 September 1995 
Figure 7-4. II-Digits Routing Example
In this vector, step 1 routes calls with no associated ii-digits to extension 1232. 
Steps 2 through 8 route calls with different ii-digits to different extensions.
  1. goto step 9 if ii-digits = none
2. goto step 10 if ii-digits = 00
3. goto step 11 if ii-digits = 01
4. goto step 12 if ii-digits = 06
5. goto step 13 if ii-digits = 07
6. goto step 13 if ii-digits = 29
7. goto step 14 if ii-digits = 27
8. goto step 15 if ii-digits = 61
9. route-to number 1232 with cov n if unconditionally
10. route-to number 1246 with cov n if unconditionally
11. route-to number 1267 with cov n if unconditionally
12. route-to number 1298 with cov n if unconditionally
13. route-to number 1255 with cov n if unconditionally
14. route-to number 1298 with cov n if unconditionally
15. route-to number 1254 with cov n if unconditionally 
						

							Issue  4  September 19958-1  
8
Look-Ahead Interflow
Introduction
Look-Ahead Interflow enhances Call Vectoring for call centers with multiple ACD 
locations. Look-Ahead Interflow allows these centers to achieve optimal call-
handling capability an d agent productivity by intelligently routing calls among 
call centers to achieve an optimum ACD load balance. This service is provided 
via ISDN-PRI D-channel messaging. The receiving switch is able to accept or 
deny interflowed calls sent by the sending switc h.
Command Set
There are no special commands for Look-Ahead Interflow. Instead, this feature 
uses the commands included within the Basic Call Vectoring and Call Promp ting  
features. The  following points concerning several of these commands should be 
noted:
nRoute-to number with coverage n or route-to digits with coverage n 
command on a switch that has Look-Ahead Interflow optioned and that 
successfully seizes an ISDN-PR I trunk automatically results in a normal 
Look-Ahead Interflow call attempt being placed. The call attemp t can be 
rejected or accepted by the remote end.
nRoute-to number with coverage y or route-to digits with coverage y 
command never results in a Look-Ahead Interflow call attempt. The 
sending end assumes the call is always going to be accepted. This 
command always completes the call. Moreover, the command should not 
be used when the vector at the receiving location ends up denying the 
call, since the caller in this case would be given a busy signal, or the call  
						

							Look-Ahead Interflow
8-2Issue  4  September 1995
will b e disconnected. This c ommand with coverage y should only be used 
for those cases when an unconditional interflow is wanted (with Look-
Ahead Interflow active) and the terminating switch is set up accordingly.
Functions and Examples
When a Look-Ahead Interflow c all attemp t is made, Call Vectoring at the sending 
location checks a potential receiving location to determine whether to hold or 
send the call. While this is done, the call remains in queue at the sending 
location. As such, the call c an still be c onnected to the sending-location agent (if 
one b e comes available) before the receiving location accepts the call.
Call Vectoring at the receiving location d e cides whether to accept the call from 
the sending location or to instruct the sending location to keep the call. In the 
latter case, the sending location can then either keep the call, check other 
locations, or provide some other treatment for the call. Conditions for sending, 
refusing, or receiving a Look-Ahead Interflow call attempt can include a 
combination of any of the following: number of calls in queue, average speed of 
answer or expected wait time for a split, number of staffed or available agents, 
the numb er of calls active in a VDN, time of day and day of week, or any other 
conditional.
If the call is accepted by the receiving switch, the call is removed from any 
queues at the sending switch, and call control is passed to the receiving switch. 
If the call is denied by the receiving switch, vector processing simply continues 
at the next step at the sending switch. Until the call is accepted by either switch, 
the caller continues to hear any tones applied by the sending switch. Should the 
call be denied, the call vector may then a pply alternate treatment, such as 
placing another Look-Ahead Interflow call to an alternate backup switch.
NOTE:
It is important to note that the Look-Ahead Interflow operation is completely 
transp arent to the caller. While a Look-Ahead Interflow call attempt is being 
made, the caller continues to hear any audible feedback provided by the 
sending switch vector. The caller also maintains his or her position in any 
split queues until the call is accepted at the receiving switch.
NOTE:
Look-Ahead interflow d oes not pass Call Promp ting digits collected in the 
sending switch to the receiving switch. Therefore, when used with LAI, Call 
Promp ting should be used to collect digits only after the last p ossible 
interflow. Alternately these digits can be passed to a CallVisor/ASAI 
a p plication, which can include them in the UUI field of the call. UUI is 
passed to the receiving switch in the SETUP message. 
						

							Functions and Examples
Issue  4  September 1995
8-3
Two Switch Configuration
Look-Ahead Interflow is enabled through the use of call vectors and their 
associated commands. For a two switch configuration, these vectors are 
included in both the sending switch, which processes vector outflow, and the 
receiving switch, which processes vector inflow. The Two Switch Configuration 
for LAI is illustrated as follows:
Figure 8-1. Two Switch LAI Connections
Sending Switch Operation
The vector(s) in the sending switch use the g oto command to d etermine whether 
the call should be sent to the receiving switch. Recall that the 
g oto command 
tests various outflow threshold conditions (such as number of calls queued). If 
the expressed condition is met, a branch is made to the appropriate 
route to 
command. This command sends the call to the receiving switch, which, as 
already noted, can accept or deny the call.
SENDING
SWITCHRECEIVING
SWITCH ISDN - PRI
INCOMING
CALLS
BACKUP
SPLIT MAIN
SPLITPRIVATE NETWORK