TCAP transactions

This topic provides the following information about TCAP transactions:

• ANSI and ITU-T transaction types

• TCAP components

• Message lengths and segmentation

• Multiple-threaded considerations

• Transaction checkpointing

ANSI transaction types

The TCAP layer supports the following ANSI transaction types (also called package types):

ITU-T transaction types

The TCAP layer supports the following ITU-T transaction types:

TCAP components

TCAP transactions are composed of components that are remote operation invocations, or invokes, and responses to invokes. Each TCAP message (begin, continue, end, query with permission, response, and so on) is composed of zero or more components. Each component can optionally have application-specific parameters associated with it. Component parameters are not interpreted by the TCAP layer but are passed on to the destination application.

The ANSI and ITU-T standards define a fairly compatible set of component types:

Each invoke component is identified by a unique invoke ID that was assigned by the application that originated the invoke. The invoke ID is returned in the response, and allows the originator to correlate the reply with the invoke operation to which it belongs.

A receiver of an invoke component can also generate a linked invoke in response to the original invoke received. An example of this is when collecting more information from the sending node before generating the response to the original invoke. The linked invoke carries its own unique invoke ID plus the invoke ID of the original invoke, called the correlation ID in ANSI or the linked ID in ITU-T. It allows the originating application to associate the linked invoke with its original invoke.

In ITU-T, an invoke operation is assigned by the application to one of four classes, numbered 1 through 4. The class designation specifies under what conditions a response is expected, and determines what a timeout implies about the success or failure of the operation.

Message lengths and segmentation

The maximum size of a TCAP transaction, including transaction part, component parts, and application parameters is approximately 254 bytes, possibly less if global titles are used in SCCP addresses.

If an application has transactions (invokes or responses) that exceed the maximum size, it must provide its own segmentation and reassembly, using either the last/not last designation for invokes (ANSI only) or responses, or some other application-specific solution.

Multiple-threaded considerations

In a multiple-threaded application, any thread can generate a transaction request when initiating a new transaction or when responding to a transaction initiated by a far SP. However, there should be a single receiver thread that receives all asynchronous events from the TCAP layer (new transaction invocations, transaction responses, and status indications) and routes them to the proper transaction thread based on the user dialog ID or other transaction information.

Consider, for example, an application that consisted of a main thread, which spawned a child transaction thread whenever it wanted to initiate a new transaction. The transaction thread would be responsible for initiating the transaction request, collecting the response, and taking the appropriate action. The application could have many simultaneous transactions, and transaction threads, active at any given time.

Multiple transaction threads could generate the transaction requests in any order. The requests would be processed by the TCAP layer in the order that they were received. If each transaction thread then called TCAPRetrieveMessage to retrieve the response to its transaction request, there would be no guarantee that the TCAP message returned by TCAPRetrieveMessage would be associated with the calling thread's transaction. The first thread to call TCAPRetrieveMessage when a message is pending would receive the first pending message, regardless of which transaction it was associated with. The incoming message could be a new transaction request from a far SP or a network status indication message.

Instead, the main thread itself or a separate child receiver thread should be the only caller of TCAPRetrieveMessage. It can then analyze each incoming event and route it to the proper child transaction thread or, in the case of a new incoming transaction, create a new child transaction thread to handle the incoming transaction request.

Note: In a multiple-threaded application similar to the one described here, call ctaInitialize from the parent thread before any of the other functions are called by any of the other threads.

Transaction checkpointing

If two TX boards are configured as a redundant pair, TCAP transaction checkpointing can be used. In this configuration, one board is designated as the primary and the other is designated as the backup. The TCAP task on the backup board is ready to take over the TCAP service if the primary board fails or is taken out of service.

To enable the backup TCAP task to take over the TCAP service, the primary and backup TX boards are connected by a private Ethernet connection. The primary TCAP task sends transaction information to the backup TCAP task, which is known as transaction checkpointing. If the primary board fails, or is taken out of service, the backup TCAP task has a complete list of open TCAP transactions so that it can properly handle TCAP traffic.

Transaction checkpointing is performed automatically, but can be controlled by the TCAP application. A default checkpointing behavior can be set in the TCAP configuration file for each service access point. The DEFAULT_CHECKPOINT field in the SAP section of the TCAP configuration file can be set to one of the following values:

A TCAP application can override the default checkpointing behavior for a single transaction by setting the chkpt field in the TCAPTransInfo structure to one of the following values:

A transaction can be checkpointed at any time during the transaction lifetime. For example, if a begin message is received and the transaction is not checkpointed (the default is set to CHKPT_SEND or CHKPT_NONE), the transaction can be checkpointed when the application sends a reply (continue) message by setting the chkpt field to TCAP_CHKPT. All further transaction information is checkpointed.