Contents

1   Introduction

This document describes how to configure the Network Announcement (NA) service in 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 MMTel AS Voice Base license must be installed.

For more information about the MMTel AS Voice Base 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 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 SIP/Q.850 Cause code). The announcement can be either fixed audio, video, or an audio-video announcement.

The NA service also offers the Network Message function when it is enabled. NM gives the possibility for an operator to configure the content of the SIP response depending on present of Warning header in the response.

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

The NM function is part of NA service. The NM function is triggered in originating MMTel AS when a SIP final response to an initial SIP INVITE in the range of 400–699 is about to be sent towards the User 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.

The NA service also offers a possibility for a UA to request an audio announcement to be played and reject the call establishment to user by sending a Non-Standard header where the name and value of the header are preconfigured strings.

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.

The configuration data for the Network Announcement service to play an announcement is selected in the following descending precedence:

1. The NA service selects an announcement based on a combination of the SIP error status code + Q.850/SIP cause code.
2. An announcement is selected based on the SIP error status code.

For Network announcements, the SIP error response that is sent to the UA-A after the announcement has ended, is selected in following descending precedence:

1. For an Originating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code + Q.850/SIP cause code: the SIP error response specified by the mtasNaAnnCauseRejectCode attribute. For a Terminating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code + Q.850/SIP cause code: the SIP error response specified by the mtasNaAnnCauseTRejectCode attribute.
2. For an Originating MTAS: the SIP error response specified by the mtasNaAnnRejectCode attribute.

   For a Terminating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code: the mtasNaAnnTRejectCode attribute.

3. The SIP error response specified by the mtasMmtSendSipOrigResponse or the mtasMmtSendSipTermResponse attributes described in MTAS Announcement Management Guide.
4. The SIP error response received.

The SIP error response can be sent including a Reason header with protocol (Q.850 or SIP) cause and reason text. The Q.850 or SIP cause and reason text are selected in following descending precedence:

1. For an Originating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code + Q.850/SIP cause code: the reason protocol, Q.850/SIP cause code, and reason text specified by the mtasNaAnnCauseRejectReason attribute are selected. For a Terminating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code + Q.850/SIP cause code: the reason protocol, Q.850/SIP cause code, and reason text specified by the mtasNaAnnCauseTRejectReason attribute are selected. The received Reason header is removed, if present.
2. For an Originating MTAS, the reason protocol, Q.850/SIP cause code and reason text specified by the mtasNaAnnRejectReason attribute.

   For a Terminating MTAS, where the configuration data for the Network Announcement service is found using SIP error status code: the mtasNaAnnTRejectReason attribute. The received Reason header is removed, if present.

3. The reason protocol, Q.850/SIP cause code and reason text received.

2.1.2   Requested Announcement Analysis

The Requested Announcement function is triggered and an analysis is started when a SIP INVITE is received.

The following input is used for the analysis:

• Configuration data for the Requested Announcement Service (mtasNaRa), the Request URI, and the media capabilities included in the SDP offer sent in the SIP INVITE.
• Configuration data for the Requested Announcement Service (mtasNaRaSipHeader) and Non-Standard SIP header in initial 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 an announcement is to be played to the UA-A. An MRF/MRFP resource is used for playing the announcement.

For Network announcements, the SIP error response that is sent to the UA-A after the announcement has ended, can be controlled as described in Section 2.1.1 Network Announcement Analysis.

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.1.4   Network Message

This subfunction it is triggered, when enabled, in originating MMTel AS when a SIP final response to an initial SIP INVITE in the range of 400–699 is about to be sent towards the UA-A. The function performs an analysis to see if the response is to be updated depending on present of Warning header in the response and the configuration.

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:

• Communication Completion No Reply (CCNR) service
• Communication Completion on Busy Service (CCBS)

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   NM Function Enable Configuration

The NM function is enabled by setting the mtasNaEnableNm attribute in the MtasNa MO to 1 (NETWORK_MESSAGE_FUNC_ENABLED).

3.3   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.3.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:

For more information on how to configure the attributes in the MtasNaAnn MO, refer to Managed Object Model (MOM).

3.3.2   SIP Error Response Returned for Specific SIP Error Code Configuration

The following attributes can be used to modify the SIP Error response by NA service:

For more information on how to configure the attributes in the MtasNaAnn MO, refer to Managed Object Model (MOM).

3.4   MtasNaAnnCause MO Configuration

The MtasNaAnnCause MO is created using <status-code>&<reason-protocol>&<reason-cause>. The <status-code> is SIP error status code and is in the range of 400–699. The <reason-protocol> is Q.850 or SIP. The <reason-cause> is Q.850/SIP cause code in Reason header and is in the range of 1–699. Examples "404&Q.850&16" or "404&SIP&488".

For MtasNaAnnCause, defined in the MtasNa MO, the following attributes can be used:

For more information on how to configure the attributes in the MtasNaAnnCause MO, refer to the Managed Object Model (MOM).

3.5   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.5.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:

For more information on how to configure the attributes in the MtasNaAnnT MO, refer to Managed Object Model (MOM).

3.6   MtasNaAnnCauseT MO Configuration

The MtasNaAnnCauseT MO is created using <status-code>&<reason-protocol>&<reason-cause>. The <status-code> is SIP error status code and is in the range of 400–699. The <reason-protocol> is Q.850 or SIP. The <reason-cause> is Q.850/SIP cause code in Reason header and is in the range of 1–699. Examples "404&Q.850&16" or "404&SIP&488".

For MtasNaAnnCauseT, defined in the MtasNa MO, the following attributes can be used:

For more information on how to configure the attributes in the MtasNaAnnCauseT MO, refer to Managed Object Model (MOM).

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

Choose an URI name that does not look like a telephone number to avoid confusion with the user=phone error correction.

Use the highest version value of the mtasNaRaVersion attribute.

3.7.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:

For more information on how to configure the attributes in the MtasNaRa MO, refer to Managed Object Model (MOM).

3.8   MtasNaRaSipHeader MO Configuration

For more information on how to configure the attributes in the MtasNaRaSipHeader MO, refer to Managed Object Model (MOM).

3.9   MtasNaNm MO Configuration

An MtasNaNm MO is keyed with the warning text string specified in the MTAS Fault Codes Catalogue.

To define network message for each MtasNaNm MO, the following attributes can be used:

For more information on how to configure the attributes in the MtasNaNm MO, refer to Managed Object Model (MOM).

3.10   MtasNaNmLanguage MO Configuration

An MtasNaNmLanguage MO is keyed with the provisioned preferred language for the calling user.

To define network message text for each MtasNaNmLanguage MO, the following attribute can be used:

For more information on how to configure the attributes in the MtasNaNmLanguage MO, refer to Managed Object Model (MOM).

3.10.1   Example Configuration of Network Message

Preconditions:

• mtasNaAdminstrativeState is unlocked.
• The 3PTY service rejects the initial INVITE with 403 Forbidden Warning: (399, "At least one 3PTY participant in the URI list is not put on HOLD by the 3PTY originator")
• MtasNaNm with the key "At least one 3PTY participant in the URI list is not put on HOLD by the 3PTY originator" exists. It is configured with:
  • mtasNaNmCauseTextToPhrase = 0 (Reason phrase in the status line is not changed).
• The calling user is provisioned with the preferred language-tag set to "en-us" in the common data.
• MtasNaNmLanguage with the key "en-us" exists.
  • mtasNmCauseText = Both 3PTY participants must be put on HOLD before creating a 3PTY call.
• MtasNaNmLanguage with the key "sv" exists configured with:
  • mtasNmCauseText = Tre parts samtalet kan inte sättas upp, minst en deltagare är inte parkerad.

mtasNaEnableNm is true

The following is sent to the caller:

Example 1:

403 Forbidden
Warning: (399,"At least one 3PTY participant in the URI list⇒
is not put on HOLD by the 3PTY originator”)
Reason: SIP; cause=403; "Both 3PTY participants must be put⇒
on HOLD before creating a 3PTY call"

Example 2:

Set mtasNaNmCauseTextToPhrase = 2 (Add the cause text in Reason header to the reason phrase in the status line).

The following is sent to the caller:

403 Forbidden: Both 3PTY participants must be put on HOLD⇒
before creating a 3PTY call
Warning: (399, "At least one 3PTY participant in the URI list⇒
is not put on HOLD by the 3PTY originator")
Reason: SIP; cause=403; "Both 3PTY participants must be put⇒
on HOLD before creating a 3PTY call"

Example 3:

The calling user is provisioned with the preferred language-tag set to "sv" in the common data.

Set mtasNaNmCauseTextToPhrase = 1 (Reason phrase in the status line is replaced with the cause text in the Reason header).

The following is sent to the caller:

403 Forbidden: Tre parts samtalet kan inte sättas upp,⇒
minst en deltagare är inte parkerad
Warning: (399,"At least one 3PTY participant in the URI list⇒
is not put on HOLD by the 3PTY originator”)
Reason: SIP; cause=403; "Tre parts samtalet kan inte⇒
sättas upp, minst en deltagare är inte parkerad"

Example 4:

Preconditions:

• MtasNaNm instance with the key "The Quick Brown Fox" is configured.
• MtasNaNmLanguage with the key en-us exists and is configured with mtasNaNmLanguageNmCauseText = Jumps Over The Lazy Dog .

Configuration:

1. Set mtasNaNmRejectReason to "Q.850;16".
2. Set mtasNaNmRejectCode to 480.

The 3PTY service rejects the initial INVITE with 403 Forbidden Warning:
(399, "The Quick Brown Fox")

The following SIP error response is sent to the caller:

480 Temporarily Unavailable
Warning: 399 "The Quick Brown Fox"
Reason: Q.850; cause=16; "Jumps Over The Lazy Dog"

mtasNaEnableNm is false

The following is sent to the caller:

403 Forbidden
Warning:(399,"At least one 3PTY participant in the URI list⇒
is not put on HOLD by the 3PTY originator")

3.11   SIP Error Response Code Configurations

For SIP error response sent to the UA-A based on the configurations, see Section 2.1.3 Play Announcement.

3.12   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.3.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.5.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration.

If the attribute is set to 0, no cause value is included in the SIP 183 Session Progress provisional response.

The MTAS can also be configured to include a Q.850 or SIP cause, corresponding cause code, and reason text in the Reason header, which is inserted in the SIP error response sent to the UA-A, generated by the NA service. Configure as follows:

• To specify the cause value for the originating MTAS, modify the attributes mtasNaAnnRejectReason and mtasNaAnnCauseRejectReason as specified in Section 3.3.2 SIP Error Response Returned for Specific SIP Error Code Configuration and Section 3.4 MtasNaAnnCause MO Configuration.
• To specify the cause value for the terminating MTAS, modify the attribute mtasNaAnnTRejectReason as specified in Section 3.5.1 Audio-Video Announcement Code for a Specific SIP Error Code Configuration.

For details, see Section 2.1.3 Play Announcement.

3.13   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.14   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.15   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 MTAS Performance Measurements.

5   Fault Management

Alarms related to the NA service are listed in MTAS Alarm List.