Error Handling As with any other protocol, errors can occur during TCAP communications. TCAP errors fall into three general categories: • Protocol Errors • Application Errors • End-user Errors P rotocol Errors Protocol Errors are the result of TCAP messages being incorrectly formed, containing illegal values, or being received when not expected. For example, receiving an unrecognized message type or component type would constitute a p rotocol error. Another example of an error would be receiving a responding Transaction ID for a nonexistent transaction. While the actual value of the ID might be within the acceptable range of values, the lack of a transaction with which to associate the response causes a protocol error. Errors at the Transaction Layer Protocol Errors that occur at the transaction sublayer are reported to the remote node by sending an Abort message type with a P-Abort cause—in other words, a Protocol Abort. The Abort message is sent only when a transaction must be closed and a Transaction ID can be derived from the message in which the error occurred. Figure 10-13 shows an Abort message being sent for an open transaction in which a protocol error is detected. Figure 10-13. Protocol Error Causes an Abort Because no Transaction ID is associated with a Unidirectional message, no Abort message would be sent if the message was received with an error. If a Query or Begin message is received and the Originating Transaction ID cannot be determined because of the message error, the message is simply discarded and an Abort message is not returned to the sender. If the Transaction ID can be determined, the Abort message is sent to report the error. Without the Transaction ID, there is no way for the sending node to handle the error because it cannot make an association with the appropriate transaction. Errors at the Component Layer Protocol errors at the component sublayer are reported using a Reject Component. The errored component's Component ID is reflected in the Reject Component. A number of different errors can be detected and reported. For example, a duplicate Invoke ID error indicates that an Invoke ID has been received for an operation that is already in progress. This results in an ambiguous reference because both operations have the same ID. Another type of error is a component that is simply coded with an incorrect value, such as an unrecognized component type. Refer to the TCAP specifications for a complete list of errors that can be detected and reported. A pplication Errors Application Errors are anomalies within the application procedure. An example is an unexpected component sequence, in which the received components do not match what the application procedures expect. Another example is a missing customer record error, which is an error that is used to indicate that a database lookup failed to find the requested information. The application is responsible for determining what actions to take when errors of this type are encountered. E nd-User Errors The End-User Error is similar to the Application Error in that it is an anomaly of the application procedure. However, as indicated by the name, the anomaly is the result of some variance from the normal actions by the user. The user might take an action, such as abandoning the call prematurely, as shown in Figure 10-14 ; or the user might enter an unexpected response when connected to a digit collection unit and prompted for input, thereby causing the error. Figure 10-14. Error Caused by User Action H andlin g Application and End-User Errors Both the Application Error and the End-User Error are reported using the Return Error component for component-related errors. Because the errors in these two categories are actually variations in the application's script or procedure flow, the application determines how they are handled. These errors also imply that no error exists at the actual TCAP layer because a protocol error would trigger prior to an error at the application level. The application can also send an Abort message type (U-Abort) to the other node to indicate that a User Abort has occurred for the transaction and that it should be closed. < Day Day Up > < Day Day Up > ITU Protocol Message Contents The definition of each message type indicates a set of fields that comprise the message. While some fields are mandatory, others are optional. As specified by Q.773, the standard set of ITU messages includes: • Unidirectional • Begin • End • Continue • Abort The following sections describe these messages, the fields that are included in each one, and indicate which fields are mandatory or optional. Unidirectional Message The Unidirectional Message is sent when no reply is expected. Table 10-9 lists the message contents. Table 10-9. Unidirectional Message Fields Unidirectional Message Fields Mandatory/Optional Message Type Total Message Length Mandatory Dialogue Portion Optional Component Portion Tag Component Portion Length Mandatory One or More Componnts Mandatory B e g in Messa ge The Begin Message is sent to initiate a transaction. Table 10-10 lists the message contents. Table 10-10. Begin Message Fields Begin Message Fields Mandatory/Optional Message Type Total Message Length Mandatory Originating Transaction ID Tag Transaction ID Length Transaction ID Mandatory Dialogue Portion Optional Component Portion Tag Component Portion Length Optional [*] One or More Components Optional [*] The component Portion Tag is present only if the message contains components. E ndMessa g e The End Message is sent to end a transaction. Table 10-11 lists the message contents. Table 10-11. End Message Fields End Message Fields Mandatory/Optional Message Type Total Message Length Mandatory Destination Transaction ID Tag Transaction ID Length Transaction ID Mandator Dialogue Portion Optional Component Portion Tag Component Portion Length Optional [*] One or More Components Optional [*] The component Portion Tag is present only the message contains components. Continue Message The Continue Message is sent when a transaction has previously been established and additional information needs to be sent without ending the transaction. Table 10-12 lists the message contents. Table 10-12. Continue Message Fields Continue Message Fields Mandatory/Optional Message Type Total Message Length Mandatory Originating Transaction ID Tag Transaction ID Length Transaction ID Mandatory Destination Transaction ID Tag Transaction ID Length Transaction ID Mandatory Dialogue Portion Optional Component Portion Tag Component Portion Length Optional [*] One or More Components Optional [*] The component Portion Tag is present only if the message contains components. A bort Messa g e The Abort Message is sent to terminate a previously established transaction. Table 10-13 lists the message contents. Table 10-13. Abort Message Fields Abort Message Fields Mandatory/Optional Message Type Total Message Length Mandatory Destination Transaction ID Tag Transaction ID Length Transaction ID Mandatory P-Abort Cause Tag P-Abort Cause Length P-Abort Cause Optional [*] Dialogue Portion Optional [*] P-Abort is present when the TC-User generates the Abort message. . Transaction ID, there is no way for the sending node to handle the error because it cannot make an association with the appropriate transaction. Errors at the Component Layer Protocol errors at. Begin message is received and the Originating Transaction ID cannot be determined because of the message error, the message is simply discarded and an Abort message is not returned to the sender transaction in which a protocol error is detected. Figure 10-13. Protocol Error Causes an Abort Because no Transaction ID is associated with a Unidirectional message, no Abort message would