MTAS MMTel Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1Subfunctions
2.2Interaction with Other Services

3
MMTel Configuration
3.1MMTel Administrative State Configuration
3.2Wholesale for MMTel Configuration
3.3MMTel Terminated Unregistered Behavior Configuration
3.4Long Duration Call Supervision for MMTel AS Configuration
3.5Service Data Configuration
3.6MMTel No Reply Timer
3.7Charging
3.8Reject Response Configuration
3.9Terminal Selection
3.10Early Media Announcement
3.11NPLI Retrieval Configuration
3.12Charging Interworking for MMTel AS Configuration
3.13Communication Diversion Loop Detection
3.14Local Ring Back
3.15Mobile User Determination
3.16MMTel for Business Line
3.17Configure Established MMTel Session Performance Measurement
3.18MMTel Services for User Without MMTel Subscription
3.19Nuisance Call Handling
3.20Mobile Subscription Charging Information Configuration
3.21Multiple Mobile Subscriptions Configuration
3.22Renegotiation Request Retry on 500 Error

4
Performance Management

5
Fault Management

1   Introduction

This document describes how to configure the Multimedia Telephony MMTel 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 MMTel service, the MMTel AS Voice Base licenses must be installed.

For more information about the MMTel AS Voice Base licenses, refer to MTAS Licenses.

1.1.2   Documents

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

1.1.3   Conditions

The following condition must apply:

2   Overview

This document describes the basic MMTel service that the MTAS offers to its subscribers.

MMTel is one of the IMS Services formats and provides the user with services belonging to the telephony service format. Additional 3GPP/TISPAN defined Supplementary Services, for example Communication Diversion (CDIV) and Communication Hold/Resume, can be executed depending on the profile of the user.

2.1   Subfunctions

This section describes the subfunctions provided by the MMTel service.

2.1.1   MMTel Session Control

An MMTel session is a session with services:

The Policing is neutral to the media transport profile. For example, the Real-Time Transport Protocol (RTP) / Audio-Visual Profile with Feedback (AVPF) profile is supported for each stream where the RTP / AVP transport is applicable.

2.1.2   Services for Unregistered Users

MMTel depending on configuration and other services, for example CDIV, play an announcement to the caller before rejecting the incoming call, in the case served user is not registered.

2.1.3   Feature Tag Processing

Table 1 details the processing of feature tags in the Accept-Contact header. Where "Known" implies a feature tag configured in, mtasMmtPrimaryFeatureTag and mtasMmtSecondaryFeatureTags, and "Unknown" implies a feature tag not configured in, mtasMmtPrimaryFeatureTag and mtasMmtSecondaryFeatureTags.

The value "urn: urn-7: 3gpp-service.ims.icsi.mmtel" is configured in the mtasMmtPrimaryFeatureTag attribute by default.

With the extended feature tag function, it is possible to tag the primary feature tag with a specified value defined in the attribute mtasMmtExtendedStringFeatureTag, for example "audio;explicit;require". The function extended feature tag is configured in mtasMmtExtendedFeatureTag and mtasMmtExtendedStringFeatureTag MO attributes.

A new Accept-Contact header entry is added if the following conditions apply:

The new Accept-Contact header entry contains the primary feature tag as defined by mtasMmtPrimaryFeatureTag extended by the feature tag extension as defined by mtasMmtExtendedStringFeatureTag.

An Accept-Contact header entry is extended if the following conditions apply:

The Accept-Contact header entry is extended by the feature tag extension as defined by mtasMmtExtendedStringFeatureTag.

Table 1    Accept-Contact Header Actions Taken in MTAS

Accept-Contact Headers

Action Taken

"Known" feature tag present in one of the Accept-Contact headers in the initial incoming INVITE.

The session is accepted as an MMTel session if any of the known feature tags are present in the Accept-Contact.


