6.1 Introduction

6.1.1 Call Transfer Operations - ETS 300 Perspective

6.1.2 Call Transfer Operations - Q.SIG Perspective

6.2 Performing an Explicit Call Transfer (ETS 300 only)

6.2.1 Invoking ECT (ETS 300)

6.2.2 Transfer Notification (ETS 300)

6.3 Call Transfer (Q.SIG)

6.3.1 Invoking a Notify Transfer Operation (Q.SIG)

6.1 Introduction

This chapter describes call transfer operations under ETS 300 and Q.SIG.

6.1.1 Call Transfer Operations - ETS 300 Perspective

ETS 300 user-side specifications (supported in the NMS ISDN package) describe interactions between a user (an application) and the network from the user's point of view. In an ETS 300 configuration, the network performs the actual transfer operation (for example, connects the two remote parties together). At least one of the parties in the transfer must have the hold service invoked.

The application's role in a call transfer is simply to request the network to perform the transfer, using the Explicit Call Transfer supplementary service. Once the transfer is complete, affected connection IDs and B channels over the S/T reference point are cleared, so the local application is no longer involved in the call. (See Figure 16.)

Note: After the ECT service is invoked, there is no way for the user side to recover the call from the network.

When an Explicit Call Transfer succeeds, the network informs the remote parties of the transfer, using a Notify Transfer operation.

Note: The application is responsible for assuring the B and C parties which are joined are compatible. For example, both parties should be carrying the same type of service (data, voice, etc.).

Figure 16. Explicit Call Transfer (ETS 300)

6.1.2 Call Transfer Operations - Q.SIG Perspective

