Contents

1   Introduction

This document describes how to configure the Flexible Communication Distribution (FCD) 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 FCD service, the FCD license must be installed.

For more information about the FCD license, refer to MTAS Licenses.

1.1.2   Documents

Before starting any procedure in this document, ensure that the following documents are available:

• Ericsson Command-Line Interface User Guide
• Managed Object Model (MOM)

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 FCD service is a terminating service which allows a user to specify a number of identities which are to be called, either serial, parallel, or flexible ringing mode.

A target list of up to 10 Related Users' identities is configured by the network operator or user. These identities are used in rules which specify either a serial, parallel, or flexible distribution. A distribution contains the list of targets to be called if the rule is valid. Each rule contains from one to 10 identities, either from the list of defined target identities or reserved identities:

• PRIMARY, which indicates that the identity called to start the FCD functionality is called as a terminating user.
• PRIMARY_MOBILE, which denotes that call is distributed to the user’s mobile.
• PRIMARY_FIXED, which denotes that call is distributed to user’s fixed device.
• VOICEMAIL.

It is possible to use the target (related users') identities and (served users') device identities from the User Common Data in the FCD rules, similar to targets from the FCD target list. When device identity is used in the rule, a single terminal, registered for the IMS Primary User, is addressed by specifying a terminal selector feature parameter.

Explicit addressing of served user’s devices pre-configured in the User Common Data and "FCD to Primary User’s Devices" are two different flavors of AS Controlled Forking supported by MTAS – a "static" and a "dynamic" one.

FCD filters out sip.instance and other selected caller preferences from Accept-Contact and Reject-Contact headers of incoming requests to avoid collisions with caller preferences added by the FCD service itself. Caller preferences to be filtered out besides sip.instance are configurable using mtasFcdCallerPrefReqFilter CM attribute.

The Primary User may reside as a user either in the IMS network in which the MTAS resides, or in another network. In the former case, the user is called an IMS Primary User and in the latter case a non-IMS Primary User. Whether the Primary User is IMS or non-IMS, is configured by the network operator in the subscriber data.

Calls to the FCD service are routed in the network to the MTAS using one of the identities defined in served user’s IRS: a default (main) or an alias PUI.

Attempts by served user to define rules based on conditions not supported by the FCD service are rejected by XML Document Management Server (XDMS).

The rules are evaluated for the terminating registered and unregistered users.

The operator (CAI3G interface) has access to both the operator part and also the subscriber part of the FCD service.

2.1   Serial, Parallel, and Flexible Distribution

Serial distribution calls each of the targets identified in the active rule consecutively until one target answer or all targets have been unsuccessfully attempted. Each communication setup attempt is limited in duration by an answer timer. Following expiry of the timer the communication setup attempt is canceled and the next target identity in the active rule, if any, is attempted.

Parallel distribution calls all targets in the active rule at the same time until one target answers or the time allowed for an answer expires. Following answer or timer expiry communication setup attempts to unanswered targets from which a final response has not been received are canceled.

Flexible distribution combines serial and parallel distribution, that is, some of the targets are called serially and some in parallel. The target list is processed from the top to the bottom. If a target is marked with serial, it is rung simultaneously with the next parallel marked targets below this target until a target marked with serial is found, or the end of the target list is reached. If a target is marked with parallel, it is rung simultaneously with the previous serial target and with the similarly marked targets below this target until a target marked with serial is found, or the end of the target list is reached.

While the parallel, serial, or flexible distribution is being attempted, the caller can, subject to configuration, be played an announcement indicating that attempts to contact the called party are being made.

2.2   Controlled Forking

Application Server Controlled Forking (ASCF) means call distribution to concrete devices of a served user done directly by Application Server instead of S-CSCF. In MTAS, it can be achieved either by enabling "Flexible Communication Distribution (FCD) to Primary User’s devices" or by adding User Common Data (UCD) defined devices to FCD rules instead of the "PRIMARY" keyword. This section describes the latter case. "FCD to Primary User’s devices" is described in the following chapter.

When the target is a device from the User Common Data, then a new Accept-Contact header line is included in the INVITE sent to the IMS Primary User. The caller preference in the Accept-Contact header is constructed from the provisioned terminal selector, and from the terminal selector prefix specified by the CM attribute mtasMmtTerminalSelectorPrefix. The "require" and "explicit" parameters are included in the Accept-Contact header as follows:

Accept-Contact: *;<prefix><selector>;require;explicit

A valid AS Controlled Forking License must be present for using the common device list.

For more information about controlled forking, refer to MTAS Target Handling Management Guide.

2.3   Distribution to Primary User's Devices

"FCD to Primary User’s Devices" is another version of Application Server Controlled Forking in MTAS. It eliminates the need to configure a "static" list of individual device targets in the User Common Data and FCD rules manually. Thus, it can be considered a "dynamic" alternative of the AS Controlled Forking, described in previous section.

The "FCD to Primary User’s Devices" function allows for parallel call distribution to all (mobile and fixed) currently registered terminals of a served user when either no FCD rule is provisioned, no rule is matched, or by PRIMARY keyword in an FCD rule. It is also possible to address a mobile terminal only, using PRIMARY_MOBILE or fixed devices only using PRIMARY_FIXED keyword in an FCD rule.

Devices are addressed by adding +sip.instancesip.instance and an optional mobile or fixed terminal selector to the caller preferences in the Accept-Contact header for each terminating call leg.

The "FCD to Primary Users Devices" interprets every currently registered terminal of a served user as a separate target in the distribution rule. The PRIMARY, PRIMARY_MOBILE, and PRIMARY_FIXED keywords in the FCD rule are "dynamically" replaced with registered devices as the factual targets in parallel ringing mode.

Accept-Contact: +sip.instance=<registered sip.instance>;\ require;explicit

Accept-Contact: *;mobility=”mobile”;explicit;require

The additional mobile and fixed terminal selectors can be configured, using mtasFcdAdditionalTermSelectorMobile and mtasFcdAdditionalTermSelectorFixed CM attributes to aid in triggering mobile or fixed access network selection. If a selector for a given mobility type is not defined, the terminal selector is not added.

The value of +sip.instance and device classification as "mobile" or "fixed" are read from contact data cached during registration.

Only the devices registered in IMS at a given time are addressed, based on the contact data cached by MTAS during 3rd-party registration. In case a mobile device is not registered in IMS, an additional INVITE is sent by FCD towards an "unregistered mobile" with intention to try to break out to CS domain. Such an INVITE does not contain a +sip.instance caller preference but can contain a mobile terminal selector, if configured.

"Active Call Preference for Fixed Devices" is an extension to the "FCD to Primary User’s Devices" function, letting a new incoming call be distributed only to served user’s fixed devices with ongoing active calls plus a mobile device.

Communication Distribution to ICS user’s devices in Fixed Mobile Convergence (FMC) scenarios is a specific application of "FCD to Primary User’s Devices". By comparing a terminal instance received in the Accept-Contact header with stored contact data, the SCC-AS can distinguish calls distributed to mobile (VoLTE) devices from calls distributed to fixed devices and apply T-ADS to the former only.

Note:  

From the device mobility classification perspective in MTAS, a "mobile" device is the same as a "VoLTE" device. These are the only two names for a non-fixed device and they are used interchangeably here.

For more information about SCC-AS, refer to MTAS IMS Centralized Services Management Guide.

"Flexible Communication Distribution to Primary User’s Devices" is enabled using mtasFcdDistributeToPrimaryUserDevices CM attribute. It do not require AS Controlled Forking License.

If "FCD to Primary User’s Devices" is deactivated, the PRIMARY, PRIMARY_MOBILE, and PRIMARY_FIXED targets are interpreted in the same way, so that one single INVITE is sent out to the served user without any selectors added.

2.4   Communication Setup

Communication setup attempts to the IMS Primary User identity are handled as normal IMS terminating calls, with the addition for distribution to ICS user's devices as described in Section 2.3 Distribution to Primary User's Devices.

Communication setup attempts to the non-IMS Primary User identity are treated as new outgoing calls. The R-URI and P-Asserted-Identity in the outgoing INVITE requests can have prefixes added for network routing and handling purposes. Prefixes are only included when the identities are global telephone number format and the prefixes and the addition of prefixes is configured by the operator.

Communication setup attempts to Related User identities are treated as new outgoing call requests. No prefixes are used in the outgoing INVITE Requests to these identities. Related User identities can be in the IMS network or any other network.

When more than one device of the IMS Primary user is included in the rules, each INVITE is routed as a normal terminating call, with the corresponding provisioned terminal selector, but with different Call-IDs in the outgoing leg.

When communication is set up to a non-IMS Primary User or a Related User and Originating AS chaining is disabled by SIP CM Parameter, the new calls have terminating treatment. There is no triggering of originating services in originating AS.

When communication is set up to a non-IMS Primary User or a Related User and Originating AS chaining is enabled by SIP CM Parameter, the new calls have originating treatment. This enables triggering of originating services in originating AS.

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

2.5   Subfunctions

The subfunctions included in the FCD service are described in this section.

2.5.1   Ring Targets

This subfunction is responsible for the serial, parallel, or flexible ringing of the users specified in the served user’s XML data.

2.5.2   Announcements

An FCD progress announcement is played to the caller while the FCD communication establishment is done by the MTAS. Upon a successful communication establishment, announcement 1 is stopped. An FCD unsuccessful announcement is played to the user upon unsuccessful FCD communication establishment. It indicates to the user an unsuccessful communication. If the FCD progress announcement is not played, owing to the configuration, the FCD unsuccessful announcement is not played.

If the FCD service times out or fails to receive reject responses from all targets in the active rule, then the calling user can, subject to configuration, be played an announcement indicating that connection to the called user has not been possible.

If the FCD progress announcement is not played owing to the configuration, the FCD unsuccessful announcement is not played.

Playing of the FCD progress announcement is controlled by mtasFcdPlayAudioAnnouncement and mtasFcdPlayVideoAnnoncement configuration parameters and by the play-announcement action in the rule.

Playing of the FCD unsuccessful announcement is controlled by mtasFcdNegPlayAudioAnnouncement and mtasFcdNegPlayVideoAnnouncement.

For more information about announcement handling and attributes for the FCD service, refer to MTAS Announcement Management Guide.

2.5.3   Auto-Answer Avoidance

Auto-Answer Avoidance is responsible for requesting a confirmation from the answering user before FCD classifies the call to have been answered. The aim is to avoid an automate device, like voicemail, from answering the call and thus stopping ringing on other devices. This function is only applicable to related user targets.

If there is no DTMF confirmation, the call leg is treated as if it was rejected by the called party:

• In case of serial distribution, the next target is attempted (if the called user was the last one in the target list the communication is rejected)
• In case of parallel distribution, other targets are not affected and they continue ringing.

The use of the Auto-Answer Avoidance function is controlled by mtasAutoAnswerAvoidanceAnnouncement configuration parameter and by auto-answer-avoidance and auto-answer-avoidance-condition elements.

2.6   FCD Interaction with Other Services

This section describes the FCD interaction with other services.

2.6.1   Call Admission Control

