Building
Communicating with Both SIUA and SIUB
The user application exchanges information with the SIU via API messages (MSG). In a dual SIU environment, each time the user application sends a message to the SIU, this should be directed to either SIUA or SIUB using a library function GCT_set_instance. In the receive direction, the application can determine the SIU that sent a MSG using the library function GCT_get_instance. Function definitions may be found in the header
file sysgct.h.
GCT_set_instance
int GCT_set_instance(unsigned int
instance, HDR *h);
This function sets the destination instance number (SIU identity or siu_id) prior to sending a message and returns 0 on success,
GCT_get_instance
unsigned int GCT_get_instance(HDR *h);
This function returns the instance number (SIU identity or siu_id) after receiving a message. The parameter h is a pointer to the HDR structure at the start of the received MSG. The returned value will be either 0 or 1. SIUA is instance 0 and SIUB is instance 1, as assigned by the siu_id parameter provided to the rsicmd utility.
Transferring Control of a Circuit Group between SIUs
Activating and Deactivating Circuit Groups
Configuration commands for all circuit groups must be present on both SIUs. At run time, the application running on each host should select which SIU is currently in con- trol of each group by “activating” and “deactivating” groups on a particular SIU.
Circuit groups are activated and deactivated using the API_MSG_COMMAND message (type 0x7f0f), with a cmd_type of 8 to activate a group and a cmd_type of 9 to deactivate a group. The format of this message is detailed in the Intel NetStructure SIU520 Developer’s Manual. This message should be issued with a request for a response (an acknowledgement); this will be returned to the requesting application with a status value of zero (indicating “success”) or
System Initialization
When the system
When the communication between the host and the SIU is established, the RSI task on the host issues an RSI_MSG_LINK_STATUS API message with a status value set to 1 (link to SIU recovered) to a destination task conc_id on the host (conc_id is set when the RSI link was started). This message will only be received by the application if the RSI link is configured with the conc_id set to the application’s module ID.
The ID field of this message is set to 0 to indicate SIUA and 1 to indicate SIUB. When the link to the SIU that normally controls a circuit group (the primary SIU) becomes active, the application should issue an activate group command to that SIU, specifying that circuit group (using its group ID). The SIU processes API commands sequentially and the application must wait for an acknowledgement of this command before proceeding. An acknowledgement that indicates “busy” should cause the application to
The application should wait for a period of time sufficient to establish communication to the preferred SIU before deciding that the preferred unit is not available and activating circuit groups on the
Once the acknowledgement of the activation of a circuit group is received, the circuits should be reset to force the circuits into a known, idle state. This is achieved using the Circuit Group Status Control (CGSC) Request API message, detailed in the appropriate Programmer’s Manual. The circuit reset is acknowledged by the terminating exchange; this acknowledgement is passed to the user application as a circuit group status confirmation API message. On receipt of this, the application may commence using the associated circuits for calls.
Failure Detection
The event that triggers the application to transfer circuit groups from one SIU to another is loss of communication between the application and the SIU.
When the failure occurs, the RSI task on the affected host detects the loss of communication and issues an RSI_MSG_LINK_STATUS API message with a status value set to 2 (link to SIU lost) to a destination task
21
