Generating TCAP transactions

Generating a TCAP transaction requires the following steps:

Step

Action

1

Allocate a memory buffer large enough for the transaction request. A TCAP transaction buffer must be at least TCAP_MSG_SIZE bytes.

2

Assign a unique user dialog ID (suDlgId) for the transaction (if it is the first request belonging to this transaction) and populate the transaction information data structure with the:

  • Message type

  • Dialog ID(s)

  • Originating address

  • Destination address

  • Quality of service parameters

3

Initialize the transaction request with TCAPInitTrans.

4

Add one or more components to the request with TCAPAddComp. Each invoke component must also have a unique invoke ID assigned within the current dialog ID.

5

Send the transaction to the destination signaling point by calling TCAPTransRqst.


The following examples show how the TCAP service implements a simple request and response transaction and a more complex conversational linked transaction. The ITU-T and ANSI variants are shown separately to clarify the conceptual differences.

Simple request and response transaction

A simple transaction consists of a transaction begin (ITU-T) or query with permission (ANSI) request with a single invoke component, followed by a single end (ITU-T) or response (ANSI) message with a single return result component. An example transaction is a request from a service switching point (SSP) to a service control point (SCP) to translate an 800 number into a subscriber directory number.

The following illustration shows the ANSI version of a simple transaction:

 

The following illustration shows the ITU-T version of a simple transaction:

Conversational linked transaction

A complicated conversational and linked transaction can occur as described in the following ANSI and ITU-T examples:

Stage

Description

1

A switching application issues an invoke on behalf of a subscriber to initiate a feature in a remote switch.

2

The remote switch decides it does not have enough information to carry out the feature invocation. It responds with a new invoke (linked to the original invoke) to play an announcement to the subscriber and collect digits.

3

The original switch collects the digits and returns them as the result to invoke #2.

4

The remote switch now completes the feature invocation and returns the result to invoke #1.


ANSI version

The following illustration shows the ANSI version of a conversational linked transaction:

ITU-T version

The following illustration shows the ITU-T version of a conversational linked transaction: