A TCAP message consists of a transaction portion and a component portion. If the transaction portion is invalid, it causes a P-Abort or it is ignored. A P-Abort indication terminates the transaction. An ignored, invalid message does not terminate the transaction. If a TCAP message has an invalid component, a reject component is generated, but the transaction generally is not closed.
The following abnormal condition scenarios are presented:
A TCAP transaction can be received that has an invalid transaction portion. The transaction portion contains the transaction type of begin (ITU-T) or query (ANSI) and any required transaction IDs (TIDs). If an error is detected and a valid transaction ID can be found:
A P-Abort is returned to the sender.
A P-Abort indication is delivered to the receiver.
The transaction is closed.
However, if the TCAP stack cannot find a valid transaction ID, it ignores the message. No response is returned to the sender and no indication is sent to the receiver. As the message is ignored, any transaction that was open remains open.
The following illustration shows a transaction where an ITU-T TCAP message is received that does not have a valid message type of begin, continue, or end. The message does have a valid originating transaction ID. The TCAP stack recognizes the invalid message and sends a P-Abort to the sender. Also, a P-Abort indication is delivered to the receiving application.
Inactivity timeouts can optionally be specified for TCAP transactions. If a specified period of time elapses with no traffic, an inactivity timeout indication (TCAP_XACTION_TIMEOUT) is sent to the TCAP application. The TCAP application can then:
Close the transaction through an end, response, or abort message.
Leave the transaction open with TCAPRetainTrans.
Do nothing and allow the transaction to expire.
TCAPRetainTrans resets the inactivity timer for that transaction. If the inactivity timer expires again and no traffic has occurred, another inactivity timeout indication is sent to the application.
If the application does nothing, and no further traffic occurs for the transaction, the inactivity timer expires a second time, and a P-Abort closes the transaction. The P-Abort indication is sent to the TCAP application, and if traffic has been received, a P-Abort message is sent to the destination.
A default inactivity timer value (INACTIVITY_TIMEOUT) can be specified in each SAP section of the TCAP configuration file. If INACTIVITY_TIMEOUT is set to zero, inactivity timers are not set for any transactions. If INACTIVITY_TIMEOUT is set to a non-zero value, inactivity timers are set to the specified number (in seconds) for every transaction.
A TCAP application can override the default inactivity timer value by setting the inactvTimer field in the TCAPTransInfo structure. If set to zero, the transaction uses the default inactivity timer. If greater than zero, an inactivity timer is set to that number of seconds for that transaction.
Once a transaction has been opened, the inactivity timer value can be modified by sending a Conversation or Continue with a non-zero value in the inactvTimer field in the TcapTransInfo structure. The TcapRetainTrans call can also be used to modify the inactivity timer value.
If the inactivity timer is not used, the application must ensure that transactions are closed. If transactions are not closed, the TCAP task eventually runs out of transaction contexts and fails.
A transaction is closed if one of the following conditions occur:
P-Abort indication is received.
User abort message is sent or received.
End (ITU-T) or Response (ANSI) message is sent or received.
If none of these conditions occur, the application must ensure that the transaction is eventually closed.
If the TCAP stack receives a begin (ITU_T) or query (ANSI) message with an invalid component, it passes a reject component to the receiving application, but does not automatically send the reject component to the sender. This occurs because the stack is unsure whether to end the transaction, as another component in the message can be valid. In this case, the application must send a continue or an end with no components. The TCAP stack attaches the reject component and sends it to the original sender.
An example of an invalid component is if a return result or return error component is received with an invoke ID that does not correspond to an outstanding invoke component. In this case, a reject component is returned to the sender with the invoke ID it was sent with. If the TCAP stack receives a component with an invalid or missing invoke ID, a reject component is returned to the sender with an invoke ID tag of ASN.1 Universal NULL (0x05). The invoke ID length is set to zero.
In the following illustration, an invalid invoke component is received. The TCAP stack recognizes the error and passes a reject component to the receiving application. Since the reject component is contained in a begin message, the receiving application sends an end message with no components. The TCAP stack attaches the reject component (it has saved the component) and sends it to the original sender. The transaction is now closed.
If the TCAP stack receives a continue (ITU-T) or conversation (ANSI) message with a bad component, it automatically sends a continue or conversation with the reject component back to the sender, and sends the reject component to the receiving application. In this case, the application does not need to send a response.
In the following illustration, after sending an invoke component, a continue message with an invalid linked invoke component is received. The TCAP stack automatically sends a continue message with a reject component back to the sender.
In addition, a continue message with a reject component is passed to the receiving application. The transaction is still open and can continue or be closed.
As shown in the following illustration, if the TCAP stack receives an end (ITU-T) or response (ANSI) message with a bad component, it sends the reject up to the receiving application, but nothing back to the sender, as the sender has already closed the transaction. The application does not need to send any response.
Generally, an invoke component is not allowed in an end message. However, invoke components are allowed by setting the ALLOW_INVOKE_END field in the USER_SAP section of the TCAP configuration file. Refer to the NMS SS7 Configuration Manual for information.
As shown in the following illustration, only the ITU-T protocol implements invoke time-outs. If an application sends an invoke component, and does not receive a return result last, return error, or a reject with the same invoke ID within a configured time, the invoke times-out. A message type of TCAP_LOC_IND is returned with a TCAP_CANCEL component. The application closes the transaction by an end (ITU-T) or a user abort.
A TCAP message can contain multiple components. As soon as an invalid component is detected by the TCAP stack, any valid components are indicated to the receiving application along with the rejected component. Any components detected after the rejected component are ignored.
For example, if a TCAP message is received with three components, and the second component is invalid, the first valid component and the second rejected component are indicated to the receiving application. The third valid component is ignored and not indicated to the receiving application.