ISUP:General guidelines for designing an efficient call control application using ISUP

As described in the section on host application requirements, a call control application must be designed as a state machine that can be applied to every individual call. Although multi-threading is preferable, it is not required as long as there is no synchronous operation during the processing of a call event. The easiest way to achieve this is to create a dynamic structure (call context) containing a call’s useful information and state.

Upon the reception of an event associated to a call (by the “circuit ID” handle), the application retrieves the call context, processes the new event, sends appropriate requests toward the Tmedia device, updates the information/state of the call context and waits for another event from the device. Usually, a call control state machine also has to deal with timers (i.e., timeout events) to cover for call failure cases (e.g., end-user not responding, retries, etc). The main state-machine thread can offload this task to a timeout service (e.g., another thread) responsible to generate timeout events to the main thread in case a specific timer, associated with a specific call, expires. Thus, timeout events are processed as any other events coming from the TB640. The state machine should be implemented to react as specified by the call flows shown in section 6.3.4 of the *TelcoBridges SS7 User's Guide (print version). A more detailed description of the SS7 ISUP state machine implementation can be found along in the SS7 sample directory of the TB640 package.

1. One thread should be responsible to process all ISUP and timeout events for every calls associated with the controlled TB640.
2. This thread should configure a TBX host library filter to receive only the ISUP events of the targeted TB640.
3. Once an event is received, the process should retrieve the call context associated with the circuit ID (or create it in the case of a new call) and process the events
4. If, during the processing of the event, a synchronous operation is required to continue (i.e. reading information from a remote database), post the request to the database, make the call to enter a ‘waiting for DB’ state and return the call context into the waiting queue. In this case, database events should be able to wakeup the thread as well as TB640 events or timeouts. This way, the main thread will be processing other calls while waiting for information from the database. When the answer from the database will arrive, the thread will re-fetch the call context and continue the processing where it had left off. The developer must remember that an SS7 call can live from a couple of seconds to hours depending on numerous factors. Thus, the latency of SS7 events related the same calls is not as important as the total capacity of event processing of the thread to achieve high performance system.

Another important aspect of an efficient system is related to flow control. The host application must have the capacity to slow down its rate of calls when the ISUP layer informs it of a potential congestion of the network as described in ISUP:Flow control. This is usually achieved by performing back-pressure on the input of the system. Some applications totally control the input into the system because they are the call generators. However, the input normally comes from an external source (such as another system calling into this one). In this last case, the rate of input calls can be reduced by refusing calls with the proper cause value (i.e., “call rejected”, “destination out-of-order”, “No circuit/channel available”, “network out-of-order”, “switching equipment congestion”, etc.) as defined in specification Q.850.