Contents

1   Introduction

This document describes how to configure the Ad-hoc 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 Ad-hoc Conference service with more than three participants, the Multi-Party Conference license must be installed. The Conference Capacity license with the desired capacity value is also required to enable conferencing with more than three participants.

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

1.1.2   Documents

Before starting any procedure in this document, ensure that 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 Ad-hoc Conference service allows subscribers to start an instant conference and invite other users, Conference Participants (CPs), to the conference. The user starting and creating the conference is called the Conference Creator (CC).

In an Ad-hoc Conference, the conference resource is created once the CC initiates a traffic session.

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 Ad-hoc Conference service in the MTAS includes the following operations:

• Conference creation, with or without list of CPs to be invited
• Conference deletion
• Conference event notification
• Invitation of CPs to join the conference (dial-out by the CC)
  • With or without answer confirmation
• Removal of CPs from the conference (kick-out) by the CC

An Ad-hoc Conference creation is performed using a conference factory URI and the dial-out method in which a user is invited to the conference. CPs are invited to the conference using a dial-out method, where the REFER is sent from the CC through originating AS to the conference focus which in turn sends the INVITE to the CPs.

The Ad-hoc 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.

New Ad-hoc Conference servers must be deployed collocate with the originating AS of the conference creator accessed over the ISC interface. However old installations can keep the original setup.

The conference server is in this deployment linked into the chain of originating services applied for the CC. The alternative of deploying the conference server as a standalone endpoint separate from the originating AS of the conference creator is deprecated and is not to be used for new installations, although still described in this document.

For more information about the Ad-hoc Conference service, refer to 3GPP TS 24.147 v8.2.0.

2.1   Survey of Included Functions

The Ad-hoc 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 maintains separate SIP dialogs with all participants.

The functional elements of the conference server are as follows:

• The conference factory is the logical entity responsible for automatically creating a new Ad-hoc Conference focus, on demand from a user agent. The conference factory is addressed by the conference factory URI.
• 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 subscription to events and implements policies and controls the media mixer.
• The conference policy is the set of rules that governs a particular conference. The Ad-hoc Conference services use a system default policy. The policy is enforced by the focus that controls the conference.
• The media mixer is a function handled by either an external Media Resource Function Processor (MRFP), H.248 controlled, or a 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.
• The Play and Collect function is provided by either an external MRFP, or MRF device, which plays conference entry announcement and collects the DTMF response of the participant representing acceptance to join the conference.

2.2   Subfunctions

The Ad-hoc Conference service function consists of the following subfunctions:

• The conference factory
• The conference focus
• The conference policies
• Answer confirmation
• Charging

2.2.1   Conference Factory

The purpose of the conference factory is to allocate a conference URI, denoting a focus, on demand from a subscriber that wishes to set up an Ad-hoc Conference. All Ad-hoc Conference servers include a conference factory.

Typically an operator assigns a set of MTASs to act as conference servers. The operators assign a subdomain to denote the factories on these servers, for example, factory.operator.net. The conference factory URI could then look like sip:conference@factory.operator.net. Load sharing between the factories is provided by other IMS network nodes.

When a CC issues an INVITE addressed to the factory URI, the conference server that receives it allocates a conference URI in the subdomain for that specific MTAS. The conference URI could look like sip:conf1234@confserver1.operator.net. The User Part of the URI identifies the focus instance that is to handle the conference and the domain name denotes the MTAS node. The conference factory is only allocate conference URIs in its own node. Once the factory has allocated the conference URI, the focus instance, it is no longer involved in the conference.

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 signaling relationship with the CPs involved in the conference. A conference SIP URI uniquely identifies a specific focus instance.

The focus controls the media mixer when performing tasks such as the following:

• Media mixing of CPs media streams
• Codec negotiations
• Transcoding for audio and video codecs
• Establishment of the Binary Floor Control Protocol (BFCP) channel for video slides sharing with the conference. Only supported if the media mixer is an MRFP controlled using the Mp (H.248) interface.

The focus applies congestion control for conference event generation.

2.2.3   Conference Policies

The conference policies maintained by the conference server are static. They do not change between conferences, nor do they change during a session. 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 enforced by the focus are listed in the following table:

