MTAS Communication Diversion Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1License Control
2.2Subfunctions
2.3CDIV Interaction with Other Services
2.4Traffic View
2.5Configuration View

3
Subscription Rules
3.1Rule Evaluation Points

4
Find the Target

5
Handle to Headers

6
Handle History-Info Headers
6.1Check Maximum Number of Diversions in Network

7
Diversion Indication to Caller

8
Diversion Indication to Served User

9
Service Activated Indication to Served User

10
Presence

11
Diversion after BYE

12
CDIV Service Configuration
12.1Announcement Configuration
12.2Default Voicemail Address Configuration
12.3Additional Configuration
12.4DTM Configuration
12.5SSC Configuration
12.6CDIV Administrative State Configuration
12.7Wholesale for CDIV Configuration
12.8Service Data Management

13
Performance Management

14
Fault Management

15
Example Configuration
15.1Forward All Calls from Alice
15.2Forward All Anonymous Calls
15.3Forward All Video Calls
15.4Forward All Calls from Coventry
15.5Forward Anonymous to Voicemail and Video to David
15.6Forward Video to David and Anonymous to Voicemail
15.7Forward All Anonymous Video Calls
15.8Multiple Independent Rules
15.9Forward Calls Based on Presence
15.10Forward Calls after Different No-Answer Time Periods
15.11Forward Call Upon DNDCF Service Activation
15.12Forward Call Upon DNDCF Service Activation Playing Generic Announcement
15.13Forward Calls at Given Periods
15.14Forward Calls Based on Served Identity
15.15Operator Forward Calls on Anonymous and after Served User Rules Operator Forward Calls on Not-Registered

1   Introduction

This document describes how to configure the Communication Diversion (CDIV) 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 basic services in the MTAS, the MMTel license must be installed.

To control the advanced CDIV service, the MMTel Extended license must be installed. For more information about the MTAS licenses, 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 CDIV supplementary service enables a served user to have the network redirect communication to another user. This applies to communication addressed to the served user that meets conditions in the CDIV rule sets, and for communication redirected by the User Agent (UA) of the served user. There are three CDIV rule sets. Two rule sets in the operator part, where the first is evaluated before the user rule set, which is in the user part, and the other rule set is evaluated after the user rule set (post-evaluated). The CDIV service operates on all communications in the service format Multimedia Telephony (MMTel). The served ability of the user to originate communications is unaffected by the CDIV supplementary service.

Configuration of the CDIV service mainly includes the following activities:

Telephony communication to IMS subscribers is routed to an MTAS based on Initial Filter Criteria in the Call Session Control Function (CSCF). The CDIV function implements the CDIV PSTN/ISDN simulation services for an Application Server (AS), in conformance with the 3GPP TS 24.604 V8.4.0specification.

The CDIV coexists with other simulation services on the same MTAS, for example, Communication Barring (CB) and Hold. CDIV-not-logged-in can be triggered (depending on a CM attribute mtasMmtTermUnregBehavior in the MMTel service) after a Session Initiation Protocol (SIP) 480 response is received in the terminating MTAS on the terminating unregistered port after an initial INVITE has been received and sent to S-CSCF.

For more information about the MMTel service, refer to MTAS MMTel Management Guide.

The CDIV function is triggered by the initial SIP INVITE method and actuated by data values and responses from the served user’s UA and time-outs. Depending on configuration data, the CDIV not-logged-in service can trigger the SIP 480 Temporarily Unavailable response instead of the initial INVITE where the triggering on the SIP 480 response is the default behavior. If 480 response code is included in any of the response code CM attributes (mtasCDivNoReplyResponses, mtasCDivNotReachableResponses, mtasCDivBusyResponses), CDIV service must check the rules for true condition (no reply condition, not reachable condition, busy condition). If no rules found with true condition, the default CDIV-not-logged-in action must be executed. The CDIV function is executed at the served user's MTAS when the served user initiates an outgoing communication, depending on configuration data set by the subscriber.

The maximum number of diversions permitted for each communication is a service provider option by the MTAS configuration. The communication is rejected when the maximum is exceeded.

When communication is diverted and AS chaining is disabled, originating services are executed internally in the terminating session case in the terminating MTAS. There is no AS chaining of originating services before the session is routed towards the new target.

When communication is diverted and AS chaining is enabled, the INVITE is returned to S-CSCF after retargeting, the S-CSCF initiates triggering of originating services by sending the INVITE to the terminating MTAS for an originating session case. AS chaining can then be performed before the session is routed towards the new target.

For more information about Originating AS chaining, refer to MTAS SIP Management Guide.

Although the CDIV service is provisioned and activated for the served user, a Communication Diversion attempt can be suppressed by the Flexible Service Format Selection (FSFS) service. The meaning of suppression here is that the incoming communication is handled as if the service was not active.

For more information about the FSFS service, see Section 2.3.12 Flexible Service Format Selection or refer to MTAS Flexible Service Format Selection Management Guide.

2.1   License Control

Communication Deflection (CD) is a flavor of CDIV which does not require any rules but always diverts when triggered by a "deflection" redirect response from the served user's UA. The CD is controlled by the MMTel Extended license on the MTAS, refer to MTAS Licenses.

Otherwise, CDIV determines if the communication is diverted by evaluating CDIV rules. The rules are built up with different conditions and a forward-to action together with other optional actions such as do-not-disturb and play-announcement. They can be combined in many ways to express if a communication is to be diverted and if notifications are to be sent.

The Do Not Disturb Communication Forwarding (DNDCF) option, as the diversion part of the Do Not Disturb (DND) service, is a type of CDIV that diverts incoming communication when the served user does not wish to be interrupted by incoming calls and activates the service.

The DNDCF service is implemented as the extension of the rule set of the CDIV service. The DNDCF service is controlled by the MMTel Extended License on the MTAS. If there is no valid MMTel Extended License, then the CDIV service does not forward the communication setup attempt.

The following condition elements are not controlled by the license:

