MTAS Communication Waiting Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1Normal Mode and Alternative Mode 1
2.2Alternative Mode 2
2.3Mobile CW Mode
2.4Mobile CW Alternative Mode 1
2.5Common Functions
2.6Subfunctions
2.7CW Interaction with Other Services
2.8Traffic View
2.9Configuration View

3
CW Configuration
3.1Operate Mode Setting
3.2Announcement Configuration
3.3Timer Setting
3.4CW Administrative State Configuration
3.5Wholesale for CW Configuration
3.6CWA Indication Configuration
3.7Service Data Management

4
Performance Management

5
Fault Management

1   Introduction

This document describes how to configure the Communication Waiting (CW) 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 Communication Waiting service allows a user to be notified of incoming calls when they are involved in other communication sessions.

The MTAS supports the following five separate modes for Communication Waiting:

2.1   Normal Mode and Alternative Mode 1

In normal mode and Alternative mode 1, the CW function works with the Call Admission Control (CAC) service, which determines if the served user is in the Approaching Network Determined User Busy (ANDUB) state, refer to MTAS Call Admission Control Management Guide.

If so, and the served user has an active subscription to CW, the CW function includes a Communication Waiting Active (CWA) indicator in the INVITE request.

The CW function then waits for a response to the INVITE request.

Upon receipt of a 180 Ringing provisional response to the INVITE request, the CW function determines if CW has been used for the subscriber with the CW service active. The reasons can be the following:

or

2.2   Alternative Mode 2

In Alternative mode 2, the INVITE request is sent to the served user without change. The CW function then waits for a response to the INVITE request. When receiving a 182 Queued provisional response to the INVITE request, the CW function determines that CW has been used for the subscriber with the CW service active.

2.3   Mobile CW Mode

In Mobile CW Mode, the INVITE request is sent to the served user without change. The CW function then waits for a response to the INVITE request. Upon receipt of a 180 Ringing response (including CWU in the Alert Info header) to the INVITE request, the CW function determines that CW has been used for the subscriber with the CW service active and starts a timer.

The served user can accept the call within this time (200 OK). If this timer expires, then the call attempt is cancelled.

2.4   Mobile CW Alternative Mode 1

In Mobile CW Alternative Mode 1, the CW function adds CWI (Communication Waiting Indication) to the INVITE request if the served user already is in an active communication session (independent of the number of waiting sessions).

CWU handling is not supported in this mode.

The CAC function ignores the CWI indication.

2.5   Common Functions

If CW has been used and the served user has an active subscription to CW, the CW function starts an operator-configurable alerting timer, and can play an operator-configurable announcement to the caller, to inform the caller that the called party has been informed that there is a waiting communication. The use of CW is recorded for charging and performance management purposes.

Upon receipt of a final response or expiry of the alerting timer, the CW announcement and the timer are stopped, if necessary, and the outcome of the CW use is recorded for performance management purposes.

The UA can make use of the Hold service to place an existing session on hold while the waiting communication is answered, refer to MTAS Hold Communication Management Guide.

2.6   Subfunctions

The subfunctions included in the CW service are described in this section.

2.6.1   CWA and CWU Indication

This section describes the format of the Communication Waiting Active (CWA) and Communication Waiting Used (CWU) indication used in normal mode, Alternative mode 1, Mobile CW mode and Mobile CW Alternative Mode 1. In Alternative mode 2, CW does not send the CWA indication or the CWU Alert-info header, nor does CW expect to receive the CWU Alert-info header.

The CWA and CWU definitions are taken from the 3GPP TS 24.615 v 8.2.0 standard.

CWA Indication

When the MTAS determines that a user with an active subscription to the CW service is in the ANDUB condition, the CW indication is added. The type of CW indication depends on value of mtasCwIndication attribute. It could be either "P-Service-IndicationSIP header", "XML body " or both of them.

The following is an example of "P-Service-Indication" header:

P-Service-Indication = "CW“

The following is an example of an "XML body":

<?xml version=”1.0”?>
<ims-cw xmlns=”urn:3gpp:ns:cw:1.0”>
</ims-cw>

