Contents

1   Introduction

This document describes how to configure the scheduled Conference 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 Scheduled Conference service, the Multi-Party conference license must be installed. The Scheduled Conference capacity license with the desired capacity value is also required.

To update a created Scheduled Conference, create, update, or delete users in relation with a created Scheduled Conference, the In Conference Control license must be installed.

For more information about the conference licenses, refer to MTAS Licenses.

1.1.2   Documents

Before starting any procedure in this document, ensure 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 Scheduled Conference service allows the subscribers to schedule and create a conference resource in advance, distribute an invitation including the conference identity, and have Conference Participants (CPs) dial-in to the conference at a scheduled time. In an Ad-hoc conference, the subscriber starts an instant conference and invites participants directly.

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

The creator of the Scheduled Conference resource is referred to as the Conference Owner (CO) mainly to emphasize that a Scheduled Conference traffic session can be initiated without the CO being a participant of the conference. The CO creates, updates, manages, and deletes a Scheduled Conference resource through an MTAS external system, here referred to as Conference Administration Server (CAS).

The entity of the MTAS providing the conference function is called the conference server. The term is used to group the different conference functions and it is not a physical server.

The Scheduled Conference service in the MTAS includes the following operations:

• Conference resource creation over the Centralized Conferencing Manipulation Protocol (CCMP) interface
• Conference deletion over the CCMP interface
• Conference resource update over the CCMP interface
• Incoming requests to join the conference (dial-in)
• Conference event notification
• Invitation of CPs to join the conference (dial-out) by the CO over the CCMP interface
• Removal of CPs from the conference (kick-out) by the CO over the CCMP interface
• Update of CPs in the conference by the CO over the CCMP interface
• Routing calling user to Operator Assistant if the maximum number of PIN code attempts is exceeded

Scheduled Conference creation is performed by the CO using the CCMP interface.

CPs having received an invitation can dial in to the Scheduled Conference using the INVITE method. How CPs have received the Scheduled Conference invitation is outside the scope of this document and irrelevant to the MTAS. The CO can also initiate an invitation of the participants over the CCMP interface to the conference with the dial-out method.

For more information about the CCMP interface, refer to MTAS CCMP Interface.

The Scheduled Conference server with its external interfaces in an IMS network is shown in Figure 1. The dotted arrows on the IP Multimedia Service Control (ISC) interface indicate that there are intermediate IMS network nodes that are not shown in the figure. The dotted arrows on the CCMP interface indicate that the external CAS is not shown in the figure.

The Scheduled Conference server is configured as an endpoint service accessed over the Ma or ISC interface. The Scheduled Conference server does not execute any originating services when executing the dial-out. The originating services are executed in the originating AS of the participant initiating the dial-out (CO). For successful execution of the originating services of the CO, the P-Served-User header and the Originating Unregistered Session case must be supported in the IMS network.

2.1   Survey of Included Functions

The Scheduled Conference service provided by the MTAS implements a tightly coupled conference, refer to RFC 4353.

This means that there is a single central point of control in the conference. This central role is played by the conference focus.

The conference focus, also referred to as conference resource, is created before initiation of the traffic session by the CO. The CO can have several conference focus instances created at the same time.

Each conference focus can be given a unique conference policy that is enforced by the focus once the traffic session is initiated. For example, the policy can limit media in the conference or number of allowed participants.

CPs connect to a Scheduled Conference using a Service Number (SN). The SN is a global E.164 telephone number representing the Scheduled Conference service for a specific customer, typically a company. Each CO having the Scheduled Conference service is served by a specific SN, which host all conference resources of the CO.

Each conference focus created by the CO is given three unique identities, a participant code, a moderator code, and an XCON object identifier. The participant and moderator codes uniquely identify the conference focus at the SN and must be used by CP to join the conference over the SIP interface. The third XCON object identifier is used by the CO to manage the conference focus over the CCMP interface.

Each MTAS instance acting as Scheduled Conference server can host several SNs.

The relationships between the SN, the CO, and the conference focus is illustrated in Figure 2. The mandatory external CAS system is not shown in the figure. As viewed from the MTAS this system is an agent of the CO.

