Supported CAP Operations Between CCF and the MSC

Call Control Framework (CCF) supports CAMEL Application Part (CAP) protocol operations for voice calls and SMS sent to the Mobile Switching Center (MSC) from CCF.

The following CAP operations are supported:

The available parameters for each operation, an indication of whether CCF supports them, and the available CAP protocol versions, are listed in the following tables. Parameters are listed in the order in which they appear in the specification documents.

ActivityTest

CCF periodically sends ActivityTest operations for non-chargeable voice calls that are being monitored (through CallInformationRequest operations) to find out whether calls are still active. The MSC returns the results in the ActivityTest response. No parameters are sent in ActivityTest operations and responses.

ApplyCharging

CCF sends the ApplyCharging operation to request charging information for a voice call or SMS. The results are returned in an ApplyChargingReport operation.

The tone parameter indicates that a tone is played to the caller if they are about to run out of funds. The tone parameter is handled differently depending on the protocol version:
  • For CAP2, the tone parameter is included in the releaseIfdurationExceeded parameter, for example: aChBillingChargingCharacteristics.timeDurationCharging.releaseIfdurationExceeded.tone. This means that a tone can be played only when the call is released.
  • For CAP3, the tone parameter is separate from the releaseIfdurationExceeded parameter, for example: aChBillingChargingCharacteristics.timeDurationCharging.tone. This means that a tone could be played without releasing the call.
  • For CAP4, the tone parameter is included in the audibleIndicator parameter, for example: ChBillingChargingCharacteristics.timeDurationCharging.audibleIndicator.tone.
Note: The CAP1 protocol does not support ApplyCharging operations.

Supported ApplyCharging Parameters lists the parameters used in ApplyCharging operations and indicates whether CCF supports them.

Table 1. Supported ApplyCharging Parameters
ApplyCharging Parameter CAP Protocol Version Supported
aChBillingChargingCharacteristics CAP2, CAP3, CAP4 Yes
- timeDurationCharging CAP2, CAP3, CAP4 Yes
- - maxCallPeriodDuration CAP2, CAP3, CAP4 Yes
- - releaseIfdurationExceeded CAP2, CAP3, CAP4 Yes
- - - tone CAP2 Yes
- - - extensions CAP2 No
- - tariffSwitchInterval CAP2, CAP3, CAP4 No
- - tone CAP3 Yes
- - extensions CAP3, CAP4 No
- - audibleIndicator CAP4 Yes
- - - tone CAP4 Yes
- - - burstList CAP4 No
extensions CAP2 No
partyToCharge CAP2, CAP3, CAP4 Yes
aChChargingAddress CAP4 No

CallInformationRequest

CCF sends CallInformationRequest operations to request specific call information for a single call party. The result is returned in a CallInformationReport operation at the end of the call or call party connection. Supported CallInformationRequest Parameters lists the parameters used in CallInformationRequest operations and indicates whether CCF supports them.
Note: The CAP1 protocol does not support CallInformationRequest operations.
Table 2. Supported CallInformationRequest Parameters
CallInformationRequest Parameter CAP Protocol Version Supported
requestedInformationTypeList CAP2, CAP3, CAP4 Yes
extensions - No
legID CAP2, CAP3, CAP4 Yes

Cancel

CCF sends Cancel operations to request cancellation of a specific correlated preceding operation, or to cancel all outstanding requests. Supported Cancel Request Parameters lists the parameters used in Cancel operations and indicates whether CCF supports them.
Note: The CAP1 protocol does not support Cancel operations.
Table 3. Supported Cancel Request Parameters
Cancel Parameter CAP Protocol Version Supported
invokeID CAP2, CAP3, CAP4 Yes
allRequests CAP2, CAP3, CAP4 Yes
callSegmentToCancel CAP4 No
- invokeID CAP4 No
- callSegmentId CAP4 No

Connect

CCF sends Connect operations to request the MSC to perform call processing actions, for example, to route a call to a specific destination or to influence other call set-up information. Supported Connect Parameters lists the parameters used in Connect operations and indicates whether CCF supports them.