The following condition elements are controlled by the license if no valid license is available on the MTAS node. Any rule containing these condition elements are ignored when the rules are evaluated for the CDIV service:

The action elements comprise the following items:

The forward-to action has the following elements:

The CD uses the following values of the action elements:

Traditional call forward services can be simulated by a subset of the following CDIV condition and action elements:

2.2   Subfunctions

This section describes the subfunctions provided by the CDIV service.

2.2.1   Rules Evaluation

This is a subfunction that evaluates the served user's subscription rules and conditions that can actuate a diversion. This function is affected by the license and is further described in Section 3 Subscription Rules.

2.2.2   Find the Target

This subfunction constructs the Request URI in the outgoing INVITE and is further described in Section 4 Find the Target.

2.2.3   Handle to Headers

This subfunction checks if the served user wishes to conceal their identity and updates the To header as required and is further described in Section 5 Handle to Headers.

2.2.4   Handle History-Information

This subfunction evaluates and sets the History-Info header used for checking the maximum number of diversions allowed for the communication and is further described in Section 6 Handle History-Info Headers.

2.2.5   Diversion Indication to Caller

This is a subfunction that indicates to the caller that the communication is being diverted. As a node level configuration option the subfunction Play Announcement is performed. This subfunction is further described in Section 7 Diversion Indication to Caller.

2.2.6   Play Announcement

This subfunction plays an announcement to the caller when the communication has been diverted.

There are two different ways of playing an announcement:

For more information about announcement handling and attributes for the CDIV service, refer to the following documents:

2.2.7   Diversion Indication to Served User

This is a subfunction that indicates to the served user that the communication is being diverted and is further described in Section 8 Diversion Indication to Served User.

2.2.8   Service Activated Indication to Served User

This is a subfunction that indicates to the served user that communication diversion rules are active. This subfunction is triggered by an originating INVITE on the AS-Originating. This subfunction is further described in Section 9 Service Activated Indication to Served User.

2.2.9   Presence

This subfunction polls the served user state, for example, "at lunch", "offline" as is further described in Section 10 Presence.

2.2.10   Diversion after BYE

This subfunction diverts the call to a preconfigured voicemail address if BYE is received from the network after 200 OK for initial terminating INVITE is received. See Section 11 Diversion after BYE for more details on diversion after BYE.

2.3   CDIV Interaction with Other Services

The CDIV interaction with other MTAS services is described in this section.

When communication is diverted and AS chaining is disabled, the served user's outgoing originating services are executed internally in the terminating session when served user B’s AS sets up the dialog to the diverted user C.

When communication is diverted and AS chaining is enabled, the INVITE is returned to S-CSCF after retargeting, the S-CSCF initiates triggering of originating services by sending the INVITE to the terminating MTAS. The served user's outgoing originating services are executed in the originating session case when served user B’s AS sets up the dialog to the diverted user C.

After diversion, the served user's terminating AS will be kept in the message path, and changes from a terminating AS mode to a "transit" mode. Other services act differently for this AS compared to originating or terminating AS.

For more information about Originating AS chaining, refer to MTAS SIP Management Guide.

2.3.1   Call Admission Control

This section describes the CDIV interaction with the following Call Admission Control (CAC) services:

For more information about the CAC services, refer to MTAS Call Admission Control Management Guide.

2.3.1.1   User Call Admission Control

The UCAC service does not count diverted calls. If UCAC disallows a terminating call, a Communication Forwarding on Busy (CFB) rule would be triggered.

2.3.1.2   Group Admission Control

The GCAC conditionally counts the outgoing leg of diverted calls, depending on node level configuration by the operator. If GCAC disallows a terminating call, a CFB rule would be triggered.

2.3.2   Carrier Select

The CDIV target can contain a Carrier Select (CS) Code.

For more information about the CS service, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.

2.3.3   Carrier Pre-Select

The CDIV target can contain a Carrier Pre-Select (CPS) Code.

For more information about the CPS service, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.

2.3.4   Charging

Terminating charging is performed on incoming leg (A to B) and originating charging is performed on outgoing leg (B to C).

The IMS Charging Identifier (ICID) and the originating Inter-Operator Identifier (IOI) in the P-Charging-Vector header within the initial INVITE request received by the diverting MTAS, are used for charging on incoming leg (A to B). The originating IOI received in the P-Charging-Vector header in responses from the diverted to party is used as the terminating IOI for charging on incoming leg (A to B).

The diverting MTAS allocates a new ICID for charging on outgoing leg (B to C). The diverting MTAS generates a P-Charging-Vector header containing the new ICID and the original ICID received on the incoming leg and includes it in the initial INVITE sent to the diverted-to party. The Originating IOI (O-IOI) and Terminating IOI (T-IOI) received in the P-Charging-Vector header in responses from the diverted-to party are used for charging on outgoing leg (B to C).

For more information about the Charging service, refer to the following documents:

2.3.5   Communication Barring

Incoming Communication Barring (ICB) is performed on the terminating INVITE before the CDIV. Outgoing Communication Barring (OCB) is performed on the diverted outgoing INVITE. When OCB holds up the diverted outgoing INVITE, the initial INVITE is answered by 486 Busy Here response towards the Caller A.

For more information about the CB services, refer to MTAS Barring and Dial Plan Services Management Guide.

2.3.6   Communication Completion

The Communication Completion (CC) service interacts with the CDIV service. For the interactions, refer to MTAS Communication Completion Management Guide.

2.3.7   Communication Waiting

The Communication Waiting (CW) service interacts with the CDIV service. For the interactions, refer to MTAS Communication Waiting Management Guide.

2.3.8   Conference

The focus rejects diverted incoming calls. The focus accepts diversion of dial-out calls. For more information about the conference services, refer to the following documents:

2.3.9   Customized Alerting Tones

Interactions between the Identity Presentation and the Customized Alerting Tones services are described in MTAS Customized Alerting Tones Management Guide.

2.3.10   Dial Tone Management

The Dial Tone Management (DTM) service interacts with the CDIV service rule Communication Forwarding Unconditional (CFU). When a request is made to activate or deactivate CFU, it can result in a DTM notification being sent.

For more information about the notify types, notify messages, and DTM configuration attributes, refer to the following documents:

2.3.11   Flexible Communication Distribution

In the terminating MTAS, Flexible Communication Distribution (FCD) is started before CDIV service if mtasFcdCDivInvocationSequenceControl is set to 0. However, when mtasFcdCDivInvocationSequenceControl is set to 1, CDIV is started before FCD. In the last case, if an incoming communication is diverted by CFU or DNDCF, then FCD is never started.

For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.

2.3.12   Flexible Service Format Selection

The CDIV service can be suppressed with the Flexible Service Format Selection (FSFS) service. The FSFS service can suppress the CDIV service both in the terminating registered and terminating unregistered MTAS. When the FSFS service suppresses the CDIV service, the incoming communication is processed as if that CDIV service was not active.

The CD, CFU, CFB, CFNR, CFNRc, CFNL, and DNDCF service can be configured separately to support the FSFS service. During the rule evaluation, the matched and activated rules of the suppressed CDIV service is ignored and bypassed by MTAS. MTAS does not report the charging information of the suppressed CDIV service.

It is also possible to configure the FSFS service whether to suppress a CDIV service that has voicemail target only, to suppress a CDIV service that has regular (non-voice mail) target only, or to suppress both.

In the case of service suppression by the FSFS service, MTAS determines that a CDIV service has target to voicemail if at least one of the following conditions is fulfilled:

For more information about the FSFS service, refer to MTAS Flexible Service Format Selection Management Guide.

2.3.13   Hold Communication

The Hold Communication service does not act in the MTAS of the served user (B) of CDIV, if the communication is diverted (to C), only in the end user's ASs.

For more information about the Hold Communication service, refer to MTAS Hold Communication Management Guide.

2.3.14   Identity Presentation

This section describes the CDIV interactions with the following Identity Presentation services:

For more information about the Identity Presentation services, refer to MTAS Identity Presentation Management Guide.

Flexible Identity Presentation

If the served user has the FIP service active, then the FIP service is started on the forwarded call leg. The FIP service will add the "privacy=history" string after the served user’s identity in the history-info header to protect it from being revealed to other users.

Originating Identity Presentation

The P-Asserted-Identity remains unchanged by the CDIV.

Originating Identity Restriction

The Privacy header "history" is escaped within the hi-targeted-to-uri field (in the History-Info header) containing the diverting user's identity in the INVITE message, if the served user has OIR.

Note:  
No conversion from tel URI is required since the last History-Info entry containing the diverting user's identity always contains a SIP URI.

The To header is changed to the targets URI if the served user has OIR.

The CDIV target can include the Ad-hoc presentation code.

When the CLIR Interworking service is unlocked and if the calling party has Originating Identity Restriction active, the subscriber defined cp:identity rules are not evaluated.

For more information about the Identity Presentation services, refer to MTAS Identity Presentation Management Guide.

Terminating Identification Presentation

A P-Asserted-Identity and History-Info header field received in the diverting AS is passed unmodified to the originating entity. The originating S-CSCF is responsible for the interpretation of the Privacy header field.

Terminating Identification Restriction

A P-Asserted-Identity header field received in the diverting AS is passed unmodified to the originating entity.

If the served user has TIR, the Privacy header field is included in the 181 ("Call is Being Forwarded")/183 response.

If the served user has TIR, the Privacy header "history" is escaped within the hi-targeted-to-uri field containing the diverting user's identity in the History-Info header passed to the originating entity in all responses. This applies if the History-Info header was included by the MTAS or was already in the response. The originating CSCF is responsible for the interpretation of the Privacy header field.

Note:  
Conversion from tel URI to SIP URI may be required because the History-Info can contain a tel URI in the last History-Info entry and tel URI do not support the Privacy header.

2.3.15   Priority Call

If the user has the Priority Call service, the priority header is set in the INVITE.

2.3.16   Video Fallback to Audio

Calls diverted by CDIV service are subject to the Video Fallback to Audio service.

For more information about the Video Fallback to Audio service, refer to MTAS Video Fallback to Audio Management Guide.

2.4   Traffic View

CDIV traffic is handled in the following steps:

  1. Service Invocation – an event triggers the execution of CDIV, for example, initial INVITE from the caller.
  2. Rule Evaluation - The CDIV evaluates the rule sets of the operator and the served user, and determines if the communication is to be diverted immediately, or is to be diverted if certain events occur, or is not to be diverted.
  3. Diversion Actuation – either the Rules Evaluation step decides that the communication is to be diverted immediately, or an event identified in Rules Evaluation occurs.
  4. Send Indications – when the communication is going to be diverted or when the service is active, indications can be sent to the caller and served user.
  5. Diversion – the communication is diverted to the target address.

The traffic view of the CDIV is shown in Figure 1. The service is triggered by the initial INVITE over IMS Service Control Interface (ISC).

Figure 1   Main Traffic View of CDIV

The rules are fetched from the Home Subscriber Server (HSS)/Subscriber Locator Function (SLF) through the Sh/Dh interfaces. If a presence condition is included in a rule, the CDIV gets the current presence of the served user through the Pw interface.

Indication to the caller is an INVITE method provisional response 181 over ISC and an announcement can be played, controlled over Mp.

Indications to the served user are sent using a MESSAGE request over ISC.

The communication is diverted with a terminating INVITE to the target address over the ISC.

After diversion, the served user’s terminating AS will remain in the message path with a terminating and an originating session (depending on SIP CM parameters) in "transit" network mode.

Figure 2   MTAS in Transit Mode

2.5   Configuration View

The node-level configuration view of the CDIV is illustrated in Figure 3.

Node-level configuration is performed by the operator where the CDIV function is customized. For example, by defining if an announcement is to be used as indication to the caller, in addition to the SIP response (181 Call is being diverted), and by defining the announcement code, which specifies the announcement to be played.

Figure 3   Configuration View of CDIV

The subscription rules are managed through the XDMS interface that provides the Ut interface (XCAP over HTTP) to the served user and CAI3G to the operator. XDMS uses Sh (Diameter) to update the HSS. The served user accesses the XDMS directly and the operator accesses it through the Business Support System. The served used can access the SSC service through the SIP ISC interface to change diversion settings.

3   Subscription Rules

The subscription rules are expressed with XML, defined by a schema and following the structure illustrated in Figure 4.

The rule set consists of zero or many rules, and one rule consists of zero or many conditions and one action.

The number of rules cannot exceed the limit defined by the <rule-limit> element in the operator part of the service.

The number of rules is also limited by the <rule-global-limit> element of the <common-data>.

Figure 4   CDIV Subscription Elements

The element Rule has one attribute Id that identifies the rule and is independent of the evaluation order.

The top-level CDIV element has an attribute active of type Boolean. If active=true, the rule set is evaluated.

The following conditions apply to the CDIV:

Figure 5   Anonymity Algorithm

If there is no valid license available on the MTAS node, all rules containing a condition element which is controlled by the license are ignored when the rules are evaluated for the CDIV service.

The rule can contain the following actions:

The forward-to action can have the following action elements:

The condition elements that are not taken from the common policy schema or OMA common policy schema are defined in the simservs document schema.

The format of the rules is checked by the XDMS.

If the service is active, the CDIV evaluates the rules. The rules are evaluated from top to bottom, for example, rule n precedes rule n + 1, where n is the order of appearance, not the rule ID.

A rule is matched if all conditions evaluate to true, meaning that the evaluation of conditions stops when the first condition is false (lazy evaluation). Only the first matching rule and its specified forward-to action elements apply.

3.1   Rule Evaluation Points

The rules are evaluated at each actuation point, as follows:

  1. INVITE for unregistered user
  2. INVITE for registered user
  3. Network determined user busy
  4. Not-reachable time-out
  5. Not-reachable response from user
  6. Busy response from user
  7. 180 from user (No-answer)
  8. Outgoing call by served user

Each rule in the full set of rules is evaluated, from top to bottom, each time an actuating event arrives. Each time the rules are evaluated, the current values of the state of the call are used in the comparison. The time and date used in cp:validity, mmt-serv:valid-periods, and mmt-serv:invalidity conditions are the time and date when the evaluation of the set of rules began. This gives a consistent view of time for the evaluation of a set of rules, and means that users do not need to be unduly concerned about how long it takes to evaluate a set of rules.

All conditions cannot be evaluated to true at all actuation points, as follows:

However, a rule containing a cp:validity, mmt-serv:valid-periods, or mmt-serv:invalidity condition can be false at actuation point 2, but true at actuation points 3, 4, 5, 6, or 7, so that the reason for diverting at actuation point 4-5 may not be not-reachable, the reason for diverting at actuation point 3 or 6 may not be busy, and the reason for diverting at actuation point 7 may not be no answer.

When the rules are evaluated at actuation point 8, only the presence-status, media, cp:validity,mmt-serv:valid-periods, mmt-serv:invalidity and rule- deactivated conditions are evaluated in each rule. All busy, not-registered, cp:identity, anonymous, not-reachable, and no-answer conditions are considered to evaluate to TRUE during rule evaluation at actuation point 8.

When CLIR Interworking service is unlocked and if the calling party has Originating Identity Restriction active, then the subscriber defined cp:identity rules are not evaluated.

For more information about the Identity Presentation services, refer to MTAS Identity Presentation Management Guide.

Section 15 Example Configuration contains examples of different rule sets.

The mmt-serv:served-identity condition is evaluated at each actuation point:

4   Find the Target

If the target action element contains a SIP URI or a tel URI, the CDIV replaces the Request URI of the incoming INVITE with the value from the target action element when constructing the outgoing INVITE.

If the request URI is in a tel format, this is converted to an equivalent SIP URI format. The domain portion of the SIP URI is taken from the domain included in the default PUI obtained from the IRS for the served user.

Example of tel URI conversion:

Default PUI: userC@domain1.com

Request URI: tel:+44247633333

SIP URI included in History-Info header:
sip:+44247633333@domain1.com;user=phone

A cause-param SIP URI attribute is added to the Request URI. The cause-param is embedded in the Request URI. The value is set according to the diversion conditions as follows:

5   Handle to Headers

If the served user does not want to reveal its identity to the diverted-to party, then the To header must be changed to the URI of the target. The served user does not want to reveal its identity when one of the following conditions holds true if the served user has the subscription option reveal-identity-to-target set to false.

Note:  
In all other cases, the To header must not be changed.

6   Handle History-Info Headers

This section describes the handling of the History-Info header.

6.1   Check Maximum Number of Diversions in Network

The CDIV checks if diverting the communication exceeds the number of diversions allowed within the network, defined by the attribute mtasCDivMaxNoOfDiversions. The number of diversions is calculated by counting the History-Info entries with a CDIV cause-param SIP URI attribute. Cause attributes which are valid for communication diversion are explained in Section 6.1.2 Set History-Info Header.

If the number of diversions is equal or greater than the specified limit, defined by the attribute mtasCDivMaxNoOfDiversions, the communication is released.

The following responses apply:

  1. If communication diversion condition busy was present in the matched rule, a 486 (Busy here) is sent.
  2. Otherwise, 480 (Temporarily unavailable) is sent.

In both cases, a Warning header field indicating that the communication is released owing to the extension of diversion hops (48x, warning: 399 mtas.operator1.com "Too many diversions") is sent.

6.1.1   Example of Counting in Branched Diversions

It is assumed that other services, for example, call hunting, add History-Info header entries.

Figure 6 shows CFB (486), Deflection after ringing (487), hunt group (xyz) no response, hunt group (xyz), CFB (486), hunt group (xyz) no response and CFU(302). Only the CDIV cause-param attributes are counted.

Figure 6   Example History-Info

6.1.2   Set History-Info Header

Two entries are added to the History-Info header field if there is no History-Info header present or the last entry does not contain the served user identity. Only the second type of entry is added if it is a subsequent diversion.