Once the conference focus has been created by the CO, a unique XCON object identifier is allocated to identify the focus in subsequent status, update, or deletion requests from the CO over the CCMP interface.

Separate SIP dialogs are established per each CP joining the conference focus.

The functional elements of the conference server are as follows:

• The SN is the entity tracking all Scheduled Conferences created by all COs for which the SN provides the Scheduled Conference service to. CPs dial-in to the SN and provide a PIN code to indicate which conference to join. The SN controls the Media Resource Processor Function (MRFP) to request CPs to provide PIN codes.
• The conference focus is the centralized manager of the conference. The focus is addressed by a conference URI. The focus maintains dialogs to the involved participants with or without subscriptions to events as well as implements policies and controls the media mixer.
• The conference policy is the set of rules that governs a particular conference. The CO can define the policy. The policy is enforced by the focus that controls the conference.
• The media mixer is a function handled by either an external MRFP, H.248 controlled, or Media Resource Function (MRF) device, SIP controlled, which produces a media mix of all (or a subset of) conference participants media before redistributing the result back to each participant.

2.2   Subfunctions

The Scheduled Conference service consists of the following subfunctions:

• The conference SN
• The conference focus
• The conference policies
• Conference Notification
• Charging

2.2.1   Conference SN

The SN is the logical entity hosting the Scheduled Conference service for a specific CO. The SN is defined as a distinct PSI service in Home Subscriber Server (HSS) with a unique E-164 telephone number representing the Scheduled Conference service for a group of conference owners, typically a company. Each SN is served by a specific MTAS application server instance, identified by a routable Fully Qualified Domain Name (FQDN) subdomain. Typically an operator assigns a set of MTAS nodes to act as Scheduled Conference servers. Each SN can only be hosted by one MTAS instance at a time. The operator assigns a specific subdomain to denote the service numbers provided by a specific server, for example, "confserver1.operator.net". The SN will, apart from the public Tel URI identity and serving AS FQDN, also hold service-specific data stored in several transparent data containers in the HSS. The purpose of the SN is to look up the conference focus at dial-in requests from CPs. In case the focus instance exists but without an active traffic session, the SN allocates a unique conference focus SIP URI and instantiates a traffic session. When a CP dials in (SIP INVITE) to an SN, a predefined announcement is played requesting the CP to provide participant or moderator code for the conference to join. The announcements to play together with other SN properties are provisioned per SN in the HSS through the MTAS and the CAI3G interface.

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

The parameters defining the SN are listed in Table 1.

Table 1    SN Parameters

Parameter	Description
Public User Identity	The Tel URI of the SN in E.164 format.
announcement-welcome-id	The announcement played requesting the CP to provide PIN code for the Scheduled Conference session.
announcement-retry-id	The announcement played when receiving an incorrect PIN code, requesting the CP to make a new attempt.
announcement-hangup-id	The announcement played once the CP has made more attempts than allowed by the attribute pin-max-no-of-attempts. The announcement is played before the MTAS disconnects the CP or connect the caller to the Operator assistant.
announcement-wait-for-moderator-id	The announcement played in case the conference policy requires the moderator to join before the traffic session can be started. The announcement informs the CP that the conference waits for the moderator to join. The MTAS initiates continuous playing of the announcement unless the operator overrides the announcement parameters using the configurable announcement parameters function.
pin-code-attempts	The maximum number of allowed attempts to provide a valid PIN code during a session.
pin-code-length	The number of required digits in the moderator and participant codes of the SN.
activating-attendant-assistance	If present the calling user is routed to Operator Assistance when the maximum number of PIN code attempts is exceeded.
announcement-attendant-assistance-id	The announcement played when the limit of number of PIN code attempts has been exceeded and the Calling User has been routed to Operator Assistance.
attendant-URI	The sip or tel URI of the attendant.

2.2.2   Conference Focus

The conference focus is the central administrator of a conference. It applies policies, generates events, controls the media mixer, and maintains a signalling relationship with the CPs involved in the conference. The conference focus of a Scheduled Conference also maintains a signalling relationship with the CO (through the external CAS system).

Each conference focus instance is uniquely identified by the identities listed in Table 2.

Table 2    Conference Focus Identities

Identity	Description
Combination of SN and moderator PIN code	Identity used to establish (dial-in) a SIP signalling relationship as CP (role moderator).
Combination of SN and participant PIN code	Identity used to establish (dial-in) a SIP signalling relationship as CP (role participant).
XCON object identifier	Identity used to establish a CCMP signalling relationship with the CO.
SIP conference URI	Identity used in the established SIP signalling relationship with the CPs.

A conference focus must be created over the CCMP interface before use. Once the conference focus is created, the CO can also invite participants with dial-out method initiated over the CCMP interface and the CP can dial in using a combination of the SN and PIN code (moderator or participant).

The focus controls the Mixer MRFP over the Mp (H.248) interface when performing tasks such as the following:

• Media mixing the media streams of CP
• Codec negotiations
• Transcoding for audio and video codecs

The focus applies congestion control for conference event generation.

2.2.3   Conference Policies

The conference policies maintained by the Scheduled Conference server can be defined by the network operator per SN and by the CO per conference focus. The policy is only read once the traffic session is initiated. Generally, any policy change during a traffic session takes effect the next time the session is initiated. The policy items, where the change is taken immediately in consideration, are marked explicitly. The conference policy is neutral to the media transport profile. For example, the RTP/AVPF profile is supported for each stream where the RTP/AVP transport is applicable.

The policies, which can be defined by the network operator per conference SN, are listed in Table 3.

Table 3    Policies per Conference SN

Policy	Description
PIN code attempts	The number of PIN code attempts a CP is allowed to make before the call is hung-up or forwarded to Operator assistant.
PIN code length	The number of digits a PIN code must have to be valid.
Operator assistance	The caller is not disconnected if the limit of PIN code attempts is exceeded, MTAS connects the caller to Operator assistant.

The policies which can be defined by the CO per conference focus are listed in Table 4.

Table 4    Policies per Conference Focus

Policy	Description
Available media	An incoming request, offering use of an unsupported media type is responded by a disabling of that specific media stream, for example, port set to 0. A dial-out INVITE contains an SDP offer with the allowed media types.
Number of participants	The maximum number of allowed participants, including the moderator, in the conference. The conference focus reserves one participant resource for the moderator.
Wait for moderator	Having a precondition on the conference that the moderator must join before open media connectivity between conference participants. The announcement identified by the SN attribute announcement-wait-for-moderator-id is played to all participants until the moderator joins.
Allow dial-in for non-moderators	Any dial-in attempts to join to the conference with participant PIN is responded with 403 Forbidden, if the dial-in for non-moderators are not allowed. Update to this policy item is enforced by the focus immediately, even on active traffic instance.

The static policies, that is, common for all conference instances are listed in Table 5.

Table 5    Static Policies

Policy
Any CP can leave the conference at any time without this affecting the rest of the conference. This policy is independent of the "Wait for moderator" policy.
Any CP can change the port.
Any CP can update the codec, if the conference is not waiting for moderator.
Any CP can update the corresponding media stream mode, if the conference is not waiting for moderator.
Any CP can add new media streams to the conference, for example, upgrading an audio conference to video, if it is allowed by the "Available media" policy.
Any transport profile can be used, for example, RTP/AVP or RTP/AVPF.
Only one audio, one application, and a maximum of nine video streams are allowed to be used per participant. Other media types are not allowed.
Subscription to conference events are allowed by all CPs. The subscription is only supported inside the existing dialog.

2.2.4   Conference Notification

The Conference notification subfunction sends notifications about the following events:

• A participant joins the conference (with method dial-in or dial-out).
• A participant leaves the conference (departs or kicked-out).
• A participant is set to HOLD.
• A participant is set to RESUME.
• A moderator joins the conference in waiting state and as a result the conference enters the active state.
• A participant is updated by the CO (and an update introduces a change in the Conference Document propagated in the NOTIFY body).
• The conference is updated by the CO (and an update introduces a change in the Conference Document propagated in the NOTIFY body).

2.2.5   Charging

The Scheduled Conference service supports offline (Rf) Scheduled Conference focus session-based charging, refer to MTAS Charging Management Guide.