The schema for this is defined in 3GPP TS 24.615 v 8.2.0.

The XML body has a Content-Type of "application/vnd.3gpp.cw+xml" and a Content-Disposition header of "render". The message handling parameter of the Content-Disposition header is set to "optional" so that terminals that do not support the CWA indication can ignore it.

The incoming INVITE to which this XML body is attached is likely to contain a Session Description Protocol (SDP) body already. If an SDP body exists, CW changes the message body to a multipart body and adds the CW XML body as the second part of the body, according to the rules in 3GPP TS 24.615 v 8.2.0.

If the body is already multipart, CW adds the CW XML body as the new last part.

An example INVITEas received by the terminating MTAS is as follows:

INVITE sip:userB@ims.com
Content-Type: application/sdp
Content-Length=192

    <sdp body>

Note:  
Some headers have been omitted and the content lengths are only to illustrate that the length parameter has to be adjusted to take account of the extra body that is added.

The CW function signals availability of a waiting call by adding an XML body to the INVITE. The resulting INVITE looks like the following example:

INVITE sip:userB@ims.com
Content-Type: multipart/mixed; boundary=”boundary1”
Content-Length=446

--boundary1
Content-Type: application/sdp

    <sdp body>

--boundary1
Content-Type: application/vnd.3gpp.cw+xml
Content-Disposition: render; handling=optional

<?xml version=”1.0”>
<ims-cw xmlns=”urn:3gpp:ns:cw:1.0>
   <communication-waiting-indication>
</ims-cw>
--boundary1--

The XML body is removed by the terminating UE and not sent back in subsequent responses.

Note:  
In the use cases in the rest of the document, the fact that an XML body has been added is shown in the abbreviated form CWA as INVITE B CWA.

CWU Indication

The CWU indication can be included in a 180 Ringing response to an INVITE by the terminating UE to show that the user has been alerted to the waiting communication. The communication can be considered to be waiting if the initial INVITE contained CWA, ANDUB, or if the terminal considers that the communication is waiting (User CW). The CWU indication takes the form of an Alert-Info header field set to "<urn:alert:service:call-waiting>" according to Alert-Info URNs for the Session Initiation Protocol (SIP).

The following is an example of a 180 Ringing response containing the Alert-Info header:

SIP/2.0 180 Ringing
Alert-Info: <urn:alert:service:call-waiting>

If the MTAS receives a 180 Ringing with a CWU indication, it passes this on to the caller.

If the served user was determined to be ANDUB and the INVITE request included a CWA, then a CWU is added to any 180 Ringing sent which was received without this indication.

Observe that in the use cases in the rest of the document, the fact that an alert-info header field has been added to a 180 Ringing provisional response is indicated by the abbreviation CWU as follows:

180 Ringing CWU

2.6.2   Announcements

This section describes the Terminate Announcement and Play Announcement subfunctions.

For more information about announcement handling and attributes for the CW service, refer to MTAS Announcement Management Guide.

Terminate Announcement

The Terminate Announcement is a subfunction that terminates a currently playing announcement on request from the CW function. When the CW function requests termination of an announcement, the Terminate Announcement subfunction sends an H.248 Subtract message to the Media Resource Function Processor (MRFP).

When the Subtract Reply is received, indicating that the announcement has ceased, the Terminate Announcement subfunction informs the CW function.

Play Announcement

The Play Announcement subfunction is called by the CW function to play an announcement to the caller. It handles the communication with the MRFP to request it to play the appropriate announcement. The announcement normally plays to completion. If the announcement is still playing at the point where the waiting communication is canceled, times out, fails, is rejected, or accepted, then the CW function uses the Terminate Announcement subfunction to stop the announcement. While the announcement can contain repeating phrases such as "Please hold the line, the other person knows that you are waiting", it is only played once by the MRFP. When the announcement has finished, the Play Announcement function informs the CW function.

2.7   CW Interaction with Other Services

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

2.7.1   Call Admission Control

This section describes the CW interactions with the CAC service.

For more information about the CAC service, refer to MTAS Call Admission Control Management Guide.

