MTAS Hold Communication Management Guide

MTAS

1	Introduction
1.1	Prerequisites
2	Overview
2.1	Subfunctions
2.2	Hold Interaction with Other Services
3	Hold Service Configuration
3.1	Announcement Configuration
3.2	Wholesale for Hold Configuration
3.3	Service Data Configuration
4	Performance Management
5	Fault Management

1 Introduction

This document describes how to configure the Hold Communication (referred to as Hold in this document) 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 basic services in the MTAS, the MMTel license must be installed.

For more information about the MMTel 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 Hold service enables a user to suspend active media streams of an established IP Multimedia session, and resume the media streams later. The Hold function supports announcements with communication hold and resume. The Hold function is specified to comply with the 3GPP TS 24.610 V.8.3.0 protocol specification.

A typical reason to hold communication is a need for privacy. The Hold function is triggered by an UPDATE and re-INVITE from a user trying to hold or resume communication.

The Hold supplementary service enables either user in a session to request the opposite user to stop sending media temporarily and later resume sending of media. The user initiating the Hold has the possibility to perform the operation either on an individual stream in a session or on all streams in a session.

2.1 Subfunctions

This section describes the following subfunctions:

Hold
Resume
Announcement
Bandwidth optimization

2.1.1 Hold

The Hold subfunction handles all aspects of SIP signaling and invokes the Announcement subfunction if it is configured to do so.

The Hold subfunction is executed in the serving Application Server (AS) meaning the AS for the user which initiated the Hold procedure. Any user in a communication can initiate Hold; in a two party call, both the caller and the called party can initiate Hold.

By monitoring the SIP traffic, the Hold subfunction detects when the criteria for a Hold operation has been fulfilled. The Hold function is invoked in an established session by UPDATE or re-INVITE and detects if a session is being held by identification of an offer to change the Session Description Protocol (SDP) for a specific media stream or all streams in a session.

A Hold invocation is recognized when a stream’s direction attribute is changed and the change matches one of the predefined Hold transitions.

An SDP offer in a re-INVITE or UPDATE, where a stream’s direction attribute changes, is interpreted to be a Hold request when the following direction attributes change:

From recvonly to inactive
From sendrecv to sendonly

Hold can also be performed for a group of streams by changing the direction attribute in the same SDP offer.

The Hold function retrieves configuration data from the Hold O&M function, which indicates if an audio or video announcement is to be played. If announcements are enabled, a Media Resource Function Processor (MRFP) is used to play an announcement to the end user.

As the Hold service proceeds, the Hold subfunction monitors the SIP message flow and increments relevant counters. The Hold subfunction maintains counters to evaluate the use and quality of service for the Hold service.

While a Hold is executing for a user, any colliding Hold/Resume invocations from other parties are rejected.

2.1.2 Resume

The Resume subfunction is executed in the AS that serves the user which initiated the Hold request.

By monitoring the SIP traffic, the Resume subfunction detects when the criteria for Resume operation has been fulfilled. The Resume subfunction is invoked at re-INVITE or UPDATE and detects if a session is being resumed by identification of an offer, in a re-INVITE or UPDATE, to change the SDP for a specific media stream or all streams in a session.

An SDP offer, where a stream’s direction attribute changes, is interpreted to be a Resume request when the following direction attributes change:

From inactive to recvonly
From sendonly to sendrecv

Resume can also be performed for a group of streams by changing the direction attribute in the same SDP offer. The Resume subfunction cooperates with the announcement subfunction to remove any announcement equipment if such was in use when a resume was detected. It also maintains counters to evaluate the use of resume.

While a Resume is executing for a user, any colliding Hold/Resume invocations from other parties are rejected.

2.1.3 Announcement

If audio announcement, video announcement, or both are configured, the held user receives an announcement corresponding to the configured type (audio, video, or audio-video).

The announcement policy is as follows:

When only audio is on hold, the value of CM attribute mtasHoldAudioCode is used, provided that the CM attribute mtasHoldAudioAnnouncement is set to enabled.
When only video is on hold, the value of CM attribute mtasHoldVideoOnlyCode is used, provided that the CM attribute mtasHoldVideoAnnouncement is set to enabled.
When both audio and video are on hold, the values of CM attributes mtasHoldAVAudioCode and mtasHoldAVVideoCode are used, provided that the corresponding CM attributes mtasHoldAudioAnnouncement and mtasHoldVideoAnnouncement are set to enabled.

Announcements are provided according to a best effort policy meaning that no Hold or Resume operation, nor the communication itself is inhibited owing to an inability to play announcements. Failure to deliver announcement is registered by a performance measurement counter.

If an offer representing a Hold or Resume is rejected with a non-2xx Final Response by the user to be held or resumed, the status of the session regarding the announcement is kept as before the offer.

If an offer representing a Hold of a stream is answered with an SDP indicating port 0 for the held stream, no announcement is initiated.

If an offer representing a Hold of a stream is answered with an SDP indicating port 0 for another stream, any ongoing announcement for that other stream is terminated.

A change of media for a stream while announcement is playing stops playing the announcement and no effort is made during the particular Hold to restore the announcement.

The announcements are cyclically repeated during a call. For more information about announcement handling and attributes for the hold service, refer to MTAS Announcement Management Guide.

2.1.4 Bandwidth Optimization

The bandwidth reserved for the call can either be kept reserved after the call was put on hold, or can be reused for new communication.

The bandwidth optimization is only applicable in networks where the functionality of the MTAS and the P-CSCF are aligned:

When the RTP bandwidth (AS) for both Session Level and Media Level is returned by an UE, the MTAS only updates the Media Level bandwidth for optimization, the P-CSCF must handle both Session Level and Media Level updates.
The P-CSCF must support the RTCP RR and RS Bandwidth AVP in the Rx interface to the PCRF.

The reuse of the bandwidth is called bandwidth optimization and it can be enabled using the configuration parameter mtasHoldBandwidthOptimizationMode. If it is enabled, the RTP session bandwidth is set to 0, while the RTCP session bandwidth is either kept (if it was originally set), or it is set to 1.25% of the original RTCP bandwidth for senders and 3.75% for the receivers.

2.2 Hold Interaction with Other Services

The Hold interaction with other MTAS services is described in this section.

2.2.1 Communication Diversion

In the case of a diverted session, the diverting user will still be in the session chain because of charging reasons.

For more information about the Communication Diversion (CDIV) service, refer to MTAS Communication Diversion Management Guide.

2.2.2 Conference

When Hold is requested to a user which is "is-focus", no announcement is played to ensure that the whole conference is not disturbed.

For more information about the Conference service, refer to the following documents:

3 Hold Service Configuration

The Hold service is controlled by the MtasHold MO. An overview of the Hold MO structure is shown in Figure 1.

Figure 1 Hold MO Structure

For configurable MOs and attributes related to the Hold service, refer to Managed Object Model (MOM).

3.1 Announcement Configuration

The Hold service offers announcement as described in Section 2.1.3 Announcement.

For information on announcement handling and hold announcement attributes, refer to MTAS Announcement Management Guide.

3.2 Wholesale for Hold Configuration

The Hold service supports Wholesale. Hold is configurable on Virtual Telephony Provider level.

For every announcement attribute in the MtasHold MO, there exists a corresponding attribute in the VtasHold MO. To activate Wholesale for the Hold service, announcement attributes in the VtasHold MO must be configured and the vtasHoldDropBack attribute must be set to 0 (use own VTP values).

For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.

4 Performance Management

For measurements related to the Hold service, refer to Managed Object Model (MOM).

5 Fault Management

The Hold service has no alarms.