AnswerCall

Purpose

Use AnswerCall to respond to a ringing line.


A screen capture of the Action AnswerCall window

Description

This action establishes the connection between the caller and Blueworx Voice Response for an incoming call. An application cannot execute actions that use the telephone line (GetData, GetKey, and so on) until this connection is established. Note that multiple AnswerCall actions do not result in the application sending multiple off-hook signals to the switch.

Note: For region/country-specific notes on the use of this function, refer to the README file located in the directory /usr/lpp/dirTalk/homologation. The file name is in the format README_homologation.xxxx, where xxxx is the region/country identifier.

When Blueworx Voice Response makes an outbound call, connection is established when the called party picks up the telephone.

The AnswerCall action need not be in the same state table as the Get actions, but must have been executed before these actions in a state table that is part of the same voice application.

When you use the Incoming Call state table, you can still use the AnswerCall action in your state tables because, once a call has been answered, subsequent AnswerCall actions are ignored by Blueworx Voice Response. However, AnswerCall actions in your state tables are used by the state table debugger and may be useful.

Handling call information:

AnswerCall supports use of the system variable SV541 to pass additional call information from a state table to a signaling process, and SV542 to receive information back from the signaling process. See Transferring information between a state table and a signaling process for more details on how information can be communicated between the application and a signaling process such as ISDN. Note the following considerations that are specific to the use of the variables within AnswerCall:

  • AnswerCall only resets SV542 when it is invoked for the first time — second or subsequent calls are ignored.
  • Blueworx Voice Response is configured to initally invoke the Incoming Call state table, which itself executes the first AnswerCall action. Therefore, to make use of information available in the tag string at that time, you need to update the Incoming Call state table or modify its name—refer to the Blueworx Voice Response for AIX: Configuring the System information for details of how to do this.
  • Even before this first AnswerCall action has been reached within the Incoming Call state table (while the caller is waiting for Blueworx Voice Response to respond), information in the tag strings can be received and communicated to the application via SV542.
  • If the EDL Call Information After Off Hook system parameter is set to Yes, SV542 cannot be used to obtain additional information (to decide whether to answer the call), as the call would already be answered before this information could be read.

Using AnswerCall with a custom-written signaling process

Use AnswerCall to answer an incoming call notified by a custom-written common channel signaling process, such as ISDN or SS7. When Blueworx Voice Response receives an incoming call from such a signaling process, it fills in the following system variables with information received from the network about the call:

If no application is configured to answer the call, Blueworx Voice Response automatically requests the signaling process to clear the call.

Using AnswerCall with ISDN

Use AnswerCall to answer an incoming call notified across an ISDN network. When Blueworx Voice Response receives an incoming call over ISDN, which is indicated by an inbound SETUP message, it automatically responds by sending an ALERTING message. This tells the network that the incoming call has been received, and that an application or user is being notified of the call.

If no application is configured to answer the call, Blueworx Voice Response automatically clears that call to the network, by sending a RELEASE message specifying a cause code of No User Responding. When an application issues the AnswerCall action, the ISDN signaling process sends the CONNECT message to the network, when it receives the CONNECT ACK message from the network, indicating that an end-to-end connection exists, and the AnswerCall action completes. If any error occurs while answering the call, Blueworx Voice Response will clear the call and return the Not Ringing result.

Parameters

No parameters are required.

Using AnswerCall with SS7

The AnswerCall confirms the acceptance of the call and indicates to the network to create a traffic path. The AnswerCall does not reassert the information in system variable SV542, so you should ensure that the previous information is saved, as SV542 may be cleared or reset.

Parameters

No parameters are required.

Possible results

AnswerCall can have one of the following results:

Succeeded
The call has been answered.

For ISDN the network has connected the call end-to-end.

Not Ringing
The line was not ringing or cannot be answered for some other reason.

For ISDN the call is not connected end-to-end, either because it was not ringing or could not be answered for any reason.

Cause Code: Any.

ASCII syntax

When using an ASCII editor, code this action as the example demonstrates:

label: "Check Edges"
	AnswerCall()
	  edge EDGE_AC_COMPLETED: 		  completed
	  edge EDGE_AC_NOT_RINGING:		 not_ringing
	;

The edges are described above under "Possible results". For more information, see Testing a state table using the debugger.

Parent topic: Alphabetical list of state table actions