How different components use primitives

Channel processes

A channel process (CHP) is the Blueworx Voice Response process that interprets the state table. There is one channel process per call.

Requests and Confirms

The signaling process receives a request primitive from a channel process for each state table call action. The signaling process must return a suitable reply code when sending a confirm primitive. The channel process then converts the reply code and returns the result to the state table. For example, Figure 1 shows the primitives involved in successfully setting up an outgoing call. When the call setup is unsuccessful, another reply code, such as SL_REPLY_NO_LINES_AVAILABLE, is sent.

Indications

Indications are sent to the channel process via the signaling interface to report asynchronous events, such as incoming calls. The following indications can be sent by the signaling process:

SL_CALL_DISCONNECT_IND (for CCS protocols only)

Call is being cleared and is no longer connected end-to-end. This indicates that the far end (either the caller or network) has hung up.

SL_CALL_SETUP_IND

Arrival of an incoming call.

SL_CALL_TERMINATE_IND

Call has been cleared and the call reference is no longer valid.

Custom servers

Voice applications can use custom servers to implement functions not provided by the state table actions. These custom servers can send implementation-defined primitives to a signaling process (see SL_USER_REQ primitive and SL_USER_CNF primitive). The responses sent by a signaling process to a custom server should be the same as those sent to a channel process. The custom server must always process the confirm primitives sent by the signaling process. How the custom server interprets these replies is implementation-dependent.

System manager

The Blueworx Voice Response system manager monitors and controls the state of the Blueworx Voice Response system.

Requests and confirms

In response to requests from the user interface the system manager brings channels into and out of service. In a Signaling System Number 7 environment, the system manager sends requests to the signaling process to perform such actions as enabling or disabling channels. As in the case of channel processes, these requests are sent to the signaling process as request primitives from the signaling interface. The signaling process must perform the necessary actions to fulfil the request and respond with a suitable confirm indicating the result of the request.

Figure 1. Primitives used when system manager disables a channel

Table 1. Requests, confirms, and valid ReplyCode values used by the system manager

Requests Sent	Confirms Received	ReplyCode Values
SL_CHANNEL_DISABLE_REQ	SL_CHANNEL_DISABLE_CNF	SL_REPLY_SUCCESS
SL_CHANNEL_ENABLE_REQ	SL_CHANNEL_ENABLE_CNF	SL_REPLY_SUCCESS
SL_CHANNEL_QUIESCE_REQ	SL_CHANNEL_QUIESCE_CNF	SL_REPLY_SUCCESS
SL_TRUNK_RECONFIG_REQ	SL_TRUNK_RECONFIG_CNF	SL_REPLY_SUCCESS
SL_TRUNK_ALARM_REQ	SL_TRUNK_ALARM_CNF	SL_REPLY_SUCCESS
SL_TRUNK_DISABLE_REQ	SL_TRUNK_DISABLE_CNF	SL_REPLY_SUCCESS
SL_TRUNK_ENABLE_REQ	SL_TRUNK_ENABLE_CNF	SL_REPLY_SUCCESS
SL_TRUNK_QUIESCE_REQ	SL_TRUNK_QUIESCE_CNF	SL_REPLY_SUCCESS

Indications

The only indication primitives that can be sent to the system manager are:

• SL_TRUNK_DISABLE_IND, SL_TRUNK_ALARM_IND and
• SL_CHANNEL_ALARM_IND.

The trunk disable indication will stop Blueworx Voice Response from using the trunk, and indicates that a severe error has occurred. The user interface status for the appropriate trunk is set to DISABLED.

The trunk alarm indication sets or clears an alarm condition on a particular trunk and should be used when a temporarily abnormal condition occurs or clears on a previously enabled trunk. When setting the alarm condition the user interface status for the appropriate trunk is set to ALARM, and returns to idle when the alarm is cleared by the signaling process.