If there are failed attempts to join a scheduled conference, one time event charging is used. One time event charging is also used at creation, update, and deletion of the scheduled conference room over the CCMP interface. The conference owner is used to populate the Subscription-ID in the charging messages generated for the conference session, and for the failed attempts to join to the scheduled conference owned by the conference owner. When the conference owner cannot be determined, for example, when the wrong PIN is provided, the service number is used to populate the Subscriber-ID AVP. The conference focus receives the charging function address information configured against the conference owner from the HSS. The information is used when sending charging messages from the conference focus. When the conference owner cannot be determined, the default charging function address is used.

The following service-specific Attribute-Value Pairs (AVPs) are applicable for Scheduled Conference charging:

• Supplementary Service Information indicates "conference creation", "conference deletion", "conference update", "conference completion", "participant join", "participant leave", "ccmp triggered participant addition", "ccmp triggered participant removal", "ccmp triggered participant update", or "start of mixing at the focus".
• Conference ID, the SIP conference URI, is included in charging messages generated at each traffic instance of the focus.
• XCON ID, the XCON object identifier, is included in all charging messages generated at the focus.
• Related ICID, a dummy conference ICID generated for the focus session, which can be used as charging data correlation anchor point, is included in charging messages generated at each traffic instance of the focus. It is also included in the orig-icid parameter of P-Charging-Vector in the dial-out INVITE.
• CCMP User Info of the received CCMP userRequest:update operation is included in charging messages generated upon CCMP initiated update of a CP.

For more information about the Charging service, refer to Diameter Offline Charging in MTAS.

2.3   Interaction with Other Services

The Scheduled Conference service interaction with other MTAS services is described in this section.

2.3.1   General

When the Scheduled Conference focus initiates dial-out to a CP, the originating services are always executed in the originating AS of the participant initiating the dial-out (CO).

2.3.2   Communication Diversion

The focus rejects diverted incoming calls. The focus accepts diversion of dial-out calls. For more information about the Communication Diversion service, refer to MTAS Communication Diversion Management Guide.

2.3.3   Communication Waiting

The Scheduled Conference service and the Communication Waiting (CW) services can interact, where the CO invites a participant to a conference, and that participant has CW active and is busy.

When the CP has CW active and is busy, the CP is notified that there is a waiting communication. The conference focus receives a 180 Ringing response which can contain a Communication Waiting Used indicator (CWU), depending on CW mode, but this information is not propagated to the CO.

The Session Description Protocol (SDP) received from the focus is set to sendrecv. However, the termination allocated on the MRFP for this leg is set to inactive to prevent media such as ringing tones from the CP being mixed in to the conference before the participant is fully connected (that is, a 200 OK has been received from the CP). Therefore, the other CPs cannot hear the announcement either.

The net result is that the CO receives no indication that the intended participant is busy but does have CW.

For more information about the CW service, refer to MTAS Communication Waiting Management Guide.

2.3.4   Explicit Communication Transfer

It is not possible to invoke Explicit Communication Transfer if one or both of the sessions to be transferred are participating in a scheduled conference.

For more information about the Explicit Communication Transfer service, refer to MTAS Explicit Communication Transfer Management Guide.

2.3.5   Forking

Forking is supported by the focus.

2.3.6   Hold Communication

The focus acts as a B party in a hold or resume scenario in regard to the signalling and media plane handling. When Hold Communication is requested to a user which is is-focus, no announcement is to be played in order not to disturb the whole conference.

For more information on interaction with the Hold Communication service, refer to MTAS Hold Communication Management Guide.

2.3.7   Originating Identity Restriction and Terminating Identity Restriction

In dial-out scenarios, The focus respects the privacy settings, Originating Identity Restriction (OIR), and Terminating Identity Restriction (TIR), for both CO and CPs, done on the originating or terminating AS respectively. The incoming signals Privacy headers are copied to the outgoing signals.