Note:  
CDIV does not add tel URIs to History-Info headers because the tel URI scheme does not support the URI cause attributes, Privacy header attributes, or Reason header attributes. All tel URIs must be converted to SIP URIs.

Example of tel URI conversion:

Default PUI: userC@domain1.com
Request URI: tel:+442476333333
SIP URI included in History-Info header:
sip:+44247633333@domain1.com;user=phone

7   Diversion Indication to Caller

When Communication Diversion occurs and if action element notify-caller is true, then a 181 (Call Is Being Forwarded) response is sent towards the caller (A). The 181 (Call Is Being Forwarded) response contains the P-Asserted-Identity header field, the History-Info header field, and conditionally the Privacy header field.

The P-Asserted-Identity includes the URI of the served user.

The 181 response is sent on the existing SIP dialogue if one exists.

Note:  
The CDIV information in the History-Info header field is identical to the CDIV information in the History-Info SIP INVITE message sent in the forward direction, see Section 6 Handle History-Info Headers.

The MTAS does not require a provisional reliable acknowledgment to the 181 (Call Is Being Forwarded) response. This minimizes the number of messages processed by the MTAS. If the INVITE contains 100rel in the Required header, the MTAS requires a provisional reliable acknowledgment to the 181 (Call Is Being Forwarded) response.

Also, CDIV can initiate a network announcement to be included towards the caller to inform about the diversion. The Announcement is played as a configuration option.

8   Diversion Indication to Served User

When Communication Diversion occurs and if action element notify-served-user is true, then a SIP MESSAGE request is sent with information text copied from the value stored in mtasCDivServedUserNotifyMessage, see Figure 7 and Example 1.

This MESSAGE request is sent out of dialog. An Accept-Contact header contains a feature tag part as specified in mtasMmtPrimaryFeatureTag. If mtasMmtPrimaryFeatureTag is defined with a feature tag part such as urn:urn-xxx:3gpp-service.ims.icsi.mmtel the Accept-Contact header contains two feature tags. This is because 3GPP uses two variants of feature tag, namely g.3gpp.icsi-ref and g.3gpp.icsi_ref. They have the same feature tag value: urn: urn-xxx: 3gpp-service.ims.icsi.mmtel.

For more information about the mtasMmtPrimaryFeatureTag, refer to MTAS MMTel Management Guide.

The MESSAGE request is sent by the S-CSCF that sent the INVITE to the MTAS. To achieve this, the MESSAGE request contains a Route header derived from the second Route header received in the INVITE, which addresses the S-CSCF that sent the INVITE. The SIP URI consists of the hostport part of the second Route header, a uri-parameter "lr" to indicate that the request must be subject to loose routing, and a uri-parameter "orig" to indicate that the request is to be treated as if it were a new request sent by the served user.

For more information about the SIP URI, refer to the IETF RFC 3261 specification.

The P-Asserted-Identity is the served user identity and P-Charging-Function-Addresses is taken from the received INVITE.

The P-Charging-Vector contains an icid-value parameter, whose unique value is generated by the MTAS.

Figure 7   Diversion Indication to Served User

If a response other than 200 OK is received, basic behavior is applied, and no action is taken by CDIV.

Example 1   Diversion Indication to Served User

MESSAGE sip:userB@operator1.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com:5083;branch=z9hG4bK776sgdkse
Route: <sip:scscf1.operator1.com;lr;orig>
Max-Forwards: 70
From: mtas@operator1.com;tag=49583
To: sip:userB@operator1.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Accept-Contact:*;g.3gpp.app_ref=”urn%3Aurn-xxx%3A3gppservice.
ims.icsi.mmtel”;g.3gpp.app-ref=”urn%3Aurn-xxx%3A3gppservice.
ims.icsi.mmtel”
P-Charging-Function-Addresses: ccf=ccf1.operator1.com
P-Charging-Vector: icid-value=mOTin47cd9c62a033900100000f8e
P-Asserted-Identity: <sip:userB@operator1.com>
Content-Type: text/plain
Content-Length: --

Communication Diverted

9   Service Activated Indication to Served User

This is performed on outbound call (at CDIV trigger points) from served user, in the originating AS.

The rule set is searched for non-deactivated rules that are currently valid and that match the media and presence of the outbound call. If any rule with the action element notify-served-user-on-outbound-call is matched, then a MESSAGE request is sent with information text copied from the value in mtasCDdivOutgoingCallMessage, see Figure 8 and Example 2.

Figure 8   Service Activated Indication to Served User

The continuation of the MESSAGE and the INVITE flows are in different dialogs that are treated separately.

The Diversion Indication to served user MESSAGE flow is as in Figure 8.

This MESSAGE request is sent out of dialog. An Accept-Contact header contains a feature tag part as specified in mtasMmtPrimaryFeatureTag. If mtasMmtPrimaryFeatureTag is defined with a feature tag part such as urn:urn-xxx:3gpp-service.ims.icsi.mmtel, the Accept-Contact header contains two feature tags because 3GPP uses two variants of the feature tag, g.3gpp.icsi-ref and g.3gpp.icsi_ref. They have the same feature tag value: urn: urn-xxx: 3gpp-service.ims.icsi.mmtel.

For more information about the mtasMmtPrimaryFeatureTag, refer to MTAS MMTel Management Guide.

The MESSAGE request is sent by the S-CSCF that sent the INVITE to the MTAS. To achieve this, the MESSAGE request contains a Route header which includes the SIP URI of the S-CSCF that sent the INVITE. The SIP URI includes a uri-parameter "lr" to indicate that the request must be subject to loose routing, and a uri-parameter "orig" to indicate that the request is to be treated as if it were a new request sent by the served user.

For more information about the SIP URI, refer to the IETF RFC 3261 specification.

The P-Asserted-Identity and P-Charging-Function-Addresses are taken from the received INVITE.

The P-Charging-Vector contains an icid-value parameter, whose unique value is generated by the MTAS.

Example 2   Service Activated Indication to Served User