Normal Mode and Alternative Mode 1

The CW service depends on the User CAC (UCAC) service. That is, it is not possible to provision a user with the CW service unless that user also has the UCAC service provisioned with a waiting limit greater than zero.

The CW service is started for a terminating served user when the UCAC or Group CAC (GCAC) services determine that the served user is in the ANDUB state, or if a 180 Ringing response is received with a CWU indicator.

To classify the served user to be in ANDUB state when receiving a new call, when having reached the allowed limit of active sessions, requires that the attribute total-active-limit of UCAC and GCAC service data is provisioned with the ANDUB limit. If GCAC is used with allocation categories, the CM parameter mtasConAllocLimit must be configured with the ANDUB limit.

The UCAC service counts a session as a waiting session if the CW service adds a CWA indicator to an initial INVITE. CAC does not count CW sessions where user CW is used, that is, CWU is returned in the 180 Ringing but no CWA was sent, as waiting sessions. These sessions are counted by CAC as active sessions. This occurs because ANDUB has not been determined for the served user and all sessions where ANDUB was not determined are counted as active sessions.

Alternative Mode 2

There is no dependency between CAC and CW, when CW is in Alternative mode 2.

Mobile CW Mode

There is no dependency between CAC and CW, when CW is in Mobile CW mode.

Mobile CW Alternative Mode 1

There is no dependency between CAC and CW, when CW is in Mobile CW Alternative Mode 1.

2.7.2   Charging

This section describes the CW interactions with the Charging service.

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

Normal Mode and Alternative Mode 1

The MTAS records when CW is used. The use of CW is recorded for charging purposes on the first 180 Ringing received where the CW function determines that CW has been used, that is, ANDUB or containing a CWU indication only. Any subsequent CWU indications are ignored. The MTAS includes this information in the ACR/CCR generated for the session on which CW was used.

This is reported even for waiting communications that are not accepted by the served user.

For details of how the use of CW is recorded in the CCR, refer to 3GPP TS 24.615 v 8.2.0.

Charging events are raised each time CW is activated, deactivated, or interrogated using SSCs. Charging events are also raised when the CW subscriber activates or deactivates the CW service using the Ut interface. For details on the SSC services, refer to MTAS Supplementary Service Codes Management Guide.

Alternative Mode 2

In Alternative mode 2, the use of CW is recorded in the ACR on the first 182 Queued.

2.7.3   Communication Diversion

There are several interactions between Communication Diversion (CDIV) services and CW.

For more information about the CDIV services, refer to MTAS Communication Diversion Management Guide.

Communication Forwarding Unconditional

Communication Forwarding Unconditional (CFU) takes precedence over CW and will result in CW not being started.

Communication Forwarding Not Logged In

Communication Forwarding Not Logged in (CFNL) takes precedence over CW and will result in CW not being started.

Communication Forwarding on Busy

If the response to an INVITE containing a CWA is 486 (Busy here), 600 (Busy Everywhere), or 603 (Decline) then CW takes no action other than to pass the response backwards to the caller. If the served user also has Communication Forwarding on Busy (CFB) active and CDIV CM data has been set for the particular response code, this is started and the communication is diverted. The Busy response can be received after the 180 Ringing response where CW has been used.

Communication Forwarding No Reply

If the subscriber with CW also has Communication Forwarding No Reply (CFNR) active, the action depends on the relative values of the CW Alerting timer (mtasCwAlertTimer) and the timer on CFNR. The timer on CFNR can either be set by the administration using the mtasCDivTimer CM object, or it can be set by the subscriber changing the value of the cdiv-no-answer-timer element in the XML data of the subscriber using Ut or SSCs.

If the subscriber has only one of these services (CW and CFNR), there is clearly no interaction.

If the value of the CW Alerting timer is less than the value of the CFNR timer and the subscriber does not respond to a waiting communication before the CW Alerting timer expires, the waiting communication is canceled and CFNR is not started.

