TR 22.948
Study of requirements of IMS Convergent Multimedia Conferencing

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2024/03 26 p.

V17.0.0 2022/03 26 p.

V16.0.0 2020/06 26 p.

V15.0.0 2018/06 25 p.

V14.0.0 2017/03 26 p.

V13.0.0 2016/01 26 p.

V12.0.0 2014/10 26 p.

V11.0.0 2012/09 26 p.

V10.0.0 2011/04 26 p.

V9.0.0 2009/12 26 p.

V8.0.0 2007/10 26 p.

Rapporteur:: Mr. Huang, Qing
China Mobile Com. Corporation

Content for TR 22.948 Word version: 18.0.1

1 Scope p. 6

The present document studies the requirements for IP-Multimedia Subsystem (IMS) Convergent Multimedia Conferencing (CMMC) service in IMS. Specifically, the objective of this study item is to:

Identify features of IMS multimedia conferencing, and describe potential service requirements for IMS multimedia conferencing.
Identify the IMS requirements for multimedia conferencing services:
1. the conference framework
2. data sharing session establishment/termination/management in a conference
3. media control for audio, video and data
4. floor control for audio, video and data
5. conference policy
Identify possible routes to standardization by:
1. Adopting existing and emerging standards, e.g. OMA, IETF, W3C.
2. Modifying and enhancing existing and emerging standards.
3. Developing of new standards.

2 References p. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1".

[3]

TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".

[4]

RFC 4376: "Requirements for Floor Control Protocols".

[5]

RFC 4353: "A Framework for Conferencing with the Session Initiation Protocol (SIP)".

[6]

RFC 4245: "High-Level Requirements for Tightly Coupled SIP Conferencing"

[7]

W3C Working Draft (November 2006): "Voice Browser Call Control: CCXML Version 1.0".

[8]

TR 24.880: "Media Server Control using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".

[9]

TR 22.115: "Charging and billing".

[10]

ETSI TS 183 005: "TISPAN; Release 1; PSTN/ISDN Simulation Services: Conference (CONF); Protocol Specification".

[11]

OMA Push to Talk over Cellular 2 Requirements; http://member.openmobilealliance.org/ftp/Public_documents/POC/Permanent_documents/OMA-RD-PoC-V2_0-20061219-C.zip.

[12]

OMA Push to talk over Cellular (PoC) - Architecture; http://member.openmobilealliance.org/ftp/Public_documents/POC/Permanent_documents/OMA-AD-PoC-V2_1-20060601-D.zip.

[13]

TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1".

[14]

draft-ietf-xcon-framework-07: "A Framework and Data Model for Centralized Conferencing".

[15]

TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

[16]

TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2".

3 Definitions, symbols and abbreviations p. 7

3.1 Definitions p. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply.

CMMC Service Subscriber:

A subscriber that has been provisioned with a CMMC service.

Conference:

An IP multimedia session with two or more participants. Each conference has a "conference focus". A conference can be uniquely identified by a user. An example for a conference could be a multimedia game, in which the conference focus is located in a game server.

Conference Focus:

