When configured for receiving inbound phone or fax calls, CopiaFacts processing varies considerably depending on the type of board or port in use. This topic describes the basic processing steps which are performed.
1. Selection of a CopiaFacts channel to handle the call
Each incoming call requires a free CopiaFacts channel to handle it. How that channel is selected is the step that varies most widely between different boards. It is important to note that there may be fewer free CopiaFacts channel than there are telephone channels on which incoming calls may arrive. It is particularly important to minimize the time needed for post-processing of calls after the connected switch has dropped the call: otherwise the next call may be delivered before the CopiaFacts channel is free to receive it. When possible, the call that cannot be handled will be rejected with a 'busy' reason code, and presumably will be retried later by the caller.
The following list outlines the selection process for each hardware type, following detection of an incoming call:
| Analog Lines and Fax Modems | The CopiaFacts channel is permanently associated with a specific hardware channel and physical phone circuit, so the CopiaFacts channel is automatically selected by the telephone channel on which the call is received. |
| Brooktrout Digital Boards and SR140 | The Brooktrout API permanently associates each CopiaFacts channel with a device and board channel, so the CopiaFacts channel is automatically selected by the board channel on which the call is received. |
| Diva Digital Boards | CopiaFacts scans all channels configured for inbound sequentially to find a free one. If the variable DIVA_OFFERED_SCANCOUNT is between 1 and 10, the scan is performed this number of times (default 1), at intervals of about 250ms. Unless a call control DLL is in use (see below) which has requested it be deferred, an Alert is immediately sent to the connected switch, acknowledging the call. |
| TE-Systems XCAPI | CopiaFacts scans all channels configured for inbound sequentially to find a free one. If the variable XCAPI_OFFERED_SCANCOUNT is between 1 and 10, the scan is performed this number of times (default 1), at intervals of about 250ms. Unless a call control DLL is in use (see below) which has requested it be deferred, an Alert is immediately sent to the connected switch, acknowledging the call. |
| BladeWare | The CopiaFacts channel is selected by reference to the channel reference returned by the API. This reference indicates which CopiaFacts channel initiated the wait-for-call that has been resolved by this incoming call. |
2. Obtaining Call Data
For digital calls, and for analog calls with supported CLI capability, the DNIS (dialed number) and ANI (caller number) are obtained from the call notification event as soon as possible after the call has been notified.
3. Call Control DLL
Where a customer-supplied Call Control DLL has been implemented, it is called at this time. The Call Control DLL is passed the DNIS and ANI (and redirect information, if available) and can optionally modify these values before CopiaFacts continues call processing. The DLL can also determine whether the call is to be answered, and if not, can specify a rejection cause value to be returned to the switch.
It is important that the DLL is written to return without delay. If there is no possibility of delay, the DLL initialization can specify that the digital call is not to be acknowledged until after the DLL returns.
4. Do-Not-Answer Check
If a global Do-Not-Answer file has been specified, the incoming ANI is looked up in it to determine if the call is to be rejected.
5. Check for "Always Answer"
Some call types are answered before a user profile is selected:
| BladeWare | If the flag is set in HDID Type (in CFHWL channel properties) to use in-band DTMF for DNIS purposes, the call needs to be answered so that an audio path is established. If the flag is not set, then the in-band DTMF is used instead for 'Software DID'. |
| Digital Lines with 'Use Default' | If the channel's HDID Type (set in CFHWL channel properties) is an odd value (least-significant bit is set) then we proceed to answer the call before attempting to find a user profile to handle the call. This bit-flag indicates that the default user profile can be selected if no specific user profile can be found for the call. |
6. Select User Profile (1)
At this stage we use the $dnis_scan parameters to parse the DNIS value and extract a numeric value which can be used (left-zero-filled) to locate the user.
The User Profile used for each DNIS value is named to match the DINS; for example 0012345678.USR contains commands describing the call destination user. Formerly, a mailbox file (the same filename with MBX extension) was also required to specify how and where the incoming fax was to be saved and dealt with. Now, the $auto_receive command in the user profile can sepecify a single builtin virtual MBX file whose few commands reference variables set in the USR file, thus eliminating the need for multiple MBX files.
See the next topic, Inbound Fax, for more details of this process.
7. Answer Call
Finally, we are ready to answer the call. This establishes an audio path (or media path, for SIP calls) which can be used in further processing of the call. For some hardware types, the user selection cannot be done until the call has been answered.
8. Resource Allocation and Call Setup
Once the user to whom the call has been directed is known, we know whether to process the call as a fax call or a voice call, or whether the decision should be deferred until a fax tone has been detected.
For inbound fax calls where Active Directory has not been used, mailbox selection proceeds as described in the Inbound Fax topic.