Table 4. Supported Connect Parameters
Connect Parameter CAP Protocol Version Supported
destinationRoutingAddress CAP1, CAP2, CAP3, CAP4 Yes
alertingPattern CAP2, CAP3, CAP4 No
serviceInteractionIndicatorsTwo CAP3, CAP4 No
callingPartysCategory CAP1, CAP2, CAP3, CAP4 Yes
originalCalledPartyID CAP1, CAP2, CAP3, CAP4 Yes
redirectingPartyID CAP1, CAP2, CAP3, CAP4 Yes
redirectionInformation CAP1, CAP2, CAP3, CAP4 Yes
genericNumbers CAP1, CAP2, CAP3, CAP4 Yes
suppressionOfAnnouncement CAP1, CAP2, CAP3, CAP4 Yes
oCSIApplicable CAP1, CAP2, CAP3, CAP4 Yes
naCarrierInformation CAP2 No
- naOliInfo CAP2 No
- naChargeNumber CAP2 No
Carrier CAP3, CAP4 No
- carrierSelectionField CAP3, CAP4 No
- carrierID CAP3, CAP4 No
naOliInfo CAP3, CAP4 No
chargeNumber CAP3, CAP4 No
cug_Interlock CAP3, CAP4 No
cug_OutgoingAccess CAP3, CAP4 No
bor-InterrogationRequested CAP4 No
legToBeConnected CAP4 Yes
extensions CAP3 No

ConnectSMS

CCF sends ConnectSMS operations to request the MSC to perform Short Message (SM) processing actions, for example, to route a message to a specific destination or to influence other SM set-up information. Supported ConnectSMS Parameters lists the parameters used in ConnectSMS operations and indicates whether CCF supports them.
Note: ConnectSMS operations are available only in CAP3 and CAP4. The CAP1, and CAP2 protocols do not support SMS operations.
Table 5. Supported ConnectSMS Parameters
ConnectSMS Parameter CAP Protocol Version Supported
callingPartysNumber CAP3, CAP4 Yes
destinationSubscriberNumber CAP3, CAP4 Yes
sMSCAddress CAP3, CAP4 Yes
extensions CAP3, CAP4 No

ConnectToResource

CCF can send a ConnectToResource request to the MSC to connect a call to a specialized resource function (SRF), such as an IVR. Supported ConnectToResource Parameters lists the parameters used in ConnectToResource operations and indicates whether CCF supports them.
Note: For ConnectToResource operations and EstablishTemporaryConnection operations, only the bothwayThroughConnectionInd sub-field of the serviceInteractionIndicatorsTwo parameter is supported. All the other serviceInteractionIndicatorsTwo sub-fields are not supported.
Table 6. Supported ConnectToResource Parameters
ConnectToResource Parameter CAP Protocol Version Supported
resourceAddress CAP2, CAP3, CAP4 Yes
- iPRoutingAddress CAP2, CAP3 Yes
resourceAddress.none CAP2, CAP3 Yes
iPRoutingAddress CAP4 Yes
none CAP4 Yes
extensions CAP2, CAP3, CAP4 No
serviceInteractionIndicatorsTwo CAP2, CAP3, CAP4 Yes
- bothwayThroughConnectionInd CAP2, CAP3, CAP4 Yes
callSegmentId CAP4 Yes

Continue or ContinueSMS

CCF can send a Continue or ContinueSMS operation to request the MSC to continue with earlier suspended call processing or SMS processing. No parameters are sent in Continue or ContinueSMS operations.
Note: ContinueSMS operations are available only in CAP3 and CAP4. The CAP1 and CAP2 protocols do not support SMS operations.

DisconnectForwardConnection

CCF provides support for DisconnectForwardConnection operations. The DisconnectForwardConnection operation is used to clear a connection to an SRF. No parameters are sent in DisconnectionForwardConnection operations.
Note: The CAP1 protocol does not support DisconnectForwardConnection operations.

EstablishTemporaryConnection

CCF can send an EstablishTemporaryConnection request to the MSC to create a temporary connection to a resource, such as an IVR, for example to play an announcement or to collect user information.
Note: The CAP1 protocol does not support EstablishTemporaryConnection operations.
Supported EstablishTemporaryConnection Parameters lists the parameters used in EstablishTemporaryConnection operations and indicates whether CCF supports them.
Note: For ConnectToResource operations and EstablishTemporaryConnection operations, only the bothwayThroughConnectionInd sub-field of the serviceInteractionIndicatorsTwo parameter is supported. All the other serviceInteractionIndicatorsTwo sub-fields are not supported.
Table 7. Supported EstablishTemporaryConnection Parameters
EstablishTemporaryConnection Parameter CAP Protocol Version Supported
assistingSSPIPRoutingAddress CAP2, CAP3, CAP4 Yes
correlationID CAP2, CAP3, CAP4 Yes
scfID CAP2, CAP3, CAP4 Yes
extensions CAP2, CAP3, CAP4 No
serviceInteractionIndicatorsTwo CAP2, CAP3, CAP4 No
- bothwayThroughConnectionInd CAP2, CAP3, CAP4 Yes
carrier CAP3 No
- carrierSelectionField CAP3, CAP4 No
- carrierID CAP3, CAP4 No
naOliInfo CAP3, CAP4 No
ChargeNumber