If the Accept-Contact header in the initial incoming INVITE does not contain the mtasMmtPrimaryFeatureTag but contains mtasMmtSecondaryFeatureTags, then the mtasMmtPrimaryFeatureTag is added. If there is a feature tag value defined in the mtasMmtPrimaryFeatureTag of urn-type for example "urn:urn-7:3gpp-service.ims.icsi.mmtel". The following feature tag is added unless +g.3gpp.icsi-ref is present in the mtasMmtSecondaryFeatureTags.


+g.3gpp.icsi-ref="urn:urn-7
:3gpp-service.ims.icsi.mmtel


This feature tag is also copied into the Contact header.

"Unknown" feature tag present- along with a recognized MMTel feature tag in one of the Accept-Contact headers in the initial incoming INVITE.

Same as in the previous row.

"Unknown" feature tag present with no MMTel recognizable feature tag in any of the Accept-Contact headers in the initial incoming INVITE.

The session is rejected with a 406 if none of the configured feature tags in mtasMmtSecondaryFeatureTags or mtasMmtPrimaryFeatureTag matches any of the Accept-Contact headers.

No Accept-Contact headers present.

  • If there are no Accept-Contact headers present in the initial incoming INVITE, and if the mtasMmtAllowNoFeatureTag is "true" then the session is accepted, and a feature tag is added to the Accept-Contact and contact headers, using the value defined in the mtasMmtPrimaryFeatureTag.

  • If there is a feature tag defined in mtasMmtPrimaryFeatureTag of urn-type for example "urn:urn-7:3gpp-service.ims.icsi.mmtel", the following two feature tags are added:


+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmte"


The session is rejected with a 406 if mtasMmtAllowNoFeatureTagis configured false.

No feature tag present in any of the Accept-Contact headers in the initial incoming INVITE.

Same as in the previous row.

2.1.3.1   Subscriber Specific Feature Tag Preference

Subscribers can be provisioned with specific feature tag preferences. In this case MTAS adds an Accept-Contact header with the defined preference in the terminating case. One example use of this function is to let Multimedia Telephony Application Server (MMTel AS) provide an access domain preference per subscriber, used by the SCC-AS.

For example, if the served user is provisioned with:

<mmt-op:feature-tag-preferences>
<mmt-op:feature-tags>lte;gsm</mmt-op:feature-tags>
</mmt-op:feature-tag-preferences>

The outgoing INVITE contains:

Accept-Contact: *;lte;gsm

Feature tag preferences are only applicable to served user's legs.

2.1.4   Prefix for Voice and Video Calls Configuration

With the prefix for voice and video call function, it is possible to add a configurable prefix number for voice and video calls to route such calls through a specific breakout point through the BGCF. The function is configured in mtasMmtMediaBasedRoutingAudioPrefix.

2.1.5   Configuration and Provisioning Options for Other Services

In addition to the basic MMTel session handling, MMTel provides configuration and provisioning support for other Supplementary Services:

2.1.6   Media Policy

With rule-based Media Policy subservice, it is possible to block certain media streams in offered SDP. Every rule matches on exactly one type of media, and media type must be one of the media types defined by RFC 4566 ("audio", "video", "text", "application", and "message"). Only "allow" action set to "false" is to be allowed, which determines that the media type-matched by the rule-should be blocked. Rule matching is to continue until all rules are checked.

MtasMediaPolicyLocalStreamBlocked and MtasMediaPolicyRemoteStreamBlocked are incremented by 1 when local or remote media streams are blocked in an SDP offer, respectively.

2.1.6.1   XML Configuration

Media policy configuration is part of the operator configuration. It is in the operator service data part of subscriber service XML. Media policy rules are based on Common Policy rules but only matching on media type is supported.

Example:

<mmt-data:operator-configuration>
<mmt-data:operator-service-data>
<mmt-op:operator-media-policy activated=“true”>
    <cp:ruleset>
        <cp:rule id=”video”>
            <cp:conditions>
                <ss:media>video</ss:media>
            </cp:conditions>
            <cp:actions>
                <ss:allow>false</ss:allow>
            </cp:actions>
        </cp:rule>
    </cp:ruleset>
</mmt-op:operator-media-policy>
</mmt-data:operator-service-data>
</mmt-data:operator-configuration>

Media Policy feature can be activated by setting activated attribute of operator-media-policy tag to "true".

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

Media Policy rule can have the following condition:

Media Policy rule can have the following action:

2.1.7   Communication Diversion Loop Detection

In addition to the basic MMTel session handling, MMTel provides a subfunction called Communication Diversion Loop Detection. The subfunction Call Diversion Loop at the terminating MMTel AS is based on the Public User Identity (PUI) of the served user and the information received in the History-Info header in the initial INVITE. If there is a loop detected, MMTel AS sends 482 Loop Detected with reason 482, Warning (399, "Call Diversion Loop Detected") to the caller. MMTel AS detects a call diversion loop by comparing the PUI of the served user and the content of the History-Info header.

2.1.8   P-Asserted-Service/P-Preferred-Service Header Processing

If CM attribute mtasMmtPAssertedSeviceBehavior is set, every INVITE requests (value 1 and 2) and optionally 18x/200 OK for INVITE responses (value 1) sent by the AS includes a P-Asserted-Service header configured with CM mtasMmtDefPAssertedService. In addition, any received P-Preferred-Service header is removed from messages when sending further.

2.1.9   Network or MTAS-Provided Local Ring Back

The mtasMmtLocalRingBackMode attribute defines if there is to be a user-controlled ring back or network-provided ring back. The default value of the attribute is 0, which is user-controlled ring back.

The mtasMmtLocalRingbackAnnouncementName attribute defines the name of the generic announcement to be used in local ring back scenario. If this attribute is empty or does not specify an instance of the MO MtasGaAnn, no announcement is played.

2.1.10   MMTel for Business Line

MMTel AS is by default deployed for consumer type of subscribers. However, there is also the option to deploy MMTel AS for Business Line with Unified Communication System (UCS) for enterprise services. Separate licenses for Business Line must then be in place. For more details on such deployment, see Section 3.16 MMTel for Business Line.

2.1.11   Mobile Subscription Charging Information

Mobile subscription and device information can be reported in charging per call depending on both configuration and provisioning.

2.1.11.1   Basic Subscription Information

IMSI is reported in the Subscription-Id AVP as type END_USER_IMSI.

IMEI and UUID available in the sip.instance feature tag of SIP messages during call establishment, reported in User-Equipment-Info and Instance-ID AVPs if available.

2.1.11.2   Extended Subscription Information

Extended subscription information includes the following information per mobile subscription:

Note:  
Only END_USER_SIP_URI is reported for diversion cases. mtasChargingProfileDefaultSubscriptionReportingBehavior can be used to report other values when set.

2.1.12   Multiple Mobile Subscriptions

MMTel AS supports subscribers with multiple mobile subscriptions (CS and EPS, or EPS only) within a single IRS.

Identical MMTel AS service settings are applied to all mobile devices. Extended subscription information is reported in charging.

2.2   Interaction with Other Services

A user can be in addition to basic MMTel have Supplementary Services tied to the subscription. A Supplementary Service can then change the behavior of MMTel. A possible service interaction is described for each subfunction where it can occur.

3   MMTel Configuration

The MMTel service is controlled by the MtasMmt Managed Object (MO). An overview of the MMTel MO structure is shown in Figure 1.

Figure 1   MMTel MO Structure

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

3.1   MMTel Administrative State Configuration

The MMTel service is enabled by setting the mtasMmtAdministrativeState attribute in the MtasMmt MO to 1 (Unlocked). If the mtasMmtAdministrativeState is set to 0 (Locked), no 3PTY service is provided by the MTAS.

3.2   Wholesale for MMTel Configuration

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

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

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

3.3   MMTel Terminated Unregistered Behavior Configuration

