Message Types The TCAP message type (which is referred to as package type in ANSI) identifies the type of message being sent within the context of a transaction. Table 10-1 lists the seven package types for ANSI and Table 10-2 lists the five message types for ITU. Table 10-1. Package Types for ANSI ANSI Package Types Hex Value Description Unidirectional 11100001 Sent in one direction and expects no reply. Query with Permission 11100010 Initiates a transaction, giving the receiving node permission to end the transaction. Query without Permission 11100011 Initiates a transaction but does not allow the receiving node to end the transaction Response 11100100 Ends a transaction. Conversation with Permission 11100101 Continues a transaction, giving the receiving node permission to end the transaction. Conversation without Permission 11100110 Continues a transaction, but does not allow the receiving node to end the transaction. Abort 11110110 Sent to notify the destination node that an established transaction has been terminated without sending any further components that might be expected. Table 10-2. Message Types for ITU ITU Message Types Hex Value Description Unidirectional 01100001 Sent in one direction and expects no reply. Begin 01100010 Initiates a transaction. (Reserved) 01100011 Not used. End 01100100 Ends a transaction. Continue 01100101 Continues an established transaction. (Reserved) 01100110 Not used. Abort 01100111 Sent to notify the destination node that an established transaction has been terminated without sending any further components that might be expected. The message type also infers the stage of transaction processing. Figure 10-4 shows an example of an ITU conversation and an equivalent ANSI conversation. In ITU, a Begin message always starts a transaction, and an End message normally ends the transaction. (The "Transactions " section of this chapter discusses an exception to this rule.) The equivalent ANSI messages that begin and end transactions are Query (with or without permission) and Response, respectively. Conversation (ANSI) and Continue (ITU) messages indicate that further communication is required in an existing transaction. Figure 10-4. Examples of ITU and ANSI Message Flow < Day Day Up > < Day Day Up > 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 p rocesses 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. N OTE CCBS is a subscriber feature used for completing calls to a busy subscriber by monitoring the called party's line and completing a call attempt when the called p arty is free. TCAP messages are exchange d b etween the telephony switches of the calling and called parties to monitor the busy line and provide notification when it is free. The service is also popularly known as Automatic Callback. 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 32 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. Figure 10-5. Transaction ID Format E stablishin g 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 R eleasin g 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 p reviously, 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 N ode 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, N ode B initiates a transaction with a Transaction ID of 1, thereby associating it with the received Transaction ID of 0. Figure 10-6. Transaction Example Using ANSI Protocol 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. Figure 10-7. Transaction Example Using ITU Protocol . line and provide notification when it is free. The service is also popularly known as Automatic Callback. When a node sends a message and expects a reply, the sending node establishes and. 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 . 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