{{indexmenu_n>40}}
====== Transfers ======
The Transfers tab provides settings that control how attempts to transfer to the mailbox extension from the auto attendant are handled, as shown below.
**On SIP-enabled systems, some of the settings shown in the dialog below are not displayed because SIP does not support those features (because SIP only supports blind transfers).**
{{:images:vs7:manual:tpl-cos-transfers.png?nolink|}}
===== General =====
This section contains the general transfer settings.\\
**Some settings are not available on SIP systems because SIP only supports blind transfers.**
|< 95% 20% >|
^Setting^Description^
|//Transfer type//|The transfer method to use when performing a transfer from the auto attendant (or any mailbox SDA that allows transferring).|
|//Play "Please Hold" prompt//|If //enabled//, the system will play //"Please hold while I try that extension"// prior to attempting the transfer.\\ \\ //Applies to all transfer types.//|
|//Redirect Transfers to operator//|Prevents callers from transferring to **any** extension. When they attempt to do so from any SDA they will be redirected to the operator.|
|//Press * for busy queue//|If //enabled//, the system will prompt the caller to press * to join, or remain in, the call queue if the transfer fails because the extension is busy.\\ \\ Not available if transfer type is //blind//.\\ \\ **Not supported on SIP systems because SIP only supports blind transfers.**|
|//Play called party's name recording//|If enabled, the system will play the called party's name recording after a successful connection; this may be useful if multiple mailboxes are sharing the same physical extension.\\ \\ Not available if transfer type is //blind//.\\ \\ **Not supported on SIP systems because SIP only supports blind transfers.**|
The following transfer types are supported //(but note that most of them are not available on SIP-enabled systems, because SIP only supports blind transfers)://
|< 95% 20% >|
^Transfer Type^Description^
|//Blind//|Dials the extension and then immediately releases the call.|
|//Supervised//|Dials the extension and monitors the line for tone-and-cadence call progress to determine ringing, busy, operator intercept, etc. The call is released only if a connection is detected; otherwise, it is recalled and sent to voice mail.\\ \\ **Not supported on SIP systems.**|
|//Confirmed//|Dials the extension and then starts playing the prompt //"To accept this call, press one."// The call is released only if a DTMF tone is detected within a set time, otherwise it is recalled and sent to voice mail.\\ \\ **Not supported on SIP systems.**|
|//Integrated//|Dials the extension and then wait for DTMF signals sent by the PBX for call progress. Used with PBX systems that provide call progress using DTMF rather than tone-and-cadence (for example, Panasonic KX-TD).\\ \\ **Not supported on SIP systems.**|
|//Account//|Limits transfers to validated callers only. Typical account transfer uses following process:
- Prompt caller to enter an ID number.
- Search the Accounts database for a matching ID.
- If a match is found and the ID has not expired, the transfer is attempted.
- If a match is not found or the ID has expired, the system will perform the action it is configured to take for the given situation (see the Account section below for more on this).
The transfer itself will employ one of the other four transfer types, depending on configuration.\\ \\ **//On SIP systems, account transfers can only use the blind transfer type.//**
|
===== Account =====
The account transfer type is designed so that you can allow or block transfers to an extension based on an account ID entered by the caller. The system will:
- Prompt the caller to enter his or her ID number
- Wait up to 15 seconds for a DTMF digit
- Wait up to 5 seconds for each additional digit, up to a maximum of 20 digits
- Validate the ID number against a database of account IDs, to verify that it exists and has not expired
If the account ID exists and is not expired, the transfer is performed. Otherwise, the transfer is blocked and a different action is taken depending on the reason for blocking the transfer: because the ID is not valid, because the ID is expired, or because the attempt to read the accounts database failed.
After selecting //account// as the transfer type, you can click the **Configure** button to open the Account Transfers Configuration dialog, as shown below.
{{:images:vs7:manual:tpl-cos-transfers-account.png?nolink|}}
This dialog allows you to configure how the system will respond in the four different cases: the ID is valid, the ID is invalid, the ID is expired, and the system was not able to complete the validation process.
|< 95% 20% >|
^Setting^Description^
|//On Expired//|Action to take if the ID is expired.|
|//On Invalid//|Action to take if the ID is not valid (not found in the database).|
|//On Failure//|Action to take if the system cannot read the database to validate the ID.|
|//Transfer type//|The real transfer type to use.\\ \\ **For SIP systems, this can only be blind.** For non-SIP systems, it can be any of the four supported transfer types (//blind, supervised, confirmed// or //integrated//).|
For the three conditional settings listed above, the following actions are supported:
|< 95% 20% >|
^Action^Description^
|//Auto Attendant//|Redirects the caller back to the auto attendant mailbox for this location.|
|//Leave Message//|Plays the call blocking greeting for, and takes a message in, the specified mailbox.\\ \\ //If a mailbox is not specified, then the current mailbox is used (that is, the one to which the caller tried to transfer).//|
|//Transfer//|Transfers to the specified mailbox.\\ \\ //If no mailbox is specified, then the current mailbox extension is used. This is the same as if the account ID was valid.//|
==== Accounts Database Management ====
A key aspect of using the account transfer type is managing the database of valid accounts. The 7.00 provides a utility which, in conjunction with a simple comma-separated value (CSV) file, allows you to update the database at any time (as long as the voice mail service has been stopped, using the Activity Monitor application).
First, you need to create a CSV file using any text editor or a spreadsheet program capable of exporting to a CSV-formatted file. This file should have only two columns. The first column is for the account IDs and the second column is for the expiration dates.
* Account IDs must be numeric and may be up to 20 digits in length. It is not necessary for IDs to have uniform length.
* Expiration dates must be specified using the one of the following formats: ''MM/DD/YY'', ''MM/DD/YYYY'', ''MM-DD-YY'' or ''MM-DD-YYYY''.
==== Example ====
111223333,04/30/17
1001,12/31/2017
2020,06-30-2018
The above example file contains three records. The first record is for account ID 111223333, which expired on April 30, 2017. Assuming a current date of May 15, 2017, the second record (account ID 1001) is valid until the end of the year, and the last record (account ID 2020) is valid through June 30, 2018.
===== Supervised Transfers =====
These settings are used when the transfer type is //supervised//.\\
**These settings are not available on SIP systems because SIP only supports blind transfers.**
|< 95% 20% >|
^Setting^Description^
|//Number of rings//|The number of rings to wait before assuming the call is unanswered (RNA).\\ \\ //At the voice card level, this value may be converted into a length of time, in seconds, assuming a value of 6 seconds per ring (a tone-and-cadence of 4 seconds on, 2 seconds off).//|
|//Play on connect//|Optional prompt ID specifying a prompt to play when the call is answered. To disable, leave the box blank or set it to 0.|
===== Confirmed Transfers =====
These settings are used when the transfer type is //confirmed//.
They are also used by any notification template that employs the //ConfirmedVerbalNotification// technique, as that technique also prompts the called party to press a digit to accept the call. DTMF wait time is also used by call screening to specify how long to wait for a DTMF response from the called party (to accept or reject the call).
**On SIP systems, these settings are only relevant for notifications because SIP does not support confirmed transfers or call screening.**
|< 95% 20% >|
^Setting^Description^
|//DTMF wait time (sec)//|Time to wait, in seconds, for a DTMF digit after playing the announcement prompt (or, in the case of call screening, the caller's name and the call screening menu).|
|//Max repetitions//|Maximum number of times to repeat the announce-call-and-wait-for-DTMF loop before assuming the call is not answered (RNA).\\ \\ //Applies to call screening only if the transfer type is// confirmed.|
|//Release on any DTMF//|If //enabled//, any DTMF will indicate that the call is answered. If //disabled//, the called party must press 1 to accept, as prompted. Any other digit is invalid.\\ \\ //Does not apply to call screening under any circumstance.//|