Contents
1 Introduction
This document describes how to configure the Communication Completion (CC) service in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the O&M area, in general.
1.1.1 Licenses
To enable the CC service, the CC license must be installed.
For more information about the CC license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The CC service allows a caller who has attempted to call a subscriber who is not available, to activate a CC request against that subscriber. The CC comprises the following two services:
CCBS allows a caller who has attempted to call a busy subscriber, to activate a CC request against that subscriber and initiates a CC Call after a busy CCxx Called Party becomes free.
CCNR allows a caller who has attempted to call a subscriber who does not answer the call, to activate a CC request against that subscriber and initiates a CC Call after a call is next ended against a CCxx Called Party who did not reply to the original call attempt.
For both CCBS and CCNR, communication is completed after the called user next becomes free. After the called user becomes free, the network originates a CC Recall to the caller. After the caller answers, the network establishes a CC Call to the original called user on behalf of the caller.
If the CC Call results in busy or no reply, the caller can activate a CCBS or CCNR request in the CC Call in the same way the caller is activating the CCBS or CCNR request in the original call.
The CC service coexists with other simulation services on the same MTAS, for example, Communication Diversion (CDIV) and Communication Barring (CB). The interaction between the Call Admission Control (CAC) and other simulated services is described in this document.
2.1 CC Service Main Functions
The CC service is divided into two main functions:
2.1.1 CC Agent
The CC Agent function is at the originating MTAS and is associated with the caller. The CC Agent is responsible for maintaining a list of CC invocation requests that have been made by the caller against different called parties.
2.1.2 CC Monitor
The CC Monitor function is at the terminating MTAS and is associated with the CCxx Called Party. The CC Monitor is responsible for maintaining a list of CC Invocation requests that have been made by different CCxx Callers against the CCxx Called Party.
The CC Monitor uses the User Call Admission Control (UCAC) or Group Call Admission Control (GCAC) service to determine when the CCxx Called Party becomes available to receive a CC Call. When the CCxx Called Party or other group user ends a call, the CC Monitor is triggered to check the current user availability and send a ready notification to the CC Agent.
During a CC Recall, the CC Agent can determine that the CCxx caller is busy, either through the UCAC or GCAC service or by a busy response from the CCxx Caller. If the CCxx Caller is busy, then the CC Recall is ended and the request is revoked.
When a call ends against a monitored user, an idle guard timer is run if the user calls immediately. During this period and the period of the subsequent CC Recall (assuming no outgoing call is made), all other terminating calls to that user are rejected with a busy response.
When a call in a group is ended making the group available again, terminating call attempts to any user of the group which does not have a maturing CC request (for example, the idle guard timer is not running and notification has not been sent against the called user) are allowed to continue and are not rejected.
2.2 Subfunctions
The subfunctions included in the CC service are described in this section.
2.2.1 Announcement
Media mapped to an announcement is a subfunction of the main CC Agent function. It is used to determine the type of announcement that is played on a media stream to be established.
Media mapped to an announcement without being played is a subfunction of the main CC Agent function. It is used to determine which announcement to use without playing the announcement.
Play Announcement on Existing Media is a subfunction of the main CC Agent function. It is used to determine which announcement to play on an existing media stream.
For more information about announcement handling and attributes for the CC service, refer to MTAS Announcement Management Guide.
2.3 Interaction with Other Services
This section describes the CC interaction with other services.
2.3.1 Call Admission Control
The CCBS service uses the UCAC service for the network to be able to determine that the user is busy. The CCBS service is started for a terminating served user when the UCAC and optionally, GCAC services determine that the served user’s group is busy.
For more information about the CAC services, refer to MTAS Call Admission Control Management Guide.
2.3.2 Carrier Select
A Carrier selected by the CCxx Caller on an original call, is used for the subsequent CC Call. This applies to both the Carrier Select (CS) and CSRn services.
For more information about the CS services, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.3.3 Carrier Pre-Select
A preselected Carrier for an original call, is used for the subsequent CC Call. This applies to both the Carrier Pre-Select (CPS) and CPSRn services.
For more information about the CPS services, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.3.4 Charging
The MTAS includes a P-Charging-Vector header and a P-Charging Function Address header in the CC Recall and CC Call INVITE messages.
For more information about the Charging service, refer to Diameter Offline Charging in MTAS and Diameter Online Charging in MTAS.
Offline Charging
For CCBS invocation in the original call, the Supplementary Service Identity included in the ACR event generated for the original session that resulted in the busy response, is set to the value "CC Busy Subscriber (CCBS) Request". For CCBS invocation in a CC call, there is no invocation indication and the Supplementary Service Identity is set to "CC Busy Subscriber (CCBS) Call". For CCNR invocation in the original call, the Supplementary Service Identity included in the ACR event generated for the original session that was canceled when the caller started CCNR, is set to the value "CC No Reply (CCNR) Request". For CCNR invocation in a CC call, there is no invocation indication and the Supplementary Service Identity is set to "CC No Reply (CCNR) Call". For the subsequent CC Call, the Supplementary Service Identity included in the ACR Start (and in an ACR event if the call is unsuccessful), is set to the value "CC Busy Subscriber (CCBS) Call" for CCBS, and "CC No Reply (CCNR) Call" for CCNR. This applies at the originating end of the call.
Online Charging
For online charging in the original call, when CCxx is started, the Supplementary Service Identity included in the Credit Control Request (CCR) Terminate Request that is generated for the unsuccessful attempt to establish a communication session, is set to the value "CC Busy Subscriber (CCBS) Request" for CCBS and to the value "CC No Reply (CCNR) Request" for CCNR.
For a CC call, the Supplementary Service Identity included in the Credit Control Request (CCR) Initial Request, is set to the value "CC Busy Subscriber (CCBS) Call" for CCBS, and "CC No Reply (CCNR) Call" for CCNR. If the call is not allowed to continue, the MTAS rejects the call.
If the CC call is allowed to continue, the caller is also allowed to start CCBS or CCNR service if invocation of the CCBS or CCNR service is offered to the caller.
2.3.5 Communication Barring
The Incoming Communication Barring (ICB) takes precedence over CCxx. If a call is rejected by the ICB, then CCxx is not offered in the response sent to the CCxx Caller.
For the CC Recall INVITE to the CCxx Caller Outgoing Communication Barring (OCB) is not applied. For the CC Call to the CCxx Called Party, normal OCB checks are applied by the originating MTAS and ICB checks by the terminating MTAS.
For more information about the CB service, refer to MTAS Barring and Dial Plan Services Management Guide.
2.3.6 Communication Diversion
The CC interaction with the CDIV service is described in this section.
For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.
Communication Forwarding Unconditional
Existing CCxx requests are suspended (for example, users are not monitored and no requests are unqueued) when a user activates Communication Forwarding Unconditional (CFU). CCxx is not offered on calls diverted by the CFU when the Diverted-To Party responds with a 180 Ringing provisional or a busy final response, or both. The CFU does not divert CC Recalls or CC Calls.
Communication Forwarding Not Logged In
Existing CCxx requests are not suspended, if the user activates Communication Forwarding Not Logged in (CFNL), but remains registered. The CCxx service duration timers continue to run. CCxx requests are processed normally when the user becomes available.
CCxx is not offered if the call diverts on CFNL and the Diverted-To Party responds with a 180 Ringing provisional or a busy final response, or both.
For CFNL, CC Recalls or CC Calls cannot be diverted by CFNL, since the user is deregistered and the CC requests are revoked.
Communication Forwarding on Busy
Existing CCxx requests are not suspended if the user activates Communication Forwarding on Busy (CFB). The CCxx service duration timers continue to run. CCxx requests are processed normally when the user becomes available.
The CCBS is offered from user B after CFB to user C results in a non-200 OK final response or when the triggered mtasCcbsProvisionalResponseTimer timer (see Section 3.4 Additional Configuration for CCBS) is expired. The mtasCcbsProvisionalResponseTimer is triggered by any 18x response from user C following the CFB from user B.
CCNR is not offered if the call diverts on CFB and the Diverted-To Party responds with a 180 Ringing provisional response.
The CFB does not divert CC Recalls or CC Calls.
Communication Forwarding on No Reply
Existing CCxx requests are not suspended if the user activates Communication Forwarding on No Reply (CFNR). The CCxx service duration timers continue to run. CCxx requests are processed normally when the user becomes available.
The CCBS is not offered if the call diverts on CFNR and the Diverted-To Party responds with a busy final response.
CCNR is not offered if the CCxx Called Party has the CFNR service activated, nor if after CFx, the Diverted-To Party responds with a 180 Ringing provisional, which contains a CCNR Possible Indicator.
The CFNR does not divert CC Recalls or CC Calls.
Communication Forwarding Not Reachable
Existing CCxx requests are not suspended if the user activates Communication Forwarding Not Reachable (CFNRc). The CCxx service duration timers continue to run. The CCxx requests are processed normally when the user becomes available.
CCxx is not offered if the call diverts on CFNRc and the Diverted-To Party responds with a 180 Ringing provisional or a busy final response, or both.
The CFNRc does not divert CC Recalls or CC Calls.
Communication Deflection
If the Communication Deflection (CD) service is active at Node level, then if a CCxx Called Party responds to a communication attempt with 302 and a 180 Ringing provisional or a busy final response, or both, is received from the Deflected-To party, then CCxx is not offered.
If the CD is active at Node level, then if a CCxx Caller responds to a CC Recall Call attempt with 302, then the 3PCC Call is ended and the CC request is terminated. If a CCxx Called Party responds to a CC Call attempt with 302, then the CC call is rejected with a 480 response and the associated CC request is terminated.
2.3.7 Communication Waiting
The Communication Completion by No Reply (CCNR) service is not offered from user B if Communication Waiting (CW) is started at the CCxx Called Party. If a called user rejects a CW request, then the Completion of Communication to Busy Subscriber (CCBS) service is offered, subject to the normal conditions being met. CW is not offered as a result of a CC call.
For more information about the CW service, refer to MTAS Communication Waiting Management Guide.
2.3.8 Conference
The Conference Creator or participants, or both, can also have the CC service activated in a conference.
If a Conference Creator adds a participant to a conference, and the participant returns a response containing a CCxx Possible Indicator, the conference focus does not include a CCxx Possible Indicator in the NOTIFY sent to the Conference Creator. Therefore, the Conference Creator does not receive any indication that CC is possible to the Conference Participant.
For more information about the conference service, refer to MTAS Ad-hoc Conference Management Guide.
2.3.9 Flexible Communication Distribution
A user can only be provisioned with the FCD service if that user has the CC Opt-Out service provisioned for both the CCBS and CCNR.
The FCD service removes the CC possible indications from provisional and final responses from the non-IMS Primary User and from the Related Users.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
2.3.10 Identity Presentation
The CC interaction with the Identity Presentation services is described in this section.
For more information about the Identity Presentation services, refer to MTAS Identity Presentation Management Guide.
Originating Identity Presentation
The Originating Identity Presentation (OIP) service is applied at the originating MTAS on the CC Recall INVITE to the CCxx Caller.
The OIP is applied at the terminating MTAS on the CC Call INVITE to the CCxx Called Party.
Originating Identity Restriction
The Originating Identity Restriction (OIR) is applied at the originating MTAS on the CC Call INVITE to the CCxx Called Party, using the same information as received in the original received INVITE.
Terminating Identity Presentation
The Terminating Identity Presentation (TIP) is not applicable at the originating MTAS for the CC Recall to the CCxx Caller, and not for the CC Call to the CCxx Called Party. This is because a 3PCC sequence is being followed and responses are not passed on.
Terminating Identity Restriction
The Terminating Identity Restriction (TIR) service is not applicable at the originating MTAS for responses to the CC Recall INVITE to the CCxx Caller, since a 3PCC sequence is being followed and responses are not passed on. The TIR is applied at the terminating MTAS on responses to the CC Call INVITE that was sent to the CCxx Called Party.
Calling Name Identity Presentation
The Calling Name Identity Presentation (CNIP) service is applied at the terminating MTAS on the CC Call INVITE to the CCxx Called Party.
CNIP is not applied by the originating MTAS on the CC Recall INVITE to the CCxx Caller.
2.3.11 Malicious Communication Identification
The CC interaction with the Malicious Communication Identification (MCID) service is described in this section.
For more information the MCID service, refer to MTAS Malicious Communication Identification Management Guide.
Permanent Mode
The permanent mode the MCID service applies to an incoming CC Call from a CCxx Caller, but not to CC Recall INVITE messages resulting from a maturing CC request.
Temporary Mode
The temporary mode in the MCID applies if the last incoming call was a CC Call from a CCxx caller, but does not apply if the last incoming call was a CC Recall resulting from a maturing CC request. A CC Recall is never reported. The last non-CC Recall call is always included in the report.
2.3.12 Priority Call
The CC Call INVITE messages have the same priority as the original INVITE on which CCxx was started.
For more information about the Priority Call service, refer to MTAS Priority Call Management Guide.
2.3.13 Serial and Parallel Ringing
If the terminating CCxx subscriber has serial or parallel ringing, then an original call is forked by the terminating Call Session Control Function (CSCF) and multiple 180 Ringing responses can be received at the originating side, each containing a CCNR Possible indicator. Only the first indicator received is acted upon. An indicator received in a subsequent response is removed and ignored.
If the originating CCxx subscriber also has serial or parallel ringing, then a CC Recall INVITE is forked by the terminating CSCF to all terminals that are currently registered.
If the terminating CCxx subscriber also has serial or parallel ringing, then a CC Call INVITE is forked by the terminating CSCF to all terminals that are currently registered.
The originating MTAS handles multiple responses to a forked CC Recall or CC Call INVITE from the Calling or Called Party in a 3PCC initiated call and prevent them from being passed on.
2.4 Configuring iFC
An Initial Filter Criteria (iFC) configuration is required in the HSS for the CC services to work and provides both the triggering for CC-related SIP messages to the terminating MTAS and to prevent other SIP messages originating from an MTAS from being triggered to come back to through the MTAS again. For iFC configuration, see Section 3.7 iFC in HSS Configuration.
2.5 Playing Announcements and Collect CC Invocation
In MTAS there are two ways for playing announcements and collect CC invocation:
- Using internal MRFC and external MRFP. In this case MTAS operates external MRFPs by use of the standard Mp interface.
- Using External MRFC. In this case MTAS operates External MRFC by use of the standard Mr interface.
- Note:
- Either internal or External MRFC can be used, but only one at a time. By default, the internal MRFC is used.
For further details, refer to MTAS Media Control Management Guide.
2.5.1 Internal MRFC and External MRFP Use
The MRFP plays announcements and collects Dual-Tone Multifrequency (DTMF) digits inband. The MRFP is controlled by the CC service through the Mp (H.248) interface.
It is possible through configuration and user provisioning to allow a user to start the CC services by DTMF digit detection only, or by Interactive Voice Recognition (IVR) only, or by both methods.
For information on the CCBS and CCNR Play start Prompt announcement configurations, see Section 3.4 Additional Configuration for CCBS and Section 3.5 Additional Configuration for CCNR. Use the MRFP Play Collect announcements path being correctly configured by setting a value in the mtasMrfPlaycolAnnouncementURI. This attribute must be configured with the physical location the directory on the MRFP where the announcement files are stored. The wildcard ‘$’ parameter must be included at the end of the path to allow the announcement code substitution to occur.
For the CC IVR configuration, see Section 3.6 Configure IVR Specific Attributes, uses the MRFP grammar path being correctly configured by setting a value in the mtasMrfAsrGrammarFileUri attribute. This attribute must be configured with the physical location in the directory where the grammar files are stored. The wildcard ‘$’ parameter must be included at the end of the path to allow the grammar code substitution to occur.
For further details, refer to Managed Object Model (MOM)
2.5.2 External MRFC Use
The MRFC controls the playing of announcements and collecting the DTMF digits inband. The MRFC is controlled by the CC service through the Mr interface.
It is possible through configuration and user provisioning to allow a user to start the CC services by DTMF digit detection only, or by Interactive Voice Recognition (IVR) only, or by both methods.
For the CCBS and CCNR Play start Prompt announcement configurations, see Section 3.5 Additional Configuration for CCNR and use the External MRFC announcements path being correctly configured by setting a value in the mtasMrControllerBaseUrl. This attribute must be configured as a symbolic link or physical location in the directory on the MRFP where the announcement files are stored. The wildcard ‘$’ parameter must be included in the path to allow the announcement code substitution to occur.
For the CC IVR configuration, see Section 3.6 Configure IVR Specific Attributes and use the MRFP grammar path being correctly configured by setting a value in the mtasMrfAsrGrammarFileUri attribute. This attribute must be configured with the physical location in the directory where the grammar files are stored. The wildcard ‘$’ parameter must be included at the end of the path to allow the grammar code substitution to occur.
The CC IVR configuration also uses the DTMF grammar file being correctly configured by setting a value in the mtasMrControllerBaseUrl attribute. This attribute must be configured with the physical location in the directory where the DTMF grammar file is stored.
For further details, refer to Managed Object Model (MOM).
2.6 CC Routing
The CC INVITEs are always sent through the I-CSCF which name is configured in the mtasSipIcscfName.
3 CC Service Configuration
The CC service is controlled by the MtasCc, MtasCcbs, and MtasCcnr MOs and their attributes.
An overview of the CC MO structure is shown in Figure 1.
For configurable MOs and attributes related to the CC service, refer to Managed Object Model (MOM).
3.1 CC Timers Configuration
The attributes to define the generic timers used to for all the CC services, included in the MtasCc MO, are shown in Table 1.
|
mtasCcInbandInvocationTimer |
|
mtasCcT2RequestOperationTimer |
|
mtasCcT4RecallTimer |
|
mtasCcT8DestIdleGuardTimer |
|
mtasCcT9RecallTimerOffset |
3.2 CC Notifier-Configured Minimum Configuration
The attribute to define the value of notifier-configured minimum, included in the MtasCc MO, are shown in Table 2.
|
mtasCcMinServiceDuration |
For more information about the CC Notifier-Configured Minimum attribute, refer to Managed Object Model (MOM).
3.3 Announcements Configuration
For attributes to define the audio, video, or audio-video codes for generic CC announcements included in the MtasCc MO, refer to MTAS Announcement Management Guide.
- Note:
- The following announcements do not have play control parameters:
- CcInvokeSuccess
- CcInvokeFail
- CcBusyTone
- CcCallFailed
- CCRecall
- CCRingTone (only if CCRecall is disabled)
- CcbsInvocationPrompt
- CcnrInvocationPrompt
These announcements are played on an already established media stream. Therefore, the announcement codes used depend on the play control attributes of the first announcement that established the stream. The announcements that can establish the media stream are as follows:
or;
From the following child MOs:
3.3.1 Announcement Configuration for CCxx
The MTAS supports playing an announcement (same announcement for all cases) before sending the SIP error response in the following cases related to unsuccessful invocation of the CCxx service:
- The user fails to enter the invocation code (CCxx Indicated - Unsuccessful Invocation, Not Invoked)
- The user says no to the invocation question (CCxx Indicated - Unsuccessful Invocation, User says No)
- The user responds with the wrong invocation code (CCxx Indicated - Unsuccessful Invocation, Wrong Code
- The user voice response cannot be understood (CCxx Indicated - Unsuccessful Invocation, Unrecognized speech)
To configure additional announcement for each error case, the user must specify the value of mtasCcInvokeUserErrorAnnouncementName. This parameter symbolizes the name of Generic Announcement which is played.
3.4 Additional Configuration for CCBS
Additional configuration activities for the CCBS service are listed in Table 3.
|
Activity |
Attribute |
|---|---|
|
Setting invocation code |
mtasCcbsInvocationCode |
|
Setting Suspend Resume functionality |
mtasCcSuspendResumeFunction |
|
Setting CC Retain Option |
mtasCcRetainOption |
|
Setting timers |
mtasCcbsT3ServiceDurationTimer |
|
mtasCcbsT7ServiceDurTimerOffset | |
|
mtasCcbsInvokePromptAVAudioAnn | |
|
mtasCcbsProvisionalResponseTimer |
For more information about the CCBS attributes, refer to Managed Object Model (MOM).
3.5 Additional Configuration for CCNR
Additional configuration activities for the CCNR service are listed in Table 4.
|
Activity |
Attribute |
|---|---|
|
Setting invocation code |
mtasCcnrInvocationCode |
|
Setting Suspend Resume functionality |
mtasCcSuspendResumeFunction |
|
Setting CC Retain Option |
mtasCcRetainOption |
|
Setting timers |
mtasCcnrT3ServiceDurationTimer |
|
mtasCcnrT7ServiceDurTimerOffset | |
|
mtasCcnrT5NoReplyTimer |
For more information about the CCNR attributes, refer to Managed Object Model (MOM).
- Note:
- The sending of 199 Early Dialog Terminated message for CCNR invocation is affected by the mtasMmt199Method attribute. For the full description, refer to MTAS MMTel Management Guide.
3.6 Configure IVR Specific Attributes
The CC service can be started using IVR by setting the attribute mtasCcIvr in the MtasCc MO to Enabled.
To enable IVR, do the following:
- Navigate to the MtasCc MO.
- In the Table Editor window, set the mtasCcIvr attribute to 1 (Enabled).
- Click Submit.
The attribute mtasCcIvrYesGrammar in the MtasCc MO is to be set to the code of the grammar file used when prompting a user to start CC.
3.7 iFC in HSS Configuration
This section describes how to configure Initial Filter Criteria (iFC) against users in the HSS.
3.7.1 Added iFC Triggers
The new iFCs required are found in Table 5.
|
Reason |
iFC |
|---|---|
|
Routing of Communication Completion out of dialog SUBSCRIBE to the MTAS |
Add to HSS-ServiceProfile for MMTel: HSS-Trigger2ApplicationServers: <xxx>:sip\:<as domainname>;call=term;lr:(1) New HSS-ServiceTrigger: HSS-TriggerPriority: <xxx>(1). HSS-IsActive: TRUE HSS-DetectionPoint: SUBSCRIBE HSS-NegatedDetectionPoint: FALSE HSS-SIPHeaders: FALSE:Event:/call-completion/i HSS-RequestedURI: HSS-TriggerType: NOT_ORIGINATING HSS-TriggerDescription: Communication Completion Subscriptions HSS-NegatedRequestedURI: FALSE HSS-ConditionType: AND |
(1) <xxx> is the terminating trigger priority.
3.7.2 Modifications to Existing iFC Triggers
The existing iFCs to be modified are found in Table 6.
|
Reason |
iFC |
|---|---|
|
Terminating iFC trigger suppression for 3PCC Communication Completion INVITE to served user (A) |
Change to HSS-ServiceProfile for MMTel: HSS-Trigger2ApplicationServers: (1)sip\:<as domainname of the AS that generated INVITE >;call=term;lr: Changed HSS-ServiceTriggers: HSS-TriggerPriority: (1) HSS-IsActive: TRUE HSS-DetectionPoint: INVITE HSS-NegatedDetectionPoint: FALSE HSS-SIPHeaders: HSS-RequestedURI: /noifc=term/i HSS-TriggerDescription: <existing text> HSS-NegatedRequestedURI: TRUE HSS-ConditionType: AND |
|
Originating iFC trigger suppression for 3PCC CC INVITE to called user (B) |
HSS-ServiceProfile for MMTel: HSS-Trigger2ApplicationServers: (1)sip\:<as domainname of the AS that generated INVITE >;call=orig;lr: Change HSS-ServiceTrigger: HSS-TriggerPriority: (1) HSS-IsActive: TRUE HSS-DetectionPoint: INVITE HSS-NegatedDetectionPoint: FALSE HSS-SIPHeaders: HSS-RequestedURI: /noifc=orig/i HSS-TriggerDescription: <existing text> HSS-NegatedRequestedURI: TRUE HSS-ConditionType: AND |
|
Originating iFC trigger suppression for Communication Completion SUBSCRIBE. |
HSS-ServiceProfile for MMTel: HSS-Trigger2ApplicationServers: (1)sip\:<as domainname of as that generated SUBSCRIBE>;call=orig;lr: Change HSS-ServiceTrigger (only if existing): HSS-TriggerPriority: (1) HSS-IsActive: TRUE HSS-DetectionPoint: SUBSCRIBE HSS-NegatedDetectionPoint: FALSE HSS-SIPHeaders: HSS-RequestedURI: /noifc=orig/i HSS-TriggerDescription: <existing text> HSS-NegatedRequestedURI: TRUE HSS-ConditionType: AND |
(1) This is the existing trigger priority.
(2) An existing trigger or
triggers that have any of the values: TERMINATING_REGISTERED, TERMINATING_UNREGISTERED, NOT_ORIGINATING.
(3) If
there is an existing trigger type that is blank or set to the value NOT_TERMINATING_REGISTERED, or NOT_TERMINATING_UNREGISTERED, then the trigger must be replaced by separate triggers covering
the Originating and Terminating side independently.
(4) This is only required if an originating iFC trigger for SUBSCRIBE exists or is created in the future, otherwise
this trigger modification is not required.
3.8 CC Administrative State Configuration
The CC service is enabled by setting the mtasCcAdministrativeState attribute in the MtasCc MO to 1 (Unlocked). If the mtasCcAdministrativeState is set to 0 (Locked), no CC service is provided by the MTAS.
3.9 Wholesale for CC Configuration
The CC service supports Wholesale. CC is configurable on Virtual Telephony Provider level.
Wholesale for CC is activated when the following attributes are set to 1 (Unlocked):
- The vtasCcAdministrativeState attribute in the VtasCc MO
- The mtasCcAdministrativeState attribute in the MtasCc MO
For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.
3.10 Service Data Configuration
This section describes how to configure the service data.
3.10.1 Operator Subscription Level Service Configuration
The operator can activate or deactivate the Agent part of the CCBS subscription for the subscriber, and deactivate the Monitor part of the CCBS subscription for the subscriber by setting the user data using the CAI3G protocol.
For more information about the CAI3G protocol, refer to MTAS CAI3G Interface.
3.10.2 Subscriber Subscription Level Service Configuration
No service data for the CC services is configured in the subscriber part of the subscriber data.
4 Performance Management
For measurements related to the CC services, refer to Managed Object Model (MOM).
5 Fault Management
For alarms related to the CC services, refer to MTAS Alarm List.