Accounting for protocol limitations

You need to be aware of the operation of the signaling protocol your system uses and design your state table accordingly. In general, trunk protocols provide call information (called and calling numbers) but not call transfer, while line-side (station) protocols provide call transfer but not call information. To get both call information and call transfer, you may need to use an exchange data link. For example, the exchange data link using CallPath Server provides call information.

Far-end hangup detection is another function that is not supported by some protocols. Again, if you use an exchange data link that uses CallPath Server, far-end hangup detection is supported. (See Coordinated call and data transfer.)

Getting call information when answering a call

The best way of choosing a state table to handle an incoming call is to use the called number (appearing to callers that they have “gone straight through to” the voice response service). However, if the called number is unavailable there are two other options: see Handling incoming calls in your production system.

Ayava switches with the converse feature cannot send DNIS information using the incoming address signaling options, and therefore cannot be retrieved by the Blueworx Voice Response system variable SV185. Such switches send DNIS information as DTMF keys after Blueworx Voice Response answers the call. To handle this, you need to modify the state table identified by the system parameter: State Table Name for Incoming Calls (the default is Incoming_Call). See Can you write your own state table to answer calls? for details of how to do this.

Making and transferring calls

When using line-side (station) protocols such as FXS and RE, you are recommended to use dial tone detection when making outbound calls and call transfers (see the information about MakeCall in the Blueworx Voice Response for AIX: Application Development using State Tables information).

Detecting far-end hangup

You need to be aware that some protocols, generally loop start protocols such as FXS, do not include positive hangup detection.

In the absence of any indication from the switch, when a caller hangs up, the state table continues to run until a CloseEverything action. To avoid executing a state table unnecessarily:

Consider using relatively low timeouts in actions that get caller input (for example, GetKey or GetData). If the Last Timeout result branches to a CloseEverything action, low timeout and repeat count values will end the state table execution soon after a caller hangs up.
After a Record... action or a speech recognition request, evaluate the System : Action additional information system variable (SV180), which may indicate that the recording was terminated because the time limit specified by the Maximum Silence Duration system parameter was exceeded.

Example:

Here’s an example that highlights the potential for various problems you may encounter based on your specific configuration. Suppose your system is connected to a ROLM 9751 switch that is configured to use the FXS Loop Start protocol. When a caller hangs up before a voice application has completed execution, the following events occur:

The protocol does not detect the hang up and Blueworx Voice Response remains off-hook.
As the voice application continues to execute, the ROLM switch issues an error tone for a number of seconds, then pauses, then issues a second error tone that alternates between the tones for the * and # keys.
The voice application state table encounters a GetData action and waits for caller input before timing out for the first time.
The state table branches to the state specified in the time-out result field (perhaps a PlayPrompt to prompt the caller for input), then again encounters the GetData action to wait for caller input.
Assuming a high time-out value, the repeat count value (the maximum number of timeouts allowed before branching to the state specified in the last timeout result field) may not be reached before the ROLM switch issues the second error tone.
GetData recognizes the # key in the error tone as “end of input,” but does not recognize the * key.
GetData exits with a result of “Input Too Short,” and branches to the state specified for this result.
If the state that is branched to is not CloseEverything, the state table continues to execute.
If the execution again encounters the GetData action, and the switch continues to issue the second error tone, the state table loops indefinitely.

The problem in this example could have been eliminated by reducing the timeout and repeat count values so that the voice application timed out before the switch issued the second error tone.