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.
See: CGIN Connectivity Pack to learn more about SS7 interfaces in the Rhino TAS platform. |
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
orTC-End
-
find out if the message is a
DialogOpenRequest
,DialogOpenAccept
,DialogOpenRefuse
,DialogUserAbort
,DialogProviderAbort
or aDialogMessage
-
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.
The |
See Using The Leg Manager in the IP-SM-GW SDK guide to learn more about using these objects during the development of your own features. |
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)
void setMyTcapMessage(DialogTcapMessage message);
/** @return 'MyTcapMessage' cmp field value */
DialogTcapMessage getMyTcapMessage();
/** @return true if 'MyTcapMessage' cmp field is set */
boolean hasMyTcapMessage();
/** Clear 'MyTcapMessage' cmp field */
void resetMyTcapMessage();
}
DatatypeCodecType annotation tells Rhino to use DialogTcapMessageCodec to encode/decode DialogTcapMessage objects |
|
set operation for the MyTcapMessage CMP field |
|
get operation for the MyTcapMessage CMP field |
|
(optional) has operation for the MyTcapMessage CMP field |
|
(optional) reset operation for the MyTcapMessage CMP field |
See: Rhino TAS > CMP Field Enhancements to learn more about using CMP fields in Rhino |