Table 1    Policies Enforced By Conference Focus

Policy
Only the CC can able invite CPs to the conference through a dial-out.
The same media types and transport profiles as used by the CC is offered to the CP in the invitation.
Only the CC can remove (kick-out) CPs from the conference.
Any CP (other than the CC) can leave the conference at any time without this affecting the rest of the conference.
If the CC leaves the conference, the conference is terminated.
Anyone can change the port.
Any participant can add new media streams to the conference, for example, upgrading an audio conference to video. The CP can only add a media stream if the CC is or has used the same media type. The CP can use a different transport profile (for example, RTP/AVP or RTP/AVPF) than the CC as long as it is supported by the MRF/MRFP.
Anyone can remove a media stream from the conference by setting the port number to zero.
Only one audio, one application (BFCP), and a maximum of nine video streams are allowed to be used per participant. Other media types are not allowed.
The use of a URI list to invite participants is only supported for the CC when used in the initial INVITE request toward the factory. The use of URI lists are controlled by an MO attribute.
Subscription to conference events are allowed by all CPs. The subscription is only supported inside the existing INVITE created dialog.
In a dial-out offer to CP, at maximum the same media lines as used by the CC are offered.

2.2.4   Answer Confirmation

Answer Confirmation is an optional feature that can be provisioned by the operator per CC. The feature plays a welcome announcement at answer requesting confirmation from the invited participant before being connected to the ad-hoc conference by providing a specific DTMF response. The feature thus prevents automata like voicemails from joining the conference.

The welcome announcement can be configured in Answer Confirmation by connecting the generic announcement.

The time-out specified to the Play and Collect MRF can be defined by connecting the generic announcement to an instance of MtasAnnouncementParameter object with an attribute mtasAnnouncementParameterDuration.

The DTMF response which represents acceptance of the participant to join the conference can be configured by the operator with mtasConfAnsConfirmDigitMap attribute.

2.2.5   Charging

The Ad-hoc Conference function supports offline (Rf) session-based charging and online (Ro) session-based charging, refer to MTAS Charging Management Guide.

The charging of the CC leg is handled by the originating Application Server (AS), as for a normal MMTel call, while the charging of the CP legs is handled by the focus. The CC is charged for the CC leg and for the CP legs.

The focus receives the P-Charging-Vector for the incoming leg from the initial INVITE during the creation of the conference. The focus creates P-Charging-Vectors (including the original IMS Charging Identifier (ICID) received and stored when creating the focus) which are used for charging against the CP legs and are included in the initial INVITE sent for the CP leg.

The focus receives the charging function address information configured against the CC from the Home Subscriber Server (HSS). The information is used when sending charging messages from the conference focus. The focus stores the information received from the HSS so it is available when creating a P-Charging-Function-Addresses header for inclusion in the initial INVITEs sent for each CP leg.

The following service-specific Attribute-Value Pairs (AVPs) are applicable to conference charging:

• Supplementary Service Information indicates creation or termination of a conference at the originating AS and indicating addition or removal of CPs at the focus.
• Conference Id, that is, conference URI is included in charging messages generated at the originating AS and at the focus.
• Related ICID, that is, CC leg ICID is included in charging messages generated at the focus.
• Supplementary Service Action indicates query, accept, or rejection during an answer confirmation.

The Rating-Group AVP for the CC leg in a collocate conference can be configured to a different value than other call legs by the CM attribute mtasChargingProfileConferenceCreationRatingGroupSession in the applicable charging profile. For more information related to the charging profile Managed Object (MO), refer to Managed Object Model (MOM).

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

2.3   Interaction with Other Services

The Ad-hoc Conference interaction with other MTAS services is described in this section.

2.3.1   AS Chaining

When AS chaining is disabled by Session Initiation Protocol (SIP) CM Parameter, originating services for the CC are executed for the REFER request in the originating AS.

When AS chaining is enabled by SIP CM Parameter, originating services for the CC are executed for the INVITE request in the originating AS, which is routed from the focus.

Note:  

The maximum number of sessions defined in the SIP CM Parameter mtasMmtMaxNumberOfSessions must be increased when all dial-out requests start originating sessions for the CC in originating AS.