MESSAGE sip:userA@operator1.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com:5082;branch=z9hG4bK776sgdkse
Route: <sip:scscf1.operator1.com;lr;orig>
Max-Forwards: 70
From: mtas@operator1.com;tag=49583
To: sip:userA@operator1.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Accept-Contact:*;g.3gpp.app_ref=“urn%3Aurn-
xxx%3A3gppservice.ims.icsi.mmtel”;
g.3gpp.app_ref=”urn%3Aurn-xxx%3A3gppservice.ims.icsi.mmtel”
P-Charging-Function-Addresses: ccf=ccf1.operator1.com
P-Charging-Vector: icid-value=mOTin47cd9c60b733900100000f8d
P-Asserted-Identity: <sip:userA@operator1.com>
Content-Type: text/plain
Content-Length: --

You have active diverts

10   Presence

The CDIV acts as a limited watcher and polls the presence status activity information from the Presence Agent only when a CDIV rule containing a presence-status condition is evaluated, and only once during the same session setup.

Rules containing the presence-status are only evaluated if a valid license is available on the MTAS node. If there is no valid license, there is no request for presence-status activity information.

CDIV uses the SUBSCRIBE method to retrieve presence state information, with Expires:0 in the request (and 200 OK) to get an immediate Notify. The subscription is then expired.

The SUBSCRIBE message is sent with the served user’s default PUI, obtained from the Implicit Registration Set, in the P-Asserted-Identity header and in the Request URI, so that the Presence Agent treats the request as if the served user were reading its own presence status, which is always allowed.

The presence activities element that can be matched is a part of the person data structure.

To reduce the size of the notification message, the CDIV polls the activity element using event notification filtering. Event notification filtering is a mechanism for the watcher to control the content of notifications.

If the Presence Agent does not understand the event notification filter in the SUBSCRIBE, it still responds with a NOTIFY, but it contains the whole presence record. Therefore, there is no need to check that the Presence Agent supports event notification filtering.

The SUBSCRIBE message is sent through the S-CSCF that sent the INVITE to the MTAS, so that the MTAS does not have to know which Presence Agent holds the information for each subscriber. To achieve this, the SUBSCRIBE message contains a Route header derived from the second Route header received in the INVITE, which addresses the S-CSCF that sent the INVITE. The SIP URI consists of the hostport part of the second Route header, a URI attribute lr to indicate that the message is to be subject to loose routing, and a URI attribute orig to indicate that the message is to be treated as if it were a new request sent by the served user.

If AS chaining is enabled, the uri-parameter "orig" is added to the Route header to indicate that the message must be treated as if it were an originating request sent by the served user and also the P-Served-User header is added with the served user’s default PUI.

For more information about Originating AS chaining, refer to MTAS SIP Management Guide.

11   Diversion after BYE

After receiving 200 OK for initial terminating INVITE, MTAS can receive a BYE as a result of a fault somewhere in the network.

If BYE is received after reception of 200 OK and before the timer-configured by mtasCDivForwardOnByeTimer (vtasCDivForwardOnByeTimer, in case of wholesale)-expires then CDIV performs a check on the Reason header. If Reason header matches any preconfigured value in mtasCdivForwardOnByeReason (vtasCdivForwardOnByeReason, in case of wholesale) the call is diverted to the preconfigured voicemail address.

If the timer is set to 0, then the Diversion after BYE feature is disabled.

12   CDIV Service Configuration

The CDIV service of the MTAS is controlled by the MtasCdiv MO and its attributes. The MO structure of the CDIV service is shown in Figure 9.

Figure 9   CDIV MO Structure

For configurable MOs and attributes related to the CDIV service, refer to Managed Object Model (MOM).

12.1   Announcement Configuration

The CDIV plays an audio or video announcement, or both, to indicate to the caller that the communication has been diverted.

For announcement handling and CDIV announcement attributes, refer to MTAS Announcement Management Guide.

12.2   Default Voicemail Address Configuration

The default voicemail address of the voicemail server can either be set explicitly by modifying the attribute mtasVoiceMailDepositServerAddress, or implicitly by setting configuration data per subscriber on node level, see Section 12.8.1 Operator Subscription Level Service Configuration.

12.3   Additional Configuration

Additional configuration activities are listed in the following table:

Note:  
Not all CDIV configuration activities are listed Table 1.

Table 1    Additional Configuration Activities

Activity

Attribute

Setting Busy Response value for the CDIV service.

mtasCDivBusyResponses

Setting Not Reachable Response value for the CDIV service.

mtasCDivNotReachableResponses

Setting timer expiring for Not Reachable Response for the CDIV service.

mtasCDivNotReachableTimer

Setting the time interval that the caller must respond within, before a session is forwarded.

mtasCDivTimer

Defining the global Communication Forwarding blacklist for the MTAS.

mtasCDivBlackList

Setting the maximum number of times the same communication is allowed to be forwarded.

mtasCDivMaxNoOfDiversions

Determining if the INVITE method response 302 causes a redirect generated by the MTAS, or if the 302 is to be passed along to the UA.

mtasCDivDeflection

Defining the contents of the MESSAGE that is sent to inform a served user that a session addressed to the served user has been diverted elsewhere.

mtasCDivServedUserNotifyMessage

Defining the contents of the MESSAGE that is sent to remind a served user, when an outgoing session is initiated, that diversions are active.

mtasCDivOutgoingCallMessage

Disabling and enabling the use of the From header when matching CDIV rules.

mtasCDivUseFromHeader

Setting No Reply Response value for the CDIV service.

mtasCDivNotReachableTimer

CDIV service on/off support for no_fork parameter in an INVITE.

mtasCDivUseFromHeader

For more information about the CDIV attributes, refer to Managed Object Model (MOM).

12.4   DTM Configuration

For the DTM configuration attributes, refer to Managed Object Model (MOM).

12.5   SSC Configuration

Diversion for the following supplementary services can be configured by the SSC:

For information on the activation, deactivation, and interrogation of the CDIV service through the SSCs, refer to MTAS Supplementary Service Codes Management Guide.