If the value of the CW Alerting timer is greater than the CFNR timer and the subscriber does not respond to a waiting communication before the CFNR timer expires, the CFNR is started and the waiting communication canceled. If the subscriber has been provisioned with the ability to control the CFNR timer, they can control which of the CW and the CFNR is started first by changing the value of the CFNR timer.

Communication Forwarding Not Reachable

The CW does not interact with the Communication Forwarding Not Reachable (CFNRc) service.

Communication Deflection

If Communication Deflection (CD) is active at the nodal level, if a served user responds to a waiting communication with 302, the CW is stopped.

2.7.4   Communication Barring

If the CW subscriber has both Incoming Communication Barring (ICB) and CW active, ICB is started before CW being started. If the communication is barred, CW is not started.

For more information about the Communication Barring services, refer to MTAS Barring and Dial Plan Services Management Guide.

2.7.5   Conference

The Conference Creator (CC) or the Conference Participants (CPs), or both, in a conference can also have CW active. The following case applies:

For more information about the conference service, refer to MTAS Ad-hoc Conference Management Guide.

2.7.6   CSCF Forking: Serial and Parallel Ringing

If the CW subscriber also has serial or parallel ringing, then an INVITE containing a CWA indication is forked by the terminating Call Session Control Function (CSCF) to all terminals that are currently registered. Depending on the busy/free state of each of the terminals, and whether they support the use of the CWA indicator, this results in multiple provisional responses being received by CW, some of which can contain a CWU indication.

The CW timer starts (mtasCwAlertTimer) when the first 180 Ringing response to an INVITE with CWA has been sent or when the first 180 Ringing containing a CWU indication is received and stops when the service terminates (the waiting communication is canceled, times out, fails, is rejected, or accepted) regardless of the number of 180 Ringing with or without CWU indications are received after the first one. Once CW has started, any subsequent 180 Ringing responses with or without CWU indications are passed transparently through to the caller except that if CW used was determined owing to the served user being in state ANDUB a CWU indicator is added to any 180 Ringing response received which does not contain the CWU indicator.

Note:  
This can result in mixed alerting at the terminal of the caller depending on how it handles multiple provisional responses.

2.7.7   Communication Completion

In normal mode and Alternative mode 1, CW is not offered as a result of a Communication Completion (CC) Call. In Alternative mode 2, CW treats a 182 Queued provisional response to a CC INVITE as a 180 Ringing provisional response, without a CWU indication.

For more information about the CC service, refer to MTAS Communication Completion Management Guide.

2.7.8   Flexible Communication Distribution

When the Flexible Communication Distribution (FCD) target is a terminal of the served user, the CWA indicator is added to the INVITEs by the CW service without considering the terminal selector. Therefore, each terminal receives it, independent of the status of the terminal.

No CWA indicator is sent to the non-IMS primary user nor to the related users.

The CWU Alert-info header, received in the 180 Ringing from any of the FCD targets, is not passed on to the caller.

For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.

2.7.9   Timers

The CW has one timer attribute, mtasCwAlertTimer.

The following timers are not controlled by the CW service but run by the MTAS, which can affect the operation of the CW:

If any of these timers expire before the mtasCwAlertTimer timer, the actions for the call depend upon the other services. The mtasMmtNoReplyTimer terminates the session while the CDIV timers result in diversion actions.

If preconditions were included in the SDP of the initial INVITE request, and the mtasMmtPreconditionTimer expires when attempting to negotiate preconditions to play the announcement, the announcement are not played.

For more information about the timers, refer to Managed Object Model (MOM).

2.8   Traffic View

CW performs the following steps:

Note:  
For Alternative mode 2, the served user does not get any indication of the subscription to CW in the INVITE. Instead the service is triggered by the served user responding with a 182 Queued instead of 180 Ringing.

For Mobile CW Alternative Mode 1, MTAS adds CW indication to all outgoing INVITE's if the user is in active session. The MtasCwUsed PM counter is incremented. No further action is performed by CW function.


The traffic view of CW is shown in Figure 1. The service is triggered by the initial INVITE over IP Multimedia Service Control (ISC).

Figure 1   Main Traffic View of CW