The terminating Unregistered behavior in MTAS is decided by the CM attribute mtasMmtTermUnregBehavior. This attribute specifies the trigger criteria for the terminating unregistered state, and this specification can be either when an initial INVITE is received in the terminating unregistered session case or when a SIP 480 is received after the initial INVITE has been sent to S-CSCF. When an initial SIP INVITE is received in MTAS for the terminating unregistered session case, no services dependent on the unregistered state is to be started. Instead the initial INVITE is sent to S-CSCF and the services dependent on the unregistered state are started if a 480 response is received from S-CSCF. The MTAS is responding with 480 Temporarily Unavailable when configured to act on the INVITE.

Note:  
  • Services dependent on unregistered state are not started after an 18x message is received by the MTAS.
  • The initial INVITE trigger criteria cannot be used with the Flexible Communication Distribution service.

3.4   Long Duration Call Supervision for MMTel AS Configuration

In addition to the basic MMTel session handling, MMTel AS provides supervision for long duration calls on Originating and Terminating MTAS. MTAS starts supervision timer on call establishment. On timer expiry, the call is disconnected with reason set as "Long Duration Call" in the Reason header of BYE and in a charging message. This feature is enabled by setting the mtasMmtLongDurationCallAdministrativeState to 1 (Unlocked). If the
mtasMmtLongDurationCallAdministrativeState is set to 0 (Locked), no supervision is applied.

The MtasMmtLongDurationCallOk PM Counter is incremented when long duration supervision timer expired. It is a keyed counter with possible values as Orig, Term, and Dest_Orig.

Long Duration Call Supervision timer value is configured in minutes and the value range is from 0 to 11,000 minutes. The user can configure Originating and Terminating calls specific timer value under MtasMmtLongDurationCall as explained in the following sections.

3.4.1   Supervision for Originating Calls Configuration

The user can configure long call supervision timer by setting different timer values under the MtasMmtLongDurationCallOrig MO as described in the following sections.

3.4.1.1   Default Originating Timer Configuration

The default originating supervision timer value is configured by the mtasMmtLongDurationCallOrigTimer. The default timer value is 480 minutes. If this timer value is set to zero, the long duration call supervision is disabled for all originating calls. This timer value is used by default when other originating supervision timers are not applicable. Diverted calls must be treated as "Originating calls" and must use originating configurations attributes.

Example configuration:

mtasMmtLongDurationCallOrigTimer: 480

3.4.1.2   Service Number Specific Originating Timer Configuration

Service number-specific supervision timer is applied when the destination number is identified as Service Number and the mtasMmtLongDurationCallOrigTimer must have a non-zero value. If this timer value is set to zero, the long duration call supervision is disabled for Service Numbers. It is set with mtasMmtLongDurationCallOrigServiceNumberTimer. The default timer value is 480 minutes.

The following are examples of service numbers:

Example configuration:

MtasMmtLongDurationCallOrigServiceNumberTimer: 480

3.4.1.3   Destination Categories Configuration

When the destination number is matched with operator defined destination categories, the corresponding timer value is used for supervision of long duration call. The mtasMmtLongDurationCallOrigTimer must have a non-zero value for this timer to be applicable. The user can define destination categories by configuring the mtasMmtLongDurationCallDestCatList attribute within the MtasMmtLongDurationCallDestCat MO, and the timer value for the same is set with the mtasMmtLongDurationCallDestCatTimer attribute. The default timer value is 480 minutes. If the timer value is set to zero, the long duration call supervision is disabled for all originating calls matched with the specific destination category.

The user can configure multiple MtasMmtLongDurationCallDestCat MO with integer number under MtasMmtLongDurationCallDestCats MO.

However, the mtasMmtLongDurationCallOrigDestCat attribute must be set in the MtasMmtLongDurationCallOrig MO to define the set of destination category configurations that are applicable for long duration originating call supervision. It is a set of integers where each integer represents destination category configuration from the MtasMmtLongDurationCallDestCat MO. The lowest integer number has the highest priority in destination category matching.