12.6   CDIV Administrative State Configuration

The CDIV service is enabled by setting the mtasCDivAdministrativeState attribute in the MtasCDiv MO to 1 (Unlocked). If the mtasCDivAdministrativeState is set to 0 (Locked), no CDIV service is provided by the MTAS.

12.7   Wholesale for CDIV Configuration

The CDIV service supports Wholesale. CDIV is configurable on Virtual Telephony Provider level.

Wholesale for CDIV is activated when the following attributes are set to 1 (Unlocked):

For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.

12.8   Service Data Management

This section describes how to configure the service data.

12.8.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the CDIV service 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.

12.8.2   Subscriber Subscription Level Service Configuration

The user subscriber data is configured through the Ut interface. The subscriber can configure the CDIV subscription rules using the conditions and action elements.

The Ut interface and the XML schema for the Ut interface are described in the following documents:

13   Performance Management

For measurements related to the CDIV service, refer toManaged Object Model (MOM).

14   Fault Management

The CDIV service has no alarms.

15   Example Configuration

This section shows examples of rule configurations that can be applied for the CDIV service.

To guarantee its uniqueness, a namespace can often be a long string. XML allows a namespace to be mapped to a short string (a prefix) which makes the XML documents more readable. The mapping between each namespace and its assigned prefix as used in this section is shown in Table 2.

Table 2    Namespace Prefix Mapping

Prefix

Namespace

Purpose

cp

urn:ietf:params:xml:ns:common-policy

Common Policies for privacy preferences as defined by the IETF

ss

http://uri.etsi.org/ngn/params/xml/simservs/xcap

User Part of the MMTel document as defined by ETSI/ TISPAN

mmt-serv

http://schemas.ericsson.com/mmtel/services

Ericsson defined services for inclusion in the MMTel user-data part

Note:  
The order of the rules defined in a configuration is significant for the CDIV service. For examples of such rule configurations, see Section 15.5 Forward Anonymous to Voicemail and Video to David and Section 15.6 Forward Video to David and Anonymous to Voicemail.

15.1   Forward All Calls from Alice

In the rule configuration shown in Example 3, the following applies for the served user:

Example 3   Forward All Calls from Alice

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="alice">
            <cp:conditions>
               <cp:identity>
                   <cp:one id="sip:alice@example.com"/>
               </cp:identity>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:charlie@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.2   Forward All Anonymous Calls

In the rule configuration shown in Example 4, the following applies for the served user:

Example 4   Forward All Anonymous Calls

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="anon">
            <cp:conditions>
               <anonymous/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>voicemail:internal</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.3   Forward All Video Calls

In the rule configuration shown in Example 5, the following is applied for the served user:

Example 5   Forward All Video Calls

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="video">
            <cp:conditions>
               <media>video</media>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:david@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.4   Forward All Calls from Coventry

In the rule configuration shown in Example 6, the following is applied for the served user:

Example 6   Forward All Calls from Coventry

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="Coventry">
            <cp:conditions>
               <cp:identity>
                   <mmt-serv:number-match starts-with="+4424"/>
               </cp:identity>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:eric@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.5   Forward Anonymous to Voicemail and Video to David

In the rule configuration shown in Example 7, the following is applied to the served user:

The significance of the order of the rules is shown in this example. An anonymous video call would satisfy the conditions of the first rule (id= "anon"), and the call would be diverted to voicemail@example.com.

Example 7   Forward Anonymous to Voicemail and Video to David

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="anon">
            <cp:conditions>
               <anonymous/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>voicemail:internal</target>
                </forward-to>
            </cp:actions>
         </cp:rule>
         <cp:rule id="video">
            <cp:conditions>
               <media>video</media>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:david@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.6   Forward Video to David and Anonymous to Voicemail

In the rule configuration shown in Example 8, the following is applied for the served user:

The significance of the order of the rules is shown in this example. An anonymous video call would satisfy the conditions of the first rule (id= "video"), and the call would be diverted to david@example.com.

Example 8   Forward Video to David and Anonymous to Voicemail

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="video">
            <cp:conditions>
               <media>video</media>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:david@example.com</target>
                </forward-to>
            </cp:actions>
         </cp:rule>
         <cp:rule id="anon">
            <cp:conditions>
               <anonymous/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>voicemail:internal</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.7   Forward All Anonymous Video Calls

In the example rule configuration shown in Example 9, the following is applied for the served user:

In this example, anonymous incoming communication not containing video, and incoming communication with an identifiable sender containing video, are not diverted.

Example 9   Forward All Anonymous Video Calls

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="anon video">
            <cp:conditions>
               <media>video</media>
               <anonymous/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:videomail@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.8   Multiple Independent Rules

In the example rule configuration shown in Example 10, the following is applied for the served user:

These rules are evaluated at different times in the call, so the order does not change the behavior.

Example 10   Multiple Independent Rules

<ss:communication-diversion active="true">
    <cp:ruleset>
         <cp:rule id="busy">
            <cp:conditions>
               <busy/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:charlie@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
         <cp:rule id="logged-out">
            <cp:conditions>
               <not-registered/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:videomail@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
         <cp:rule id="no reply">
            <cp:conditions>
               <no-answer/>
            </cp:conditions>
            <cp:actions>
                <forward-to>
                   <target>sip:david@example.com</target>
                </forward-to>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</ss:communication-diversion>

15.9   Forward Calls Based on Presence

In the example rule configuration shown in Example 11, the following is applied for the served user:

Example 11   Forward Calls Based on Presence

<ss:communication-diversion active="true">
   <cp:ruleset>
      <cp:rule id="meetings">
         <cp:conditions>
            <cp:presence-status>meeting</cp:presence-status>
         </cp:conditions>
         <cp:actions>
            <forward-to>
               <target>sip:joyce@example.com</target>
            </forward-to>
         </cp:actions>
      </cp:rule>
      <cp:rule id="steering">
         <cp:conditions>
            <cp:presence-status>steering</cp:presence-status>
         </cp:conditions>
         <cp:actions>
            <forward-to>
               <target>sip:kevin@example.com</target>
            </forward-to>
         </cp:actions>
      </cp:rule>
   </cp:ruleset>
