Contents
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 licenses must be installed.
For more information about the MMTel licenses, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
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.
If the mtasMmtExtendedFeatureTag attribute is set to "true" and the received INVITE does not contain an Accept-Contact header with the primary feature tag as defined in mtasMmtPrimaryFeatureTag with the extension as defined in mtasMmtExtendedStringFeatureTag, then a new Accept-Contact header entry is added which contains the primary feature tag as defined by mtasMmtPrimaryFeatureTag, extended by the feature tag extension as defined by mtasMmtExtendedStringFeatureTag.
|
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 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. |
+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:
- Provisioning of common target list and common device list, that can be used by more than one supplementary service
- Provisioning and configuration of attributes for time and calendar handling, used by more than one supplementary service
- Configuration of terminal selector prefix
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
This condition evaluates to "true" if one of the media types in "m=" line in offered SDP matches the value of this condition, the types are defined in RFC 4566 ("audio", "video", "text", "application" and "message").
Media Policy rule can have the following action:
- allow
Allow action can only have "false" value. This means that a matched media stream is not allowed.
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 served user’s Public User Identity (PUI) 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 served user's PUI and the content of the History-Info header.
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.
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):
- The vtasMmtAdministrativeState attribute in the VtasMmt MO
- The mtasMmtAdministrativeState attribute in the MtasMmt MO
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 in combination with the Flexible Communication Distribution service.
- Services dependent on unregistered state are not started
after an 18x message is received by the MTAS
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:
- Destination classified as OSN/NSN by Number Normalization configuration
- DNM Location-based short code
- National short code classified by Number Translation
- Directory assistant (OCT) call
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.
3.4.1.3.1 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:
- "tel:+1800", "sip:+1800@;user-phone"
Left-string match of the global number prefix "+1800"
- "tel:411", "sip:411@;user=phone"
Sub-string match of the number "411", the "411" can appear in any position of the destination URI
- ":411"
Left-string match of local number prefix "411"
- "+1^^^700", "tel:+1^^^700", "sip:+1^^^700@;user=phone"
Left-string number prefix match including wildcard characters, any destination in the range of +1000700 and +1999700 (for example. tel:+10007001111 or sip:+10007001111@operator.com;user=phone) is considered as destination category matched
- "example.com"
Substring domain match, any destination URI including the subdomain of "example.com" is considered as destination category matched
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
This section describes how to configure the service data.
3.5.1 Operator Subscription Level Service Configuration
The User Common Data is a "quasi service" holding user data common for more than one service.
The operator can:
- activate/deactivate the User Common Data subscription for the subscriber,
- Set the maximum number of targets in the common target list and in the common device list for the user,
- allow/disallow the use of the common device list and the holiday list for the user.
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.
| |
| Common device list | Holding user-defined names
and the related terminal selectors, identifying the served terminals
of the user.
| |
| 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.
| |
| 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 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.5.4 Charging
This section describes the Charging attributes.
For more information about charging in the MTAS, refer to MTAS Charging Management Guide.
3.5.4.1 Charging Profile
The mtasMmtChargingProfileRef attribute points to the charging profile that is applicable for MMTel.
3.5.4.2 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.5.5 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.5.6 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.5.7 Early Media Announcement
This section describes the early media announcement attributes.
3.5.7.1 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:
3.5.7.2 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 shall be sent. This attribute has effect only if mtasMmt199Generation is set to Enabled. If mtasMmt199Method is set to 199_ON_ALL, 199 provisional response is generated for all MTAS initiated early dialogs. If set to 199_ON_CONTINUE, 199 provisional response is generated only when the session continues after terminating the early dialog, according to 3GPP standards TS 24.642 and 24.628.
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.5.8 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 has 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 i.e [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.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 case of local ring back scenario. If this attribute is empty or does not specify an instance of the MO MtasGaAnn , no announcement is played.
3.5.10 NPLI CS Location Information
The mtasMmtNpliCSLocationInformation attribute defines if the Visitor Location Register (VLR) Number or Mobile Switching Center (MSC) Number provided by Network Provided Location Information (NPLI) Carrier Select (CS) Location Information, are added as extra parameters to the Access-Network-Information AVP, towards charging and P-Access-Network-Information (PANI) header used in SIP signaling. This attribute is considered only for terminating calls. The default value of the attribute is 0, which means that only the Cell Global Identity (CGI) is added to the Access Network Information AVP and PANI header. If the value of the attribute is 1, then the CGI, or the VLR Number, or the MSC Number, or all three, are added to the Access Network Information AVP and PANI header.
3.6 Configure Charging Interworking for MMTel AS
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.7 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.
4 Performance Management
For measurements related to the MMTel services, refer to Managed Object Model (MOM).
5 Fault Management
For alarms related to the MMTel service, refer to MTAS Alarm List.