Destination Category List Configuration

The mtasMmtLongDurationCallDestCatList is a list of strings and each entry is a substring matched with a normalized target request URI.

The use of the wildcard character ‘ "^"’ (circumflex) is allowed in mtasMmtLongDurationCallDestCatList entries. Each occurrence of "^"’ matches any single character. For example, :+46^^7196992 matches both +46107196992 and +46207196992.

The definition of TEL URIs and SIP embedded TEL URIs (that is, SIP URI with user=phone) is supported. If both the destination and the entry URIs are TEL or SIP embedded TEL URIs, then the substring matching is performed only for the number part of the entry.

The substring match can be limited to left-string number prefix match if the entry starts with colon ":" or plus "+" characters, followed by the number prefix.

Entry configuration examples:

Example configuration:

MtasMmtLongDurationCallOrig MO:
 mtasMmtLongDurationCallOrigDestCat: 1
MtasMmtLongDurationCallDestCats MO:
MtasMmtLongDurationCallDestCat MO: 1
mtasMmtLongDurationCallDestCatList: "tel:+1800"
mtasMmtLongDurationCallDestCatList: ":411"
mtasMmtLongDurationCallDestCatTimer: 480
Note:  
When the feature is activated and the destination category list is configured in full capacity (250 entries), there is an average capacity dip of about 1%. This is because all originating calls are subjected to destination category matching through iterating all entries in worst case. It is recommended to configure destination category-specific numbers as service numbers to avoid destination category matching.

3.4.1.4   MMTel AS Terminating Calls Configuration

Default Terminating Supervision timer is configured with the mtasMmtLongDurationCallTermTimer. If this timer value is set to zero, the long duration call supervision is disabled for all terminating calls. Default timer value is 479 minutes.

Example configuration:

mtasMmtLongDurationCallTermTimer: 479

3.5   Service Data Configuration

3.5.1   Operator Subscription Level Service Configuration

The operator can configure the following:

In the MMTel configuration data for a subscriber, the operator indicates whether the subscriber is allowed to initiate MMTel through the CAI3G protocol. For more information, refer to MTAS CAI3G Interface.

3.5.2   Subscriber Subscription Level Service Configuration

The user part of the User Common Data includes the following data:

Common target list Holding user-defined names and the related URIs, that can be used as target in more than one service.
  • Fixed target list (true/false, changeable only by the operator) When fixed-targets is set to "true", then the target identities are set by the operator and cannot be changed by the user.
  • User-defined name
  • URI
Common device list Holding user-defined names and the related terminal selectors, identifying the served terminals of the user.
  • Fixed target list (true/false, changeable only by the operator) When fixed-targets is set to "true", then the target identities are set by the operator and cannot be changed by the user.
  • User-defined name
  • Terminal selector (feature tag)
UTC offset Holding the offset to be taken from UTC when determining times of day and when each day starts and ends. This attribute is considered when evaluating time conditions not containing the offset. If neither of them is provisioned, the offset given by CM attribute mtasMmtCalUtcOffset is used.
Note:  
When setting the value of this attribute, the Daylight Saving Time correction is to be considered as well.

The recommended way of specifying the UTC is to use the CM attribute mtasMmtCalUtcOffset.


Start day of week Holding the starting day of the week, used when evaluating time conditions related to weeks of the year or containing weekly repetition. It also serves as base of determining the week number. When the attribute is set to the Monday, the week number is set according to ISO 8601; week no. 1 in the year is the first week with at least 4 days from the new year. Otherwise week no. 1 is the week of 1st of January. If this attribute is omitted, then the starting day from the CM attribute mtasMmtCalStartDayOfWeek is used.
Non-workday list Holding list of weekdays considered as non-workday during evaluation of the time conditions. If this attribute is omitted, then the workday list from the CM attribute mtasMmtCalNonWorkday is used.
Holiday list Holding a list of private holidays to be used during evaluation of the time conditions associated. Use also the public holidays defined by CM attribute MtasMmtCalPubHoliday (yes/no).