The conference focus is an entity which has abilities to host conferences including their creation, maintenance, and manipulation of the media. A conference focus implements the conference policy (e.g. rules for talk burst control, assign priorities and participant's rights).

Floor:

An individual temporary access or manipulation permission for a specific shared resource (or group of resources) RFC 4376.

Floor Chair:

A floor chair is a human or automated entity, who is authorized to manage access to one floor and can grant, deny or revoke access. The floor chair does not have to be a participant in the conference instance.

Floor Control:

Floor control is a means to manage joint or exclusive access to shared resources in a conferencing environment RFC 4376.

Floor Owner:

Floor owner is a conference participant who is granted the floor and is allowed to send media.

Host:

The conference host is a specific conference participant who manages and controls the conference, e.g. adding and removing participants, adding and removing media in the conference, terminating the conference etc. There is only one host in a conference.

3.2 Abbreviations p. 7

For the purposes of the present document, the following abbreviations apply in addition to TR 21.905:

CMMC

Convergent Multi-Media Conference

4 Requirements and objectives p. 8

The objective of this study item is to study requirements, terminal requirements and potential new capabilities in 3GPP that need to be standardized for the CMMC service, especially additional features for roaming and interoperability support.

5 General description of IP-Multimedia Subsystem (IMS) convergent multimedia conferencing service p. 8

5.1 General p. 8

This clause gives general description of CMMC service, identifying the features of CMMC service.

The IP-Multimedia Subsystem (IMS) Convergent Multimedia Conferencing service enables a multi-party conversation with multimedia including audio, video, message and various data and application. Such a conversation can be associated with a conference focus to manage and control the on-going sessions.

Conferencing in 3GPP is expected to be under the control of the operator who will take responsibility for the overall management of the conference and the definition/configuration of their policies. To facilitate this, a focal point is required. Two types of conferencing are described in RFC 4353, loosely (distributed) and tightly coupled, only one of which fulfils this operator need.

A loosely coupled conference is one where no coordinated signalling relationship between participants exists. Typically multicast is used to distribute conference membership and no focal point exists.

A tightly coupled conference is one in which a focal point exists. This focus maintains dialogue with each participant, provides a centralised manager and can be addressed by a conference URI.

CMMC is only concerned with the tightly coupled conferencing model which offers suitable levels of operator oversight and control.

5.2 Basic CMMC p. 8

5.2.1 Conference types p. 8

5.2.1.1 Ad-hoc conference and scheduled conference p. 8

An ad-hoc conference is a conference that is created on demand by a conference participant TS 24.147.

A scheduled conference is one that is created to take place at a pre-determined time by a CMMC service subscriber or by a third party.

5.2.2 Conference roles p. 8

5.2.2.1 Conference host p. 8

The host of ad-hoc conference is the conference creator by default. In a scheduled conference, one of the participants can be authorized to be the host at the time of conference reservation or during the conference.

5.2.2.2 Conference participant p. 8

A user that joins or is added to the conference is a conference participant.

5.2.2.3 Floor chair p. 8

The floor chair is a person or another entity that has floor control for a floor (e.g. grants, denies, or revokes a floor). The floor chair does not have to be a participant in a conference, RFC 4376. The floor chair is able to grant permission to a conference participant to send media on behalf of another conference participant.

Different media or media combination (e.g. audio & video) may have different floors. Each floor may have a different chair.

5.2.3 Media in conference p. 9

The participants in CMMC can communicate with each other with multiple types of media including audio, video, message, various data such as file, whiteboard etc.

5.2.4 Operations in conference p. 9

5.2.4.1 Creating conference p. 9

The ad-hoc conference is created on demand by the initiator. The scheduled conference is created by the conferencing service automatically at the scheduled time.

5.2.4.2 Starting conference p. 9

The ad-hoc conference is started at the same time it is created. The scheduled conference is started when the first participant joins the conference.

5.2.4.3 Joining conference p. 9

A user can join a conference by requesting to join (e.g. dialing in) the conference or by accepting the invitation from an other participant or the conference focus.

5.2.4.4 Leaving conference p. 9

A participant can leave a conference at any time during the conference. The host can also remove a participant causing the participant to leave the conference.

5.2.4.5 Terminating conference p. 9

A conference may be terminated upon:

A request from a participant in the conference
Other predefined conditions (e.g. timeout)

5.2.4.6 Hosting Conference p. 9

The conference host is responsible for managing and controlling the conference. The host can add and remove participants, mute/unmute participants, add and remove media, set and change the conference policy etc.

5.2.4.7 Adding and removing media p. 9

The conference can be started with a particular set of media types, for example voice only and during the conference, other types of media such as video, message and data can be added to the conference. Media types can be removed from the conference. Adding and removing media types in a conference is based on the conference policy.

A particular media type may be added or removed for the entire conference or for a specific list of the participants.

5.2.4.8 Floor control p. 9

The conference has shared resources such as the right to talk, input access to a limited-bandwidth video channel, or a pointer or input focus in a shared application. Floor control is a means to manage joint or exclusive access to shared resources in a conferencing environment, RFC 4376. Floor control enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource.

5.2.5 Conference state p. 10

Conference state is information provided to all or part of the participants before and during a conference which includes Conference Status and Participants Status.

Conference Status may contain the information with respect to topics, agenda, permitted media types, currently used media types, conference mode (e.g. whether the ongoing conference is a hosted conference or a non-hosted conference, etc.) allow or not allow file transfer, mute/un mute status, etc.

Participants Status may contain information of conference roles, floor right, management right, user device capability (e.g. media types supported by participant's devices.) and the process announcement of participants joining/leaving a conference.

5.3 Advanced CMMC p. 10

5.3.1 Data conference p. 10

While attending audio and video conference, the participants can share various data and applications including whiteboard, files, applications, documents and web pages.

5.3.1.1 Whiteboard p. 10

The whiteboard is a shared resource for participants in the conference, on which participants can draw text and graphics.

5.3.1.2 File transmission p. 10

During the conference, the participants can deliver or exchange files. A participant can send out a file to some or all participants in the conference, when permitted, based on conference policy. The sender gets the feedback of whether the receivers have received the files successfully.

5.3.1.3 Application/desktop sharing p. 10

A participant in the conference can share with other participants an application running on his terminal when permitted based on conference policy. The owner of the application can authorize another participant to control the application remotely. The shared application can be presented to all the participants.

5.3.1.4 Synchronized web page browsing p. 10

The participants in the conference can browse the web pages on the Internet synchronously. A participant, who has the floor for synchronized web page browsing, is the controller. There is only one controller and when he specifies a new link for synchronized browsing the new web page is presented to other participants through their web-browsers in a new window. A participant shall be able to refuse to accept synchronized browsing.

Means by which the web browser is invoked are outside of scope of 3GPP standardisation.

5.3.2 Sidebar conferences p. 11

A sidebar appears to the users as a "conference within the conference". It is a conversation amongst a subset of the participants to which the remaining participants are not privy (RFC 4353). The sidebar has the same conferencing capabilities (e.g. sidebar identifier, hosts, floor controls) as the general conference. The maximum number of participants is restricted according to the configuration of the conference policy.

5.3.3 Voting p. 11

A participant who is authorized by conference policy can initiate a poll among the participants. One or more topics can be polled at a time. Several options are presented for each topic, and the participants can select one or more options for each topic in a list. Presentation of the options can utilize the media used in the conference. The voting can be public or anonymous. For public voting the participants can see who voted for which option. The votes are collected and the initiator can publish the results to all participants. The initiator of the voting can set parameters for the voting such as:

Allowed participants
An expiry time for the voting
public or anonymous mode

5.3.4 Conference agenda p. 11

The conference host can create a conference agenda. A conference agenda is composed of a set of consecutive topics. Each topic is associated with starting time, ending time and the on-going state (e.g. finished). The conference agenda and the on-going state are published and updated to all the participants during conferencing by the host. With conference agenda, the participants know about conference schedule and the on-going state.

6 Proposed requirements for IP-Multimedia Subsystem (IMS) convergent multimedia conferencing service p. 11

This clause specifies potential requirements for CMMC service.

6.1 Conference control p. 11

6.1.1 Creating a conference p. 11

6.1.1.1 Creating an ad-hoc conference p. 11

A user shall be able to request the creation of an ad-hoc conference.

It shall be possible for a user to specify the participants when creating an ad-hoc conference.

The user shall be able to give a name to a conference. When a participant is invited to the conference this name is displayed to the invitee.

Upon conference creation the user shall be able to set properties of the ad-hoc conference in any of the following ways: default, based on his user profile, and explicitly.

6.1.1.2 Creating a scheduled conference p. 11

It shall be possible for a user to request the creation of a scheduled conference with specified properties including additional information on the conference (e.g. the conference subject), starting time, ending time, participants, media types, conference policy, etc.

The user shall be able to give a name to a conference. When a participant is invited to the conference this name is displayed to the invitee.

Upon conference creation the user shall be able to set properties of the scheduled conference in any of the following ways: default, based on his user profile, and explicitly.

The participants of the scheduled conference can be selected individually or by choosing a pre-arranged group.

6.1.1.3 Conference identifier p. 12

The conference identifier is an identifier associated with a conference session that uniquely distinguishes a particular conference from all other conferences in the same network, including those that currently exist and those that do not. The conference identifier is allocated to the conference when the conference is initiated. The conference identifier can be applied for charging, for a user to identify a conference when joining a conference, etc.

6.1.2 Starting a conference p. 12

The Conference Host shall be able to control when to start the conference.

6.1.3 Terminating a conference p. 12

It shall be possible for the Conference Focus, based on the conference policy, to terminate the conference upon:

A request from a participant in the conference
Other predefined conditions.

6.1.4 Adding participants p. 12

In a Scheduled Conference, a user shall be able to request to be added to a conference, and become a conference participant.

The Conference Focus shall be able to invite a user to a conference, and if the user accepts the invitation, he becomes a conference participant.

Conference participants shall be able to invite a user or a list of users to join the conference, based on the conference policy. If any users accept the invitation, they will become conference participants.

The Conference Focus shall be able to query a user if he wants to receive certain types of media in this conference when he is invited to the conference.

6.1.5 Removing participants p. 12

A participant shall be able to request to leave the conference.

Conference participants shall be able to remove a participant or a list of participants from the conference based on the conference policy.

6.1.6 Sidebar creation p. 12

A user shall be able to request the creation of a Sidebar within the existing Ad-hoc conference or Scheduled conference.

It shall be possible for a user to configure the subset of the participants in the existing conference when creating a sidebar.

It shall be possible to configure whether or not the termination of the original conference terminates the Sidebar.

The communication behaviour (e.g., sidebar creation, media data transfer) shall only be limited within the sidebar the specified subset of participants.

It shall be possible for a participant in a Sidebar to configure whether or not to receive media from the original conference.

Since the sidebar conference has the same conferencing capabilities as the general conference, the sidebar shall be uniquely identified, and the user shall be able to give the sidebar a name and set properties of the sidebar as that in the conference creation.

6.2 Media control and processing p. 12

6.2.1 Adding and removing media p. 12

Based on the conference policy it shall be possible for

a participant to request to add or remove media types to be available for use to all participants or to a specific group of the participants.
the Conference Focus to add media types during a conference on behalf of a conference participant.

The Conference Focus shall be able to query a participant if he wants to receive certain types of media in this conference.

It shall be possible for a participant to reject media types in a conference, in which case these media shall not be presented to the participant.

6.2.2 Media mixing p. 13

Media Mixing denotes the process of combining several real-time media streams (e.g. audio, video) from the participants, generating one or more output media streams to the participants.

It shall be possible for the Conference Focus, based on the media mixing policy, to determine the proper media mixing mode.

6.2.3 Floor control p. 13

It shall be possible to apply floor control to media types such as: audio, video, whiteboard and shared applications etc.

It should be possible to apply individual floor control to individual media types or a combination of media types (e.g., audio & aideo), different media or media combinations may have different floors.

Each instance of a media type or media combination has one floor control. Multiple instances of a media may share the same floor control.It should be possible to apply floor control to a single media type for multiple participants (e.g. grant, deny, or revoke the floors simultaneously to more than one participants).

For floor controlled media types at least the following requirements shall be fulfilled:

A participant shall be able to request a one or more floors simultaneously.
A participant shall be able to request multiple floors associated with to more than one or more media types.
A floor owner shall be able to release a floor before or after sending media.
The floor chair shall be able to revoke a floor from a floor owner.
The floor chair shall be able to grant a floor to a participant.
The floor chair shall be able to grant or revoke floors of a media type or combination of media types simultaneously to a set of participants.
The floor chair shall be able to reject a participant's floor request.
It shall be possible for a participant to request a floor control operation (e.g., floor request/release) on behalf of another participant (third-party floor control).
It shall be possible for a participant to authorize another participant to request the floor on his behalf.
It shall be possible to inform conference participants about a participant's floor request.
It shall be possible to notify conference participants about the change of the floor owner.

It shall be possible to support queuing for floor control during a conference. When queuing for floor request is applied in a conference, it shall be able to support the capabilities described as per below:

It shall be possible to inform conference participants that a floor request has been queued.
It shall be possible to permit a conference participant who has requested the floor to obtain the information of his state in the floor request queue.
It shall be possible to grant more than one priority level in access to the floor, e.g. a participant with higher priority may be allowed to pre-empt a participant with lower priority.
The floor chair shall be able to adjust (e.g. cancel, reorder etc.) a previously queued floor request.

6.3 Conference state p. 14

6.3.1 Conference state information p. 14

It should be possible to provide Conference State information to all participants during a conference.

Conference State information may include:

Conference Status
This may contain the information with respect to topics, conference mode (e.g. whether file transfer, muting/unmuting the conference, sending of particular media types, etc are allowed or not).
Participants Status
Participants Status is dynamic information on the current status of every participant in the conference.
This may contain information of conference roles, floors, participant's queuing state, participant's device capability (e.g. media types supported by the participant's device.).

The interval of updating conference state information shall be subject to conference policy (e.g. periodically or when changes occur in the conference).

It shall be possible to specify the extent of conference state information to be provided to the participants in the conference policy.

6.3.2 Conference state subscription p. 14

It shall be possible for a participant to subscribe to receive conference state information. A participant who has subscribed to receive Conference State information is a conference state subscriber.

As a subscription option it shall be possible to set the minimum interval between receiving conference state information.

Participants shall be able to unsubscribe from receiving Conference State information.

6.3.3 Conference state notification p. 14

A conference state subscriber shall be able to receive conference state information during an ongoing conference.

It shall be possible to notify conference state subscribers about the conference state periodically or upon changes of conference state based on the conference policy.

It shall be possible to adjust the frequency of conference state notification based on conference policy. Conference State Notification shall be terminated when the conference is terminated.

6.4 Conference policy p. 14

6.4.1 General p. 14

The conference policy contains the rules on how the Conference Focus operates in a conference. The conference policies applied to CMMC service shall be able to include conference control policy, media mixing policy, floor control policy, participant privacy policy and conference state notification policy.

It shall be possible to store conference policies for later re-use.

6.4.2 Conference control policy p. 14

Conference control policy is defined before a conference by the host or conference service provider and shall be enforced during a conference.

A conference control policy contains at least the following attributes:

for creating a conference
- Allow or block a user to create a conference.
for terminating a conference
- The way to terminate a conference:
- by conference host or an authorized participant
- due to time out of a scheduled conference
- after the conference is not active (i.e. no participant in the conference) for a defined period
for adding participants
- Allow or block a user to be added to a conference.
- Allow or block a participant to invite a user to join the conference
for removing participants
- Allow or block a participant to remove another participant.

6.4.3 Floor control policy p. 15

The IP-Multimedia Subsystem (IMS) Convergent Multimedia Conferencing service shall support individual Floor Control policies per conference.

Floor Control policy provides a regulation (e.g. round robin) which grants the permission to individual conference participants to access a shared resource (e.g. to send media) in a conference. The creator of a conference shall be able to choose and decide the possible policies used in the conference.

It shall be possible to define which types of media in the conference are floor controlled, and which ones are not floor controlled.

6.4.4 Media mixing policy p. 15

If multiple media mixing modes are available it shall be possible to specify one or more preferred modes.

6.4.5 Participants privacy policy p. 15

The CMMC service should provide some degree of privacy protection for participants. The privacy protection level of CMMC service should not be lower than that provided by the network.

It shall be possible for a participant to select the identity that is shown to other participants i.e. a nickname or the identity provided by IMS. If a participant requests to use a nickname then the CMMC service should ensure this nickname is unique in the conference.

It shall be possible for the CMMC service to choose a random nickname for a participant.

It shall be possible for a participant to request that his identity is excluded from the Conference state information.

The CMMC service shall allow authorized users (e.g. legal authorities) to override anonymity settings of other participants. To an authorized conference participant all available identities of specified participants shall be provided.

6.4.6 Conference state notification policy p. 15

The CMMC service shall be able to control the content and frequency of Conference State Notification information delivered to participants based on participants preferences and network policy (e.g. for the purpose of reducing network traffic).

6.5 Conference management p. 16

6.5.1 General p. 16

The CMMC service shall allow management of conference resources in order to meet the requirements of conference participants.

There shall be means for participants to realize manipulation of conference management:

Generate and manage conference subscriber defined pre-arranged group lists.
Choose proper means to respond to the invitation to join a conference, i.e. automatically or manually accept or reject the invitation based on conference policy and terminal capabilities.

Conference service providers shall have the following minimum set of capabilities for conference management:

Generate and manage pre-arranged group lists.

6.5.2 Conference reservation p. 16

A CMMC subscriber shall be able to reserve a conference with pre-defined parameters (e.g. pre-arranged group lists, starting time, maximum number of participants, etc). The CMMC service should support reserving conference resources according to the preferred configuration of users.

6.5.3 Conference announcement p. 16

Conference announcement may be used to provide conference related information before the conference starts or during the conference.

The conference announcement provides necessary information for users to join the conference, including the conference access URI, conference ID and PIN code. General information such as conference starting time, conference topic, agenda and conference type etc, may also be included in conference announcement.

It shall be possible to support multiple media formats in conference announcement in accordance to CMMC service provider's policy. The mechanism (e.g. email) to distribute conference announcement information to a specified set of 3GPP subscribers is out of scope of this TR.

6.5.4 Conference recording p. 16

It should be possible for CMMC to record the conference. Audio and video parts, including whiteboard screen are recorded, transmitted files, web links and voting results are stored for later retrieval. Conference participants shall always be informed, prior to the start of a conference, or when joining an ongoing conference, that the conference will be or is being recorded.

It should be possible for CMMC to replay conference during the conference. It should be possible fast forward, skip or rewind the recorded parts of a conference. These operations should be available to authorized participants during the conference and authorized CMMC service subscriber after the conference.

The recording, storage and disclosure of conference material e.g. conference proceedings and media shall, in relation to data protection, user privacy and confidentiality, be in accordance with all applicable regulatory requirements.

6.5.5 Conference roles assignment and replacement p. 16

The CMMC service should support means of role assignment in conference establishment as well as role replacement during conference. A conference participant can assume multiple roles at a time. The roles in a conference are:

conference host,
floor chair (per media),
conference participant

Management requirements for a conference host:

The conference host shall be able to reject or approve the participant's application to be the conference host or floor chair.

Management requirements for a conference host or a floor chair:

When the conference host or the floor chair is to leave the conference, it should be possible for him to select one of the participants as his successor and handover the conference control or floor control to the successor. In this case, the successor changes his conference role to conference host or floor chair.

6.6 Interaction with other services p. 17

6.6.1 General p. 17

3GPP and OMA are defining several service enablers and standard services including presence service, group management service, messaging services and IMS Multimedia Telephony service. It shall be possible to take into account service enablers and standard services when creating CMMC service.

6.6.2 Interaction with presence service p. 17

The CMMC service shall be able to utilize capabilities of a Presence Service enabler if appropriate (e.g. to provide participant status information). Presence Service status information will normally be restricted to the conference participant states, these may include, for example, 'Entered Conference', 'Exited Conference', 'Focus', 'Floor - (media type)'. If authorised and subscribed to the Presence Service, participants may also be able to view additional, non-conference related, information for another participant who has joined or left the conference. Similarly, conference participant states will not normally be made available to non-participants. Registered participants who have left the conference and non-participants, who are authorised and subscribed to the Presence Service, may be notified when a participant joins or leaves a conference e.g. 'In a meeting / conference' or 'Free'.

6.6.3 Interaction with group management service p. 17

The CMMC service shall be able to reuse the functionality of current Group Management Service where appropriate.

6.6.4 Interaction with messaging service p. 17

The CMMC service shall be able to reuse the functionality of current Messaging Services where appropriate.

6.6.5 Interaction with IMS multimedia telephony service and its supplementary services p. 17

CMMC shall be able to reuse the capability and functionality of IMS Multimedia Telephony Service [13] defined by 3GPP to connect a CMMC participant with the CMMC focus.

Whilst a user is participating in a CMMC conference via MMTel all supplementary services apply with the following exception:

CONF: a Multimedia Telephony communication with a CMMC focus can not be included into a MMTel CONF conference

If Communication Barring (CB) is invoked for a user, the user is prohibited to join or be added to a CMMC conference.

6.6.6 Interaction with calendar applications p. 17

It shall be possible to schedule conferences both in advance and on a recurring basis, conference start and stop times should be configurable by a CMMC user. To support this, it is desirable that the CMMC solution will be required to interwork with calendar applications. For this it is recommended to utilize draft-ietf-xcon-framework-07 [14].

6.7 Service provisioning p. 17

It shall be possible for the CMMC service provider to set up and update CMMC communication feature configuration remotely in the terminal device.

It shall be possible for the CMMC service provider to provide means (e.g. a user-interface from the CMMC subscriber's terminal or via a web page) for the CMMC subscribers to configure and update their CMMC settings.

7 Proposed terminal requirements p. 18

The terminal shall be able to support the capabilities provisioned by CMMC which includes:

Implement the roles of a conference, i.e. host, floor chair and participant.
Support the operations and services in basic CMMC, i.e. create/start/join/leave/terminate/host a conference, obtain conference state information.
Support the reception of information from the Conference Focus.
May have the capabilities to allow user to manage conference policies.
Media process capability.

Dependent on terminal capabilities, it shall be possible to:

Support multiple media types provided during the conference.
Support the operations and services in advanced CMMC, e.g. white board, file transmission, application sharing, synchronise web page browsing, voting etc.
Support interaction with IMS Multimedia Telephony Service.

8 Quality of service p. 18

General QoS requirements as specified for IMS services in TS 22.228 apply.

9 Charging p. 18

The CMMC service should support offline and online charging. The CMMC service shall be able to support various charging mechanisms (e.g. reverse, prepaid and reply charging etc.) defined by 3GPP contained within TS 22.115. Charging models that shall be supported by CMMC includes (non-exhaustive list) the following items.

Subscription based charging which includes:

Participant status relative to CMMC subscription.
Identity of each conference in which the user participates.
Maximum number of participants who joined the conference within a defined period (as configured in Conference Focus).

Traffic based charging which includes:

Duration of a session.
Duration of a conference.
Amount of messages containing user content delivered in a conference.
Media types used in a conference.
Number of sessions proceed, i.e. successful and failed attempts.
Number of participants.
Volume of data transmitted.
Number and type of media exchanged.
Duration of media transmit time.
Roles of participants.
QoS based on sessions and individual media components.

Storage based charging which includes:

Storage space required for a recorded conference.
Conference storage duration, i.e. how long the conference content is retained before permanent deletion.
Conference replay times, i.e. the number of times the stored conference is replayed.

Different charging options shall be permissible for CMMC service, and it shall be possible to charge to the individual participants.

10 Security p. 19

10.1 General security requirements p. 19

Access authorization to the conference shall be provided, i.e. the conferences will be governed by a set of authorization rules defined in the conference policy to ensure that unauthorized access to the conference is not allowed.

10.2 PIN security feature p. 19

The CMMC service providers should be able to offer a security feature which requires invited participants to enter a PIN number before joining the conference call. If the CMMC service providers offer it, users can use this feature when creating a meeting with the conference service option that restricts the meeting to specific participants. When the user creates a conference, it can be secured by an automatically allocated PIN. This PIN may be displayed to the participants during the conference.

11 Interworking p. 19

The CMMC should support conveyance of services (e.g. voice calls and multimedia services) between users using different domains or networks (e.g. IMS users and users in CS domain/PSTN networks) as specified in TS 22.228.

12 Roaming p. 19

Roaming scenarios in CMMC service shall be compliant with that of IMS.

13 Considerations on re-use of existing conferencing capabilities p. 19

13.1 Re-use of 3GPP conferencing capabilities p. 19

As the architecture for the 3GPP conference service is specified in TS 23.228 and TS 23.218, the current TS 24.147 specifies the usage of Session Initiation Protocol (SIP), SIP Events, the Session Description Protocol (SDP) and the Binary Floor Control Protocol (BFCP) to realize 3GPP conference service based on the protocols specified by the IETF defined conference service.

TS 24.147 covers conference services requirements specified in TS 22.228, which include the following aspects:

Conference roles
Operations in conference:
- Conference creation,
- Termination of the conference
- Joining a conference,
- Leaving a conference,
- Modification of the conference (e.g. add/remove media, manipulation of data streams, add/remove participants)
- Receipt of information from the conference focus (e.g. participants in conference, participants joining or leaving the conference)
Floor control for conferencing

However, the functionality for conference policy control which is essential for a complete IMS conferencing service is not specified in TS 24.147.

13.2 Re-use of OMA conferencing capabilities p. 20

Currently the Open Mobile Alliance (OMA) is working on the specification of several enablers that will support Multimedia Conferencing functions.

The following OMA enablers seem to be relevant (note, that documents can be found in the Publicly Available Documents section of OMA at http://www.openmobilealliance.org/tech/publicmaterial.html ):

Converged IP Messaging (CPM)
Push-to-Talk over Cellular (PoC version 1 and version 2)
Instant Messaging (IM)
Presence
XML Document Management (XDM)

PoC and IM are based on the architecture model which is inherited from IETF conferencing framework. The architecture model and technical specifications are currently limited to near real time medias as the (radio) access technology is (was) not ready yet to support full-duplex traffic. In addition OMA has defined horizontal applications to support multiparty applications namely Presence and XDM.

13.2.1 Converged IP Messaging (CPM) p. 20

CPM enabler V1.0 is targeted to provide a converged messaging capability focussing on the user experiences provided with the following services:

Text messaging enabled services. SMS, IMPS, SIMPLE IM, Email, MMS
Voice-enabled services: PoC, VoIP
Video-enabled service: Video-o-IP

Converged IP Messaging (CPM) is a messaging framework which accommodates different user experiences such as deferred and immediate messaging, session-based messaging, and half duplex / full duplex conferencing. It aims at consolidating common functionalities of existing messaging services and new features introduced by the convergence of communications brought by SIP-based technologies.

Requirements are currently specified in the OMA REQ group and are currently undergoing approval. Work on the architecture of CPM has started.

13.2.2 Push-to-Talk over Cellular (PoC version 1 and version 2) p. 20

While PoC v1 defines SIP based half-duplex group communication for voice only PoC v2 is extending the Release Version 1.0 PoC service with:

Other media types than voice. Examples of other medias are: Video, images, text and files.
Enhanced PoC Group handling, for example creation of PoC Group Sessions based on dynamic data such as presence state of the individual PoC Group members.
Enhanced PoC Session handling, for example moderator controlled PoC Sessions.
Others.

PoC v2 contains full-blown conferencing capabilities, which are described (see in particular section 6.1.8.11 "Moderated PoC Groups") in the Requirements document OMA-RD-PoC-V2_0.

While the conferencing capabilities of PoC v.2 seem to overlap to a great extent with the potential requirements proposed in the current TR the reader should be reminded, that PoC only supports half-duplex real time media and thus voice- or video signal mixing is not supported.

PoC v.2 is currently at the stage of a Candidate OMA enabler. Documents (requirements- and architecture specifications) can be found at

Requirements document:

Push to Talk over Cellular 2 Requirements [11],

Architecture document:

OMA Push to talk over Cellular (PoC) - Architecture [12].

13.2.3 Comparison of proposed CMMC functionality with OMA PoC v2 p. 21

The following Table gives an overview of the proposed CMMC functionalities and equivalent OMA PoC v2 functionalities

CMMC functionality	PoC v2 functionality	Comment
Conference Types: Ad-Hoc- and Scheduled Conference	Ad-hoc PoC Group Session, Pre-arranged PoC Group Session
Conference Roles: Participant, Chair, Host	Participant, PoC Chair, PoC Session Owner	In PoC v2 the concept of a Host is more fine-grained than in CMMC. 'PoC Session Owner' and 'PoC Group Administrator' are defined in OMA PoC.
Media in Conference	In addition to voice Media Types supported could be still images, live-streamed video, file transfer and text, but not limited to the above-mentioned list	PoC v2 does support all media types required by CMMC
Operations in Conference Creating, Starting, Joining, Leaving, Terminating, Hosting a conference, Adding and removing Media, Floor Control	The same functions exist in PoC v2
Conference State Conference Status, Participants Status	Automatic Notification of Limited Participating Information
Conference Record and Replay	PoC Box
Data Conference Whiteboard, File Transmission, Application/Desktop Sharing, Synchronized Web Page Browsing	File transmission, video- and still image sharing is supported in PoC 2	Application/Desktop sharing with remote control by other participants, synchronized Web Page Browsing do not exist in PoC v2
Sidebar Conferences	partly covered by 1-1 mode within a 1-many PoC session	Does not exist in PoC v2. in the form requested by CMMC
Voting	PoC voting service	The PoC voting service is a potential PoC v2.1 feature and is not incorporated in PoC v 2.0
Conference Agenda	partly covered by Enhanced PoC Session Establishment	Does not exist in PoC v2. in the form requested by CMMC

13.3 Re-use of W3C conferencing capabilities p. 22

CCXML [7] is a W3C XML scripting language for conferencing and call control functionality. The language uses an event-driven algorithm where user-defined actions are triggered when events are fired. One advantage of CCXML is that it can be used both on Application Server and also MRFC to control conferencing.

CCXML provides constructs for conference management and media control using VoiceXML for a conference.

3GGP TR 24.880 proposes a delegation model where CCXML can be invoked using SIP in IMS networks. For example:

INVITE sip:control@mrf.example.com;ccxml=http://server.example.com/conference.ccxml
SIP/2.0: This allows application servers to use CCXML as an interface to MRFC in IMS network.

A drawback of CCXML is that it currently supports voice only conferencing.

14 Conclusion p. 22

The architecture and protocol of CMMC shall be consistent with what has been specified for IMS conferencing in TS 24.147 and TISPAN ETSI TS 183 005 [10].

As related activity is ongoing in OMA duplicate work should be avoided.

OMA should be consulted whether their ongoing work would cover the proposed functionality for CMMC as well.