chargeNumber

CAP3

CAP4

Yes
callSegmentID CAP4 Yes

FurnishChargingInformation

CCF can send a FurnishChargingInformation (FCI) operation to instruct the MSC to add charging information to the call data record (CDR) for a call. CCF can send an FCI operation for one or more of the following:
  • In response to every ApplyChargingReport operation
  • With every Connect or Continue operation
  • With every ReleaseCall operation
Note: The CAP1 protocol does not support FurnishChargingInformation operations.

Supported FurnishChargingInformation Parameters lists the parameters used in FurnishChargingInformation operations and indicates whether CCF supports them.

Table 8. Supported FurnishChargingInformation Parameters
FurnishChargingInformation Parameter CAP Protocol Version Supported
FCIBillingChargingCharacteristics CAP2 Yes
FCIBCCCAMELsequence1 CAP2 Yes
- FreeFormatData CAP2 Yes
- PartyToCharge CAP2 Yes
fCIBillingChargingCharacteristics CAP3, CAP4 Yes
- fCIBCCCAMELsequence1 CAP3, CAP4 Yes
- - freeFormatData CAP3, CAP4 Yes
- - partyToCharge CAP3, CAP4 Yes
- - appendFreeFormatData CAP3, CAP4 Yes

PlayAnnouncement

CCF can send a PlayAnnouncement operation to the MSC requesting that a specific announcement is played to the subscriber. Supported PlayAnnouncement Parameters lists the parameters used in PlayAnnouncement operations and indicates whether CCF supports them.
Note: The CAP1 protocol does not support PlayAnnouncement operations.
Table 9. Supported PlayAnnouncement Parameters
PlayAnnouncement Parameter CAP Protocol Version Supported
informationToSend CAP2, CAP3, CAP4 Yes
- inbandInfo CAP2, CAP3, CAP4 Yes
- - messageID CAP2, CAP3, CAP4 Yes
- - - elementaryMessageID CAP2, CAP3, CAP4 Yes
- - - text CAP2, CAP3, CAP4 Yes
- - - elementaryMessageIDs CAP2, CAP3, CAP4 Yes
- - - variableMessage CAP2, CAP3, CAP4 Yes
- - - - elementaryMessageID CAP2, CAP3, CAP4 Yes
- - - - variableParts CAP2, CAP3, CAP4 Yes
- - numberOfRepetitions CAP2, CAP3, CAP4 Yes
- - duration CAP2 Yes
- - interval CAP2 Yes
- tone CAP2 Yes
- - toneID CAP2 Yes
- - duration CAP2 Yes
- duration CAP3, CAP4 Yes
- interval CAP3, CAP4 Yes
tone CAP3, CAP4 Yes
- toneID CAP3, CAP4 Yes
- duration CAP3, CAP4 Yes
disconnectFromIPForbidden CAP2, CAP3, CAP4 Yes
requestAnnouncementCompleteNotification

requestAnnouncementComplete

CAP2, CAP4

CAP3

Yes
extensions CAP2, CAP3 No
requestAnnouncementStartedNotification CAP4 No
callSegmentID CAP4 Yes

PromptAndCollectUserInformation

CCF can send a PromptAndCollectUserInformation (PACUI) operation instead of sending a PlayAnnouncement operation, to allow the MSC to interact with the subscriber and collect information. The information collected is returned in a ReceivedInformationArg operation. Supported PromptAndCollectUserInformation Parameters lists the parameters used in PACUI operations and indicates whether CCF supports them.
Note: The CAP1 protocol does not support PromptAndCollectUserInformation operations.
Table 10. Supported PromptAndCollectUserInformation Parameters
PACUI Parameter CAP Protocol Version Supported
collectedInfo CAP2, CAP3, CAP4 Yes
- collectedDigits CAP2, CAP3, CAP4 Yes
- - minimumNbOfDigits CAP2, CAP3, CAP4 Yes
- - maximumNbOfDigits CAP2, CAP3, CAP4 Yes
- - endOfReplyDigit CAP2, CAP3, CAP4 Yes
- - cancelDigit CAP2, CAP3, CAP4 Yes
- - startDigit CAP2, CAP3, CAP4 Yes
- - firstDigitTimeOut CAP2, CAP3, CAP4 Yes
- - interDigitTimeOut CAP2, CAP3, CAP4 Yes
- - errorTreatment CAP2, CAP3, CAP4 Yes
- - interruptableAnnInd CAP2, CAP3, CAP4 Yes
- - voiceInformation CAP2 , CAP3, CAP4 Yes
- - voiceBack CAP2, CAP3, CAP4 Yes
disconnectFromIPForbidden CAP2, CAP3, CAP4 Yes
informationToSend CAP2, CAP3, CAP4 Yes
- inbandInfo.messageID.elementaryMessageID CAP2, CAP3, CAP4 Yes
- inbandInfo.messageID.text CAP2, CAP3, CAP4 Yes
- inbandInfo.messageID.elementaryMessageIDs CAP2, CAP3, CAP4 Yes
- inbandInfo.messageID.variableMessage CAP2, CAP3, CAP4 Yes
- numberOfRepetitions CAP2, CAP3, CAP4 Yes
- duration CAP2, CAP3, CAP4 Yes
- interval CAP2, CAP3, CAP4 Yes
- tone CAP2, CAP3, CAP4 Yes
- - toneID CAP2, CAP3, CAP4 Yes
- - duration CAP2, CAP3, CAP4 Yes
extensions CAP2, CAP3, CAP4 No
requestAnnouncementStartedNotification CAP4 No
callSegmentID CAP4 Yes
For information about ReceivedInformationArg operation parameters, see the discussion about supported CAP operations between the MSC and CCF.