3.5.3   Calendar Configuration and Recommendation for Summer/Winter Time

The mtasMmtCalStartDayOfWeek attribute specifies the starting day of the week. This attribute is used when evaluating service rules with conditions on calendar weeks. It also serves as base of determining the week number. When the attribute is set to the default value, the week number is set according to ISO 8601. That is, week no. 1 in the year is the first week with at least 4 days from the new year. Otherwise week no. 1 is the week of 1st of January. If the served user has been provisioned with own starting day of the week in the user document, then this attribute is ignored.

The mtasMmtCalUtcOffset attribute specifies the offset to be taken from UTC during evaluation of time-related service rule conditions. If the attribute is set to the default value, then days and times are based on UTC. This attribute is ignored if the user has provisioned UTC offset in the condition or in the user common data of the user document.

Note:  
When setting the value of this attribute, the Daylight Saving Time correction is to be considered as well.

Offset can be + or - regarding UTC, that is, [+-] hour is 00-23 ([0-1][0-9]|2[0-3]) minute is 00-59, that is, [0-5][0-9].

The mtasMmtCalNonWorkday attribute specifies the days of week that are considered as NOT working days during evaluation of time-related service rule conditions. This attribute is ignored if the user has provisioned nonworkday list in the user common data of the user document.

The MtasMmtCalPubHoliday attribute is created by the user.

3.5.4   Mobile Subscription Configuration

The operator can provision mobile subscriptions of the subscriber in the operator configuration part of User Common Data.

The following attributes must be provisioned per subscription:

The following attributes are optional per subscription. If not provisioned, MTAS fetches the information from HSS:

3.6   MMTel No Reply Timer

The mtasMmtNoReplyTimer attribute specifies the no-reply timer for MMTel sessions. The mtasMmtOrigNoReplyTimer is applicable for originating MMTel sessions if it is enabled (> 0), mtasMmtNoReplyTimer is then applicable only for the terminating MMTel sessions. Either timer is started when 180 Ringing is received.

3.7   Charging

This section describes the Charging attributes.

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

Charging Profile

The mtasMmtChargingProfileRef attribute points to the charging profile that is applicable for MMTel.

Charged Service Id

The mtasMmtChargedServiceId attribute specifies the charged service id, in feature tag format, for MMTel calls, to be included in charging data.

3.8   Reject Response Configuration

The mtasMmtSendSipTermResponse attribute is used to change/set which SIP error response the MMTel unregistered, Network Announcement or Incoming Communication Barring service have to send when an announcement has been played.

3.9   Terminal Selection

The mtasMmtTerminalSelectorPrefix attribute indicates that the prefix added in front of each provisioned feature parameter used for selecting a single terminal (terminal selector). The prefix is for adding such elements of the feature parameter that are not relevant for the end user. For example, the leading ‘+’ indicating non-RFC 3840 base parameters, or tags for operator/vendor specific namespace, for example "+g.operator.7.".

The mtasMmtAscfAdministrativeState attribute indicates the administrative state of the AS Controlled Forking feature. This attribute determines if MTAS can use terminal selector in the INVITEs sent to the served user.

3.10   Early Media Announcement

This section describes the early media announcement attributes.

Precondition Timer

The mtasMmtPreconditionTimer attribute specifies the time limit imposed to achieve the QoS precondition (RFC 3312) when attempting to play an announcement in early media. 0 has the special meaning that no timer is used to supervise the achievement of preconditions.

For more information about QoS precondition, refer to the following standards:

199 Provisional Response Configuration

The mtasMmt199Generation attribute indicates the administrative state of the 199 provisional response generation. If set to Enabled, 199 provisional response is generated when MTAS initiates the release of the MTAS established announcement early dialog.