For more information about Originating AS chaining, refer to MTAS SIP Management Guide

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 Ad-hoc Conference and the Communication Waiting (CW) services can interact, where the CC adds 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.

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 CC cannot hear the announcement either.

The net result is that the CC 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 start Explicit Communication Transfer if one or both of the sessions to be transferred are participating in an Ad-hoc Conference.

2.3.5   Flexible Identity Presentation

This section describes the Flexible Identity Presentation (FIP) service interaction with the Ad-hoc Conference service.

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

2.3.5.1   FIP Interaction When Co-Location Is Disabled

The provisioning of FIP service is not allowed when the Ad-hoc Conference service is active for the served user and co-location is disabled. Also the provisioning of Ad-hoc Conference service is not allowed if the FIP service is active for the served user and co-location is disabled.

2.3.5.2   FIP Interaction When Co-Location Is Enabled

The FIP service is applied when the conference controller executes dial-out to bring in a new participant into the conference. The following headers are changed by the FIP service: P-Asserted-Identity and Referred-by (assuming that no Referred-by token is created by the Ad-hoc Conference service).

2.3.6   Forking

Forking is supported by the focus. The CC receives notification for each 180 Ringing received for a forked dial-out call.

2.3.7   Hold Communication

The focus acts as a B party in a hold or resume scenario about the signaling 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.

If a conference participant connected to DTMF attempts to send a reINVITE or UPDATE with a Hold request during Answer Confirmation, MTAS rejects such a request with a 488 Not Acceptable Here response.

The interaction with the Hold Communication service is described in MTAS Hold Communication Management Guide.

2.3.8   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 CC and CPs, done on the originating or terminating AS respectively. The incoming signals Privacy headers are copied to the outgoing signals.

The focus respects the privacy settings (OIR or TIR) for both CC 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.9   Communication Barring

Communication Barring interacts with the Ad-hoc Conference service by inspecting the URI list entries and the headers Refer-To and Referred-By.

The focus does not perform any validation of Outgoing Communication Barring (OCB) rules when in standalone deployments. The validation of OCB rules for the CC is performed by the originating AS of the CC. The OCB considers all entries of a provided conference URI list. When the focus is collocate with the originating AS, only non-barred entries are invited to the conference.

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

2.3.10   Video Fallback to Audio

The dial-out calls to CPs are subject to Video Fallback to Audio (VFB), which means that the VFB service can intercept an error response from the CP and if it has a specific Q.850 code, VFB repeats the dial-out call.

For more information about the VFB service, refer to MTAS Video Fallback to Audio Management Guide.

2.3.11   CrankBack

The dial-out calls to CPs are subject to congestion control, which means that the CrankBack service can intercept an error response from the CP and if it has a specific Q.850 code, CrankBack repeats the dial-out call.

For more information about CrankBack, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.

2.3.12   Video FallBack to Audio – CrankBack

If the CrankBack service and the VFB service are both configured to process error responses with the same Q.850 cause code, the CrankBack processing repeats the dial-out call first. If CrankBack fails, VFB executes its fallback logic.

3   Ad-hoc Conference Configuration

The Ad-hoc Conference service is controlled by the MtasConf MO and to some extent also the MtasXdms MO. An overview of the Conference MO structure is shown in Figure 2.

For configurable MOs and attributes related to the Ad-hoc Conference services, refer to Managed Object Model (MOM).

3.1   Ad-hoc Conference Configuration Activities

Configuration activities are listed in Table 2.

Table 2    Extra Configuration Activities for Ad-hoc Conference

