3.1 Introduction

3.2 The Bridge Calls Supplementary Service

3.2.1 Explicitly Invoking the Service

3.1 Introduction

This chapter describes tandem supplementary services. These services allow a Q.SIG application to support a transit node. A transit node is a node that exists between two other nodes, and routes messages from one node to the other. (See Figure 8.)

Figure 8. Transit Node

The Tandem service supported by NMS ISDN is the Bridge Calls service. This service filters messages routed through the transit node between two served users, so the application at the transit node receives only basic call control messages (facilities and notification information is automatically forwarded).

3.2 The Bridge Calls Supplementary Service

The Bridge Calls service is invoked by an application once the local node has assumed the role of a transit node between two calls. After this service is invoked, the stack at the local node forwards facilities and notification information between the two legs of the network path, without involving the application. However, basic call control signaling for the two calls (such as call clearing) is still managed by the application on the local node (see Figure 9).

The Bridge Calls service is supported by the Q.SIG variant only.

Figure 9. Call Bridging

3.2.1 Explicitly Invoking the Service

To explicitly invoke this service, send an extended data structure to the stack in an ACU request message, invoking the Invoke Bridge Calls operation. The service header to this structure must contain:

• Operation ID ACU_OP_ID_BRIDGE_CALLS

• OpType ACU_OP_TYPE_INVOKE

As the connection ID, use the ID of one of the calls. Specify the connection ID of the other call in the bridge_to field in the acu_ss_bridge_calls_invoke supplementary service structure.

Note: In order for the Bridge Calls supplementary service to operate properly, the NS_IE_RELAY_BEHAVIOUR bit must be set to its default setting (in the ns_behavior substructure referenced in the call to isdnStartProtocol). For more information, see your NMS ISDN Messaging API Developer's Reference Manual.

The following is a listing of the acu_ss_bridge_calls_invoke extended data structure:

struct acu_ss_bridge_calls_invoke
{
  struct acu_ext_hdr ext_hdr;   /* Extension header                   */
  struct acu_ss_hdr  ss_hdr;    /* Supp. services header              */
  struct acu_conn_id bridge_to; /* Connection ID of call to bridge to */
};

The bridge_to field is mandatory in requests for this service.

Note: Only one invocation is required in order to cause both connections to be bridged together.

The Bridge Calls service can also be invoked implicitly, when the application performs a transfer-by-join operation (see Section 5.1.2).

Successful Bridge Calls Invocation

If the Bridge Calls invocation is successful, both remote parties receive an acu_ss_bridge_calls_ret_result extended data structure in an ACU confirmation or indication message, indicating that the calls have been bridged. The service header to this structure contains:

• Operation ID ACU_OP_ID_BRIDGE_CALLS

• OpType ACU_OP_TYPE_RETRES

No additional data is sent.

The following is a listing of the acu_ss_bridge_calls_ret_result extended data structure:

struct acu_ss_bridge_calls_ret_result
{
  struct acu_ext_hdr ext_hdr; /* Extension header      */
  struct acu_ss_hdr  ss_hdr;  /* Supp. services header */
};

Once the Bridge Calls service is invoked, it can not be disabled. When either of the calls is cleared, the service ends.

Unsuccessful Invocation

The Bridge Calls invocation operation is rejected in the following situations:

• Either of the connections is not Q.SIG. Bridging between the Q.SIG variant and other variants is not supported.

• The NAIs for the two involved connections are on different boards. Bridging between boards is not supported. In these cases, the application layer must provide the bridging function.

• One or both of the calls is already bridged.

• The connection ID specified in the bridge_to field is not found.

If the Bridge Calls invocation operation is rejected, an acu_ss_reject extended data structure is sent to the application. The service header contains:

• Operation ID ACU_OP_ID_BRIDGE_CALLS

• OpType ACU_OP_TYPE_REJECT

For more information about the acu_ss_reject data structure, see Section 2.9.

Figure 10. Bridge Calls Service