The mtasMmt199Method attribute modifies when the 199 provisional response is to be sent. This attribute effects only if mtasMmt199Generation is set to Enabled.

The mtasMmt199Method attribute can be set to the following:

The mtasMmtGen199Reliably attribute indicates whether the 199 provisional response is generated reliably or unreliably. If set to Enabled, MTAS generates a 199 provisional response reliably.

3.11   NPLI Retrieval Configuration

The following attributes are used to configure Network Provided Location Information (NPLI):

3.12   Charging Interworking for MMTel AS Configuration

Interworking between MMTel AS and charging to report configured message body is decided by mtasMmtChargingInterworkingSupport and mtasChargingProfileFlexResponseEntry attributes configuration.

mtasMmtChargingInterworkingSupport attribute specifies message body types which Originating MMtel AS adds to the Accept header in outgoing INVITE message. Originating MMTel AS reports the message body contents in group AVP Transaction-info in online and offline charging messages based on the Charging Profile and mtasChargingProfileFlexResponseEntry attribute configuration.

3.13   Communication Diversion Loop Detection

The MMTel service enables the Communication Diversion Loop Detection function by setting the mtasMmtLoopDetection attribute in the MtasMmt MO to 1 (enabled). If the mtasMmtLoopDetection is set to 0 (disabled), no checks for Communication Diversion Loop Detection are performed.

3.14   Local Ring Back

The Local Ring Back function ensures correct generation of local Ring Back Tone towards caller at some scenarios by applying the following:

The Alert-Info filtering function prevents an Alert-Info:rtrequest by the terminating network to reach the caller, therefore avoiding a potentially incorrect generation of the local ring tone.

The "local ring back fallback at diversion" function provides ring tone towards caller in call diversion scenarios where a previous network or called party provided ring tone ends but with continued alerting. The function is required by some originating legacy networks that cannot switch to local ring tone generation following through-connection, that is, having received ring tone as early media. A prerequisite for the fallback function to trigger is that the initial INVITE includes a no-fork directive and that early media during alerting suddenly ends following diversion.

The renegotiation performed by the terminating MMTel AS towards the diverted target as part of the terminating local ringback function, can fail if the callee receives re-INVITE before ACK(INVITE). MTAS can be configured to apply a delay before initiating the renegotiation by setting attribute mtasMmtReInviteDelayTime to a non-zero value.

MTAS can in addition initiate a retry if receiving a 500 response to the re-INVITE with a Retry-After header if setting the attribute mtasMmtReInviteRetryAfterSupport to enable. The attribute mtasMmtReInviteRetryAfterTimeMax sets the maximum acceptable value of the re-INVITE retry time. The received Retry-After value is truncated to the upper limit, if it is exceeded.

The "local ring back fallback after early announcement generated by Originating MTAS" function provides ring tone towards caller in the call where early announcement generated by Originating MTAS and later first response from callee side is empty 180 Ringing. The function is required by some originating legacy networks that cannot switch to local ring tone generation following through-connection, that is, having received ring tone as early media. A prerequisite for the fallback function to trigger is that the initial INVITE includes a no-fork directive, that early media played from Originating MTAS to caller, and that first response from caller side is empty 180 Ringing.

The attribute mtasMmtLocalRingBackMode in the MtasMmt MO defines if there is user-controlled ring back or network provided ring back. For "local ring back tone fallback at diversion" case attribute mtasMmtLocalRingBackMode must be configured to any of the values:

For "local ring back tone fallback after announcement generated by Originating MTAS" case, attribute mtasMmtLocalRingBackMode must be configured to value:

For user-controlled ring back case, attribute mtasMmtLocalRingBackMode must be configured to value:

3.15   Mobile User Determination

MMTel AS provides the optional configuration mtasMmtMobileUserDetermination to determine served user as a mobile subscriber. The domain/sub-domain value of this attribute, typically in the IMS format ims.mnc<MNC>.mcc<MCC>.3gppnetworks.org, is right string match with the served users IP Multimedia Public User Identity (IMPU) domain part present in the Implicit Registration Set (IRS).

