Table of Contents Index NMS Glossary Previous Page Next Page Version


Chapter 4

Tandem Services


4.1 Introduction
4.2 The Bridge Calls Supplementary Service
4.2.1 Explicitly Invoking the Service

4.1 IntroductionTop of Page

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.)


chap40.gif

Figure 8. Transit Node


Tandem services supported by AG ISDN are:

4.2 The Bridge Calls Supplementary ServiceTop of Page

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.


chap42.gif

Figure 9. Call Bridging

4.2.1 Explicitly Invoking the ServiceTop of Page

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:

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 AG 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 6.1.2).

Successful Bridge Calls InvocationTop of Page

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:

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 InvocationTop of Page

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

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

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


chap41.gif

Figure 10. Bridge Calls Service



Table of Contents Index NMS Glossary Previous Page Next Page Version


Want to send us feedback on our documentation? Email: Tech_Pubs@nmss.com
Copyright © 2000, Natural MicroSystems, Inc. All rights reserved.