# Supplementary services under Q.SIG

This section provides an overview of the supplementary services available with the Q.SIG variant and how these services are implemented in the network architecture. It describes:

- The Q.SIG variant

- Using supplementary services

- Tandem services

- Transfer services

- Call forwarding services

- Call identification services

## Q.SIG variant

Q.SIG specifications describe interactions between nodes in a private ISDN network (PISN). Each node is a private ISDN network exchange (PINX). These nodes play identical roles in the network. Q.SIG is a symmetric protocol because there is no distinct user side and network side.

The following illustration shows a sample Q.SIG network and the reference points where an NMS ISDN Q.SIG supplementary service application can join the network. As shown in the illustration, an NMS ISDN application written for this variant interfaces with the network at the Q reference point. The role of the application is to implement call control, and to control message exchanges at the reference point.

Network illustration showing position of Q.SIG application

The following illustration shows the part of an NMS ISDN application that is the Q reference point.

Note: Application code related to local access (such as analog lines) is not considered part of the Q reference point.

Q reference point

Supplementary services over the Q reference point are generally requests sent by the application for services from another node in the network, or notifications that the local node performed various services.

Note: If you are building a Q.SIG application, the PINX node address must be specified in your initial call to isdnStartProtocol. For more information, see Specifying the Q.SIG node address.

## Using supplementary services

Q.SIG applications provide supplementary services as part of their basic duties: the subscription concept has no meaning at this level. All supported services are activated at all times. A Q.SIG application only needs to invoke a service to use it.

## Tandem services

Tandem services support the transit node role. A transit node is an intermediate step in a call being set up through a network. A PINX may take on the responsibilities of a transit node during the call setup procedures as a result of routing decisions, or it may happen as a result of supplementary service activation (such as call transfer). A transit node must maintain two separate basic calls, and combine the events from one call with actions on the other call.

NMS ISDN supports the call bridging tandem service. When this service is active, all notification and facility information elements are passed from one end to the other through the transit node. However, the application remains responsible for basic call control interaction. For example, the application must handle hanging up.

The call bridging service can be invoked in either of the following two ways:

- Explicitly, using the invoke bridge calls operation.

- Implicitly when the notify transfer operation is called, and both transfer parties are remote. Implicit call bridging does not take place if one or both calls are local.

## Transfer services

NMS ISDN supports transfer-by-join operations between Q.SIG nodes. In a transfer-by-join operation, two separate calls are connected through the local node. The local node is still involved in the call (the call is not rerouted).

To transfer a call under Q.SIG, the application must perform the switching required to connect calls together, using standard calls to the Natural Access Switching service. The application also invokes a notify transfer operation to notify each remote party that the transfer took place.

## Call forwarding services

Under Q.SIG, call diversion supports:

- Call forwarding - unconditional

- Call forwarding - busy

- Call forwarding - no response

The following call diversion operations are supported under Q.SIG:

Operation | Usage
--- | ---
Invoke call diversion | The served user node sends a request to the originating node to forward a call.
Notify diversion | The originating node notifies the diverted-to node that the call has been forwarded.

## Call identification services

All of the call identification services for the ETS 300 variant are also implemented for Q.SIG. In addition, the following Q.SIG-only identification services are implemented in NMS ISDN:

Service | Usage
--- | ---
Calling name identification presentation (CNIP) | The called party receives the name of the calling party. Available only under the Q.SIG variant.
Connected name identification presentation (CONP) | The calling party receives the name of the called party. Available only under the Q.SIG variant.