Supported Message Sequences

MATRIXX Call Control Framework (CCF) provides support for message sequences using the Camel Application Part (CAP) protocol.

Message Protocols

The following protocols are used between:

  • The Mobile Switching Center (MSC) or service switching point (SSP) and Network Enabler — SCCP over M3UA over SCTP over IP.
  • Network Enabler and CAMEL Gateway — SCCP messages over TCP/IP.

SCCP management messages can also be sent between Network Enabler and CAMEL Gateway; for example, CAMEL Gateway might send subsystem allowed (when it is ready to accept traffic) or subsystem prohibited (when it is not ready to accept traffic). If Network Enabler cannot send a message to its destination then it sends a UDTS message to CAMEL Gateway.

Withheld Time

Call Control Framework withholds 30 seconds of granted call time for voice calls by default. MATRIXX Engine uses withheld call time if the caller runs out of funds. A warning tone is played to the caller and the caller is cut off after the withheld number of seconds (the warning period) expires.

Replacing CAP Continue Operations with CAP Connect Operations

A CAP Continue operation can be replaced by a CAP Connect operation in the following situations:

  • If the service or MATRIXX Engine specifies a prefix for the called party number or destination routing address.
  • If MATRIXX Engine diverts to a new number.

Call Control Framework Support for Empty TCAP END Operations

CAP2 does not support empty TCAP END operations although this type of operation is sometimes sent by the MSC. Call Control Framework can handle empty TCAP END operations. You can configure Call Control Framework to send an empty TCAP END operation instead of TCAP ABORT based on the application context or based on the originating SCCP address.

Sending TCAP Connect Instead of TCAP Continue

MATRIXX Engine can set the ServiceInfo.VcsInfo.SendConnectFlag parameter in MtxDiamRoMsg messages to force CAMEL Gateway to send a TCAP Continue or ContinueSMS operation to the MSC instead of sending TCAP Connect or ConnectSMS.

When ServiceInfo.VcsInfo.SendConnectFlag is set to:
  • 0 — Call Control Framework sends a TCAP Continue or TCAP ContinueSMS operation to the MSC and ignores any other fields.
  • 1 — Call Control Framework sends a TCAP Connect or TCAP ConnectSMS operation to the MSC.
  • 2 or not present — If the number to connect to (the destination number) and the called party number are the same, Call Control Framework sends a TCAP Continue or TCAP ContinueSMS operation to the MSC. If the destination number has changed so that it is not the same as the called party number, then Call Control Framework sends a TCAP Connect or TCAP ConnectSMS operation to the MSC. This is the default behavior.

TCAP NOTICE Messages

CAMEL Gateway returns a TCAP NOTICE message to the Charging Server when CAMEL Gateway is unable to deliver a message from the Charging Server to its destination, for example, if:
  • CAMEL Gateway cannot deliver a message to Network Enabler.
  • Network Enabler is unable to deliver a message to the network.
  • A downstream routing element such as an STP (signal transfer point) cannot route a message.

When the Charging Server receives a TCAP NOTICE message, the Charging Server cleans up all the resources associated with that TCAP transaction and its associated session.

ApplyChargingReport and EventReportBCSM Operation Order

The CAP2 rules for the order in which to send ApplyChargingReport and EventReportBCSM operations are:

  • If oDisconnect is armed as notify, send EventReportBCSM first.
  • If oDisconnect is armed as interrupted, send ApplyChargingReport first.

Call Control Framework supports receiving ApplyChargingReport and EventReportBCSM operations in either order; for example, Call Control Framework can handle message sequences where oDisconnect is armed as notify on both legs but the MSC sends EventReportBCSM after ApplyChargingReport. For message sequence details, see the discussion about EventReportBCSM received after ApplyChargingReport message sequence.

EventReportBCSM and ApplyChargingReport operations can be followed by a TCAP ABORT or an empty TCAP END, or sent together in the same TCAP CONTINUE or TCAP END.

To enable Network Enabler to handle disconnections correctly; for example, when the subscriber's funds are exhausted and Network Enabler must wait for the EventReportBCSM operation, configure Call Control Framework to assume one of:

  • The disconnect message sequences always follow the CAP2 rules for the order in which the MSC sends ApplyChargingReport and EventReportBCSM operations.
  • The message sequence never ends with TCAP CONTINUE(ApplyCharging).

BCSM Event Values

BCSM Event Values describes the basic call state model (BCSM) event values in EventReportBCSM operations and RequestReportBCSMEvent operations.

Table 1. BCSM Event Values
Value Description
A number The leg ID of the call where:
  • 1 (leg 1) is associated with the calling party or A-party.
  • 2 (leg 2) is associated with the called party or B-party.
N Means notify and continue, or notification.
I Means interrupted.