The conference focus respects the privacy settings (OIR/TIR) for both the CO and CPs for NOTIFY messages, including the XML body. Privacy of identity is observed when sending NOTIFY messages to CPs. The privacy is indicated by the Privacy header in the INVITE request for the conference controller, or in the Privacy header in the 1XX/2XX response for the CPs. The URI mapping of an anonymous user in a conference is done according to the following specification: RFC 4575

For more information about the OIR and TIR services, refer to MTAS Identity Presentation Management Guide.

2.3.8   Incoming Communication Barring

The conference focus does not support Incoming Call Barring (ICB). For more details about the ICB, refer to MTAS Barring and Dial Plan Services Management Guide.

3   Scheduled Conference Configuration

The Scheduled Conference service is controlled by the MtasSchedConf and the MtasIcc Managed Objects (MOs) and to some extent also the MtasXdms MO. An overview of the Scheduled Conference MO structure is shown in Figure 3.

For information on configurable MOs and attributes related to the conference services refer to Managed Object Model (MOM).

3.1   Configuration Activities

Configuration activities for Scheduled Conference are listed in Table 6.

Table 6    Configuration Activities for Scheduled Conference

Activity	Attribute
Defines the Scheduled Conference domain.	mtasSchedConfServiceNumberDomain (only the host part of the attribute is considered by the Scheduled service)
Defines the username prefix part of the conference URI.	mtasSchedConfUriPrefix
Defines the subdomain part of the conference URI.	mtasSchedConfUriSubdomain
Defines if the conference notifications are activated or deactivated.	mtasSchedConfNotificationService
Defines the charging profile that is applicable for the Scheduled Conferencing AS sessions.	mtasSchedConfChargingProfileRef
Defines the Video profile used in the dial-out offer for video stream in case of Scheduled Conference.	mtasSchedConfVideoAvpType
Enables the In Conference Control feature.	mtasIccAdministrativeState

Note:  

The MtasSchedConf and MtasIcc MOs are system created.

For more information about the Scheduled Conference attributes, refer to Managed Object Model (MOM).

3.2   Conference Administrative State Configuration

The Scheduled Conference service is enabled by setting the mtasSchedConfAdministrativeState attribute in the MtasSchedConf MO to 1 (Unlocked). If the mtasSchedConfAdministrativeState is set to 0 (Locked), no Scheduled Conference service is provided by the MTAS.

This service can be deactivated immediately or gracefully. For more information, refer to MTAS Service Management Guide.

For Scheduled Conference service, the mtasCcmpAdministrativeState attribute in the MtasXdms MO must in addition be set to 1 (Unlocked).

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 Scheduled Conference 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.

In the Scheduled Conference service configuration data for a subscriber, it must be defined if the subscriber is allowed to use the service or not.

The Scheduled Conference SN must be configured with the following information:

• Welcome announcement identity
• Incorrect PIN announcement identity
• PIN code failure announcement identity
• Wait for moderator announcement identity
• PIN code attempts allowed
• PIN code length
• Operator Assistance activation
• Operator Assistance announcement identity
• Sip or tel URI of the attendant

The HSS must be configured before performing subscriber provisioning of the scheduled service and SN configuration.

For more information about the HSS configuration, refer to MTAS External Network Configuration.

A check of the subscriber data is performed in the XML Document Management Server (XDMS), as follows:

• The XDMS rejects an update if the update does not comply with the schema.

3.3.2   Subscriber Subscription Level Service Configuration

No service data for the Scheduled Conference service is configured in the subscriber part of the subscriber data.

3.4   Managing Cached Scheduled Conference Data in MTAS

The main storage for scheduled conference-related data (SN data, conference configuration data) is the HSS, MTAS fetches the data from HSS and caches it for quick access. There is a possibility to query or purge the cached scheduled conference data in MTAS. For information on how to query, or purge, refer to MTAS Subscriber Data Management Guide.

It is advised to initiate a purge operation on all scheduled conference data (using '*' wildcard as a command syntax for the operation) if there is only 1 HSS in the system and it has been restarted (Zone Reloaded). This is to force resubscriptions for scheduled conference data in the HSS, avoiding a possible loss of scheduled conference data-related notifications coming from the HSS.

4   Performance Management

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

5   Fault Management

For alarms, related to the Scheduled Conference service, refer to MTAS Alarm List.