The CW subscription data is fetched from the Home Subscriber Server (HSS)/Subscriber Locator Function (SLF) through the Sh/Dh interfaces.

The served user receives an indication that there is an active subscription to CW in an INVITE received over ISC. The caller receives an indication that CW has been used at the end of the served user when a 180 Ringing response is received over the ISC interface when ANDUB was determined for the served user at the initial INVITE request and a CWA was added OR the 180 Ringing response contains a CWU indication. The CW function can play an announcement to the caller using the MRFP controlled over the Mp interface if playing of announcements is configured.

2.9   Configuration View

The node level configuration view of the CW is shown in Figure 2.

Node level configuration is performed by the operator who can customize the CW function. For example, by defining if an announcement is used as indication to the caller and by defining the announcement code, which specifies the identity and type of announcement to be played.

Figure 2   Configuration View of CW

The subscriber subscription data is managed through the XDMS that provides the Ut interface (XCAP over HTTP) to the served user and CAI3G to the operator. XDMS uses Sh (Diameter) to update the HSS. The served user accesses the XDMS directly and the operator accesses it through the Business Support System. The served user can access the SSC Service through the SIP ISC interface to activate, deactivate, and interrogate the status of CW.

3   CW Configuration

The CW service of the MTAS is controlled by the MtasCw MO and its attributes. The MO structure of the CW service is shown in Figure 3.

Figure 3   CW MO Structure

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

3.1   Operate Mode Setting

Alternative mode 1 or 2 is set when the CW is to control other features that are not included in the generic CW service.

The operate mode can only be changed if the mtasCwAdministrativeState is set to 0 (Locked) and the mtasUCacAdministrativeState is set to 0 (Locked).

The attribute mtasCwOperateMode can be set to the following values:

3.2   Announcement Configuration

Announcement is played to a caller when the CW service is activated. Also, the CW can request a termination of a played announcement.

Announcement handling and CW announcement attributes are described in the following document: MTAS Announcement Management Guide.

3.3   Timer Setting

The timer in the CW service is controlled by the mtasCwAlertTimer attribute. Timers defined in other services can also affect the CW performance.

3.4   CW Administrative State Configuration

The CW service is enabled by setting the mtasCwAdministrativeState attribute in the MtasCw MO to 1 (Unlocked). If the mtasCwAdministrativeState is set to 0 (Locked), no CW service is provided by the MTAS.

Note:  
If the mtasCwOperateMode attribute is set to 0 (Normal Mode) or 1 (Alternative Mode 1), the mtasCwAdministrativeState attribute must not be set to 1 (Unlocked), unless the mtasUCacAdministrativeState attribute is set to the value 1 (Unlocked).

3.5   Wholesale for CW Configuration

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

Wholesale for CW is activated when the following attributes are set to 1 (Unlocked):

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

3.6   CWA Indication Configuration

The type of CW indication is controlled by the mtasCwIndication attribute.

The mtasCwIndication attribute can be set to the followings values:

0 XML CW indication.
1 P-Service-Indication SIP header.
2 P-Service-Indication and XML both are used.

3.7   Service Data Management

This section describes how to configure the service data.

3.7.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the CW service subscription for the subscriber by setting the user data using the CAI3G protocol.

For more information about the CAI3G protocol, refer to MTAS CAI3G Interface.

3.7.2   Subscriber Subscription Level Service Configuration

The subscriber data is configured through the Ut interface. The subscriber can set the value of the active attribute of the "communication-waiting-active" element to either True (Active) or False (Inactive).

If the mtasCwOperateMode attribute is set to 0 or 1, the "activated" attribute of "Communication Waiting" can only be set to True if the "activated" attribute of "user-call-admission-control" is set to True, and the value of "waiting-limit" element within "user-call-admission-control" is greater than 0. The XML schema for the Ut interface is defined in MTAS Ut Structure.

For an example of an XML document conforming to the schema, refer to MTAS Examples of Provisioning Requests.

4   Performance Management

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

5   Fault Management

The CW service has no alarms.



Copyright

© Ericsson AB 2016. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    MTAS Communication Waiting Management Guide         MTAS