Transactions

The services that use TCAP vary in complexity. Some require a node to translate and receive only a single message. For example, a basic toll-free call typically works in this manner. Other services, such as Call Completion to a Busy Subscriber (CCBS), can exchange a number of messages between nodes.

A transaction is a set of related messages that are exchanged between application processes at two different nodes. At any time, a node can have many simultaneous transactions in progress and send and receive multiple TCAP messages. For example, several subscribers might invoke a CCBS during the same period of time.

When a node sends a message and expects a reply, the sending node establishes and maintains a Transaction ID. This allows an incoming message to be properly associated with previously sent messages.

Transaction IDs

Transactions always begin with an initiating TCAP message that contains an Originating Transaction ID. When the service has completed, the Transaction ID becomes available for use again by the application. Each transaction must have a unique Transaction ID for all outstanding transactions. When an ID is in use, it cannot be used again until the current transaction releases it. If the same ID belonged to two transactions, the system that received a message would not know the transaction to which it belonged. The ANSI Transaction ID is 4 octets in length, thereby allowing a total number of 2³² concurrent transactions to exist at a given time. The ITU Transaction ID is variable from 1 to 4 octets. Up to two Transaction IDs can be included in a TCAP message, an Originating Transaction ID, and a Responding Transaction ID (called a Destination Transaction ID in ITU). ANSI packages the Transaction IDs differently than ITU by nesting both IDs within a single Transaction ID Identifier. The following figure shows the Transaction ID section.

Establishing Transaction IDs

The node that originates the transaction assigns an Originating Transaction ID, which the node sends to the destination in the first message, to establish the transaction. When the destination node receives a message, the application examines its contents and determines whether it should establish its own transaction.

When the destination node responds to the originating node, the message that is sent contains a Responding (or Destination) Transaction ID. The Responding Transaction ID is the same as the Originating Transaction ID that was received in the Begin/Query message. It can be thought of as a reflection of the Originating ID. The destination node examines the contents of the message to determine if it should establish a transaction with the originating node. If establishing a transaction is necessary, an Originating Transaction ID is assigned by the responding destination node and placed in an ANSI Conversation or ITU Continue message along with the Responding Transaction ID to be sent back to the transaction originator. In this situation, each node establishes a transaction from its own point of view. Depending on the message type, a TCAP message can contain zero, one, or two Transaction IDs. Tables 10-3 and 10-4 show the relationship between a message type and Transaction IDs for ITU and ANSI, respectively. For example, in Table 10-3, a Unidirectional message does not contain any Transaction IDs, while a Continue message contains two Transaction IDs.

Table 10-3. ITU Message Transaction IDs

ITU Message Type	Originating Transaction ID	Destination Transaction ID
Unidirectional	No	No
Begin	Yes	No
End	No	Yes
Continue	Yes	Yes
Abort	No	Yes

Table 10-4. ANSI Message Transaction IDs

ANSI Package Type	Originating Transaction ID	Responding Transaction ID
Unidirectional	No	No
Query with Permission	Yes	No
Query without Permission	Yes	No
Response	No	Yes
Conversation with Permission	Yes	Yes
Conversation without Permission	Yes	Yes
Abort	No	Yes

Releasing Transaction IDs

The communicating applications can end transactions in one of two ways: either with a terminating message or a prearranged end. The most common method is a terminating message—a Response package in ANSI and an End message in ITU. The prearranged transaction end is simply an agreement at the application layer that a transaction ends at a given point. Releasing the Transaction ID returns it to the available pool of IDs so that another transaction can use it.

Transaction Message Sequence

Applications do not always establish a transaction during TCAP communications. The Unidirectional message is used to communicate when no reply is expected, therefore, requiring no Transaction ID. All other messages require a Transaction ID.

Figure 10-6 shows an example of a transaction occurring between two SS7 nodes. A conversation is established between Node A and Node B. As mentioned previously, a Query or Begin message always initiates a transaction. Node A establishes a transaction with a Transaction ID of 0. When the service logic at Node B processes the incoming message, it determines that it is necessary to establish a transaction from its own point of view. This is usually done to request additional information from the node that sent the message. In this example using the ANSI protocol, node B does not have a choice about engaging in a conversation because it has received a "Query without Permission" message. The message's "without Permission" designation is used to deny the receiving node the opportunity to end the transaction until it receives permission. In this example, Node B initiates a transaction with a Transaction ID of 1, thereby associating it with the received Transaction ID of 0.

Figure 10-7 shows the same transaction using the ITU protocol. As shown by comparing the two examples, the two protocols are conceptually quite similar. Other than naming conventions and binary encoding, the primary difference is that the ITU message types do not explicitly state whether the receiving node must engage in a transaction from its perspective. This must be determined from the application logic.