The TCAP message and TCAP component hierarchies represent the TCAP messages sent and received between the IPSMGW and remote TC-Users. These objects are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields.

TCAP Messages - The Dialog Message Hierarchy

The IPSMGW receives events from the CGIN MAP resource adaptor and builds message objects the correspond to whole TCAP messages received on the wire.

Tip

See: CGIN Connectivity Pack to learn more about SS7 interfaces in the Rhino TAS platform.

dialog messages
Figure 1. The Dialog Message Hierarchy

At the top of the hierachy is the DialogTCAPMessage interface, which has operations that you use to:

  • find out if the message is a TC-Begin, TC-Continue or TC-End

  • find out if the message is a DialogOpenRequest, DialogOpenAccept, DialogOpenRefuse, DialogUserAbort, DialogProviderAbort or a DialogMessage

  • see if the message contains any components.

The concrete classes include:

  • DialogOpenRequestTcapMessage — The initial message for a new dialog (always a TC-Begin). An open request includes source and destination address, a TCAP Application Context to use for the new dialog and may optionally include components.

  • DialogOpenAcceptTcapMessage — A first response on a new Dialog, which indicates the remote TC-User has accepted the new Dialog (a TC-Continue or a TC-End). An open accept may optionally include components.

  • DialogOpenRefuseTcapMessage — A first response on a new Dialog, which indicates the remote TC-User has refused the new Dialog (always a TC-End). An open refuse contains a refuse reason, (optionally) a peer abort cause and (optionally) a suggested alternative TCAP Application Context

  • DialogUserAbortTcapMessage — A message indicating the fatal ending of a Dialog (always a TC-End).

  • DialogProviderAbortTcapMessage —  A message indicating the fatal ending of a Dialog related to the local TC provider (always a TC-End).

  • DialogMessageTcapMessage — Every other type of message received on a Dialog (a TC-Continue or a TC-End). This type of message may optionally include components.

Tip

The DialogTcapMessage interface and concrete classes API can be found in the “com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage” section of the Sentinel IP-SM-GW API Javadoc

TCAP Components - The Operation Component Hierarchy

components
Figure 2. The Operation Component Hierarchy

Storing TCAP Messages in CMP fields

The TCAP messages are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields. Whilst these objects are all Serializable it is far more efficient to use the DialogTcapMessageCodec as in the following example.

package com.opencloud.sentinel.ipsmgw.myfeature;

import com.opencloud.rhino.cmp.codecs.DatatypeCodecType;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.DialogTcapMessage;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.persist.DialogTcapMessageCodec;

public interface MyFeatureCMP {

    /**
     * Set the 'MyTcapMessage' cmp field
     * @param message cmp field value
     */
    @DatatypeCodecType(DialogTcapMessageCodec.class)  1
    void setMyTcapMessage(DialogTcapMessage message); 2

    /** @return 'MyTcapMessage' cmp field value */
    DialogTcapMessage getMyTcapMessage(); 3

    /** @return true if 'MyTcapMessage' cmp field is set */
    boolean hasMyTcapMessage(); 4

    /** Clear 'MyTcapMessage' cmp field */
    void resetMyTcapMessage(); 5
}
1 DatatypeCodecType annotation tells Rhino to use DialogTcapMessageCodec to encode/decode DialogTcapMessage objects
2 set operation for the MyTcapMessage CMP field
3 get operation for the MyTcapMessage CMP field
4 (optional) has operation for the MyTcapMessage CMP field
5 (optional) reset operation for the MyTcapMessage CMP field
Tip

See: Rhino TAS > CMP Field Enhancements to learn more about using CMP fields in Rhino

Previous page Next page