Contents
1 Introduction
This document describes how to configure the Parlay X in MMTel service in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.
1.1.1 Licenses
To enable the Parlay X in MMTel services, the Parlay X license (not part of the MMTel service) must be installed.
For more information about the Parlay X 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
This document describes the Parlay X in MMTel service that the MTAS offers to its subscribers. Compared to the Parlay X service, the Parlay X in MMTel service is a part of the MMTel service format.
Currently, the MTAS Parlay X in MMTel service supports Call Notification. For more information about Call Notification, refer to 3GPP TS 29.199-03.
For further information about the Parlay X in MMTel support, refer to Parlay X in MMTEL.
For further information about the Parlay X support, refer to Parlay X MMTel Extensions.
2.1 Call Notification
Call Notification enables the MTAS to send a notification about a call event to the external Parlay X application.
The Parlay X in MMTel service of the MTAS can be configured and monitored by an O&M operator, who accesses the Parlay X in MMTel service configuration through the CAI3G and OAM interface. When the service is configured and enabled, MTAS sends notifications about call event to external Parlay X application.
2.2 External Parlay X Application Server Redundancy
The MTAS supports DNS-based redundancy of the External Parlay X Application Server in relation with the Call Notification interface.
The following failure situations exist:
- The Parlay X request timer, hard-coded to 300 ms, expires.
- Any Error is received from the Parlay X Application Server.
- A communication error between the MTAS and Parlay X Application Server takes place.
When one of the failure situations are encountered, and there is an alternative Parlay X Application Server address received from the DNS, the request is resent to the alternative Server, the Parlay X request timer is restarted, and the mtasFuncFailover PM counter is stepped.
If a communication error occurs, the failed server is put on the black list for the time duration specified by CM attribute IcmpBarringTime. (If the network error is detected by receiving an ICMP Destination Unreachable (3) packet with net unreachable (0), host unreachable (1), protocol unreachable (2), port unreachable (3) reason, or ICMP Parameter Problem (12) packet) or by CM attribute mtasFunctionBlackListTime (any other reason). While the server is on the black list, new requests cannot be received.
2.3 Subfunctions
The subfunction included in the Parlay X in MMTel service is described in this section.
2.3.1 Call Notification
The MTAS sends a notification about a call event to the external Parlay X application.
2.4 Interaction with Other Services
This section describes how the Parlay X in MMTel service interacts with other services.
Since the Parlay X application cannot control the call, there are no service interactions between the Intelligent Networks (IN) services in the Parlay X application and MMTel services.
In general, when the MMTel services create a new outgoing call leg, a new Parlay X trigger fires and the Parlay X application is notified about this new call event. The following sections list MMTel services that have this behavior.
2.4.1 Ad-hoc Conferencing
When a new participant is invited to a conference through the Ad-hoc conference service, a new outgoing call leg is created. The Parlay X application is notified based on the served users originating Parlay X trigger.
For more information about the Ad-hoc conference service, refer to MTAS Ad-hoc Conference Management Guide.
2.4.2 Communication Diversion
When a new outgoing call leg is created as a result of the Communication Diversion service, the Parlay X application is notified based on the served users originating Parlay X trigger.
For more information about the Communication Diversion service, refer to MTAS Communication Diversion Management Guide.
2.4.3 Charging
The MTAS populates the AVP "Supplementary-Service-Identity" (1130) with the enum value PX_CALL_NOTIFICATION (2100) if the NotifyCallEventRequest operation is called.
For more information about the Charging service, refer to the following documents:
2.4.4 Communication Completion
When a Communication Completion recall is made, a new outgoing call leg is created. The Parlay X application is notified based on the served users originating Parlay X trigger.
For more information about the Communication Completion service, refer to MTAS Communication Completion Management Guide.
2.4.5 Flexible Communication Distribution
When a new outgoing call leg is created as a result of Flexible Communication Distribution service, the Parlay X application is notified based on the served users originating Parlay X trigger. In this case, the Parlay X application can be notified several times for the served user.
For more information about the Flexible Communication Distribution service, refer to MTAS Flexible Communication Distribution Management Guide.
2.4.6 Session Transfer to Own Device
When a new outgoing call leg is created as a result of Session Transfer to Own Device service, the Parlay X application is notified based on the served users originating Parlay X trigger. In this case, the Parlay X application can be notified several times for the served user.
For more information about the Session Transfer to Own Device service, refer to MTAS Session Transfer to Own Device Management Guide.
3 Parlay X in MMTel Configuration
The Parlay X in MMTel service is controlled by the MtasMmtPx Managed Object (MO). An overview of the Parlay X in MMTel MO structure is shown in Figure 1.
Configurable MOs and attributes related to general Parlay X in MMTel configuration are defined in Managed Object Model (MOM).
3.1 CSI and NCC Administrative State Configuration
Before enabling the Parlay X in MMTel service, the Circuit Switched Integration (CSI) and Northbound Call Control (NCC) for CAMEL services must be enabled. To enable, set the mtasCsiAdministrativeState in the MtasCsi MO and mtasNccAdministrativeState in the MtasNcc MO to 1 (Unlocked).
For more information about the CSI and NCC MOs and attributes, refer to Managed Object Model (MOM).
3.2 Parlay X in MMTel Administrative State Configuration
The Parlay X in MMTel service is enabled by setting the mtasMmtPxAdministrativeState attribute in the MtasMmtPx MO to 1 (Unlocked). If the mtasMmtPxAdministrativeState is set to 0 (Locked), no Parlay X in MMTel service is provided by the MTAS.
3.3 Service Data Configuration
This section describes how to configure the service data.
3.3.1 Operator Subscription Level Service Configuration
The operator can activate or deactivate the Parlay X in MMTel service subscription for the subscriber by setting the user data using the CAI3G protocol. If an option is not present and it has a default value, then the default value applies.
For more information about the CAI3G protocol, refer to MTAS CAI3G Interface.
3.3.1.1 DNS Configuration
If the MTAS needs to look up a hostname, the DNS Resolver is used. The DnsLocalAddress attribute must be configured to enable that DNS communication with the Name Server is displayed on the SIP traffic interface. For more information about the DNS configuration, refer to Managed Object Model (MOM).
3.3.1.2 Activate Northbound-call-control
The Activated option of northbound-call-control must be set to true to enable northbound-call-control.
3.3.1.3 Configure Parlay X Triggers
The <px-originating-trigger> and <px-terminating-trigger> are grouping elements for the data to be used for an originating or terminating Parlay X session. They must be under the group of <northbound-call-control>. For each trigger, there is one <px-application-address>, one or multiple <px-call-notification>.
The <px-application-address> element specifies the URL, including the port, to the Parlay X application server to be used for the Parlay X session.
The <px-call-notification> element defines the possible Call Events that are to be reported on the CallNotification interface. This element is a multi-value attribute, meaning that it can appear more than once with several Call Event values. The allowed values are in shown in Table 1.
|
Value |
Comment |
|---|---|
|
busy |
Used by MTAS to indicate that any of the SIP responses 486 Busy Here or 600 Busy Everywhere was received. |
|
not-reachable |
Used by MTAS to indicate that any of the SIP responses 4XX (except 401, 407, 408, 480, 486), 5xx, or 6xx (except 600, 603) was received. |
|
no-answer |
Used by MTAS to indicate that any of the SIP responses 603 Decline, 408 Request time-out, or 480 Temp Unavailable was received. |
|
called-number |
Used by MTAS to indicate that a SIP INVITE was received. |
|
answer |
Used by MTAS to indicate that a SIP 200 OK was received. |
|
disconnected |
Used by MTAS to indicate that a SIP BYE was received on an established SIP session. |
3.3.2 Subscriber Subscription Level Service Configuration
No service data for Parlay X in MMTel is configured in the subscriber part of the subscriber data.
4 Performance Management
For measurements, related to the Parlay X in MMTel service, refer to Managed Object Model (MOM).
5 Fault Management
For alarms, related to the Parlay X in MMTel service, refer to MTAS Alarm List.