Contents
1 Introduction
This document describes how to configure the Network Announcement (NA) 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 NA service, the NA license must be installed.
For more information about the NA license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The NA service offers a possibility for an operator to play an announcement to a calling user when fault situations occur during a Multimedia Telephony (MMTel) session establishment, for example, a congestion or a wrong number. It is possible to configure if an announcement is played depending on the received SIP error status code and which announcement is played. The announcement can be either a fixed audio, video, or an audio-video announcement. An overview of the entities involved in the NA service is shown in Figure 1.
The MMTel system is an IMS-based system that provides multimedia services to both fixed and mobile devices. The MTAS is an application server within the MMTel system that provides services.
The NA function is part of the MTAS and is triggered when the MTAS is operating in the originating or terminating half-call. The MTAS communicates with the Media Resource Function Processor (MRFP) by the use of the H.248 protocol to control media stream resources. The MTAS communicates with the Call Session Control Function (CSCF) by the use of the SIP and Session Description Protocol (SDP) protocols.
The NA service is triggered during the establishment of an MMTel session, in an originating or terminating MTAS when a SIP final response to an initial SIP INVITE in the range of 400–699 is about to be sent to the User Agent (UA-A).
ITU-E.181 gives the general recommendation to provide all tones announcements as close to the originator as possible. MRF dimensioning consideration must be taken before activating NA on SIP responses that can cause mass signaling to MRF resources. For instance, SIP 500 and 503 responses that are received in network overload conditions.
The NA service also offers a possibility for a UA to request an audio announcement to be played to a user by sending an INVITE with a Request URI that is a preconfigured string identifying the required announcement. For example, an (MSAN/IAD) can wish to play an announcement when a user enters an invalid switching order code. The user can be the calling or called party on an existing call, but the request to play an announcement is always received by the MTAS as a new originating dialog request. This service is referred to as Requested Announcement (RA).
2.1 Subfunctions
This section describes the subfunctions included in the NA service.
2.1.1 Network Announcement Analysis
The NA function is triggered and an analysis is started when a SIP Error response is received from the terminating network during a MMTel session establishment. Input to the analysis is configuration data for the NA service and the media capabilities included in the SDP offer sent in the initial SIP INVITE.
2.1.2 Requested Announcement Analysis
The Requested Announcement function is triggered and an analysis is started when a SIP INVITE is received. Input to the analysis is configuration data for the Requested Announcement service, the Request URI, and the media capabilities included in the SDP offer sent in the SIP INVITE.
For more information about announcement handling and attributes for the NA service, refer to MTAS Announcement Management Guide.
2.1.3 Play Announcement
This subfunction is started if the outcome of the NA analysis is that an announcement is to be played to the User Agent UA-A. An MRFP resource is used for playing the announcement. For NAs, the SIP error response that is sent to the UA-A after the announcement has ended, can either be the SIP error response received previously or a SIP error response specified by the mtasMmtSendSipOrigResponse or the mtasMmtSendSipTermResponse attributes.
For Requested announcements, the early dialog with UA-A is released after the announcement has ended.
For more information about announcement handling and attributes for the NA service, refer to MTAS Announcement Management Guide.
2.2 NA Interaction with Other Services
The NA interaction with other MTAS services is described in this section.
2.2.1 Communication Diversion
If the NA service is triggered in the terminating MTAS for originating or terminating session cases, the NA service checks if a Communication Diversion (CDIV) has been performed (the MTAS is in the transit mode). If so, no announcement is played.
For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.
2.2.2 Communication Completion
The NA service does not play terminating network announcements if the terminating user is provisioned with either of the following:
For more information about the Communication Completion service, refer to MTAS Communication Completion Management Guide.
2.2.3 Number Translation
The RA service can also be used with the Number Translation service to provide the customized final reject announcements at outgoing calls of the served user.
3 NA Configuration
The NA service is controlled by the MtasNa MO and its children. An overview of the NA MO structure shown in Figure 2. The structure makes it possible to customize whether an announcement is played and which announcements that are played when the NA function is triggered.
Configurable MOs and attributes related to the NA service are defined in Managed Object Model (MOM).
3.1 NA Administration State Configuration
The NA service is enabled by setting the mtasNaAdministrativeState attribute in the MtasNa MO to 1 (Unlocked).
If the mtasNaAdministrativeState is set to 0 (Locked), no NA service is provided by the MTAS.
3.2 MtasNaAnn MO Configuration
The MtasNaAnn MO defines the audio or video, or both, announcements to be played when a certain SIP error code is received in the originating MTAS from the terminating side, or when this certain SIP error code is generated internally in the originating MTAS.
3.2.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration
When an MtasNaAnn MO is created, it must have the same name as the SIP error code. The name is an integer in the range of 400-699.
To define the audio/video code for each MtasNa MO, the following attributes can be used:
|
Attribute |
Description |
|---|---|
|
mtasNaAnnPlayAudioAnnouncement |
This attribute specifies whether an audio announcement is to be played when the final response is received. |
|
mtasNaAnnAudioCode |
This attribute specifies the audio announcement code to be played when the final response is received. |
|
mtasNaAnnPlayVideoAnnouncement |
This attribute specifies whether a video announcement code is to be played when the final response is received. |
|
mtasNaAnnVideoOnlyCode |
This attribute specifies the video announcement code to be played when the final response is received and the SDP offer contain video capabilities but not audio. |
|
mtasNaAnnAVAudioCode |
This attribute specifies the audio component of the audio-video announcement to be played when the final response is received. |
|
mtasNaAnnAVVideoCode |
This attribute specifies the video component of the audio-video announcement to be played when the final response is received. |
|
mtasNaAnnCauseValue |
This attribute specifies which Q.850 cause value and corresponding cause code that is to be included in a Reason header sent in the SIP 183 Session Progress, which is sent by the originating MTAS before the announcement is played. If this attribute indicates zero, no Reason header is included in the 183 Session Progress. |
For more information on how to configure the attributes in the MtasNaAnn MO, refer to Managed Object Model (MOM).
3.3 MtasNaAnnT MO Configuration
The MtasNaAnnT MO defines the audio or video, or both, announcements to be played when a certain SIP error code is received in the terminating MTAS from the terminating side or when this certain SIP error code is generated internally in the terminating MTAS.
3.3.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration
When an MtasNaAnnT MO is created, it must have the same name as the SIP error code. The name is an integer in the range of 400-699.
To define the audio/video code for each MtasNa MO, the following attributes can be used:
|
Attribute |
Description |
|---|---|
|
mtasNaAnnTPlayAudioAnnouncement |
This attribute specifies whether an audio announcement is to be played when the final response is received. |
|
mtasNaAnnTAudioCode |
This attribute specifies the audio announcement code to be played when the final response is received. |
|
mtasNaAnnTPlayVideoAnnouncement |
This attribute specifies whether a video announcement is to be played when the final response is received. |
|
mtasNaAnnTVideoOnlyCode |
This attribute specifies the video announcement code to be played when the final response is received and the (SDP) offer contain video capabilities but not audio. |
|
mtasNaAnnTAVAudioCode |
This attribute specifies the audio component of the audio-video announcement to played when the final response is received. |
|
mtasNaAnnTAVVideoCode |
This attribute specifies the video component of the audio-video announcement to played when the final response is received. |
|
mtasNaAnnTCauseValue |
This attribute specifies which Q.850 cause value and corresponding cause code that is to be included in a Reason header sent in the SIP 183 Session Progress, which is sent by the terminating MTAS before the announcement is played. If this attribute indicates zero, no Reason header is included in the 183 Session Progress. |
For more information on how to configure the attributes in the MtasNaAnnT MO, refer to Managed Object Model (MOM).
3.4 MtasNaRa MO Configuration
An MtasNaRa MO defines the following SIPs:
• the URI strings for which an announcement is to be played in an
originating MTAS on receipt of the matching Request URI.
In case of SIP embedded telephone numbers or tel URIs, the URI strings in MtasNaRa contains telephone number in user part and "Ericsson.com" in the domain part of URI.
The recommendation is to choose a URI name that does not look like a telephone number to avoid confusion with user=phone error correction.
3.4.1 Audio Announcement Code for a Specific SIP URI Configuration
To define the audio code for each MtasNaRa MO, the following attributes can be used:
|
Attribute |
Description |
|---|---|
|
mtasNaRaPlayAudioAnnouncement |
This attribute defines the audio announcement code to be played when the final response is received. |
|
mtasNaRaAudioCode |
This attribute defines the audio announcement code to be played when the final response is received. |
For more information on how to configure the attributes in the MtasNaRa MO, refer to Managed Object Model (MOM).
3.5 SIP Error Response Codes from MTAS Configuration
The mtasMmtSendSipOrigResponse attribute is used to set or change which SIP error response the NA service to send when an announcement has been played from the originating MTAS. If this attribute is set to 0, the same SIP error code as received is sent.
The corresponding attribute for the terminating MTAS is mtasMmtSendSipTermResponse. If this attribute is set to 0, the same SIP error code as received is sent.
3.6 Cause Value Configuration
The MTAS can be configured to include a Q.850 cause value and corresponding cause code in a Reason header that is inserted in the SIP 183 Session Progress provisional response sent to the UA-A, generated by the NA service.
To specify the cause value for the originating MTAS, modify the attributes mtasNaAnnCauseValue, see Section 3.2.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration.
To specify the cause value for the terminating MTAS, modify the attributes mtasNaAnnTCauseValue, see Section 3.3.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration.
If the attribute is set to 0, no cause value is included.
3.7 NA Administrative State Configuration
The CDIV service is enabled by setting the mtasNaAdministrativeState attribute in the MtasNa MO to 1 (Unlocked). If the mtasNaAdministrativeState is set to 0 (Locked), no NA service is provided by the MTAS.
3.8 Wholesale for NA Configuration
The NA service supports Wholesale. NA is configurable on Virtual Telephony Provider level.
Wholesale for NA is activated when the following attributes are set to 1 (Unlocked):
- The vtasNaAdministrativeState attribute in the VtasNa MO
- The mtasNaAdministrativeState attribute in the MtasNa MO
For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.
3.9 Service Data Configuration
No service data for the NA service is configured for the subscriber data.
4 Performance Management
Measurements related to the NA service are detailed in Managed Object Model (MOM).
5 Fault Management
Alarms related to the NA service are listed in MTAS Alarm List.