3.16   MMTel for Business Line

MMTel AS can be configured to serve Business Line (BL) users in a Unified Communication System (UCS) solution. A separate set of licenses for business deployment enables the MMTel services, and also a service to route Originating and Terminating calls to UCS for enterprise services (UC Routing).

MMTel AS is configured to serve the business line users when mtasMmtServedSubscriberType is set to BUSINESS (1) or BUSINESS_AND_CONSUMER (2). A served user is identified as being a business user if provisioned as subscriber-type = BUSINESS.

For more information about MMTel for Business Line users, refer to the following documents:

3.17   Configure Established MMTel Session Performance Measurement

The MMTel AS provides minimum, average, and maximum number of established MMTel sessions for a measurement Granularity Period. The MMTel service enables the established MMTel session performance measurement function by setting the mtasMmtEstablishedSessionGauge attribute in the MtasMmt MO to 1 (SESSION_GAUGE_ENABLED). If the mtasMmtEstablishedSessionGauge is set to 0 (SESSION_GAUGE_DISABLED), no established MMTel Session performance measurements are performed. The minimum, average, and maximum calculation is based on the set of established MMTel sessions count values, which are reported within the measurement period. The following apply:

3.18   MMTel Services for User Without MMTel Subscription

MMTel AS can be configured to serve a user without MMTel subscription. For the service to work, the following conditions must be met:

Outgoing calls of this user are by default barred unless the called number matches a white listed destination, for example, customer care.

When this type of call is allowed, the outgoing INVITE includes the calling party identity in the P-Asserted-Identity and From headers as configured Public User Identity (PUI) in attribute mtasMmtNoSubscriptionSharedPUI. This asserted identity is set as private in the SIP signaling.

The number of established sessions by subscribers without MMTel subscription is limited. The value is configured by attribute mtasMmtNoSubscriptionSimultaneousLimit. Any new call attempt, which exceeds the maximum number of simultaneous calls, is rejected with a 486 Busy response code.

3.19   Nuisance Call Handling

MMTel AS provides call handling support for emergency nuisance calls.

If CSCF detects that a subscriber is making a nuisance call, MMTel AS can be triggered to play a specific final announcement before rejection.

The function is an extension to the Service for users without the MMTel subscription feature but applies to all subscribers; with or without an MMTel subscription.

A call is treated as a nuisance call by MMTel AS if the Request URI (set by the CSCF) matches the configuration and the user is classified as not having an MMTel subscription.

3.20   Mobile Subscription Charging Information Configuration

3.20.1   Basic Subscription Information

IMSI provisioned in element IMSI of User Common Data.

3.20.2   Extended Subscription Information

Attribute mtasMmtMobileBehaviour must be set to MOBILE_ENHANCEMENT_ON.

At least one mobile subscription provisioned in User Common Data.

3.21   Multiple Mobile Subscriptions Configuration

The following configuration must be set to utilize Multiple Mobile Subscription support:

3.22   Renegotiation Request Retry on 500 Error

MMTel AS can receive 500 error response with Retry-After header for a relayed mid-dialog renegotiate request triggered by either Re-INVITE or UPDATE in downstream or upstream direction. In such scenario MMTel AS retries the renegotiation request after the delay time indicated in the received Retry-After header. The function is controlled with the CM mtasMmtMidCallRenegotiationRetryAfterSupport. The attribute mtasMmtReInviteRetryAfterTimeMax sets the maximum acceptable value of the retry time. If the received Retry-After value is exceeded it truncated to the upper limit.

4   Performance Management

For measurements related to the MMTel services, refer to MTAS Performance Measurements.

5   Fault Management

For alarms related to the MMTel service, refer to MTAS Alarm List.

Legal | © Ericsson AB 2016–2018