Key Voice Voice Processing System Installation And Maintenance Manual

							INSTALLATION AND MAINTENANCE MANUAL 4/007-66Note:When using the digit translation feature with a telephone system that sends voice mailintegration digits, you must specify the placement of the transfer-bypass digit as LASTDIGIT on the CALL TRANSFER screen (VP systems) / PBX INFORMATION screen(NTVP systems).If you have used the transfer bypass feature manually, you know that at the conclusion of the process the
VP system plays the prompt, “You may transfer the call now,” to let the person who is transferring the
call know that he/she can hang up.  When transfer bypass is specified in the TRANS.TXT file, however,
there is no need for the system to play this prompt.  To eliminate the prompt, add a short pause followed
by a second *.  Using the previous example, the translation rule in TRANS.TXT is now:
146=146*,*
7.13.2 Using Wildcard Characters in Translation Rules
So that you do not have to build a translation rule for each mailbox on the system, the VP system allows
you to use certain “wildcard” characters: the letters N and P through Z (letter O is not allowed to avoid
confusion with zero). Either upper or lower case letters can be used.  There are two ways you can use
wildcard characters:
· Each wildcard character (X, Y, Z, etc.) can represents any number of digits in a field.  This is the
default operation.
· Each wildcard character can represent a single digit in a field (you set this by specifying 512 as a
custom code, see section 7.13.4).
A field is the part of a digit stream that is distinct in type.  Each field is separated by a delimiting
character.  To understand the concept of fields, consider the following translation rule:
#X#Y#=X,Y
On the left of the equal sign, there are two fields of incoming digits (X and Y) separated by the digit #,
which is the delimiter (# separates the fields).  On the right side of the equal sign, the delimiter is a
comma, which is the only delimiter character the VP system recognizes.
Note:  The $ and the @ character can also be used as wildcard characters in translation tables.These characters differ from other wildcards, however, in that they cannot be set torepresent either a single digit or any number of digits in a field.  The $ character alwaysmatches a single digit, and the @ character always matches any number of digits in afield, regardless of whether custom code 512 is specified (see section 7.13.4).  You canuse the $ and @ wildcards in DOS-based VP system versions 8.2 revision 6A and higher,NT-based VP system versions 9.1D or higher, and unified messaging VP system versions10.1 and higher.Using Wildcards to Translate Extension Numbers Sent by the Phone System
If the telephone system sends only the extension numbers of the station when forwarding a call to voice
mail, you can use the following translation rule to cover every extension on the system:
X=X*,* 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-67By default, X represents “any number of digits.”  Therefore, the mailbox numbers on the system can be of
mixed length (for example, 3- and 4-digit mailboxes).  This is the most often used translation rule and
may be the only one required for the system, especially if Reason codes are not needed.  (Reason codes
are discussed below.)
7.13.3 Storing the Calling Party’s Number
If the incoming digit sequence contains the calling party’s telephone number, this can be extracted and
stored as the account number for the call.  The account number can then be used for various purposes.
See section 7.23.
Use the word CALLER to tell the VP system which digits represent the calling party’s number.  Consider
an example where the host telephone system sends the calling party’s number, followed by a pound,
followed by the called extension:
xxxxxxx#yyyy
To inform the VP system that the first 7 digits represent the calling party’s number, you include the
following line in the TRANS.TXT file:
xxxxxxx#yyyy=yyyy*,*:CALLER=x
The VP system stores the digits as the account number for the call.
7.13.4 Using Reason Codes
Some telephone systems send additional digits along with extension numbers when a call is forwarded to
voice mail.  These additional digits are called Reason codes because they explain why the call has been
sent to the VP system.  The terminology used by each telephone system varies, but the most common
reasons for a call to be sent to voice mail are:
· Forwarded on no-answer
· Forwarded on busy
· Forwarded all calls
· Direct call
· Message retrieval (auto log-on)
· Recall
These Reason codes may be sent before or after the station extension number.  Sometimes the codes and
their placement are fixed by the telephone system, and sometimes you can make modifications.  If you
can make modifications, choose only those codes that the VP system needs and choose digits that will not
conflict with mailbox numbers (such as *, #, A, B, C, D).  These guidelines help to keep the translation
rules simple.  Below are examples of Reason codes sent first and for Reason codes sent last in the digit
string. 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-68Reason Codes Sent Last (As a Suffix to Extension Number)
Example using simple translation rules:  Assume you working with a telephone system that provides
Reason codes that are flexible (programmable), but are always sent after the extension number.  The
system sends Reason codes for Busy, Ring-no-answer, and Auto log-on only.
You want to treat both busy and ring-no-answer calls the same way, sending them to the mailbox owner’s
personal greeting.  If for both of these call types, the DTMF digit A is specified as the Reason code, the
translation rule is:
XA=X*,*
This rule specifies that when any number of digits (X) followed by the digit A is received from the phone
system, the VP system is to repeat those same digits (X), remove the A, and add * , * at the end.
Now consider the case when the Reason code is not programmable and the telephone system sends, for
example, a 6 to indicate busy and a 7 to indicate ring-no-answer, then the extension number.  The
translation table format and content must be modified.  Consider the consequence if you retained the
format and simply modified the rule to read:
X6=X*,*
This rule functions well as long as there is never a 6 in the extension number.  Consider, however, if there
is a 6 in the extension number.  Because X indicates “any number of digits,” if the call was forwarded
from extension 164, the VP system interprets this as 1646.  The VP system sees the 1 as the entry for X
(any number of digit) then sees the first 6, which it interprets as indicating a busy condition. It ignores the
last two digits 4 and 6.  As a result, it mistakenly translates the string as:
1646=1*,*
Which transfers the call to mailbox 1.
To accommodate Reason codes that can conflict with extension numbers and cannot be reprogrammed,
you set up wildcard characters so each character represents only one digit (not any number of digits).  To
indicate you want to use wildcard characters this way, you must enter 512 in one of the CUSTOM fields on
the OTHER CUSTOMIZATIONS screen (VP systems) / CUSTOM FLAGS screen (NTVP systems) (see section
4.11).  Once you make this entry, each wildcard character you enter represents only one digit.
The translation code that accommodates Reason codes 6 (discussed in the example above), reads as:
XXX6=XXX*,*
The rule indicates:   “for any three digits followed by a 6, repeat the three digits, remove the 6, and add
* , *.”
To accommodate Reason code 7, you re-enter the rule using the same format and changing the 6 to a 7:
XXX7=XXX*,*
To further simply these rules, you can combine them and use a second wildcard character Y:
XXXY=XXX*,*
This rule now specifies, that no matter what Reason code the telephone system sends (represented by Y),
the VP system is to remove the code, then add * , *.  The call is transferred directly to the mailbox, and 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-69the caller hears the mailbox owner’s personal greeting.  One situation that this rule does not
accommodate, however, is when the phone system sends an Auto Log-in code.
The Auto Log-in code is sent when a mailbox owner uses a Message Waiting Retrieval button or dials a
Message Retrieve code from his/her telephone.  By pressing this button or using this code, the owner is
attempting to access the voice mail gateway to log in to his/her mailbox.  Using the previous example,
assume that the telephone system sends a 9 as the Auto Log-in code.  The translation rule needed is
shown below:
XXX9=#,XXX
This rule translates as “for any three digits received followed by the digit 9, remove the 9, insert the digit
# (since the DESTINATION FOR DIGIT # is set on ROUTING BOX screens to go to box 9992, which is the
voice mail gateway.  The VP system is to then redial the three digits received from the phone system,
which indicates the extension number.
To create a TRANS.TXT file that accommodates the two rules created for the above example, you must be
aware that the VP system reads the TRANS.TXT file from top to bottom, executing the first rule it finds that
matches the incoming digit sequence.  Therefore, you must list the most specific rule at the top of the file
and the least specific rule at the bottom of the file.
Note:In the translation table TRANS.TXT, the most specific rules must display at the top of thefile, descending to the least specific at the bottom of the file.The TRANS.TXT file for the example discussed above must list the rule for the Auto Log-in code before
the more generic rule for Reason codes 6 and 7:
XXX9=#,XXX
XXXY=XXX*,*
The first statement is the most specific, since the Reason code is specified as a 9.  In the second statement,
the Reason code Y represents any digit.  Since the VP system reads this table from the top down, it
matches the rule for the Auto Log-in digit 9, first, if that is the digit sent by the telephone system.  If that
is not the digit sent, the second rule is applied (in this example, for digits 6 or 7).  If these two statements
were reversed in order, the system would never perform the Auto log-on call to box 9992, as the code
1649 when sent from the phone system, would be matched first with the XXXY rule, which would send
the call to the mailbox personal greeting.
As a final point to this example, consider an example where Reason codes are sent as the last digit and the
system includes variable length mailbox numbers.  All of the rules for digit translation still apply.  It need
only be noted that the longest digit strings should be listed first in the table and the shorter digit strings
last.  In the example discussed above, if the system used both 3 and 4 digit mailboxes, the translation
table would include four entries:
XXXX9=#,XXXX
XXX9=#,XXX
XXXXY=XXXX*,*
XXXY=XXX*,*
The first two rules are similar to the last two, but the first two are more specific.  Therefore, they are
placed first in the TRANS.TXT file.  Length is the second consideration.  Considering the two rules that
specify the digit 9, the rule with the longer character sequence must be placed first.  The same logic
applies when ordering the last two rules. 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-70Reason Codes Sent First (As a Prefix to Extension Number)
If you have not already, review section 7.13.  The scenario and examples discussed previously are used
here, except this section considers how translation rules are affected when the Reason code is sent before
the extension number.  With this in mind, consider the scenario where the VP system transfers a caller to
extension 164 and that extension is busy.  If the Reason code is sent first by the telephone system, the
telephone system forwards the call back to voice mail with the digits 6164.
In almost every case where Reason codes are sent before extension numbers, you can use the default
wildcard characters (where a character such as X equals any number of digits).  This is possible since the
Reason code match is made before an extension number match, and the two are never confused.  The only
exceptions to this standard involve cases where other types of integration signaling (such as C.O.
identifier codes) or D.I.D. lines are in use on the system and therefore, there are dialing plan conflicts.
Consider first, the scenario where there are no other types of integration signaling.  There are three
general translation rules that both allow the system to recognize the three Reason codes discussed earlier
and work for extension numbers of any length:
6X=X*,*
7X=X*,*
9X=#,X
These three rules work even if the system uses C.O. identifier codes and/or D.I.D. lines, as long as they
do not begin with 6, 7, or 9.
D.I.D Line Considerations
Consider the following scenario, which illustrates how you modify translation rules to accommodate
systems on which D.I.D lines do conflict with digits 6, 7, or 9.
Assume the telephone system has all three-digit mailboxes (and extensions).  The system is also receiving
D.I.D digits that begin with 6 (600 - 699).  First, the translation table wildcard characters must be
modified to represent single digits.  As discussed earlier, you do this by entering 512 in any CUSTOM field
on the OTHER CUSTOMIZATIONS screen (VP systems) / CUSTOM FLAGS screen (NTVP systems).  This
modification forces you to update the translation rules so they now read as follows:
6XXX=XXX*,*
7XXX=XXX*,*
9XXX=#,XXX
XXX=XXX
If the VP system receives a D.I.D. number during the initial pause, 656, for example, it is matched to the
fourth rule in the table and is not confused with a call that was forwarded from a busy extension.  In this
case a busy extension is represented by a total of 4 digits (6XXX).  When a three-digit number is sent to
the VP system, it is interpreted as simply an extension number, even though it begins with a 6.  And since
this is a new call (just received via a D.I.D. trunk) that includes no Reason code, the VP system passes the
digits through the table without modification.  The call is transferred to the mailbox owner’s extension.
As noted earlier, you can use up to twelve wildcards in the translation table (N and P through Z), but all
codes have the same digit representation characteristics.  By default, each code can be used to represent
any number of digits.  If CUSTOM is set to 512 on the OTHER CUSTOMIZATIONS screen (VP systems) /
CUSTOM FLAGS screen (NTVP systems), however, one code represents only a single digit. 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-71C.O. Line Identifier Digits (Trunk I.D.) Considerations
If all of the central office lines are to be answered by the same initial greeting, you do not need C.O. line
identifier digits.
Consider, however, a company that has two groups of C.O. lines, each with a unique telephone number,
for example, 555-1212 for Sales, 555-3434 for Service.  The Sales department has 6 lines, designated as
C.O. lines 1 - 6 in the telephone system, and the Service department has 5 lines, designated as C.O. lines
7 - 11.
Assume the telephone system does not provide options for assigning I.D. digits.  When they are used,
they are automatically assigned an I.D. that is the same as the C.O. line number (starting at 01 for line 1,
02 for line 2, etc.). The Sales department’s main greeting is in Routing box 500, and the Service
department’s main greeting is in Routing box 501.
To specify translation rules for these C.O. line identifier digits in the TRANS.TXT file, you make the
following entries:
01=500
02=500
03=500
04=500
05=500
06=500
07=501
08=501
09=501
10=501
11=501
These rules are specified at the top of the TRANS.TXT file, since they are more specific than any rules that
use wildcard characters.
Now assume the C.O. line identifier digits sent by the telephone system are programmable (they can be
selected by the installer).  In many cases where the lines are programmable, the programmer can choose
any number that is either two-, three-, or four-digits (length may be dictated by the phone system) to
assign as an I.D. for each trunk.  When specifying translation rules in this case, you can keep the
TRANS.TXT file as simple as possible by assigning a unique series of I.D. digits to each grouping of
trunks.
For example, if the telephone system allows you to assign any three-digit number as a trunk I.D (these
I.D.s cannot conflict with the station extension numbers) you can assign trunks 1 - 6 (the Sales
department) I.D. numbers 300 through 305, and trunks 7 - 11 (the Service department) I.D. numbers 400
through 404.
The TRANS.TXT file now reads as follows:
300=500
301=500
302=500
303=500
305=500
400=501
401=501
402=501 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-72403=501
404=501
Since each group of trunks is using a unique series of numbers, you can simplify the file using wildcard
characters:
3XX=500
4XX=501
Note that in this example, one of the CUSTOM fields on the OTHER CUSTOMIZATIONS screen (VP systems)
/ CUSTOM FLAGS screen (NTVP systems) needs to include the 512 entry discussed earlier, to stipulate that
each wildcard character represents one digit, not any number of digits.
Note:The VP system defaults to begin accepting in-band (DTMF) digits 500 milliseconds afteranswering the call.  Some telephone systems may begin sending digits before the 500 mshas passed, so the VP system may miss them.  If you find that the VP system is missingdigits at the beginning of a call, you can lower the 500 ms time to 300 ms, by entering thefollowing line in the configuration file VM.CFG:OFFHOOK DELAY = 300If this does not correct the problem, refer to section 9 for information on using TRACEfunctions.  TRACE can help you determine if the VP system is receiving all or part of theexpected incoming digits.Using TRANS.TXT and Reason Codes to Play Specific Greetings
Previous material in this section focuses on sending calls with Reason codes (except those with the Auto
Log-in code) directly to the mailbox, where callers hear the mailbox’s personal greeting.  If the mailbox
owner has recorded multiple greetings, however, you can further modify TRANS.TXT to specify which
greeting the caller is to hear.  The technique you use to set this up depends on the transfer type used by
the mailbox:
· WAIT FOR RING
When the mailbox’s TRANSFER TYPE field is set to WAIT FOR RING, if the extension is busy and
the calling party decides to leave a message, he/she hears the currently active personal greeting of
the mailbox.  When the VP system plays the greeting, it has not yet released the call, but it has
canceled the transfer process in response to a busy signal.  Consider the following example with
Mary who owns mailbox 128.
The VP system transfers callers to Mary anytime it can ring her extension (WAIT FOR RING
transfer).  It does not transfer a call if it detects Mary’s extension is busy.  If the call is not
answered, the telephone system forwards the unanswered call back to the VP system and supplies
Mary’s extension number.  In this case, the only time a call is returned to the VP system from a
mailbox using WAIT FOR RING transfers is under the no-answer condition.  (A Reason code is not
needed to supply this information).
Mary can record a greeting that plays specifically under this circumstance.  The greeting may be
worded as follows:
“Hi, this is Mary.  I’m either away from my desk or out of the office.  Please leave a message and
I will return the call as soon as I return.” 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-73If Mary records this greeting as, for example, greeting 2 in her mailbox, you can specify the
following translation rule, which instructs the VP system to play greeting 2 when it receives a no-
answer call from Mary’s extension:
128=128*,*:G2
If the telephone system does not supply Reason codes, you can modify this rule for system-wide
usage by simply substituting wildcard characters:
XXX=XXX*,*:G2
If the telephone system does supply Reason codes, simply add the ring-no-answer Reason code to
the above rule.  For example, assume the telephone system uses the prefix digit 7 as the no-
answer Reason code.  The translation rule is now specified as:
7XXX=XXX*,*:G2
Not all mailbox owners may care to have two separate greetings.  If a greeting requested by a
TRANS.TXT rule does not exist (has not been recorded), the VP system plays the currently active
personal greeting for that mailbox.
· BLIND
To play specific greetings by reason when a mailbox uses a BLIND transfer, the telephone system
must provide Reason codes.  The VP system makes BLIND transfers unconditionally and does not
listen for a busy signal.  Therefore, the telephone system must supply some distinguishing
information about the call when it returns it to the VP system in a busy or no-answer condition.
Building upon the example discussed above, assume that Mary’s mailbox is using BLIND
transfers, that she has recorded a “busy” greeting as greeting 0, and the telephone system uses the
prefix digit 6 to indicate that a call has been forwarded in the busy condition.  Two TRANS.TXT
rules are now required for Mary’s extension:
7128=128*,*:G2
6128=128*,*:G0
As described earlier, you can use wildcard characters instead of specific rules for each extension:
7XXX=XXX*,*:G2
6XXX=XXX*,*:G0
When these translation rules are included in the TRANS.TXT file, any mailbox owner can take
advantage of this greeting feature as long as he/she records a “busy” greeting as greeting 0 and a
“no-answer” greeting as greeting 2.  If the greeting called for in the TRANS.TXT rule has not been
recorded in a particular mailbox, the currently active personal greeting plays.
You can make a translation rule for each Reason code supplied by the telephone system.  More
that one rule can be directed to play the same greeting, or you can select a different greeting for
each rule (up to 10, which is the maximum number of greetings possible for a mailbox). 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-747.13.5 Specifying Rules for Recording Calls
Some telephone systems have a record-call feature.  To record a call, the telephone system calls the voice
mail system, conferences it in to an existing call, and passes the voice mail system a packet of digits
meaning “record this call.”  For example, the telephone system may send ** followed by the called
party’s extension number.  To set up the VP system so this code’s translation invokes the VP system’s
call record feature, you include the following line in the TRANS.TXT file:
**X=X,*,*,1,1
On a VP system, if you dial an extension number followed by * then *, then you press 1 then 1, the VP
system plays the recording tone and immediately begins recording.  This is the digit sequence specified
on the right side of the equation in the rule shown above.
The recorded conversation is stored as a message for the mailbox represented by X.
Disabling the Recording Tone
If you want to prevent the VP system from playing the tone just before recording, add :N (for No Beep) to
the end of the rule in the TRANS.TXT file:
**X=X,*,*,1,1:N
Note:The VP system also has a record-call feature (see section 7.24).7.13.6 Specifying Digit Translation Based on Time of Day
If you want to use different translation rules based on the VP system service mode (Day Service, Night
Service, Lunch Service, or Holiday Service), you place the translation rules in separate files as follows:FilenameUsageTRANS.DAYThe VP system uses this file while in Day Service mode.TRANS.NITThe VP system uses this file while in Night Service mode.TRANS.LUNThe VP system uses this file while in Lunch Service mode.TRANS.HOLThe VP system uses this file while in Holiday Service mode.If the specific file does not exist (for example, if the VP system is in Lunch Service mode, and the file
TRANS.LUN does not exist), then the VP system uses the rules specified in the TRANS.TXT file.  If
TRANS.TXT does not exist, then no digit translation takes place. 
						

							INSTALLATION AND MAINTENANCE MANUAL 4/007-757.13.7 Specifying Digit Translation Based on Port Number
If you want to use different translation rules based on the VP system port number on which the call is
received, place the translation rules in separate files, one per port.  Name the translation files using the
convention:
TRANSn.TXT
where n  is the VP system port number
For example, to store a separate set of translation rules that are to be used for calls coming in on port 4,
put the rules in the file TRANS4.TXT.
If a specific file does not exist (for example, if a call is received on port 3, and the file TRANS3.TXT does
not exist), the VP system uses the rules specified in the TRANS.TXT file.  If TRANS.TXT does not exist, then
no digit translation takes place.
Note:You can use the digit translation based on port and the digit translation based on servicemode feature together.  For example, if you want to specify a special set of digittranslation rules that are to be used only for ports 5 and 6 and only during Night Servicemode, you place the rules in two files named TRANS5.NIT and TRANS6.NIT.The VP system searches for the appropriate translation file in the following order:1.  Looks for TRANSn.xxx     where n is the port number and xxx is the service mode (DAY, NIT, LUN, HOL).2.  Looks for TRANS.xxx     where xxx is the service mode (DAY, NIT, LUN, HOL).3.  Looks for TRANSn.TXT     where n is the port number.4.  Looks for TRANS.TXT.7.13.8 Specifying Rules for Automatic Logon
If the telephone system sends a unique digit sequence when an extension dials the VP system directly,
this digit sequence can be used to automatically log the caller into a mailbox.  For example, if the
telephone system sends the digit sequence **123 indicating, “This is extension 123 calling to listen to
his/her messages,” the VP system can translate this sequence to send the caller to the prompt for his/her
password.  The translation rule (using wildcard characters) for this is as follows:
**xxx=xxx*,#
The digit sequence shown on the right side of the equation represents the keypresses that a caller normally
(by default) dials from the main greeting to access the mailbox’s (shown as xxx) password prompt.  With
this translation rule, someone calling the VP system from extension 123 is prompted to enter the
password for mailbox 123.
If you want subscriber’s calling in from their extensions to be able to bypass the password entry prompt
and go right to the main voice menu for their mailbox, you can modify the translation rule as shown
below: