Contents
1 Introduction
This document describes how to configure the Gateway Model (GM) 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 GM service, the GM license must be installed.
For more information about the GM 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 GM service allows the MTAS to map events received from the terminating User Agent (UA) or network, in one or several early-dialogs, to the originating UA or network in one single dialog. This service is used when the originating UA or network does not support multiple early dialogs, cannot distinguish between early media (media before final answer for the initial INVITE) and regular media (media after final answer sent for the initial INVITE).
The GM service can be used in static mode, where it applies to every call, or in dynamic mode where the originating UA or network indicates its limited capabilities by including the "no-fork" directive in the Request-Disposition header of the initial INVITE.
The GM service can also be used by nodes, which does not support the concept of multiple dialogs per call. The node can add the "no-fork" directive to the Request-Disposition header of the initial INVITE. The GM service is triggered when the GM service is configured to unlocked and the mode is configured to dynamic.
2.1 Subfunctions
The subfunction included in the GM service is described in this section.
2.1.1 Handling of SIP Requests and Responses
This subfunction handles the mapping of events between the Originating User and the Terminating User. It also executes checks on events received from Originating User.
Since there is only one dialog between the Originating User and the MTAS, events received on the terminating side must be mapped to the single dialog on the incoming side. This means that when exchanging SIP events on the incoming side, the same From tag, To tag, and Call ID is used. Also, when exchanging Session Description Protocol (SDP) offers or answers, the same session Id is used (one in the Originating User to MTAS direction, and one in the MTAS to Originating User direction), and only the session version is incremented.
2.2 Terminal and Network Interaction
Terminals and other networks must include supported 100rel and must not include Require precondition or Accept: "application/vnd.etsi.sci+xml" for RTTI.
2.3 GM Interaction with Other Services
This section describes the GM interaction with other services.
2.3.1 Flexible Communication Distribution
GM deployed on the target side of the Flexible Communication Distribution (FCD) service, for example, on another MTAS, sends updates for any forked responses containing updated Session Description Protocol (SDP) answers.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
3 GM Configuration
The GM service is controlled by the MtasGm MO. An overview of the GM MO structure is shown in Figure 1.
Configurable MOs and attributes related to the GM service are defined in Managed Object Model (MOM).
3.1 Setting GM Mode
The attribute mtasGmMode defines the mode the GM service works in, and can be set to the value 0, 1, 2 or 3. The values represent the following modes:
- Originating (Orig) = 0
Originating mode provides the GM service on the originating side. It assumes that the mtasGmAdministrativeState is set to unlocked.
- Terminating (Term) = 1
Terminating mode provides the GM service on the terminating side. It assumes that the mtasGmAdministrativeState is set to unlocked.
- Both Originating and Terminating (OrigTerm) = 2
Both originating and terminating mode provides the GM service on both the originating and terminating side. It assumes that the mtasGmAdministrativeState is set to unlocked.
- Dynamic = 3
The dynamic mode provides the GM service on both the originating and the terminating side. It assumes, that the mtasGmAdministrativeState is set to unlocked and the GM is triggered when the "no-fork" directive is present in the Request-Disposition header of the initial INVITE.
3.2 GM Administrative State Configuration
The GM service is enabled by setting the mtasGmAdministrativeState attribute to 1 (Unlocked).
If the mtasGmAdministrativeState is set to 0 (Locked), no GM service is provided by the MTAS.
3.3 Service Data Configuration
No service data for the GM service is configured for the subscriber data.
4 Performance Management
The GM service has no measurements.
5 Fault Management
Alarms related to the GM service are listed in MTAS Alarm List.