FCD calls only count as a single terminating call for both User Call Admission Control (UCAC) and Group Call Admission Control (GCAC) services. For the UCAC service, the FCD call counts as a single call against the limits specified for the served user in the served user’s XML subscription data.

The GCAC service is not compatible with the FCD service, and both services must not be concurrently unlocked on the same MTS node.

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

2.6.2   Carrier Pre-Select

Initial INVITE requests sent by the FCD service to the non-IMS Primary User and Related Users are subject to the Carrier Pre-Select (CPS) or Carrier Pre-Select Rn (CPSRn) service.

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

2.6.3   Carrier Select

The FCD allows the Related User identity to include a Carrier Select (CS) code.

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

2.6.4   Charging

Terminating charging (online or offline, or both) is performed on incoming leg (A to B), if applicable. Originating charging (online or offline, or both) is performed on each outgoing leg to a non-IMS Primary User or a Related User, if applicable. There is no originating charging on the outgoing leg to an IMS Primary User. However, in the case where an incoming communication being distributed to PRIMARY is diverted to an alternative target (indicated in the divert-to element) by FCDDP service, or in the case where the incoming communication being distributed to PRIMARY is deflected with SIP 302 and FCD determines to generate new INVITE to the alternative target (indicated in the Contact header in the SIP 302 response), the FCD MTAS allocates a new IMS Charging Identifier for charging on outgoing legs to the alternative target of PRIMARY. The FCD MTAS also generates a P-Charging-Vector header containing the new IMS Charging Identifier and includes it in the initial INVITE sent to the alternative target of PRIMARY. In this situation, the supplementary-service-identity is set to FCDDP.

The IMS Charging Identifier and the Orig-IOI in the P-Charging-Vector header within the initial INVITE request received by the FCD MTAS are used for charging on incoming leg (A -> B). The Orig-IOI received in the P-Charging-Vector header in responses from the non-IMS Primary User or a Related User is used as the Term-IOI for charging on incoming leg (A -> B).

The FCD MTAS allocates new IMS Charging Identifiers (ICID) for charging on outgoing legs to non-IMS Primary Users and Related Users. The FCD MTAS generates a P-Charging-Vector header containing the new ICID and also the original ICID received on the incoming leg (A to B) and includes them in the initial INVITE sent to the non-IMS Primary User or Related Users.

The Orig-IOI and Term-IOI received in the P-Charging-Vector header in responses from the non-IMS Primary User and Related Users are used for charging on outgoing legs to non-IMS Primary Users and Related Users.

The P-Charging-Vector header received in responses to the initial INVITE request from outgoing leg (non-IMS Primary Users and Related Users) is not passed to the incoming leg. The FCD MTAS node replaces the header with a P-Charging-Vector header containing the IMS Charging Identifier and the Orig-IOI received in the INVITE request and containing a Term-IOI copied from the Orig-IOI received in the response from the non-IMS Primary Users or Related Users.

If a P-Charging-Vector header is present in any other request or response, received from either the incoming leg (A->B) or from the outgoing leg (B -> non-IMS Primary User or a Related User), the FCD MTAS removes the header from the message.

The P-Charging-Function-Addresses header within the initial INVITE request received by the FCD MTAS is:

1. Used to identify the charging functions to be used for charging on incoming leg (A -> B).
2. Included in the initial INVITE request sent to the IMS Primary User.
3. Used to identify the charging functions to be used for charging on outgoing legs to non-IMS Primary Users and Related Users.
4. Included in the initial INVITE request sent to the non-IMS Primary Users and Related Users.

The P-Charging-Function-Addresses header received in responses to the initial INVITE request from outgoing leg (B -> non-IMS Primary User or a Related User) is passed on to the incoming leg (A -> B).

If a P-Charging-Function-Addresses header is present in any other request or response received from either the incoming leg (A -> B) or from the outgoing leg (B -> non-IMS Primary User or a Related User), the FCD MTAS removes the header from the message.

The following service-specific AVPs are applicable to the terminating charging performed for the incoming leg:

• Supplementary Service Information – Indicating use of FCD and whether parallel, serial, or flexible distribution has been used. Auto-Answer Avoidance is also indicated.
• Related ICID – Included for correlation purposes when the communication session is successfully established to a non-IMS Primary User and Related User. This AVP contains the new IMS Charging Identifier allocated to the successful outgoing leg.

The following service-specific AVPs are applicable to the originating charging performed for each outgoing leg:

• Supplementary Service Information – Indicating use of FCD and whether parallel, serial, or flexible distribution has been used.
• Redirecting Party Address – Identifying the original called party.
• Related ICID – Included for correlation purposes. This AVP contains the IMS Charging Identifier received on the incoming leg.

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

• Diameter Offline Charging in MTAS
• Diameter Online Charging in MTAS

2.6.4.1   Multi-Device Offline Charging

If Multi-Device Charging is enabled in a charging profile, then terminating offline charging is performed on outgoing legs to served user’s devices. This enables an operator to collect offline charging information per device in AS Controlled Forking scenarios, so that the operator can provide served users with a call log including information about individual devices ringing at an incoming call.

Note:  

The charging profiles can be assigned per user so that for some served users, the Multi-Device Charging can be enabled and for other users registered on the same node, the Multi-Device Charging can be disabled.

Preconditions

mtasChargingTerminatingOffline=1

mtasChargingProfileMultiDevice=1 (in the charging profile assigned to the served user)

If both of these preconditions are met, then a specific offline charging behavior related to the Primary User’s devices is applied, which consists of:

• Generating a new ICID value for each outgoing leg to a primary user’s device.
• Capturing User Equipment Info (sip.instance) values of primary user’s devices being FCD targets.
• Capturing IMPI values of primary user’s devices being FCD targets.
• Reporting all the successful and unsuccessful non-provisional responses to outgoing FCD INVITEs to served user’s devices using one time event charging.
• Sending sip.instance of a device in the User-Equipment-Info AVP and IMPI in the username AVP in the above mentioned ACR Event messages.
• Adding all outgoing leg ICIDs to the main A-to-B charging ACR messages as Related ICIDs.
• SIP_Ringing_TS is set individually per Charging Session, representing the answer time stamp per leg. It can be used to see whether (and when) a particular terminal was ringing.

