6 Call Transfer-Related Services

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

ETS 300 user-side specifications (supported in the AG 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 (i.e. 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)

Q.SIG specifications describe the behavior of nodes in a network, and how they interact. AG 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 (i.e. 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 CT 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).

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

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:

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:

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

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:

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

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:

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

Figure 18: ECT Explicit Transfer, Error Returned

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:

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 	*/  
};

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:

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 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:

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:

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

Figure 19: Transfer Notification Service, ETS 300

To transfer a call under Q.SIG, the application must perform the switching required to connect calls together, using standard calls to the CT 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 (i.e. on separate PINXs), or whether one party is local (i.e., 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):

Note: Notification of both parties should take place back-to-back.

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 AG ISDN Messaging API Developer's Reference Manual.

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

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

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:

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 is a list of the fields in this structure (other than the header fields), and when they are used.

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.

Notify Transfer Return Result messages are generated if:

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:

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 (i.e. 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 is a list of the fields in this structure (other than the header fields), and when they are used.

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:

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

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

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