</ss:communication-diversion>

15.10   Forward Calls after Different No-Answer Time Periods

In the example rule configuration shown in Example 12, the following is applied for the served user:

Example 12   Forward Calls after Different No-answer Time Periods

<ss:communication-diversion active="true">
   <ss:NoReplyTimer>5</ss:NoReplyTimer>
    <cp:ruleset>
      <cp:rule id="customer no reply">
            <cp:conditions>
               <ss:no-answer/>
               <cp:identity>
                   <cp:one id="sip:customer@example.com"/>
               </cp:identity>
            </cp:conditions>
            <cp:actions>
                <ss:forward-to>
                   <ss:target>sip:joyce@example.com</ss:target>
                </ss:forward-to>
                <ss:NoReplyTimer>10</ss:NoReplyTimer>
            </cp:actions>
      </cp:rule>
      <cp:rule id="no reply">
            <cp:conditions>
               <ss:no-answer/>
            </cp:conditions>
            <cp:actions>
                <ss:forward-to>
                   <ss:target>sip:joyce@example.com</ss:target>
                </ss:forward-to>
            </cp:actions>
      </cp:rule>
   </cp:ruleset>
</ss:communication-diversion>

15.11   Forward Call Upon DNDCF Service Activation

In the rule configuration shown in Example 13, the following is applied for the served user:

Example 13   Forward Call Upon DNDCF Service Activation

<ss:communication-diversion active=true>
   <cp:ruleset>
      <cp:rule id=”do-not-disturb”>
         <cp:conditions>
         </cp:conditions>
         <cp:actions>
            <ss:forward-to>
               <ss:target>sip:assistant@myoffice.com</ss:target>
            </ss:forward-to>
            <mmt-serv:do-not-disturb/>
         </cp:actions>
      </cp:rule>
   </cp:ruleset>
</ss:communication-diversion>

15.12   Forward Call Upon DNDCF Service Activation Playing Generic Announcement

In the rule configuration shown in Example 14, the following is applied for the served user:

Example 14   Forward Call Upon DNDCF Service Activation Playing Generic Announcement

<ss:communication-diversion active=true>
  <cp:ruleset>
     <cp:rule id=”dndcf-with-generic-announcement”>
        <cp:conditions>
        </cp:conditions>
        <cp:actions>
           <ss:forward-to>
              <ss:target>sip:assistant@myoffice.com</ss:target>
              <ss:notify-caller>true</ss:notify-caller>
          </ss:forward-to>
          <mmt-serv:do-not-disturb></mmt-serv:do-not-disturb>
          <mmt-serv:play-announcement>in a meeting</mmt-serv:play-announcement>
        </cp:actions>
     </cp:rule>
  </cp:ruleset>
</ss:communication-diversion>

15.13   Forward Calls at Given Periods

In the rule configuration shown in Example 15, the following applies for the served user:

Example 15   Forward Calls on Workdays

<ss:communication-diversion active="true">
   <cp:ruleset>
      <cp:rule id="working">
         <cp:conditions>
            <mmt-serv:valid-periods except-holidays="true">
		           <mmt-serv:valid-days>
		              <mmt-serv:day>Workday</mmt-serv:day>
		           </mmt-serv:valid-days>
		           <mmt-serv:valid-times>
		              <mmt-serv:interval from="09:00" until="12:00"/>
		              <mmt-serv:interval from="13:00" until="17:00"/>
		           </mmt-serv:valid-times>
		        </mmt-serv:valid-periods>
	       </cp:conditions>
         <cp:actions>
            <forward-to>
               <target>sip:charlie@example.com</target>
            </forward-to>
        </cp:actions>
     </cp:rule>
  </cp:ruleset>
</ss:communication-diversion>

For further examples and details on the configuration of time-based services in MTAS, refer to MTAS Time Based Services Management Guide.

15.14   Forward Calls Based on Served Identity

In the rule configuration shown in Example 16, the following applies for the served user:

Example 16   Forward Calls Based on Served Identity

<ss:communication-diversion active="true">
  <cp:ruleset>
    <cp:rule id="cdiv-served-id">
      <cp:conditions>
        <mmt-serv:served-identity>
          <mmt-serv:one id="sip:john.doe@office.com"/>
        </mmt-serv:served-identity>
      </cp:conditions>
      <cp:actions>
        <ss:forward-to>
          <ss:target>sip:jesse.james@office.com</ss:target>
        </ss:forward-to>
      </cp:actions>
    </cp:rule>
  </cp:ruleset>
</ss:communication-diversion>

15.15   Operator Forward Calls on Anonymous and after Served User Rules Operator Forward Calls on Not-Registered

In the rule configuration shown in Example 17, the following applies:

Example 17   Operator Forward Calls on Anonymous and after Served User Rules Operator Forward Calls on Not-Registered 

<mmt-op:operator-communication-diversion activated="true">
<cp:ruleset>
   <cp:rule id="cfb-pre">
      <cp:conditions>
        <ss:anonymous/>
      </cp:conditions>
      <cp:actions>
        <ss:forward-to>
           <ss:target>voicemail:internal</ss:target>
        </ss:forward-to>
      </cp:actions>
   </cp:rule>
</cp:ruleset>
<mmt-op:ruleset-for-post-evaluation>
   <cp:ruleset>
      <cp:rule id="cfu-post">
      <cp:conditions>
        <ss:not-registered/>
      </cp:conditions>
        <cp:actions>
           <ss:forward-to>
              <ss:target> sip:secretary@example.com </ss:target>
           </ss:forward-to>
        </cp:actions>
      </cp:rule>
   </cp:ruleset>
</mmt-op:ruleset-for-post-evaluation>
&mldr;
</mmt-op:operator-communication-diversion>


Copyright

© Ericsson AB 2016. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    MTAS Communication Diversion Management Guide         MTAS