Although Multi-Device Offline Charging is intended mainly for Application Server Controlled Forking scenarios (see sections Section 2.2 Controlled Forking and Section 2.3 Distribution to Primary User's Devices), it is a separate feature and can be configured independently on any other service settings.

2.6.4.2   Multi-Device Online Charging

If Multi-Device Charging is enabled in a charging profile, then fixed device use control is performed, independent of mobile device credit control, in terminating online charging. In this way, subscribers can use fixed devices although no credit exists for the mobile device.

Note:  

The charging profiles can be assigned per user, so that for some served users the Multi-Device Charging can be enabled and for other users registered on the same node the Multi-Device Charging can be disabled.

Preconditions

mtasChargingTerminatingOnline=1

mtasChargingProfileMultiDevice=1 (in the charging profile assigned to the served user)

mtasChargingProfileWaitForCca=1 (in the charging profile assigned to the served user)

If all these preconditions are met, then a specific online charging behavior related to the Primary User’s devices is applied which consists of:

• Capturing User Equipment Info (sip.instance) values of primary user’s devices being FCD targets.
• Capturing IMPI values of primary user’s devices being FCD targets.
• Interpreting the main terminating Online Charging session as a charging session for a mobile device.
• Sending additional separate terminating CCR-I (use control) requests to OCS per each subscriber’s fixed device being a Communication Distribution target, so that the subscriber can use fixed devices although no credit exists for the mobile device. Every OCS session for fixed device is independent but refers to the same ICID as the main charging session (for a mobile device).
• Sending sip.instance of a device (if available) in the User-Equipment-Info AVP and IMPI in the username AVP in all CCR requests for both "mobile" and "fixed" charging sessions.

Although Multi-Device Online Charging is intended mainly for Application Server Controlled Forking scenarios (see Section 2.2 Controlled Forking and Section 2.3 Distribution to Primary User's Devices), it is a separate feature and can be configured independently on any other service settings.

2.6.5   Communication Barring

The Incoming Communication Barring (ICB) service is performed on the terminating INVITE before the FCD service. The Outgoing Communication Barring (OCB) service is performed on the outgoing INVITE requests to the non-IMS Primary and Related Users.

Related User identities cannot be an identity which would be barred by the OCB or included in the CDIV blacklist.

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

2.6.6   Communication Completion

A user can only be provisioned with the FCD service if that user has the Communication Completion (CC) service 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 CC service, refer to MTAS Communication Completion Management Guide.

2.6.7   Communication Diversion

When mtasFcdCDivInvocationSequenceControl attribute is set to 0, FCD is started before CDIV in the terminating MTAS. When mtasFcdCDivInvocationSequenceControl is 1, CDIV is started before FCD. Set the value to 1. All FCD-CDIV or CDIV-FCD interworking can be achieved by FCD only rules as FCD supports the same conditions and actions as CDIV.

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

2.6.7.1   CDIV Started before FCD – VOICEMAIL Supported

FCD supports the VOICEMAIL target and divert primary subservice.

CDIV rules trigger first if conditions are met. In that case FCD is not to be performed as the leg towards the served user is diverted by CDIV before FCD.

When no CDIV rules are triggered FCD could distribute the call. If the distribution is unsuccessful and finished, the CDIV not-registered condition could be evaluated as TRUE and CDIV rule can be triggered, but the same diversion can be achieved by using flexible distribution in the FCD rule. Other CDIV call-state conditions (busy, no-answer, not-reachable) will not be evaluated as TRUE after an unsuccessful communication distribution.

Incoming communication distributed to the IMS primary user identity can be diverted into configurable alternative target by using FCD Divert Primary (FCDDP) subservice. The incoming communication distributed to the IMS primary user can also be deflected to other target following the receipt of SIP 302 response sent from the IMS primary user. In both cases, the communication setup attempts are handled as new outgoing calls.

When the FCD rules contain a specific device of the IMS primary user, the FCD is not allowed to be active when any type of CDIV is active.

2.6.7.2   FCD Started before CDIV – VOICEMAIL Not Supported

FCD does not support the VOICEMAIL target and divert primary subservice.

CDIV will only be started for INVITE requests to an IMS primary user. Outgoing legs to Non-IMS primary users and related users do not start the CDIV service.

The INVITE to the IMS primary user without terminal selector is subject to CFU or DNDCF containing no condition, but not to CFB, CFNR, CFNL, and CFNRc. The XDMS validation prevents the FCD service being active when there are CDIV rules which would use CDIV except as CFU or DNDCF.

When the FCD rules contain a specific device of the IMS Primary User, the FCD is not allowed to be active when any type of CDIV is active.

2.6.8   Communication Waiting

When the FCD target is a terminal of the served user, the Communication Waiting Active (CWA) indicator is added to the INVITEs by the Communication Waiting (CW) service without considering the terminal selector. Therefore, each terminal receives it, independent of the status of the terminal.

No CWA indicator is sent to the non-IMS primary user nor to the related users.

The CW Used (CWU) Alert-info header, received in the 180 Ringing from any of the FCD targets, is not passed on to the caller.

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

2.6.9   Flexible Service Format Selection

The FCD service can be suppressed by Flexible Service Format Selection (FSFS) service. The FSFS service can suppress the FCD service both in the terminating registered and terminating unregistered MTAS. When the FSFS service suppresses the FCD service, the incoming SIP INVITE is forwarded and left untouched. The rules evaluation attempt is also suppressed.

The FCDDP can be configured separately to support the FSFS service. If the FCDDP is configured to support the FSFS service, a received SIP INVITE that matches the configured regular expression of the FSFS service suppresses the diversion attempt triggered by FCDDP towards alternative target of IMS Primary.

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

2.6.10   Gateway Model

The Gateway Model (GM) deployed on the calling party side of the FCD service, for example, on the same or another MTAS, works independently of the FCD service. The FCD service works irrespective of whether the GM is locked or unlocked.

GM deployed on the target side of the FCD service, for example, on another MTAS, sends updates for any forked responses containing updated Session Description Protocol (SDP) answers.

For more information about the GM service, refer to MTAS Gateway Model Management Guide.

2.6.11   Hold Communication

The Hold Communication service does not act in the MTAS of the served user (B) of FCD, if the connected user is a non-IMS Primary User or a Related User, only in the end user’s AS.

Hold is not allowed during the DTMF execution in case of Auto-Answer Avoidance and any UPDATE or reINVITE with a Hold attempt is rejected.

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

2.6.12   Identity Presentation

This section describes the FCD interactions Identity Presentation services.

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

Dynamic Ad-Hoc Identity Presentation

The FCD allows the Related User identity to include the Supplementary Service Code indicating Ad-hoc Identity Restriction or Presentation.

Flexible Identity Presentation

The FIP service is applicable when a FIP served user calls the FCD primary number or an FCD-related number. The PAI and From headers are changed.

The FIP service is applicable when the FCD served user also has the FIP service provisioned. In this case, the FIP service modifies the History-info headers made during the communication distribution. The service adds the "privacy=history" string after the served user’s identity, thus protecting it from being revealed to the called party.

The FIP service is applicable when the service is assigned to FCD-related users. The PAI and From headers are changed. If the FIP identity is set to the same value as the FCD primary identity, then any calls made from the FCD-related users appear as if it would have been placed by the FCD primary users. This means that if the called subscriber returns such a call, it is placed towards the FIP primary number and thus the FCD service is started. This is considered to be an intended use scenario for the FIP service.

Originating Identity Restriction

For an FCD outgoing INVITE request to a non-IMS Primary User or a Related User, the Originating Identity Restriction (OIR) service performs the following tasks (if the server user has OIR settings which provide privacy for the user identity):

• The Privacy header "history" is escaped within the hi-targeted-to-uri field (in the History Info header) containing the served user’s identity in the INVITE message.
• The To header is changed to the URI of the target.

The same restrictions apply to all other messages containing these headers in the same direction as the initial INVITE request.

Terminating Identification Restriction

A P-Asserted-Identity header field received by the FCD AS in a final response is passed unmodified to the originating entity.

If the served user has Terminating Identification Restriction (TIR), the Privacy header field is included in the 180 Ringing and 183 Session Progress responses.

A Privacy header received from a target user in a provisional response, for example, 180 Ringing, is transferred to subsequent messages if there is no included Privacy header.

If the served user has TIR settings to protect the served user’s identity, the Privacy header "history" is escaped within the hi-targeted-to-uri field containing the served user’s identity in the History-Info header in all messages containing History-Info headers which are passed to the originating entity. This applies whether the History-Info header was included by the MTAS or was already in the received response. The originating MTAS and CSCF are responsible for the interpretation of the Privacy header field.

When the target is the IMS Primary User TIR operates in the normal TIR mode.

Restriction of the served user’s identity is applied to all subsequent messages in the same direction.

2.6.13   Malicious Communication Identification

For FCD calls, the MTAS ensures that the Temporary Malicious Communication Identification (MCID) service knows that the IMS Primary User’s terminal has signaled that the user is being alerted (180 Ringing provisional response).

For FCD calls, the MTAS ensures that the Temporary MCID service does not store the call details when a 200 OK or 180 Ringing (in response to the INVITE request) is received from the non-IMS Primary User and from the Related Users.

Permanent MCID has no interaction with FCD service, because it records the caller’s details on every terminating initial INVITE.

For more information the MCID service, refer to MTAS Malicious Communication Identification Management Guide.

2.6.14   Priority Call

The MTAS passes on the contents of any Priority header received in the incoming initial INVITE in the outgoing initial INVITE it sends to the FCD IMS Primary User.

The MTAS replaces any Priority header received in the incoming initial INVITE with a Priority header. The Priority header reflects the priority of the served user in the outgoing initial INVITE requests that it sends to the FCD non-IMS Primary User and the FCD Related Users.

2.6.15   Subscriber Data

FCD to Primary User’s Devices depends on registered contacts information to be able to distinguish the device identifier (sip.instance) and the type of device (mobile/fixed).

This information is parsed from the registered contacts’ feature tags in the third-party registration and cached (Contact Data).

For this purpose, the iFC in HSS is configured to trigger initial registration, re-registration, and deregistration to the MMTel Telephony AS and to include the user REGISTER request and 200 OK response in the "message/sip" body of the third-party registration. The mtasSubsDataCacheContactData attribute must also be enabled.

The UE terminal type classification (mobile or fixed) during registration can be based on either registered contact’s feature tags or P-Access-Network-Info (PANI) header. Feature tags, being the basis for device mobility classification as mobile (VoLTE), are configurable through mtasSubsDataMobileClassification attribute. If it contains at least one entry, the classification is based on feature tags listed in this attribute only without taking P-Access-Network-Info header into account. Otherwise, that is, if the attribute is empty (default value), a device is classified as "mobile" based on PANI header indicating 3GPP GERAN, 3GPP UTRAN or 3GPP E-UTRAN access and if PANI header is absent – based on presence of +g.3gpp.ics="server" or +g.3gpp.accesstype="cellular" feature tag. If none of the above conditions is fulfilled, a device is classified as "fixed" by default.

For more information about the MMTel Telephony AS registration procedures, refer to MTAS External Network Configuration.

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

2.6.16   IMS Centralized Services

FCD calls can be distributed to ICS user's devices with caller preference on the sip.instance feature tag as described in Section 2.3 Distribution to Primary User's Devices.

In this case, the SCC-AS T-ADS service ignores the calls to fixed devices.

For this purpose, the registered contacts information must be available to FCD in the Subscriber Data storage.

This is already the case if MMTel Telephony AS is co-located with SCC-AS.

However, if the MMTel Telephony AS is standalone, it must be ensured that the iFC for MMTel Telephony AS in HSS is configured to trigger initial registration, re-registration, and deregistration and to include the user REGISTER request and 200 OK response in the message/sip body of the third-party registration. The mtasSubsDataCacheContactData attribute must also be enabled.

2.6.17   MMtel Basic Service

The option of triggering a specific unregistered behavior at the initial INVITE (immediate 480 response optionally preceded by a specific announcement) is not supported in combination with FCD distribution to IMS subscriber.

3   Subscription Rules

The FCD subscription rules are expressed with XML defined, by a schema and follow the structure illustrated in Figure 1.

The FCD service has a single target-list and a single Rule set.

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

The FCD service can also use targets from the common target list and from the common device list. Only those targets can be marked with the auto-answer avoidance feature.

For more information about target handling for the FCD service, refer to MTAS Target Handling Management Guide.

The element <target-list> defines the target elements (mmt-serv:target) which contain the id and name attributes that are the list of identities which can be included in the rule actions. The number of targets in the FCD target-list must not be more than the targets defined by element <max-targets> (2-10).

The element Rule (<fcd-rule>) has one id attribute that identifies the rule. It is not related to the evaluation order. The top-level FCD element has an attribute active of type Boolean. If active=true, then the rule set is evaluated. The rules are evaluated from top to bottom, that is 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. This means that the evaluation of conditions stops when the first condition is false (lazy evaluation). Only the first matching rule and its specified action elements apply.

The <conditions> element is a grouping element for conditions for a rule. All conditions must be satisfied for the rule to take effect. If no conditions are present, then the rule is always applicable.

3.1   Conditions

The different conditions that apply to FCD are as follows:

• cp:validity
  All other common policy (cp) conditions are not used by the FCD, refer to IETF RFC 4745: Common Policy: A Document Format for Expressing Privacy Preferences specification for details and definitions:
• ss:rule-deactivated
• mmt-serv:valid-periods
• mmt-serv:invalidity
• busy
• not-registered
• not-reachable
• presence-status
• identity
• mmt-serv:served-identity
• anonymous
• media
• no-answer
• mmt-serv:in-sip-request

3.1.1   cp:validity

Specifies one of more periods. The condition evaluates to TRUE when the current time is within the validity period expressed by one of the time periods included in this condition. In all other cases, the condition evaluates to false.

It expresses the rule validity period by two attributes, a starting and an ending time. The validity condition is TRUE if the current time is greater than or equal to at least one <from> child, and less than the <until> child after it.

The format is XML dateTime. Its canonical representation is UTC and time zones are expressed as a positive or negative duration (2005-12-24 12.00 in Stockholm, GMT+1, is expressed as 2005-12-24T12:00:00+01:00 and has the corresponding canonical representation 2005-12-24T11:00:00Z).

When the validity period is given in local time format, the UTC offset is taken from the <user-common-data>. If the UTC offset is not provisioned for the user, the value from the CM attribute mtasMmtCalUtcOffset is used.

Times in cp:validity conditions are converted to UTC before being compared to the current time, also in UTC. An example of this is shown in Example 1.

<cp:validity>
<!-- This example shows time being defined as an offset from UTC-->	
     <cp:from>2008-10-12T20:00:00-08:00</cp:from>
     <cp:until>2008-10-19T19:59:59-08:00</cp:until>
     <!-- example in UTC as shown by the Z -->
     <cp:from>2008-11-27T20:00:00Z</cp:from>
     <cp:until>2008-11-28T08:00:00Z</cp:until>
</cp:validity>

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

3.1.2   ss:rule-deactivated

This condition always evaluates to FALSE. This can be used to deactivate a rule, without losing information. By removing this condition, the rule can be activated again.

3.1.3   mmt-serv:valid-periods

Allows the assembly of complex time condition based on the following elements and subconditions:

• times of day (in form of intervals, like 09:00-12:00)
• days of the week (for example Monday)
• workdays/non-workdays (use of preprovisioned/configured list of weekdays)
• private and public holidays (for example Monday)
• days of the month (for example, first day, last day, first Wednesday, the 13th)
• calendar months
• calendar weeks
• daily, weekly, and monthly repetitions (with start day and repetition interval)

If any element within the subconditions evaluates to TRUE, then the subcondition evaluates to TRUE. The mmt-serv:valid-periods evaluates to TRUE only when all the included subconditions evaluates to TRUE.

The mmt-serv:valid-periods evaluates to TRUE only when all the included subconditions evaluates to TRUE.

It is also possible to mark the holidays as exception for the whole mmt-serv:valid-periods condition. So, when the current day is holiday, then the mmt-serv:valid-periods evaluates to FALSE.

For more information on the other provisioned and configured data used at evaluation of mmt-serv:valid-periods, refer to MTAS Time Based Services Management Guide.

The details of the subconditions have been moved to MTAS Time Based Services Management Guide.

3.1.3.1   mmt-serv:utc-offset

The mmt-serv:utc-offset element is used to specify the time zone offset. The value of the offset can be + or - concerning UTC, for example, [+-], The value of an hour is 00-23, for example, [0-1][0-9]|2[0-3]. For minutes, the value is 00-59, for example, [0-5][0-9].

If mmt-serv:utc-offset element is omitted, the mmt-serv:valid-periods condition uses UTC. An example of a time zone offset is shown in Example 2.

<mmt-serv:utc-offset>+06:30</mmt-serv:utc-offset>

3.1.3.2   mmt-serv:valid-days

The mmt-serv:valid-days element is a subcondition. It is used to define days of the week on which the mmt-serv:valid-periods condition is evaluated to TRUE. One day or multiple days can be defined (Monday to Sunday). If mmt-serv:valid-days is omitted, the mmt-serv:valid-periods condition applies to all days of the week. An example of a valid-days subcondition is shown in Example 3.

<mmt-serv:valid-days>
     <mmt-serv:day>Monday</mmt-serv:day>
     <mmt-serv:day>Tuesday</mmt-serv:day>
     <mmt-serv:day>Wednesday</mmt-serv:day>
     <mmt-serv:day>Thursday</mmt-serv:day>
     <mmt-serv:day>Friday</mmt-serv:day>
</mmt-serv:valid-days>

3.1.3.3   mmt-serv:valid-times

The mmt-serv:valid-times element is a subcondition. It used to define the intervals of the day within the condition is evaluated to TRUE. If mmt-serv:valid-times is omitted, the mmt-serv:valid-periods condition applies to all times of day, that is, to 00:00-24:00. An example of a valid-times subcondition is shown in Example 4.

<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>

3.1.4   cp:invalidity

Specifies one of more periods. The condition evaluates to false when the current time is within the validity period expressed by one of the time periods included in this condition. In all other cases, the condition evaluates to TRUE.

It expresses the rule invalidity period by two attributes, a starting and an ending time. The invalidity condition is FALSE if the current time is greater than or equal to at least one <from> child, and less than the <until> child after it. The invalidity condition is TRUE only when the current time is not within any of the invalidity periods.

The format is XML dateTime. Its canonical representation is UTC and time zones are expressed as a positive or negative duration (2005-12-2412.00 in Stockholm, GMT+1, is expressed as 2005-12-24T12:00:00+01:00 and has the corresponding canonical representation 2005-12-24T11:00:00Z).

When the invalidity period is given in local time format, the UTC offset is taken from the <user-common-data>. If the UTC offset is not provisioned for the user, the value from the CM attribute mtasMmtCalUtcOffset is used.

Times in mmt-serv:invalidity conditions are converted to UTC before being compared to the current time, also in UTC.

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

3.1.5   busy

This condition evaluates to TRUE when the served user is busy. In all other cases, the condition evaluates to FALSE. Rules with this condition are evaluated when a busy indication is received from the served party.

3.1.6   not-registered

This condition evaluates to TRUE when the served user is not registered. In all other cases, the condition evaluates to FALSE.

3.1.7   not-reachable

This condition evaluates to TRUE when there is a signaling channel outage during session setup to the served user's UE and the served user is registered. In all other cases, this condition evaluates to FALSE.

3.1.8   presence-status

This condition evaluates to TRUE when the served user’s current presence activity status contains a value equal to the value set for this condition. In all other cases, the condition evaluates to FALSE.

3.1.9   cp:identity

This condition evaluates to TRUE when the calling user’s identity matches with the value of the identity element.

The FCD matches P-Asserted-Identity and optionally the From-Header with this condition.

If there are more than one P-Asserted-Identity, then FCD iterates over all P-Asserted-Identity header lines and evaluates the FCD rules, if one matches then the condition matches.

The From-Header is only used if there is no match with the P-Asserted-Identity and the CM attribute mtasFcdUseFromHeader is set to Enabled.

However, for FCD, the input tel URI is only considered equal to the <one id> or <except> element in the cp:identity condition (the rule URI) if the number parts match and the parameters satisfy the following conditions:

• If there is a “phone context=pvalue” parameter in the rule URI, then there must be an identical “phone context=pvalue” parameter in the input URI.
• If there is no phone-context parameter in the rule URI, then there must be no phone context parameter in the input URI.
• If there is an “ext=phonedigits” parameter in the rule URI, then there must be an identical “ext=phonedigits” parameter in the input URI.
• If there is no ext parameter in the rule URI, then any ext parameter in the input URI is ignored.
• If there is an “isub=subaddress” parameter in the rule URI, then there must be an identical “isub=subaddress” parameter in the input URI.
• If there is no isub parameter in the rule URI, then any isub parameter in the input URI is ignored.
• Any other parameters are ignored.

For FCD, the input tel URI is considered to match the <number-match> element in the cp:identity condition (the rule URI) if the first few characters of the number part of the input URI match all the characters in the rule URI. Parameters cannot appear in the <number-match> element, so any parameter in the input URI is ignored.

However, only the user and host parts of SIP URIs are considered when comparing for FCD, that is the password, port, URI parameters, and headers are ignored for comparing SIP URIs for the FCD. For a SIP URI that was converted from a tel: URI, the user part of the SIP URI contains the number and parameters of a tel: URI, so the comparison must first consider the host part of the SIP URI, and then must treat the user part as if it was a tel: URI.

3.1.10   mmt-serv:served-identity

This condition evaluates to TRUE when one of its mmt-serv:one subelements matches the served user’s identity and a valid Multi-Subscriber Number license is available. The mmt-serv:one subelements are interpreted similar to those of cp:identity.

The served user is determined in accordance with section AS serving a terminating user of 3GPP TS 24.229 V11.6.0 : IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3.

The determination process is the following:

• The P-Served-User header field must be used, if present.
• Otherwise, the content of the Request URI must be used.

If the served user cannot be determined, service rules using the served-identity condition are ignored:

• For each served-identity condition, it is checked if the user has any matching alias in IRS. This is done by iterating through all PUIs in IRS and matching them against the served-identity condition. There must be at least one PUI which matches.
• Within a served-identity condition of a Communication Distribution rule, each "one" element must have a unique ID value.
• The served-identity element can contain only the mmt-serv:one subelements.

3.1.11   anonymous

This condition evaluates to TRUE when the calling party is anonymous. The called party is anonymous if the Privacy header contains any privacy values except "none", or if no identity is found in both the P-Asserted-Identity and From-Header.

3.1.12   media

This condition evaluates to TRUE when the value of this condition matches the media field in one of the "m=" lines in the SDP offered in the INVITE.

3.1.13   no-answer

This condition evaluates to TRUE when the served user does not answer. In all other cases, the condition evaluates to FALSE. Rules with this condition are evaluated when a no-reply time-out is detected.

3.1.14   mmt-serv:in-sip-request

This condition is an assembly of regexp subconditions on a SIP request triggering a given rule. A particular header or header parameter can be matched directly or inversely. Subconditions used in service rules must be predefined by operator in the User Common Data. The condition evaluates to TRUE if ALL subconditions evaluate to TRUE.

3.2   Actions

The rule only has one action. The actions supported in the rules within the ruleset are the following:

• mmt-serv:parallel-distribution
• mmt-serv:serial-distribution
• mmt-serv:flexible-distribution
• play-announcement

3.2.1   mmt-serv:parallel-distribution

The action mmt-serv:parallel-distribution is associated with an optional "ring-period" attribute specifying the maximum time period for which the targets are to be left ringing in parallel without an answer. The "ring-period" attribute applies to all the targets, and has a range of 15–360 seconds. It also has up to 10 <target> elements with the "name" attribute as the unique key. It is a reference by name to a target identity to which the communication is to be distributed. The name in the rule must have a matching name either in the FCD target list or in the common target list, or in the common device list from the User Common Data or it has to be the special value (PRIMARY, or PRIMARY_MOBILE, or PRIMARY_FIXED).

For more information about target handling for the FCD service, refer to MTAS Target Handling Management Guide.

At least one <target> element must be present on creation of a <parallel-distribution> element.

The special value PRIMARY cannot be used in the same rule together with targets from the common device list.

3.2.2   mmt-serv:serial-distribution

The action mmt-serv:serial-distribution has up to 10 <target> elements with the "name" attribute as the unique key. It is a reference by name to a target identity to which the communication is to be distributed. The name in the rule must have a matching name either in the FCD target list or in the common target list, or in the common device list from the User Common Data or it has to be the special value (PRIMARY, or PRIMARY_MOBILE, or PRIMARY_FIXED).

For more information about target handling for the FCD service, refer toMTAS Target Handling Management Guide.

The order of serial dialing is defined by the order the mmt:serv:target is defined within a rule. At least one <target> element must be present on creation of a <serial-distribution> element.

Each <target> element has associated with it an optional "ring-period" attribute specifying the maximum time period for which the target is to be left ringing without an answer. The ring period range is 15–360 seconds.

The special value PRIMARY cannot be used in the same rule together with targets from the common device list.

The PRIMARY keyword cannot be combined with PRIMARY_MOBILE or PRIMARY_FIXED in the same action set.

3.2.3   mmt-serv:flexible-distribution

The action mmt-serv:flexible-distribution has up to 10 <target> elements with the "name" attribute as the unique key. It is a reference by name to a target identity to which the communication must be distributed. The name in the rule must have a matching name either in the FCD target list or in the common target list, or in the common device list from the User Common Data, or it has to be the special value (PRIMARY, PRIMARY_MOBILE, PRIMARY_FIXED, or VOICEMAIL). At least one <target> element must be present on creation of a <flexible-distribution> element.

For more information about target handling for the FCD service, refer to MTAS Target Handling Management Guide.

In this action, it is possible to combine parallel and serial ringing. Attributes serial and parallel are used to mark the targets in the target list. The target list is processed from the top to the bottom. If a target is marked with serial, it is rung simultaneously with the next parallel marked targets below this target until a target marked with serial is found, or the end of the target list is reached. If a target is marked with parallel, it is rung simultaneously with the previous serial target and with the similarly marked targets below this target until a target marked with serial is found, or the end of the target list is reached.

It is possible to use the optional ring-period parameter for every serial target in the target list. Within the same parallel target, the set MTAS uses the ring-period that is set for the corresponding serial target and restrict different settings for the subsequent targets, which are marked as parallel.

It is not possible to add the same target to the same parallel target set.

3.2.4   play-announcement

The action play-announcement, when present in the rule, it indicates which operator named announcement to be played to the caller. It replaces the regular announcement.

This action plays a user-selected network announcement to the caller by using the Generic Announcement service.

The Generic Announcement service allows the operator to associate a name with a combination of announcement parameters. This way, the name can be used in other services to control the playing of an announcement.

The FCD service uses the generic announcement attributes from the instance of MtasGaAnn with the specified name to play the announcement.

If there is no instance of MtasGaAnn with the specified name, the default FCD announcements which are specified in the MtasFcd MOC (mtasFcdAudioAnnounceCode, mtasFcdVideoAnnounceCode, mtasFcdAVAudioAnnounceCode, mtasFcdAVVideoAnnounceCode) are used.

3.2.5   Rule Evaluation Points

The rules are evaluated at each actuation point:

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:

• "not-registered" can only be TRUE for 1
• "not-reachable" can only be TRUE for 4 or 5
• "busy" can only be TRUE for 3 or 6
• "no-answer" can only be TRUE for 7

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 cannot be “not-reachable”. The reason for diverting at actuation point 3 or 6 cannot be "busy". The reason for diverting at actuation point 7 cannot 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, mmt-serv:served-identity 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.

4   FCD Configuration

The FCD service is controlled by the MtasFcd MO. An overview of the FCD MO structure is shown in Figure 2.

Configurable MOs and attributes related to the FCD service are defined in Managed Object Model (MOM).

4.1   FCD Service in Transparent Mode

The FCD Service may work in Transparent Mode if the attribute mtasMmtTransparentMode is set to 1 (and vtasMmtTransparentMode respectively) and Calling party supports the private P-Early-Media header extension.

The FCD Service in Transparent Mode passes all early messages from the Called party to Calling party so as from Calling Party to Called party. To constrain unwanted backward early media from target terminals, the FCD Service suppresses the P-Early-Media header value by using the "P-Early-Media: inactive" header in SIP signals relayed upstream.

When the mtasMmt199Generation attribute is enabled and Calling party supports 199 responses, the FCD Service notifies the Calling party of early dialog termination.

4.2   FCD Service in Non-Transparent Mode

The FCD Service works in non-transparent Mode if the attribute mtasMmtTransparentMode is set to 0 (and vtasMmtTransparentMode respectively) or Calling party does not support private P-Early-Media header extension.

In this mode "precondition" and "199" option tags are removed from the supported header field in initial Invite message sent to Called party. To constrain unwanted backward early media from target terminals, the FCD Service changes all media direction to "sendonly" and removes preconditions in SDP in Invite messages to target terminals. In non-transparent mode all early update messages are rejected. All provisional responses from Called party are not forwarded upstream to the Calling party but are served by FCD Service.

4.3   Announcement Configuration

The FCD plays an audio or video announcement, or both, to indicate to the caller that the FCD communication is established.

Announcement handling and FCD announcement attributes are described in MTAS Announcement Management Guide.

4.4   Auto-Answer-Avoidance Announcement Configuration

The FCD plays an audio or video announcement, or both, to indicate to the Called party that the confirmation by pressing any digit is required.

4.5   Prefix Configuration

Prefixes can be added to specify routing in the network for non-IMS targets. The MTAS can add a prefix to both the R-URI and P-Asserted-Identity based on the FCD service configuration. The prefix is defined in the FCD service data as the network-type attribute. If network-type is non-IMS, then a prefix is added. Prefixes are defined by the attributes mtasFcdCallingPrefix (P-Asserted-Identity Tel or SIP E.164 URI) and mtasFcdCalledPrefix (main called number in the FCD service Tel or SIP E.164 URI).

4.6   FCD Administrative State Configuration

The FCD service is enabled by setting the mtasFcdAdministrativeState attribute to 1 (Unlocked).

If the mtasFcdAdministrativeState is set to 0 (Locked), no FCD service is provided by the MTAS.

4.7   Wholesale for FCD Configuration

The FCD service supports Wholesale. The FCD is configurable on Virtual Telephony Provider (VTP) level.

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

• The vtasFcdAdministrativeState attribute in the VtasFCD MO
• The mtasFcdAdministrativeState attribute in the MtasFCD MO

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

4.8   FCD to Primary User’s Devices Configuration

4.8.1   Node Level Configuration

FCD to Primary User’s Devices is enabled by setting mtasFcdDistributeToPrimaryUserDevices attribute to 1.

FCD to Primary User’s devices requires caching contact data to be enabled in MTAS (mtasSubsDataCacheContactData=1). Served user’s devices are classified as "mobile/VoLTE" or "fixed" during registration based on criteria configured in mtasSubsDataMobileClassification attribute. For more information on caching contact data and UE terminal type classification, see MTAS Subscriber Data Management Guide.

Optional mobile and fixed terminal selectors added to caller preferences in the Accept-Contact headers for each INVITE sent towards mobile and fixed devices are configured using mtasFcdAdditionalTermSelectorFixed and mtasFcdAdditionalTermSelectorMobile CM attributes.

Active Call Preference for Fixed Devices is enabled by setting mtasFcdActiveCallPreference attribute to 1.

Multi-device charging is enabled by setting mtasChargingProfileMultiDevice attribute to 1 (in the charging profile).

Multi-device online charging also requires mtasChargingProfileWaitForCca to be set to 1 (enabled).

4.8.2   Subscription Level Configuration

The following subscription level configuration options are mandatory for FCD to Primary User’s Devices:

• The served user has the FCD service provisioned and active.
• Primary Number Hosting is set to "IMS".
• FCD Divert Primary is disabled.

See Section 4.10.1 Operator Subscription Level Service Configuration for details.

If FCD to Primary User’s Devices is enabled and all the preconditions listed in this section are fulfilled, then the reserved names used in the name attribute of the mc:target element in Subscription Rules, have the following meaning:

• PRIMARY : denotes parallel call distribution to all (mobile/VoLTE and fixed) currently registered terminals of a served user.
• PRIMARY_MOBILE: denotes call distribution to mobile terminal only.
• PRIMARY_FIXED: denotes call distribution to fixed terminal only.

If none of the above names is used in an active rule, the call is distributed to Primary User’s Devices anyway besides the targets defined within the rule, as if the rule contained also the PRIMARY keyword.

If either no FCD rule is provisioned or no rule is matched, all calls are unconditionally distributed to all (mobile/VoLTE and fixed) currently registered terminals of a served user on initial INVITE.

To enable Multi-device charging for selected served users, an appropriate charging profile, with mtasChargingProfileMultiDevice attribute set to 1, must be assigned to these served users.

For more information about charging profiles, refer to MTAS Charging Management Guide.

4.9   Caller Preference Filtering Configuration

The mtasFcdCallerPrefReqFilter attribute defines which caller preferences of the Accept-Contact and Reject-Contact headers of an incoming request are not to be copied by the FCD service to outgoing requests towards distribution targets to avoid collisions with caller preferences added by the FCD service itself. It contains a list of feature tags, for example, "mobility". An empty string, being a default value of the mtasFcdCallerPrefReqFilter attribute, means that all caller preferences, besides sip.instance is copied. The sip.instance caller preference is always filtered out independent of this setting.

Parameters configured as mobile and fixed terminal selectors (mtasFcdAdditionalTermSelectorMobile and mtasFcdAdditionalTermSelectorFixed) are to be typically added to the list of filtered out caller preferences.

Caller Preference Filtering is independent of the FCD to Primary User’s Devices function.

Caller preferences are filtered out only when FCD is enabled at node level and provisioned to the subscriber.

4.10   Service Data Configuration

This section describes how to configure the service data.

Details on the CAI3G and Ut XML element mappings are shown in Table 1. The mapping is used to associate CAI3G operator elements detailed in Section 4.10.1 Operator Subscription Level Service Configuration with the Ut subscription elements given in Section 3 Subscription Rules and examples.

(1)  Read-only

4.10.1   Operator Subscription Level Service Configuration

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

The operator can set or delete the following data:

• Maximum number of targets in the target-list.
• Primary number hosting, IMS, or non-IMS.
• Maximum number of FCD rules.
• FCD Divert Primary service.
• Whether to allow the subscriber to control length of the no reply timer.
• Which individual conditions and actions the subscribers can use.
• No Reply Timer.
• List of distribution targets
• Fixed-target attribute of the list of distribution targets
• FCD rules

4.10.1.1   Maximum Number of Targets

The mc:max-targets element controls the maximum number of distinct targets that the user can have in addition to the PRIMARY, PRIMARY_MOBILE, PRIMARY_FIXED, and VOICEMAIL identities. It is an integer value from 2 through 10.

4.10.1.2   Primary Number Hosting

The mc:primary-hosting element defines where the primary identity is hosted. The following values are possible:

• IMS: For users hosted on the IMS network
• non-IMS : For users who have communication distribution performed by the IMS network but are not registered on the IMS network, for example, users on a separate circuit-switched network.

4.10.1.3   Maximum Number of FCD Rules

The mc:rule-limit element defines the maximum number of allowed FCD rules in the user document. Not specified or zero limit means no limit.

4.10.1.4   FCD Divert Primary

The mc:fcd-divert-primary element in the operator part of the XML document can have values "activated" or "deactivated". When set to "activated", the user is able to use divert-primary element to divert the incoming communication distributed to PRIMARY to a different target. If set to "deactivated", it withdraws the divert-primary service from the user.

The mc:divert-primary element in the user part of the XML document is used for diverting the incoming communication distributed to PRIMARY to an alternative target.

The mc: divert-primary element consists of the following subelements:

mc:active

The mc:active element has values "TRUE" or "false". It indicates whether FCD divert primary service is activated or not.

mc:forward-to

The mc:forward-to element is a grouping element with details of the target to which the communication towards the PRIMARY is to be diverted and optional control of notifications and which identities are revealed to whom.

mc:target

The mc:target element specifies the identity to which the communication is to be diverted. This takes the form of a sip: or tel: URI or "voicemail:internal" for forwarding to voicemail. Each tel: URI and sip: URI that was converted from a tel: URI, according to section 19.1.6 of RFC 3261 contains a normalized number or a number that can be normalized after removing a dynamic ad-hoc presentation SSC or a CSC.

mc:notify-caller

The mc:notify-caller element has values "TRUE" or "false". It controls whether the caller is notified that the call is being forwarded. If it is not included in the mc:forward-to element, then the default behavior is to notify the caller (TRUE).

mc:reveal-identity-to-caller

The mc:reveal-identity-to-caller element has values "TRUE" or "false". It controls whether the caller being notified that the call is being forwarded receives the target's identity information. If it is not included in the mc:forward-to element, then the default behavior is to reveal the target's identity to the caller (TRUE).

mc:notify-served-user

The mc:notify-served-user element has values "TRUE" or "false". It controls whether the served user is notified that the call is being forwarded. If it is not included in the mc:forward-to element, then the default behavior is not to notify the served user (false).

mc: notify-served-user-on-outbound-call

The mc:notify-served-user-on-outbound-call element has values "TRUE" or "false". It controls whether the served user is notified that calls are being forwarded when making a call attempt. If it is not included in the mc:forward-to element, then the default behavior is not to notify the served user on outbound calls (false).

mc: reveal-identity-to-target

The mc:reveal-identity-to-target element has values "TRUE" and "false". It controls whether the diverted-to party receives identity information of the diverting party. If it is not included in the mc:forward-to element, then the default behavior is to reveal the diverting party's identity to the target (TRUE).

4.10.1.5   No Reply Timer

The mc: user-no-reply-timer element in the operator part of the XML document has values "activated" or "deactivated". When set to "activated", it allows the subscriber to control the length of the no reply timer.

The mc: NoReplyTimer subelement of the mc:fcd-service-options element in the user part of the XML document specifies the time, that must expire without any response, before the no-answer condition is triggered. The value is an integer in the range of 5–180 seconds. This value applies to rules with no-answer condition which do not contain their own individual timer.

4.10.1.6   List of Distribution Targets

The mc:target-list element defines a list of related users' identities that can be used as targets for the FCD service rules in addition to PRIMARY, PRIMARY_MOBILE, PRIMARY_FIXED, and VOICEMAIL identities. It can contain up to 10 entries.

The list is located in the fcd-user-configuration part of the XML document.

The target-list in user-common-data is the preferred way to define related targets, so that they are available across multiple services. The target-list is retained within communication-distribution for backwards compatibility.

The mc:target-list element consists of the following subelements:

mc:target

The mc:target element consists of two attributes, id and name.

mc:id

The attribute id of the mmt-serv:target element is a sip: or tel: URI. Each tel: URI and sip: URI that was converted from a tel: URI, according to section 19.1.6 of RFC 3261, contains a normalized number or a number that can be normalized after removing a dynamic ad-hoc presentation supplementary service code or a Carrier Select Code, or both.

mc:name

The attribute name of the mc:target element is a unique name by which distribution rules can refer to a given target from. The name attribute of mmt-serv:target element, see attribute name, from distribution rules, see Section 3.2.1 mmt-serv:parallel-distribution, Section 3.2.2 mmt-serv:serial-distribution, and Section 3.2.3 mmt-serv:flexible-distribution.

The name attribute of the mc:target element is a string of 1–30 characters long. It must be different from the reserved names: PRIMARY, PRIMARY_MOBILE, PRIMARY_FIXED, and VOICEMAIL.

mc:fixed-targets

The operator can set the fixed-targets element to TRUE (read only) or false (read, write). When set to TRUE, the target identities are set by the operator and cannot be changed by the user. When set to false, the served user can read and write the list of targets through the Ut interface.

4.10.1.7   FCD Rules

See Section 3 Subscription Rules for details.

4.10.2   Subscriber Subscription Level Service Configuration

The user subscriber data is configured through the Ut interface. The Ut interface and the XML schema for the Ut interface are described in the following documents:

• MTAS Ut Interface
• MTAS Ut Structure

The subscriber can set or remove the following:

• divert-primary – This element belongs to FCD Divert Primary service. When present, the incoming communication distributed towards IMS Primary User is diverted to configurable alternative target.
• No Reply Timer – specifies the time, that must expire without any response before the no-answer condition is triggered. The value is an integer in the range of 5–180 seconds. This value applies to rules with no-answer condition that do not contain their own individual timer.
• target-list – A list of the related targets that can be included in communication distribution rules. Up to ten target elements can be included in the target-list.
  • fixed-targets – When fixed-targets is set to "TRUE" then the target identities are set by the operator and cannot be changed by the user.
  • target – The target element allowing multiple instances with name as the unique key.
    • name – The name is the key for the distribution target. This is the name by which distribution rules refer to targets. It must be present on the creation of a <target> element.
    • id – The id is the identity of the target. It is a sip: or tel: URI. It must be present on the creation of a <target> element.
• Rules – Rules can be configured which contain the following elements:
  • Conditions – Specify the validity of a rule
  • Actions – Serial, parallel, or flexible ring mode with up to 10 identities from: FCD target list, common target list, common device list, or PRIMARY (the default identifier for the Primary User), PRIMARY_MOBILE, PRIMARY_FIXED, or VOICEMAIL.

    Refer to MTAS Target Handling Management Guide for details of common target list and common device list.

  • Subscriber can configure the FCD Rules using the condition and action elements described in Section 3 Subscription Rules.

4.11   Configuration of FCD Service for Error Responses

This section describes the configuration of FCD service for error responses.

4.11.1   Configuration of FCD Service in Case of 486 Busy Here Response

The FCD sends either 486 Busy Here response or 480 Temporarily Available response depending on the value of CM attribute mtasFcdBusyIndication.

To configure the FCD to send back 486 Busy Here response, the mtasFcdBusyIndication CM attribute must be set to 1 and one of the following conditions must be met:

• All targets must have reported 486 Busy Here.
• At least one FCD target has reported back 486 Busy Here and the other FCD targets have reported 408, 5xx or 6xx answers.
• Any target reported back Busy Everywhere which is configured by the mtasFcdBusyEverywhereResponses parameter and mtasFcdBusyEverywhereBehavior attribute is set to 0 and all other related users have reported 408, 5xx or 6xx answers.

If the mtasFcdBusyIndication parameter is set to 0, the FCD responses with 480 Temporarily Unavailable.

To configure the FCD to send back 486 Busy Here response when at least one FCD target has reported back 486 Busy Here without additional conditions, the mtasFcdBusyIndication parameter must be set to 2.

4.11.2   Configuration of FCD Service in Case of Busy Everywhere Responses

Busy everywhere behavior upon a response from a target is determined by the mtasFcdBusyEverywhereResponses CM attribute.

The mtasFcdBusyEverywhereResponses CM attribute is used to determine which SIP responses are treated as "Busy Everywhere" to initial INVITE. The attribute may contain three parts separated by colon. The first part contains the code of SIP response message, the second (optional) part can contain the Reason header or response phrase of response message, and the third (optional) part contains the alerting or progress (18x) message code.

For example if mtasFcdBusyEverywhereResponses contains these lists:

486:Call rejected by user:180
486:User has declined the call
603

Then all the following responses are handled as "Busy Everywhere” scenario":

• Client sends first 180 Ringing message and then 486 Busy Here message with "Call rejected by user" reason text in Reason header.
• Client sends first 180 Ringing message and then 486 with custom reason phrase "Call rejected by user"
• Client sends 486 Busy Here message with "User has declined the call" reason text in Reason header with or without previous 18x message.
• Client sends 486 with custom reason phrase "User has declined the call" message with or without previous 18x message
• Client sends 603 Decline. The Reason header in the response adds that the alerting message is not relevant. If MTAS receives 603 Decline, then the situation is handled as "Busy Everywhere".

If any target (during the FCD distribution) sends the response defined in mtasFcdBusyEverywhereResponses parameter, then FCD behavior depends on mtasFcdBusyEverywhereBehavior CM attribute:

• If the mtasFcdBusyEverywhereBehavior CM attribute is set to 1, then the FCD terminates distribution to all targets and send back 603 Decline to the caller regardless of the mtasFCDBusyIndication.
• If the mtasFcdBusyEverywhereBehavior CM attribute is set to 0, then the FCD terminates distribution only for the served user’s devices and continues distribution to related users. If all related users have reported error response, the MTAS sends back 480 Temporary Unavailable or 486 Busy Here, depending on the mtasFcdBusyIndication CM attribute.

4.12   Configuration of Reason Text in CANCEL Message

This section describes the configuration of reason text for Reason header in CANCEL message sent by FCD service.

4.12.1   Configuration of CM Attribute mtasFcdCallCompletedElsewhereReason

When an incoming call is distributed by the FCD service in parallel to multiple devices and one of those devices answers the call, use CANCEL message to terminate all other parallel call legs to other devices. The CM attribute mtasFcdCallCompletedElsewhereReason defines the reason text for Reason header in CANCEL message sent to devices not answering the incoming call.

The content of the attribute is copied to the reason text field of the Reason header. The value is to be added without quotation mark.

If mtasFcdCallCompletedElsewhereReason is set to text Call completed elsewhere, then the Reason header in CANCEL message looks like:

Reason: SIP; cause=200; text="Call completed elsewhere". 

The protocol type and the cause code are non-configurable.

If mtasFcdCallCompletedElsewhereReason attribute is empty, then the CANCEL message does not include the Reason header.

4.12.2   Configuration of CM Attribute mtasFcdBusyEverywhereReason

When an incoming call is distributed by the FCD service, a 486 Busy Here response message that fulfills the conditions for Busy Everywhere behavior is treated as a 603 Decline response and a CANCEL is sent to all other devices.

The Reason header text in CANCEL message is configurable using the attribute mtasFcdBusyEverywhereReason. The content of the attribute is copied to the reason text field of the Reason header. The value is to be added without quotation mark.

If mtasFcdBusyEverywhereReason includes Busy everywhere text, then the Reason header looks like this:

Reason: SIP; cause=600; text="Busy everywhere". 

The protocol type and the cause code are non-configurable.

If mtasFcdBusyEverywhereReason attribute is empty, then the CANCEL message does not contain the Reason header.

5   Performance Management

Measurements related to the FCD services are detailed in Managed Object Model (MOM).

6   Fault Management

Alarms related to the FCD services are listed in MTAS Alarm List.

7   FCD Rule Examples

The FCD rule examples described in this section use the following data:

• PRIMARY is the served user who has the FCD service. A served user has an FCD service with bundled targets.
• tel:+446666100001
• tel:+446666100002
• tel:+446666100003
• tel:+446666100004

7.1   Simple Rule Example 1

The following is applied for simple rule 1:

• Serially dial with ring period 30 seconds for all targets
• Target list read-only fixed-targets = true
• PRIMARY is not dialed first

This sort of rule defines a serial hunt type of dialing, where each terminal is dialed in a serial fashion for 30 seconds. If after 30 seconds the target does not answer, the next terminal is dialed. A typical use would be a family mode serial ring. It is activated anytime the served user who has the FCD service receives a communication.

An example of the simple rule 1 is shown in Example 5.

<ss:simservs>
	<mmt-serv:communication-distribution active="true">
		<mmt-serv:target-list fixed-targets="true"> 

<!-- list of targets that can be referred to by name from \
distribution rules -->
<!-- in addition to the special target named PRIMARY -->
<!-- fixed-targets set to true means the operator sets \
the targets and the user cannot change them -->
			<mmt-serv:target id="tel:+446666100001" name="Yasmin"/>
			<mmt-serv:target id="tel:+446666100002" name="Bilal" />
			<mmt-serv:target id="tel:+446666100003" name="Nargis"/>
			<mmt-serv:target id="tel:+446666100004" name="Rabbani"/>
		</mmt-serv:target-list>
		<cp:ruleset>
			<cp:rule id="cdist-family-serial-mode">
				<cp:conditions/>
<cp:actions>
					<mmt-serv:serial-distribution>
						<mmt-serv:target name="Yasmin" ring-period="30"/>
						<mmt-serv:target name="PRIMARY" ring-period="30"/>\
 <!-- note that the PRIMARY does not have to be rung first -->
						<mmt-serv:target name="Nargis" ring-period="30"/>
						<mmt-serv:target name="Rabbani"/>
					</mmt-serv:serial-distribution>
				</cp:actions>
			</cp:rule>	
		</cp:ruleset>
</mmt-serv:communication-distribution>
</ss:simservs>

7.2   Simple Rule Example 2

The following is applied for simple rule 2:

• Parallel ring with ring period 30 seconds for all targets
• Target list read-only fixed-targets = true
• The PRIMARY may or may not be defined in the rule

This sort of rule defines parallel dialing, where each terminal is dialed in parallel for 30 seconds. A typical use would be a family mode parallel ring. It is activated anytime the served user who has the FCD service receives a communication.

An example of the simple rule 2 is shown in Example 6.

<ss:simservs>
	<mmt-serv:communication-distribution active="true">
		<mmt-serv:target-list fixed-targets="true"> <!--user\
 may not add or remove targets (read-only)-->
			<mmt-serv:target id="tel:+446666100001" name="Yasmin"/>
			<mmt-serv:target id="tel:+446666100002" name="Bilal" />
			<mmt-serv:target id="tel:+446666100003" name="Nargis"/>
			<mmt-serv:target id="tel:+446666100004" name="Rabbani"/>
		</mmt-serv:target-list>
		<cp:ruleset>
		    <cp:rule id="cdist-family-parallel-mode">
		<!-- no conditions or empty conditions means this will catch\
 everything not matched by earlier rules -->
			    <cp:actions>	
			        <mmt-serv:parallel-distribution ring-period="30">
				    <mmt-serv:target name="PRIMARY"/>
				    <mmt-serv:target name="Yasmin"/>
				    <mmt-serv:target name="Nargis"/>
				    <mmt-serv:target name="Bilal"/>
				</mmt-serv:parallel-distribution></cp:actions>
			</cp:rule>		
</cp:ruleset>
	</mmt-serv:communication-distribution>
</ss:simservs>

7.3   Combining Simple Rules

Working mode and family mode scenarios could be achieved by having a set of simple rules, one for each mode with only one of which is activated at any time. The next two rules show working mode deactivated, and family mode activated.

An example of combined simple rules is shown in Example 7.

<ss:simservs>
	<mmt-serv:communication-distribution active="true">
	  <mmt-serv:target-list fixed-targets="true"> 
           
<!-- list of targets that can be referred to by name from\
 distribution rules -->
<!-- in addition to the special target named PRIMARY -->
<!-- fixed-targets set to true means the operator sets \
the targets and the user cannot change them -->
		    <mmt-serv:target id="tel:+446666100001" name="Yasmin"/>
		    <mmt-serv:target id="tel:+446666100002" name="Bilal" />
		    <mmt-serv:target id="tel:+446666100003" name="Nargis"/>
		    <mmt-serv:target id="tel:+446666100004" name="Rabbani"/>
	 </mmt-serv:target-list>
 <cp:ruleset>
     <cp:rule id="cdist-working-mode">
		<cp:conditions>
		    <ss:rule-deactivated/>
		</cp:conditions>
		<cp:actions>
		    <mmt-serv:parallel-distribution>
			<mmt-serv:target name="PRIMARY"/>
			    <mmt-serv:target name="Yasmin"/>
			    <mmt-serv:target name="Bilal"/>
		    </mmt-serv:parallel-distribution>
		</cp:actions>
    </cp:rule>								
    <cp:rule id="cdist-family-mode">
		<cp:conditions/>
		<cp:actions>
		    <mmt-serv:parallel-distribution>
		    <mmt-serv:target name="PRIMARY"/>
		    <mmt-serv:target name="Yasmin"/>
		    <mmt-serv:target name="Nargis"/>
		    </mmt-serv:parallel-distribution>
		</cp:actions>
    </cp:rule>
       </cp:ruleset>
    </mmt-serv:communication-distribution>
</ss:simservs>							
			

7.4   Time-based Complex Rules

Time mode type of rules can be defined by the users of the FCD service. Under time mode, the user can set several time segments, each of which contains start time and end time. The user can set parallel ring or sequential ring for each time segment.

A time-based rule can be defined by using the common policy validity condition. This uses absolute date-time values with offsets as required from UTC. If the current time falls between any of the from and until values, the validity condition is satisfied, and the action is performed, parallel ringing the targets.

An example of a time-based complex rule is shown in Example 8.

<ss:simservs>
	<mmt-serv:communication-distribution active="true">
		<mmt-serv:target-list fixed-targets="true"> <!--user may\
 not add or remove targets ( read-only)-->
			<mmt-serv:target id="tel:+446666100001" name="Yasmin"/>
			<mmt-serv:target id="tel:+446666100002" name="Bilal" />
			<mmt-serv:target id="tel:+446666100003" name="Nargis"/>
			<mmt-serv:target id="tel:+446666100004" name="Rabbani"/>
		</mmt-serv:target-list>
<cp:ruleset>
<cp:rule id="cdist-time-mode-1">
				<cp:conditions>
					<cp:validity>
		<!-- This example shows time being defined as an offset\
 from UTC-->	
						<cp:from>2008-10-12T20:00:00-08:00</cp:from>
						<cp:until>2008-10-19T19:59:59-08:00</cp:until>
												<cp:from>2008-11-27T20:00:00Z</cp:from>
						<cp:until>2008-11-28T08:00:00Z</cp:until>
					</cp:validity>
				</cp:conditions>
				<cp:actions>													
            <mmt-serv:parallel-distribution ring-period="60">
						<mmt-serv:target name="Yasmin"/>
						<mmt-serv:target name="Nargis"/>
						<mmt-serv:target name="Bilal"/>
					</mmt-serv:parallel-distribution>
				</cp:actions>
			</cp:rule>
</cp:ruleset>
</mmt-serv:communication-distribution>
</ss:simservs>	

7.5   Day and Time-Based Complex Rules

Complex rules based on day and time can be defined where users can set different ring modes with different ring periods and different days from Monday to Sunday. For example, working day, family mode, and sleeping mode are available.

A day time-based rule can be defined by using the mmt-serv:valid-periods condition as shown in Example 9. A repeating time mode can be based on days of the week and times within each day, see Section 3.1.3.2 mmt-serv:valid-days.

Working mode: If the current day is Monday-to-Friday (work) and the time falls between 09:00 and 12:00 or 13:00 and 17:00, the validity condition is satisfied, and the action is performed, serial ringing the targets as defined in the following by the rule cp:rule id = cdist-day-time-mode-2-working-week.

Family mode: If the current day is Saturday or Sunday (home) and time falls between 21:00 and 22:00, the validity condition is satisfied, and the action is performed, serial ringing the targets as defined in the following example by cp:rule id = cdist-day-time-mode-2-home.

<ss:simservs>
	<mmt-serv:communication-distribution active="true">
  	    <mmt-serv:target-list fixed-targets="true">
<!--user may not add or remove targets ( read-only) -->   			 

			<mmt-serv:target id="tel:+446666100001" name="Yasmin"/>
			<mmt-serv:target id="tel:+446666100002" name="Bilal" />
			<mmt-serv:target id="tel:+446666100003" name="Nargis"/>
			<mmt-serv:target id="tel:+446666100004" name="Rabbani"/>
		</mmt-serv:target-list>
  		<cp:ruleset>
    			<cp:rule id="cdist-day-time-mode-2-working-week">



       				<cp:conditions>
				    <mmt-serv:valid-periods>
				        <mmt-serv:utc-offset>+05:30</mmt-serv:utc-offset>\
				  		<mmt-serv:valid-days>
					    <mmt-serv:day>Monday</mmt-serv:day>
					    <mmt-serv:day>Tuesday</mmt-serv:day>
					    <mmt-serv:day>Wednesday</mmt-serv:day>
					    <mmt-serv:day>Thursday</mmt-serv:day>
					    <mmt-serv:day>Friday</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>
				    <mmt-serv:serial-distribution>
				         <mmt-serv:target name="Yasmin" ring-period="15"/>
				         <mmt-serv:target name="PRIMARY" ring-period="20"/>\
 <!-- note that the PRIMARY does not have to be rung first -->
				         <mmt-serv:target name="Nargis" ring-period="30"/>
					 <mmt-serv:target name="Rabbani"/>
				    </mmt-serv:serial-distribution>
				</cp:actions>
    			</cp:rule>
<cp:rule id="cdist-day-time-mode-2-home">
  				 <cp:conditions>
					<mmt-serv:valid-periods>
					    <mmt-serv:utc-offset>+05:30</mmt-serv:utc-offset>
					    <mmt-serv:valid-days>
					      <mmt-serv:day>Saturday</mmt-serv:day>
					      <mmt-serv:day>Sunday</mmt-serv:day>
					    </mmt-serv:valid-days>
					    <mmt-serv:valid-times>
					       <mmt-serv:interval from="21:00" until="22:00"/>
					    </mmt-serv:valid-times>
					</mmt-serv:valid-periods>
   				</cp:conditions>   
   				<cp:actions>
					<mmt-serv:serial-distribution>
					    <mmt-serv:target name="Yasmin" ring-period="15"/>
					    <mmt-serv:target name="PRIMARY" ring-period="20"/>\
 <!-- note that the PRIMARY does not have to be rung first -->
					    <mmt-serv:target name="Nargis" ring-period="30"/>
					    <mmt-serv:target name="Rabbani"/>
					</mmt-serv:serial-distribution>
  				</cp:actions>
			</cp:rule>
</cp:ruleset>
</mmt-serv:communication-distribution>
</ss:simservs>

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

7.6   Rules Using Targets from the Common Target List and Common Device List

The targets used in the FCD rules can be defined in the FCD target list, but also in the common device and common target lists. The common target list holds user-defined names and the related URIs, which can be used as targets (referred by name) in more than one service. The common device list holds user-defined names and the related terminal selectors, identifying the served user's terminals. The terminals can be used as targets (referred by name) in more than one service. The addressing of specific terminals of the served user by the MTAS is called AS Controlled Forking.

<ss:simservs
    <mmt-serv:communication-distribution active="true">
        <mmt-serv:target-list fixed-targets="true">
           <!-- list of targets that can be referred to by name from 
                distribution rules -->
           <!-- in addition to the special target named PRIMARY -->
           <!-- fixed-targets set to true means the operator sets the targets
                and the user cannot change them -->
           <mmt-serv:target id="tel:+446666100001" name="Alice"/>
           <mmt-serv:target id="tel:+446666100002" name="Bob" />
           <mmt-serv:target id="tel:+446666100003" name="Carol"/>
           <mmt-serv:target id="tel:+446666100004" name="Dave"/>
        </mmt-serv:target-list>
        <cp:ruleset> 
            <cp:rule id="cdist-user-common-data">
            <!-- this scenario shows targets both from the FCD target list and
                 from the user-common data -->
                <cp:actions> 
                     <mmt-serv:parallel-distribution ring-period="120">
                          <mmt-serv:target name="mobile"/>
                          <mmt-serv:target name="landline"/>
                          <mmt-serv:target name="Elin"/>
                          <mmt-serv:target name="Fredrik"/>
                          <mmt-serv:target name="Alice"/>
                     </mmt-serv:parallel-distribution>
                </cp:actions>
            </cp:rule>
       </cp:ruleset>
    </mmt-serv:communication-distribution>

    <mmt-serv:user-common-data>
      <mmt-serv:target-device-list fixed-targets="true">
         <mmt-serv:target-device name="mobile" terminal-selector="my-mobile" />
         <mmt-serv:target-device name="landline" terminal-selector="my-fixed" />
      </mmt-serv:target-device-list>
      <mmt-serv:target-list fixed-targets="false">
         <mmt-serv:target id="tel:+446666100005" name="Elin" /> 
         <mmt-serv:target id="tel:+446666100006" name="Fredrik" /> 
      </mmt-serv:target-list>
    </mmt-serv:user-common-data>
</ss:simservs>

7.7   Flexible Ringing If Served User Is Busy

This FCD rule executes flexible ringing after the PRIMARY user responds with busy. Although the ringing is defined as flexible, the serial alerting of Alice and Bob is going to happen.

<cp:rule id="fcd-busy-rule">
  <cp:conditions>
    <ss:busy/>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode="serial"/>
      <mmt-serv:target name="Bob" ring-mode="serial"/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.8   Flexible Ringing If Served User Is Not Reachable

This FCD rule executes flexible ringing if the PRIMARY user is not available. First of all the PRIMARY user is alerted but it responds with a 4xx/5xx/6xx SIP message which code is configured as not-reachable response code. After that Alice and Bob are alerted parallel. Although the ringing is defined as flexible, parallel distribution can also be used instead of flexible in this example.

<cp:rule id="fcd-not-reachable-rule">
  <cp:conditions>
    <ss:not-reachable/>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode="serial"/>
      <mmt-serv:target name="Bob" ring-mode="parallel"/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.9   Flexible Ringing If No Answer from PRIMARY User

This FCD rule executes flexible ringing if the PRIMARY user does not answer their phone. The PRIMARY user is alerted but the no-answer timer times out before the user accepts the call. After that Alice is alerted first, then Bob and Carol are alerted in parallel if Alice does not accept the call.

<cp:rule id="fcd-no-answer-rule">
  <cp:conditions>
    <ss:no-answer/>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode="serial"/>
      <mmt-serv:target name="Bob" ring-mode="serial"/>
      <mmt-serv:target name="Carol" ring-mode="parallel"/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.10   Flexible Ringing If Served User Is Not Registered

This FCD rule executes flexible ringing if the PRIMARY user is not registered and the mtasFcdNotRegisteredBehaviour is set to 1. Alice and Bob are alerted together in parallel then the call is diverted to VOICEMAIL.

<cp:rule id="fcd-not-registered-rule">
  <cp:conditions>
    <ss:not-registered/>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode="serial"/>
      <mmt-serv:target name="Bob" ring-mode="parallel"/>
      <mmt-serv:target name="VOICEMAIL" ring-mode="serial"/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.11   Flexible Ringing Based on Presence Status with Play-Announcement Action

This FCD rule executes flexible ringing if the PRIMARY user’s presence status is set to “on holiday”. First Alice is rung who is backup of the PRIMARY user during holiday. PRIMARY user is only disturbed with work related calls if Alice does not accept the call.

<cp:rule id="fcd-presence-rule">
  <cp:conditions>
    <ss:presence-status>on holiday</ss:presence-status>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode="serial"/> 
      <mmt-serv:target name="PRIMARY" ring-mode="serial"/>
    </mmt-serv:flexible-distribution>
    <mmt-serv:play-announcement>FCD on holiday</mmt-serv:play-announcement>
  </cp:actions>
</cp:rule>

7.12   Flexible Ringing Based on Identity

In the following example the served user wants to distribute all incoming communication from john@example.com in a flexible way: first Alice is rung for 15 seconds, then Bob is rung for default ringing period, then Carol and Dave are rung in parallel for 20 seconds, then PRIMARY is rung for default ringing period, finally VOICEMAIL is contacted:

<cp:rule id="alice">
  <cp:conditions>
    <cp:identity>
      <cp:one id="sip:john@example.com"/>
    </cp:identity>
</cp:conditions>
<cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="Alice" ring-mode=”serial” ring-period="15"/>
      <mmt-serv:target name="Bob" ring-mode=”serial”/> 
      <mmt-serv:target name="Carol" ring-mode=”serial” ring-period="20"/>
      <mmt-serv:target name="Dave" ring-mode=”parallel”/>
      <mmt-serv:target name="PRIMARY" ring-mode=”serial”/>
      <mmt-serv:target name="VOICEMAIL" ring-mode=”serial”/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.13   Flexible Ringing Based on Media Type and Anonymous

This FCD rule executes flexible ringing if an incoming anonymous call has not only audio but also video stream. In that case, the PRIMARY user is alerted with Videoroom1 in parallel, then with Videoroom2 in parallel. It means that the PRIMARY user is rung all along the distribution, only the parallel Related users are prioritized.

<cp:rule id="fcd-media-anonymous-rule">
  <cp:conditions>
    <ss:media>audio</ss:media>
    <ss:media>video</ss:media>
    <ss:anonymous/>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:flexible-distribution>
      <mmt-serv:target name="PRIMARY" ring-mode="serial" ring-period="70"/> 
      <mmt-serv:target name="Videoroom1" ring-mode="parallel"/>
      <mmt-serv:target name="PRIMARY" ring-mode="serial"/>  
      <mmt-serv:target name="Videoroom2" ring-mode="parallel"/>
    </mmt-serv:flexible-distribution>
  </cp:actions>
</cp:rule>

7.14   Parallel Ringing Based on Served-identity

The call is distributed to a target list when sip:john.doe@office.com is called but when the call arrives on any other ID of the same user (for example, sip:johnny@home.com), the call is not distributed.

<mmt-serv:communication-distribution active="true">
  <mmt-serv:target-list fixed-targets="true">
    <mmt-serv:target id="tel:+446666100001" name="Alice"/>
    <mmt-serv:target id="tel:+446666100002" name="Bob" />
    <mmt-serv:target id="tel:+446666100003" name="Carol"/>
    <mmt-serv:target id="tel:+446666100004" name="Dave"/>
  </mmt-serv:target-list>
  <cp:ruleset>
    <cp:rule id="cdist-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>
        <mmt-serv:parallel-distribution ring-period="60">
          <mmt-serv:target name="Alice"/>
          <mmt-serv:target name="Carol"/>
          <mmt-serv:target name="Bob"/>
        </mmt-serv:parallel-distribution>
      </cp:actions>
    </cp:rule>
  <cp:ruleset>
</mmt-serv:communication-distribution>

7.15   Flexible Communication Distribution to Primary User’s Devices Based on SIP regexp Condition

This is an example of two rules where PRIMARY or PRIMARY_MOBILE communication distribution target is combined with Related Users’ targets in the same action set. The first rule is based on SIP regexp condition.

The result of evaluating these rules is different depending on whether "FCD to Primary User's devices" is enabled at node level or not.

If the "FCD to Primary User's devices" function is enabled, the first rule triggers parallel communication distribution to all the served user’s devices (based on the PRIMARY keyword) and to two related users at an initial INVITE, if the INVITE contains a video caller preference. If there is no video caller preference in the initial INVITE, the second rule triggers parallel communication distribution to the served user’s mobile device (based on the PRIMARY_MOBILE keyword) and to two related users.

If the "FCD to Primary User's devices" function is disabled, each rule results in parallel communication distribution to the Primary User (based on either the PRIMARY or the PRIMARY_MOBILE keyword) and two related users. One single INVITE is sent towards the Primary User in this case without any terminal differentiation (no caller preference added).

FCD to Primary User's devices requires the served user to be configured as an "IMS Primary User" and FCDDP to be disabled, which is shown in the following "FCD operator part".

The SIP regexp condition on video caller preference must be defined in the operator configuration of the User Common Data.

FCD User Part
<mmt-serv:target-list fixed-targets="true">
  <mmt-serv:target id="C@ericsson.com" name="sim-ring-target-1"/>
  <mmt-serv:target id="D@ericsson.com" name="sim-ring-target-2"/>
</mmt-serv:target-list>

<cp:rule id="fcd-video-sip-regexp-to-primary-devices">
  <cp:conditions>
    <mmt-serv:in-sip-request>
      <mmt-serv:flexcondition id="video caller preference"/>
    </mmt-serv:in-sip-request>
  </cp:conditions>
  <cp:actions>
    <mmt-serv:parallel-distribution ring-period="30">
      <mmt-serv:target name="PRIMARY"/>
      <mmt-serv:target name="sim-ring-target-1"/>
      <mmt-serv:target name="sim-ring-target-2"/>
    </mmt-serv:parallel-distribution>
  </cp:actions>
</cp:rule>

<cp:rule id="fcd-all-other-to-primary-mobile-devices">
  <cp:actions>
    <mmt-serv:parallel-distribution ring-period="30">
      <mmt-serv:target name="PRIMARY_MOBILE"/>
      <mmt-serv:target name="sim-ring-target-1"/>
      <mmt-serv:target name="sim-ring-target-2"/>
    </mmt-serv:parallel-distribution>
  </cp:actions>
</cp:rule>


FCD Operator Part
<mmt-op:operator-communication-distribution activated="true">
  <mmt-op:max-targets>10</mmt-op:max-targets>
  <mmt-op:primary-hosting>IMS</mmt-op:primary-hosting>
  <mmt-op:fcd-divert-primary activated=”false"/>
</mmt-op:operator-communication-distribution>


User Common Data
<mmt-op:in-sip-request-condition activated="true"/>

<mmt-op:in-sip-request-condition-list>
  <mmt-op:flexcondition id="video caller preference"
    header="Accept-Contact" parameter="video" value="^true$"/>
</mmt-op:in-sip-request-condition-list>

7.16   Activated Divert Primary without Optional Forward-to Elements

This example shows the Flexible Communication Distribution Divert Primary (FCDDP) segment which tells to FCD to divert the incoming communication distributed (by FCD) towards the first instance of IMS Primary User to tel:+36-30-555-1234. The divert-primary service in this example is activated.

<mmt-serv:divert-primary>
  <mmt-serv:active>true</mmt-serv:active>
  <ss:forward-to>
    <ss:target>tel:+36-30-555-1234</ss:target>
  </ss:forward-to>
</mmt-serv:divert-primary>

7.17   Deactivated Divert Primary with Optional Forward-to Elements

This example shows the Flexible Communication Distribution Divert Primary (FCDDP) segment which tells to FCD to divert the incoming communication distributed (by FCD) towards the first instance of IMS Primary User to tel:+36-30-555-1234. When diverted by FCDDP, the following actions are performed:

• The diverted-to user's identity information is revealed to the caller party.
• The served user's identity information is revealed to the diverted-to party.
• The served user is not notified that the communication is being diverted.
• The served user is not notified that the communication is being diverted when making a call attempt.

The divert-primary service in this example is deactivated.

<mmt-serv:divert-primary>
  <mmt-serv:active>false</mmt-serv:active>
  <ss:forward-to>
    <ss:notify-served-user>false</ss:notify-served-user>
    <ss:notify-served-user-on-outbound-call>false
</ss:notify-served-user-on-
      outbound-call>
    <ss:reveal-identity-to-caller>true
</ss:reveal-identity-to-caller>
    <ss:reveal-identity-to-target>true
</ss:reveal-identity-to-target>
    <ss:target>tel:+36-30-555-1234</ss:target>
  </ss:forward-to>
</mmt-serv:divert-primary>