Q.SIG specifications describe the behavior of nodes in a network, and how they interact. NMS ISDN supports transfer-by-join operations between Q.SIG nodes. In a transfer-by-join operation, the two separate calls are connected through the local node, and the local node remains involved in the call (for example, 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 has taken place.

If both parties are remote, once the notification has taken place, the stack at the local node allows the two separate calls connected through the node to pass facilities information to each other without involving the local application. However, basic call control signaling for the two calls (such as call clearing) must still be managed by the application. In effect, the calls have been bridged (see Chapter 4).

6.2 Performing an Explicit Call Transfer (ETS 300 only)

To perform a call transfer, an ETS 300 application invokes the Explicit Call Transfer (ECT) supplementary service. This service allows an application serving two calls, one of which is in the auxiliary HELD state, to request the network to join the two remote calls together and drop the local connection. (See Figure 16.)

6.2.1 Invoking ECT (ETS 300)

For an Explicit Call Transfer service invocation to work, one of the remote calls must be in the auxiliary HELD state (described in Chapter 5). The other can be in an active or alerting state. (See Figure 16.)

To invoke the service, the application sends an acu_ss_transfer_invoke extended data structure to the stack, in an ACU request message. The service header to this structure must contain:

• Operation ID ACU_OP_ID_TRANSFER

• OpType ACU_OP_TYPE_INVOKE

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

struct acu_ss_transfer_invoke
{
 struct acu_ext_hdr   ext_hdr;          /* Extension header               */
 struct acu_ss_hdr    ss_hdr;           /* Supp. services header          */
 struct acu_party_num redir_nb;         /* Number to direct call to       */
 struct acu_conn_id   related_conn;     /* Reference to held connection   */
 struct acu_ss_association charge_association;/* Optional, used when      */
                                        /* AOC-E service has been invoked */
 ushort               call_status;      /* From ACU_SS_CALL_STATUS_...    */
 pad6                                   /* constants                      */
};

The following is a list of the fields in this structure (other than the header fields). The table also indicates which fields the application must fill in this request:

Field	Description	Must be filled in this request?
redir_nb	Number to direct call to	Reserved
related_conn	Reference to "c" connection	Yes
charge_association	Charge identifier, used when AOC-E service has been invoked. (See Section 8.3.4 .)	Optional
call_status	Status of other leg. From SS_CALL_STATUS constants	Yes

When the network receives the transfer invocation message, it attempts the call transfer.

Successful Transfer (ETS 300)

If the network successfully transfers the call, the network responds by initiating call clearing of the two legs of the local connection (see Figure 17). An acu_ss_transfer_ret_result extended data structure is returned in an ACU indication message. The service header to this structure contains:

• Operation ID ACU_OP_ID_TRANSFER

• OpType ACU_OP_TYPE_RETRES

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

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

No additional data is returned in this structure.

Figure 17. ECT Explicit Transfer, Success

Unsuccessful Transfer (ETS 300)

If the network does not transfer the call successfully, an acu_ss_transfer_ret_err extended data structure is returned in an ACU indication message. The service header to this structure contains:

• Operation ID ACU_OP_ID_TRANSFER

• OpType ACU_OP_TYPE_RETERR (See Figure 18.)

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

struct acu_ss_transfer_ret_err
{ 
  struct acu_ext_hdr ext_hdr; /* Extension header                   */
  struct acu_ss_hdr  ss_hdr;  /* Supp. services header              */
  ushort             err_id;  /* From TRANSFER_RETERR_... constants */
  pad6
};

The err_id field contains the reason for the error, from the TRANSFER_RETERR constants listed in Appendix B.

Figure 18. ECT Explicit Transfer, Error Returned

6.2.2 Transfer Notification (ETS 300)

If a call transfer succeeds, the network also uses a Notify Transfer operation to notify the remote parties of the transfer.

The remote parties each receive an ACU indication message, containing an acu_ss_notify_transfer_invoke extended data structure. The service header to this structure contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_INVOKE (See Figure 19.)

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

struct acu_ss_notify_transfer_invoke
{
  struct acu_ext_hdr     ext_hdr;        /* Extension header             */
  struct acu_ss_hdr      ss_hdr;         /* Supp. services header        */
  struct acu_party_name  redir_name;     /* Name of new connected party  */
  struct acu_ss_association   charge_id; /* For AOC-E Interworking, Q.SIG*/
                                         /* only                         */
  struct acu_party_num   redir_nb;       /* Indicates no. of joined party*/
  struct acu_conn_id     joined_conn_id; /* Applies in APPL->CC direction*/
  struct acu_party_subaddress redir_sub; /* Subaddress of joined party   */
  ushort                 response_rq;    /* If ON, app must respond      */
  uchar                  call_status;    /* From ACU_SS_CALL_STATUS...   */
                                         /* constants                    */
  uchar                  end_designation;/* Primary/Secondary, for Q.SIG */
  pad4                                   /* only                         */
};

The following table lists of the fields in this structure (other than the header fields) and indicates which fields will be filled in this message:

Field	Description	Will be filled in this response?
redir_name	Indicates supplementary service is invoked, and remaining name fields are valid, for Q.SIG only.	Not included
charge_id	Charge identifier, used when AOC-E service has been invoked. (See Section 8.3.4.)	Not included
redir_nb	Indicates number of joined party.	Optional
joined_conn_id	Connection ID for joined party. Can be left out of request message if only one party is on the network (for example, the other is local).	Not included
redir_sub	Subaddress of joined party.	Optional
response_rq	ON/OFF. If ON, then application requested to respond.	Yes
call_status	Joined user alerting or answered. From SS_CALL_STATUS constants.	Yes
end_designation	Primary/secondary, for Q.SIG only. From SS_END_DESIGNATION constants.	Not included

Successful Transfer Notification (ETS 300)

If the Notify Transfer invocation operation is successful, the user B or user C application sends an acu_ss_notify_transfer_ret_result extended data structure in an ACU request or response message. The structure's service header contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_RETRES

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

struct acu_ss_notify_transfer_ret_result
{
  struct acu_ext_hdr     ext_hdr;       /* Extension header             */
  struct acu_ss_hdr      ss_hdr;        /* Supp. services header        */
  struct acu_party_name  redir_name;    /* Provides name of redirecting */
                                        /* party                        */
  struct acu_party_num   redir_nb;      /* Provides no. of redirecting  */
                                        /* party                        */
  struct acu_party_subaddress redir_sub;/* Provides subaddress of       */
};                                      /* redirecting party            */

The following table lists the fields in this structure (other than the header fields) and indicates which fields the application must fill in this request:

Field	Description	Must be filled in this request?
redir_name	Indicates supplementary service is invoked, and remaining name fields are valid, for Q.SIG only	Yes
redir_nb	Indicates number of joined party	Not included
redir_sub	Indicates subaddress of joined party. If response_rq is on in the invocation request, the application should send this information back.	Not included

Unsuccessful Transfer Notification (ETS 300)

If the Notify Transfer operation invocation is unsuccessful, an acu_ss_reject extended data structure is returned in an ACU confirmation or indication message, indicating that the invocation request has been rejected. The service header to this structure contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_REJECT

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

Figure 19. Transfer Notification Service, ETS 300

6.3 Call Transfer (Q.SIG)

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 has taken place.

The procedure for performing a transfer differs slightly depending upon whether the parties to be connected together are both remote (for example, on separate PINXs), or whether one party is local (for example, on the same PINX as the served user) and the others remote. (See Figure 20.)

Figure 20. Local-Local vs. Local-Remote Configurations

If both parties are remote (see Figure 21):

1. One party must be in a HELD auxiliary state. The other party must be in Active or Alerting state.

2. The local application notifies both parties, by invoking a Notify Transfer operation for both of them. In each message, the application includes the connection ID of the other party, and the status of the party (for example, Active or Alerting).
   In each case, the local stack responds with a Notify Transfer Return Result message, indicating that the Notify Transfer operation was successfully processed.
   Note: Notification of both parties should take place back-to-back.
3. When both parties are in the Answered state, the application performs the switching required to connect calls together, using standard calls to the Natural Access Switching service.
   If one of the parties was in the Alerting state when the Notify Transfer operation was invoked, and since then has entered the Answered state, the local stack automatically notifies the other party of the state change by invoking a Notify Transfer operation.

Once the Notify Transfer operation has been invoked for both remote parties, any facilities information pertaining to the transfer which is exchanged between the two remaining parties is automatically forwarded. In effect, the calls are bridged (see Chapter 4).

The application is responsible for assuring that the B and C parties which are joined are compatible. For example, both parties should be carrying the same type of service (data, voice, etc.).

Note: In order for the call bridging to be successful, 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.

If one party is remote and one is local (see Figure 22):

1. One party must be in Active or Alerting state.

2. The local application notifies the remote party, by invoking a Notify Transfer operation. In the message, the application includes the status of the local party to be transferred (for example, Active or Alerting).
   The local stack responds with a Notify Transfer Return Result message, indicating that the Notify Transfer operation was successfully processed.

3. When both parties are in the Answered state, the application performs the switching required to connect calls together, using standard calls to the Natural Access Switching service.
   If the local party was in the Alerting state when the Notify Transfer operation was invoked, and since then has entered the Answered state, the local stack automatically notifies the remote party of the state change by invoking a Notify Transfer operation.

In this case, no bridging takes place; the application is responsible for routing all message traffic between the involved parties. The application is also responsible for assuring that the B and C parties which are joined are compatible. For example, both parties should be carrying the same type of service (data, voice, etc.).

6.3.1 Invoking a Notify Transfer Operation (Q.SIG)

To invoke a Notify Transfer operation, the application sends an acu_ss_notify_transfer_invoke extended data structure to the stack, in an ACU request message. The service header to this structure contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_INVOKE

The connection IDs specified are those of the active calls.

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

struct acu_ss_notify_transfer_invoke
{
  struct acu_ext_hdr    ext_hdr;         /* Extension header             */
  struct acu_ss_hdr     ss_hdr;          /* Supp. services header        */
  struct acu_party_name redir_name;      /* Name of new connected party  */
  struct acu_ss_association charge_id;   /* For AOC-E Interworking, Q.SIG*/
                                         /* only                         */
  struct acu_party_num  redir_nb;        /* Indicates no. of joined party*/
  struct acu_conn_id    joined_conn_id;  /* Applies in APPL->CC          */
                                         /* direction                    */
  struct acu_party_subaddress redir_sub  /* Subaddress of joined party   */
  ushort                response_rq;     /* If ON, app must respond      */
  uchar                 call_status;     /* From ACU_SS_CALL_STATUS...   */
                                         /* constants                    */
  uchar                 end_designation; /* Primary/Secondary, Q.SIG only*/
  uchar                 update;          /* If ON, provides additional   */
  pad3                                   /* info for last transfer       */
};

The following table lists the fields in this structure (other than the header fields) and when they are used.

Field	Description	Must be filled in message sent from PINX serving user A?	Will be filled in messages received by PINXs serving users B and C?
redir_name	Indicates supplementary service is invoked, and remaining name fields are valid, for Q.SIG only	Optional	Not included
charge_id	Charge identifier, used when AOC-E service has been invoked. (See Section 8.3.4 .)	Reserved	Reserved
redir_nb	Indicates number of joined party. Note that either this field, or joined_conn_id, or redir_sub must be specified in request messages.	Yes	Optional
joined_conn_id	Connection ID for joined party. Must be specified in first invocation of Notify Transfer for a remote party. Exception: can be left out of request message if only one party is on the network (for example, the other is local). Note that either this field, or redir_nb, or redir_sub must be specified in subsequent request messages.	Optional	Not included
redir_sub	Subaddress of joined party. Note that either this field, or redir_nb, or joined_conn_id must be specified in request messages.	Optional	Optional
response_rq	ON/OFF. If ON, then application requested to respond.	Not included	Yes
call_status	Joined user alerting or answered. From SS_CALL_STATUS constants.	Yes	Yes
end_designation	Primary/secondary, for Q.SIG only. From SS_END_DESIGNATION constants.	Yes	Yes
update	If ON, indicates this structure contains updated information not included in previous acu_ss_notify_transfer_invoke structure.	Optional	Optional

If both transfer parties are remote, in the first Notify Transfer message to each remote party, the joined_conn_id field must be used to specify the connection ID of the call to be connected to it. If one party is remote and one party is local, the call to be connected is implicitly specified, and the joined_conn_id field can be left out.

The update field is used to specify whether a Notify Transfer message indicates a new transfer operation, or contains information about a currently ongoing transfer operation. For example, when the application first notifies a remote party of an impending transfer, the update field is set to OFF. When the application notifies the same party of a state change, the update field is set to ON to indicate that information in the message pertains to the currently ongoing operation.

Successful Transfer Notification (Q.SIG)

Notify Transfer Return Result messages are generated if:

• A Notify Transfer operation was successfully processed. In this case, the RETRES arrives at the application from the local stack. All fields in the data structure are unpopulated. Note that receipt of this message does not necessarily indicate that the calls are connected, or that bridging has taken place (if both parties are remote).

• A remote party has successfully processed a Notify Transfer operation. Note that if both connected parties are on the network (for example, neither is local) the remote parties are bridged at the originating user's stack. This means that each remote party's RetRes message is passed to the other party in the form of an INVOKE, as shown in Figure 21.

Notify Transfer Return Result messages include an acu_ss_notify_transfer_ret_result extended data structure in an ACU confirmation or indication message. The service header to this structure contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_RETRES

Other information (such as subaddress information, etc.) is added by the originating user's stack. The local application plays no part in this messaging.

In cases where the transfer involves only one party on the network (for example, the other is local), and the joined_conn_id field can be left out of the acu_ss_notify_transfer_invoke supplementary service structure. In this case, the application may receive one or more Notify Transfer RetRes messages.

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

struct acu_ss_notify_transfer_ret_result
{
  struct acu_ext_hdr    ext_hdr;         /* Extension header            */
  struct acu_ss_hdr     ss_hdr;          /* Supp. services header       */
  struct acu_party_name redir_name;      /* Provides name of redirecting*/
                                         /* party                       */
  struct acu_party_num  redir_nb;        /* Provides no. of redirecting */
                                         /* party                       */
  struct acu_party_subaddress redir_sub; /* Provides subaddress of      */
};                                       /* redirecting party           */

The following table lists the fields in this structure (other than the header fields) and when they are used.

Field	Description	Must be filled in messages sent from PINXs serving user B or C?	Will be filled in messages arriving at PINX serving user A?
redir_name	Indicates supplementary service is invoked, and remaining name fields are valid, for Q.SIG only	Optional	Not included
redir_nb	Indicates number of joined party	Optional	Optional
redir_sub	Indicates subaddress of joined party. If response_rq is on in the invocation request, the application should send this information back.	Optional	Optional

Unsuccessful Transfer Notification (Q.SIG)

If a Notify Transfer invocation operation is unsuccessful, an acu_ss_reject extended data structure is returned in an ACU confirmation or indication message. The service header to this structure contains:

• Operation ID ACU_OP_ID_NOTIFY_TRANSFER

• OpType ACU_OP_TYPE_REJECT

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

Figure 21. Notify Transfer (Q.SIG) - Both Parties Are Remote

Figure 22. Notify Transfer (Q.SIG) - One Party is Local, the Other is Remote