Using Caller Number and Called Number
CopiaFacts can make use of both the caller number (ANI) and called number (DNIS) to direct and control an incoming call. This information may be provided 'in-band' (using DTMF codes) or as part of the data collected when a digital call is presented. The principal use of the DNIS data is to direct the incoming call for processing with a user profile (USR) numbered to match the 'direct inward dial' (DID) value. The USR file determines how the call is handled.
Irrespective of the source of the data, CopiaFacts has two methods of analyzing the digit strings made available with the call. The first is to assume one of a number of fixed formats, and the second allows scanning of the incoming DNIS string to allow for variable formats.
This feature requires DID to be enabled on the license page in the configurator (CFHWL), which enables the DID options section on each line page. This section can then be used to select the options for each line.
See the Inbound Calls topic for information about the sequence of inbound call steps for different hardware and port types.
Fixed Format DNIS/ANI
This method of analyzing DNIS and ANI applies principally to T1 circuits in North America. This is the default. The processing assumes that the digit string received at the start of the call is one of a specific set of formats, starting with '*'.
To obtain DNIS and ANI digits (shown below as d and a respectively) the options below are tested in turn against the incoming string:
•If the string is 23 bytes, assume *aaaaaaaaaa*dddddddddd*
•If the string is 22 bytes, the last four are used as DID.
•If the string is 20 bytes, assume *aaaaaaaaaa*ddddddd*.
•If the string is 17 bytes and the 6th byte is also '*', assume *dddd*aaaaaaaaaa*.
•If the string is 17 bytes, 6th byte not '*', assume *aaaaaaaaaa*dddd*.
•If the string is 16 bytes, assume the DNIS starts at position 11.
•If the string is 13 bytes, starting '**', assume **dddddddddd*.
•If the string is 7 bytes, starting '**', assume **dddd*.
•If the string is 10 bytes, assume *aaa*dddd*.
•Otherwise, use the whole string (excluding non-numeric characters) is taken as DID. This option is also used when DNIS is extracted from special devices (hardware DID) on analog circuits.
All the above options are tested for every call. Normally only one format is presented on any one line, however. For Brooktrout boards, you should ensure that the did_digits and did_variable parameters in BTCALL.CFG are set appropriately for the expected digits.
The above fixed formats are also used to analyze DNIS/ANI strings at sites where the string to be scanned has been presented as in-band DTMF signalling ("software DID", see below). This procedure is applied automatically when the incoming DTMF sequence begins with an asterisk character and the DID Type code for the line is set to zero in the configurator (CFHWL).
Variable Format Scanned DNIS
This option is set when the line is configured in CFHWL. In the 'DID type' box at the bottom left of the line options, you can right-click and select the option, 'Use DNIS scan for user and auto-call'. In addition a $dnis_scan configuration command is needed to set the scan parameters.
This option is provided principally for use on Euro-ISDN systems. The caller's number (ANI) is available separately and is not involved in the scan of the incoming DNIS string. DNIS may sometimes be presented including the (country or) city code, and sometimes without. For this reason the system will scan the incoming string for fixed digits which will be included in all incoming numbers, even if preceded by a prefix.
The $dnis_scan command specifies the string to scan for, the number of following digits to skip, and then the number of following digits to use as the DID (to select a user profile). Any additional characters in the incoming string are then retained and made available to select either an infobox or a fax mail box for the call. This allows the DNIS string to specify both a user profile and a document, infobox or mailbox, and is enabled by means of the DNIS or USRDNIS keywords on the $auto_call command in the user profile.
There is a mechanism to allow different $dnis_scan specifications for different incoming PRI-ISDN spans. See the command reference for details.
The $dnis_scan parameters can also be specified for analyzing "software DID" (described below) at sites where the DNIS string to be scanned has been presented as in-band DTMF signalling. This also requires the DID type to be configured as described above.
Using DNIS to select an Application or Client, or a Mailbox for Incoming Faxes
The principal use of DNIS is to select a different USR file to handle an incoming call. By default, all the DNIS digits (usually 4 in the USA) are used as the numeric filename (with leading zeros) of the USR file. So a DNIS value of 1234 will select 00001234.USR. Once the USR has been selected, it can typically specify an $auto_call value to start a specific script, or an $auto_receive value to select a specific mailbox for an incoming fax.
Where DNIS data has been selected from a longer incoming DNIS string (typically in European E1 systems) the $auto_call command can specify that the remaining parts of the incoming string are to be used to form the initial infobox at which an IVR script is to start.
To permit DID to be used to select a mailbox (MBX) for the receipt of inbound faxes, the line operation Receive Fax Mail must be enabled for the line. This causes the line to start a receive operation on an incoming fax call, and uses the settings and folder defined in the MBX selected from the USR. If the USR derived from the DID cannot be found, then the call is rejected, unless the DID type code set for the line in the configurator specifies that the default USR file is to be loaded in this case. The default USR can be set up either to receive the fax into a common mailbox, or to play a voice message indicating the reason for the failure.
If DID and DNIS are not used, incoming faxes can still be received and controlled by 00000000.MBX when the line operation Accept Inbound Faxes is enabled for the line in the configurator. The 'zero' MBX file is created automatically with default settings if it is not present.
The CopiaFacts system has an optional feature called "software DID" (SDID). Software DID is useful if you have to support different configurations or applications on the same line. It is implemented as a special initial prompt to which the caller responds with a numeric value. This numeric value is used to select a numeric-filename USR file as if were a DNIS value.
A common use for software DID is to support different languages. The SDID feature does not require DID (direct inward dial) or DNIS capability from your telephone company; however CopiaFacts also uses SDID as the "software part" of a DID implementation, and hence the name.
The SDID extra prompt is standard voice prompt 43) to be played at the start of an inbound call, and uses the caller's numeric response to this message to select a user profile. A typical system greeting would be:
Please enter 1 for the English system, 2 for Spanish
The way that SDID operates is to load the user profile file that matches the number entered at this first voice prompt. So in the above example you would set up the English system in the user profile file 00000001.USR, and the Spanish system in file 00000002.USR. If the number entered does not have a .USR file that matches, an error message is played and the prompt for a number is repeated.
Software DID can also be used to select the application when a call transfer or PBX sends selection DTMF (touch-tone) digits after placing the call on the CopiaFacts extension. And in some countries the PTT will send DTMF data immediately after CopiaFacts has answered the incoming call, and this DTMF data can be interpreted as SDID to select a user profile. For all these SDID variants, you would normally disable the SDID greeting prompt by copying EMPTY.VOX over FAXMSG.43.
When your system has SDID enabled, the details such as the number of expected SDID digits are specified in the CopiaFacts configurator CFHWL. The $user_profiles command specifies the directory in which your user profiles will be found.
Changing the Controlling User Profile
At any time in an IVR call, you can assign a new (DNIS, SDID) number to the system variable DIDNO and then use $next_box to transfer to state s:SETUP_USER. This will restart the IVR session as if the appropriate numbered USR file had been selected originally. User variables that have already been assigned to will remain available with their assigned values.
Modifying the DNIS and ANI values
Incoming data can be modified for custom applications by providing a Call Control DLL and defining notification functions.
Trace Information For a full explanation of the processing of incoming DTMF and DID, enable 'Debug DTMF Analysis' on the Trace/Debug tab in COPIAFACTS.