Configuration and Setup > 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 analysing 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.

Fixed Format DNIS/ANI

This method of analysing 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 aaaaaaaaaadddddddddd*

•	If the string is 22 bytes, the last four are used as DID.

•	If the string is 20 bytes, assume aaaaaaaaaaddddddd*.

•	If the string is 17 bytes and the 6th byte is also '', assume ddddaaaaaaaaaa.

•	If the string is 17 bytes, 6th byte not '', assume aaaaaaaaaadddd.

•	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 aaadddd*.

•	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 analyse 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 (FFHWL).

Variable Format Scanned DNIS

This option is set when the line is configured in FFHWL. 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 analysing "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

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 typicall 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.

Emulating DNIS with an Extra Initial Prompt

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 DNID 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 FFHWL. 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.

Topic url: http://www.copia.com/support/refmanual/index.html?usingcallernumberandcalled.htm