Activity	Attribute
Defines the Ad-hoc Conference factory URI, consisting of a username and a subdomain.	mtasConfFactoryUri
Defines the username prefix part of the conference URI.	mtasConfUriPrefix
Defines the subdomain part of the conference URI.	mtasConfUriSubdomain
Defines the ISC port on the originating Serving Call Session Control Function (S-CSCF), where all the requests from the MTAS conference server (focus) are routed to when the focus is acting as an originating User Agent (UA).	mtasConfScscfIscPortNum
Defines if the conference notifications are activated or deactivated.	mtasConfNotificationService
Defines if the additional progress information notifications are activated or deactivated when focus is dialing-out to CP or when CP is responding for the dial-out with "180 Ringing" or any of 4xx-6xx messages.	mtasConfNotificationProgressInfo
Defines activation and deactivation of the usage of display names from CCs initial INVITE URI-list, in conference events notifications as display text.	mtasConfNotificationShowDisplayName
Defines if the conference subscription is rejected with "403 Forbidden" or "489 Bad Event" failure response.	mtasConfSubsRejectResponse
Defines if the conference focus is to allow invitation of conference participants using URI list.	mtasConfUriList
Defines the Answer Confirmation announcement that is played while waiting for the DTMF response of the invited participant.	mtasConfAnsConfirmAnnouncement
Defines the DTMF response in Answer Confirmation function, which represents participant acceptance to join to the conference.	mtasConfAnsConfirmDigitMap
For external MRF, enable or disable offering of all supported codecs when inviting users to join the conference.	mtasConfDialOutCodecOfferingMode
Determine the charging behavior of two-party sessions moved into a conference. The original two-party session can be preserved when the participant is moved into the conference or the original charging session is terminated and a new charging session is created representing the new conference participant.	mtasConfChargingSessionBehaviorOnMove
Determine whether the CC is to be included or not in the values of user-count and maximum-user-count sent to the conference users as part of conference notifications.	mtasConfNotificationUserCountBehavior
Defines the setting of route header in Dial-Out INVITE of Ad-hoc conference. This parameter is applicable only when mtasSipCallOutOfBlueRouting is set to S-CSCF. When this parameter is enabled, MTAS copies the route headers from the initial conference creating INVITE to the Dial-out invites in both uri_list of the initial INVITE and REFER cases. When it is disabled, the default behavior of getting S-CSCF details from HSS are applied.	mtasConfRouting
Defines the code used for rejecting joining conference. If empty, any other value then mtasConfAnsConfirmDigitMap causes rejection, if not empty, only this value causes rejection. Observe that this attribute is used by the MTAS when requesting the Media Resource Function Processor to collect the confirmation code inband from the called party.	mtasConfAnsConfirmDeclineDigitMap
Defines the code that corresponds to the desired audio announcement to be played to the called target when entered DTMF input is not matched with the expected one. It is used as key for MtasGaAnn.	mtasConfAnsConfirmNoMatchAnnouncement

The Ad-hoc conference service can populate the contact header using either the domain name or the IP address. In case of domain, the DNS has to be updated to be able to resolve the domain name specified in ConfUriSubDomain.

Note:  

It is also possible to update the confUriPrefix and the ConfUriSubDomain to empty strings to make MTAS continue to use the IP address instead of the domain name.

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

3.2   Conference Administrative State Configuration

The Ad-hoc Conference service is enabled by setting the mtasConfAdministrativeState attribute in the MtasConf MO to 1 (Unlocked). If the mtasConfAdministrativeState is set to 0 (Locked), no Ad-hoc Conference service is provided by the MTAS.

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

3.3   Wholesale for Ad-hoc Conference Configuration

The Ad-hoc Conference service supports Wholesale. Ad-hoc Conference is configurable on Virtual Telephony Provider level.

Wholesale for Ad-hoc Conference is activated when the following attributes are set to 1 (Unlocked):

• The vtasConfAdministrativeState attribute in the VtasConf MO
• The mtasConfAdministrativeState attribute in the MtasConf MO

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

3.4   Service Data Configuration

This section describes how to configure the service data.

3.4.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the Ad-hoc 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 Ad-hoc Conference service configuration data for a subscriber, the following is to be indicated:

• The maximum number of participants (including the subscriber) the subscriber is allowed to have in a conference.

  This option only applies if the subscriber is allowed to create conference.

• The status of the Answer Confirmation function (enabled/disabled).

  This option only applies if the subscriber is allowed to create conference.

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.
• The XDMS rejects service provisioning of Ad-hoc Conference service if the user already has FIP Service activated and the node level co-location is disabled.

3.4.2   Subscriber Subscription Level Service Configuration

No service data for the Ad-hoc Conference service is configured in the subscriber part of the subscriber data.

4   Performance Management

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

5   Fault Management

For alarms related to the Ad-hoc Conference service, refer to MTAS Alarm List.