2 Example ACS Message Sequences
Overview
Introduction
This chapter describes example message sequences that can be sent between Oracle Communications Convergent Charging Controller Advanced Control Services (ACS) and Service Switching Points (SSPs) or Specialized Resource Functions (SRFs) by using the INAP CS1, INAP CS2, CAP2, CAP3, CAP4, and MAP protocols.
Message Sequence Examples
Introduction to Message Sequence Examples
This section provides the following example message sequences used by ACS. The message sequences are ordered by level of complexity (from less complex to more complex) and by type of message sequence:
- Unconditional Call Connection Message Sequence
- Release Call Message Sequence
- Divert on Busy Message Sequence
- CallInformationReport Message Sequence
- FurnishChargingInformation Message Sequence
- SendChargingInformation Message Sequence
- Play an Announcement (Internal SRF) Message Sequence
- Prompt for Digits Using External Intelligent Peripheral SRF Message Sequence
- Post Answer Beep or Announcement Message Sequence
- Real Time Charging, Caller Hangs Up Message Sequence (CAP2, CAP3, or CAP4)
- Real Time Charging, Funds Exhausted Message Sequence
- Real Time Charge, Disconnect B-party When Funds Exhausted Message Sequence (CAP4)
- Real Time Charge, Location Information Retrieval Message Sequence
- Call Initiation (CS1) Message Sequence
- Call Initiation (CAP4) Message Sequence
- CollectInformation Message Sequence
- Combined Message Sequence Example
Unconditional Call Connection Message Sequence
ACS supports message sequences for unconditionally connecting a call, as shown in the following figure. The yellow box on the left represents the Unconditional Termination feature node. You use an Unconditional Termination feature node in the control plan to set the connection destination:
Figure 2-1 Unconditional Call Connection Message Sequence
Release Call Message Sequence
ACS supports message sequences for releasing a call, as shown in the following figure. The yellow box on the left represents the Disconnect feature node. You use a Disconnect feature node in the control plan to release the call:
Figure 2-2 Release Call Message Sequence
Divert on Busy Message Sequence
ACS supports message sequences for diverting a call when a busy response is received, as shown in the following figure. The yellow boxes on the left represent Attempt Termination feature nodes. You use Attempt Termination feature nodes in the control plan to set the connection destination, and divert on busy destination.
Figure 2-3 Divert on Busy Message Sequence
Divert on Busy RequestReportBCSMEvent Table
The table below lists eventTypeBCSM detection points for the RequestReportBCSMEvent operation, and shows how each event is armed in divert on busy message sequences.
Note:
- If the InitialDP.eventTypeBCSM detection point indicates the terminating basic call model, then the originating event detection points in the table below are replaced with the corresponding terminating event detection points.
- If the EventReportBCSMEvent(oAnswer, notification) is sent in a TCAP_CONTINUE message response, then ACS assumes a pre-arranged end of the transaction.
| eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|
oAnswer
|
notifyAndContinue | 2 | Not set |
oCalledPartyBusy
|
interrupted | 2 | Not set |
oAnswer
|
interrupted | 2 | Sets the applicationTimer parameter to the time in
seconds that the SSP should wait before reporting
noAnswer. You can configure ACS so that this parameter
is not set. When applicationTimer is not set, the
timeout is network specific.
|
oAbandon
|
notifyAndContinue | 1 | Not set |
routeSelectFailure
|
interrupted | 2 | Not set |
CallInformationReport Message Sequence
The following figure shows an example message sequence where ACS uses the CallInformationReport operation to collect information about the call to put in the call data record (CDR). Apart from call information reporting, the message sequence is the same as for Divert on Busy, and the same event detection points are armed. For details, see Divert on Busy RequestReportBCSMEvent Table .
Figure 2-4 CallInformationReport Message Sequence
ACS supports receiving separate TCAP messages for CallInformationReport and EventReportBCSM operations. The SSP sends:
- CallInformationReport before EventReportBCSM when the event is armed as interrupted
- EventReportBCSM before CallInformationReport when the event is armed as notifyAndContinue
Some SSPs will not send CallInformationReport operations for oCalledPartyBusy, oNoAnswer and routeSelectFailure. You can configure ACS to handle this situation.
Note: You can include the CallInformationRequest and CallInformationReport operations in unconditional call connection message sequences by using a similar scenario.
FurnishChargingInformation Message Sequence
The following figure shows an example message sequence where ACS sends a FurnishChargingInformation operation before each Connect in order to provide the SSP with information to put in its call data record.
Note:
- You can also configure ACS to send FurnishChargingInformation before ReleaseCall, ConnectToResource, and EstablishtemporaryConnection operations.
- When the MTP protocol is used to convey the INAP operations, each MTP packet is limited to 272 octets in length. A FurnishChargingInformation operation can sometimes exceed this limit; for example, if it has been combined with RequestReportBCSMEvent and Connect operations. You can configure ACS to always send FurnishChargingInformation in a separate TCAP_CONTINUE message to avoid this problem.
Figure 2-5 FurnishChargingInformation Message Sequence
SendChargingInformation Message Sequence
Note:
You can also configure ACS to send SendChargingInformation before ReleaseCall, ConnectToResource, and EstablishtemporaryConnection operations.Figure 2-6 FurnishChargingInformation Message Sequence
Play an Announcement (Internal SRF) Message Sequence
ACS supports message sequences for playing announcements. The example message sequence in the following figure plays two announcements to the caller before connecting the call. You configure the announcements to play in Play Announcement feature nodes in the control plan. You connect the call by using an Unconditional Termination feature node.
Note:
The example uses an internal SRF as the SSP.Figure 2-7 Play an Announcement (Internal SRF) Message Sequence
Prompt for Digits Using External Intelligent Peripheral SRF Message Sequence
ACS supports message sequences using external intelligent peripherals to issue prompts. In the following example message sequence ACS prompts the caller for a digit, using an external intelligent peripheral, and repeats the prompt after the caller enters an invalid option. Then, using a different external intelligent peripheral, ACS prompts the caller for the phone number to connect to.
Figure 2-8 Prompt for Digits Using External Intelligent Peripheral SRF Message Sequence
Post Answer Beep or Announcement Message Sequence
The following scenario uses some CS2 operations to provide a short announcement, such as a beep, to the B-party immediately after the call is answered; for example, to warn the B-party that they will be required to pay for the incoming call. In order to play the beep announcement, legs 1 and 2 (the A and B legs respectively) are temporarily split apart while leg 2 connects to the internal SRF in the SSP.
Note:
This scenario uses a valid message sequence; however, only a minority of SSPs will support this message sequence.Post Answer Announcement Example
This example shows the message sequence for a post answer announcement where:
- The leg 1 event detection points are armed in a separate RequestReportBCSMEvent operation from the leg 2 event detection points.
- All operations after the SplitLeg operation are sent in separate TCAP messages to ensure that all SSPs will be able to complete the message sequence correctly.
You configure the beep announcement in an Unconditional Termination feature node in the control plan.
See RequestReportBCSMEvent Table for details of how the events in the RequestReportBSCMEvent operation are armed and disarmed.
Figure 2-9 Post Answer Beep or Announcement Message Sequence
RequestReportBCSMEvent Table
This table lists the RequestReportBCSMEvent operations from the Post Answer Announcement Example in operation order, and provides details of how each event for the RequestReportBCSMEvent operation is armed.
| Operation | eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|---|
| First RequestReportBCSMEvent operation |
oDisconnect
|
notifyAndContinue | 1 | Not set |
| Second RequestReportBCSMEvent operation |
|
interrupted notifyAndContinue |
2 2 |
Not set Not set |
This table provides details of how each event for the RequestReportBCSMEvent operation is disarmed, in operation order.
| Operation | eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|---|
| Third RequestReportBCSMEvent operation |
oDisconnect
|
transparent | 1 | Not set |
| Second RequestReportBCSMEvent operation |
oDisconnect
|
transparent | 2 | Not set |
Real Time Charging, Caller Hangs Up Message Sequence
ACS supports the CAP2, CAP3, and CAP4 message sequences used for charged calls, where the caller hangs up, as shown in the following figure:
Note:
ACS supports sending the EventReportBCSM operation and final ApplyChargingReport operation in one TCAP_CONTINUE message, or as two separate TCAP messages.Figure 2-10 Real Time Charging, Caller Hangs Up Message Sequence
Caller Hangs Up RequestReportBCSMEvent Table
The following table provides details of how each event is armed for the RequestReportBCSMEvent operation in the example message sequence for a charged call where the caller hangs up.
| eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|
oCalledPartyBusy
|
interrupted | 2 | Not set |
oAnswer
|
interrupted | 2 | Sets the applicationTimer parameter to the time in
seconds that the SSP should wait before reporting
noAnswer. You can configure ACS so that this parameter
is not set. When applicationTimer is not set, the
timeout is network specific.
|
oAbandon
|
notifyAndContinue | 1 | Not set |
routeSelectFailure
|
interrupted | 2 | Not set |
oDisconnect
|
notifyAndContinue | 1 | Not set |
oDisconnect
|
interrupted | 2 | Not set |
Real Time Charging, Funds Exhausted Message Sequence
The following figure shows the message sequence used by ACS for
real time charging when the caller's funds are exhausted. Note that
the second ApplyCharging operation sets the
releaseIfdurationExceeded parameter.
The callReleaseAtTcpExiry parameter that is
available for CAP3, does not exist in CAP2. Therefore, if the
B-party (leg 2) hangs up, the message sequence for CAP2 will be
different from the example message sequence in the following
ways:
- The callReleaseAtTcpExpiry operation will be absent
- An EventReportBCSM(oDisconnect,leg 2, request) will be received in another message from the SSP
This means that for CAP2, ACS does not know whether the timer has expired (because this is the pre-arranged end of the message sequence) or whether the B-party has hung up, and ACS should wait for the EventReportBCSM. You can configure ACS to recognize the difference between B-party hang-up and timer expiry for CAP2 in one of the following ways:
- By assuming that when the B-party hangs up, the EventReportBCSM(oDisconnect,leg 2, request) is always in the same TCAP message as the ApplyChargingReport(callActive=false)
- By assuming that the message sequence always ends with an empty TCAP_END
Figure 2-11 Real Time Charging, Funds Exhausted Message Sequence
Real Time Charge, Disconnect B-party When Funds Exhausted Message Sequence
The following figure shows the message sequence for disconnecting only the B-party (leg 2) after the funds expire, so that ACS can play an announcement to the caller giving the cost of the call.
Note:
In this message sequence thereleaseIfdurationExceeded parameter is not
specified in the ApplyCharging operation.
Figure 2-12 Real Time Charge, Disconnect B-party When Funds Exhausted Message Sequence
Real Time Charge, Location Information Retrieval Message Sequence
The following figure shows the message sequence ACS uses for
retrieving the location of the caller. In the example message
sequence, ACS is configured to use the MAP
AnyTimeInterrogation parameter to retrieve the
caller's location when it receives an ApplyChargingReport
operation.
Note:
The location information can affect the charging applied.Figure 2-13 Real Time Charge, Location Information Retrieval Message Sequence
Call Initiation (CS1) Message Sequence
ACS supports call initiation message sequences that use INAP CS1. In the message sequence in the following figure, the USSD Gateway receives a MAP USSD operation (not shown), and then sends ACS an internal InitialDP to initiate a new call to the A-party. In the message sequence, the A-party (leg 1) is connected to another number, the B-party (leg 2), with no real time charging. You use a Call Initiation feature node in the control plan to initiate the call.
Figure 2-14 Call Initiation (CS1) Message Sequence
Initiate Call (CS1) RequestReportBCSMEvent Table
The following table provides details of how each event is armed for the first RequestReportBCSMEvent operation in the call initiation (CS1) message sequence example.
Note:
For details of how the events are armed in the second RequestReportBCSMEvent operation, see Divert on Busy RequestReportBCSMEvent Table .| eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|
oAnswer
|
interrupted | 1 | Not set |
oNoAnswer
|
notifyAndContinue | 1 | Sets the applicationTimer parameter to the time in
seconds that the SSP should wait before reporting
noAnswer. You can configure ACS so that this parameter
is not set. When applicationTimer is not set, the
timeout is network specific.
|
routeSelectFailure
|
notifyAndContinue | 1 | Not set |
oCalledPartyBusy
|
notifyAndContinue | 1 | Not set |
Call Initiation (CAP4) Message Sequence
ACS supports call initiation message sequences that use CAP4. In the message sequence in the following figure, the USSD Gateway receives a MAP USSD operation (not shown), and then sends ACS an internal InitialDP to initiate a new call to the A-party (leg 1). In this example, the A-party is connected to another number, the B-party (leg 2), with real time charging. You use a Call Initiation feature node in the control plan to initiate the call.
Note:
Although not recommended, you can configure ACS to use leg 3 instead of leg 1 for a call initiation (CAP4) message sequence. This is because the CAP4 specification explicitly states that leg 3 or higher must be used for InitiateCallAttempt operations.Figure 2-15 Call Initiation (CAP4) Message Sequence
Initiate Call (CAP4) RequestReportBCSMEvent Table
The following table provides details of how each event is armed for the first RequestReportBCSMEvent operation in the call initiation (CAP4) message sequence example.
Note:
For details of how the events are armed in the second RequestReportBCSMEvent operation, see Divert on Busy RequestReportBCSMEvent Table .| eventTypeBCSM | monitorMode | legID | dpSpecificCriteria |
|---|---|---|---|
oAnswer
|
interrupted | 1 | Not set |
oNoAnswer
|
notifyAndContinue | 1 | Sets the applicationTimer parameter to the time in
seconds that the SSP should wait before reporting
noAnswer. You can configure ACS so that this parameter
is not set. When applicationTimer is not set, the
timeout is network specific.
|
routeSelectFailure
|
notifyAndContinue | 1 | Not set |
oCalledPartyBusy
|
notifyAndContinue | 1 | Not set |
CollectInformation Message Sequence
In the message sequence in the following figure, a service running on top of ACS, such as the Convergent Charging Controller Virtual Private Network (VPN) service, determines that more digits are needed from the SSP before the correct action for the call can be taken. For more information about VPN, see VPN Technical Guide.
Figure 2-16 CollectInformation Message Sequence