ReleaseCall

CCF sends the ReleaseCall operation to release the call or call party connection. Supported ReleaseCall Parameters lists the parameters used in ReleaseCall operations and indicates whether CCF supports them.

Table 11. Supported ReleaseCall Parameters
ReleaseCall Parameter CAP Protocol Version Supported
releaseCause CAP2, CAP3, CAP4 Yes
Cause CAP1 Yes

ReleaseSMS

CCF sends the ReleaseSMS operation to release the SMS connection. Supported ReleaseSMS Parameters lists the parameters used in ReleaseSMS operations and indicates whether CCF supports them.
Note: ReleaseSMS operations are available only in CAP3 and CAP4. The CAP1 and CAP2 protocols do not support SMS operations.
Table 12. Supported ReleaseSMS Parameters
ReleaseCallSMS Parameter CAP Protocol Version Supported
rpCause CAP3, CAP4 Yes

RequestReportBCSMEvent

CCF can send a RequestReportBCSMEvent request to the MSC to monitor a call-related event, such as answer or disconnect. The MSC returns an EventReportBCSM response when the event is detected. Supported RequestReportBCSMEvent Parameters lists the parameters used in RequestReportBCSMEvent operations and indicates whether CCF supports them.

Table 13. Supported RequestReportBCSMEvent Parameters
RequestReportBCSMEvent Parameter CAP Protocol Version Supported
bcsmEvents CAP1, CAP2, CAP3, CAP4 Yes
- eventTypeBCSM CAP1, CAP2, CAP3, CAP4 Yes
- monitorMode CAP1, CAP2, CAP3, CAP4 Yes
- legID CAP1, CAP2, CAP3, CAP4 Yes
- dPSpecificCriteria CAP2, CAP3, CAP4 Yes
- - applicationTimer CAP2, CAP3, CAP4 Yes
- automaticRearm CAP4 No
extensions CAP2, CAP3, CAP4 No

RequestReportSMSEvent

CCF can send a RequestReportSMSEvent request to the MSC to monitor an SMS-related event. The MSC returns an EventReportSMS response when the event is detected. Supported RequestReportSMSEvent Parameters lists the parameters used in RequestReportSMSEvent operations and indicates whether CCF supports them.
Note: RequestReportSMSEvent operations are available only in CAP3 and CAP4. The CAP1 and CAP2 protocols do not support SMS operations.
Table 14. Supported RequestReportSMSEvent Parameters
RequestReportSMSEvent Parameter CAP Protocol Version Supported
sMSEvents CAP3, CAP4 Yes
- eventTypeSMS CAP3, CAP4 Yes
- monitorMode CAP3, CAP4 Yes
extensions CAP3, CAP4 No

ResetTimer

CCF can send a ResetTimer operation to the MSC to reset the application timer, before playing an announcement or running a VXML script. Supported ResetTimer Parameters lists the parameters used in ResetTimer operations and indicates whether CCF supports them.
Note: The CAP1 protocol does not support ResetTimer operations.
Table 15. Supported ResetTimer Parameters
ResetTimer Parameter CAP Protocol Version Supported
timerValue CAP2, CAP3, CAP4 Yes
timerID CAP2, CAP3, CAP4 Yes
extensions CAP2, CAP3, CAP4 No
callSegmentID CAP2, CAP3, CAP4 Yes