Subject: RE: [MEGACO] conferencing requirements - updated version

From: "Even ,Roni" <[email-masked]>
Date: Wed, 29 Aug 2001 09:08:33 +0200

Hi,
This is the updated version after the comments. Again I think that the list
will serve both as requirements and a check list to verify that we can
support this functionality. I intend to prepare a contribution to the next
ITU meeting the week of September 24. I want to have the requirements and
update the architecture. I would like to start working on parameters and
then decide how to divide them to base functionality and enhanced one.

Regards
Roni Even

Requirements

The MG will be able to support the following requirements as seen from the
MGC

General

1.	The MGC will be able to command the MG to support the conferencing
modes described in H.323 (H.323 Version 4 section 6.8) and SIP
(draft-rosenberg-sip-conferencing-models-01.txt). 
2.	The MGC will also enable meet me per user (each user has his dial in
number), meet me per conference (each conference has a dial in number) and
meet me per MCU (the MCU has one number and the user is directed to his
conference according to his callee information).
3.	The MG will be able to signal the MGC about changes in capabilities
and limits.
4.	The MGC shall be able to audit the MG to determine the capabilities
and capacities of the MG to support conferencing
5.	Support for simultaneous audio, video and T.120 data conferencing. 
6.	Support dial-in and dial-out participants. (There is an open issue
who will select dial in numbers is it the MGC or the MG, for example who
will create conference URIs or assign ISDN dial-in numbers)
7.	The system will be able to support a simple conference where all
participants must have a pre-defined conference capability set.
8.	The system will be able to support a conference with dynamic
conference capability set based on highest common. The conference mode will
be dynamic based on the highest common denominator capability set of all
participants
9.	The system will be able to support a transcode conference where the
MGC will decide what codecs will be used in each connection. This enables
each participant to get the best connection he can support.
10.	The MGC will be able to command the MG to support conferences that
include H.320 participants.
11.	The MGC will be able to send floor control commands to the MG
12.	The MGC will be able to command the MG to support conference
features like conference tones (party joined, party left)

Audio

1.	A participant can be an audio listener or talker. He can be a
listener in more then one side conference but can be a speaker in only one.
2.	The volume level of each participant can be controlled from the MGC.
3.	The level of the received audio will be available to the MGC.
4.	The MGC will be able to define the mix level and let the MG mix the
N loudest speakers.
5.	The MGC will be able to define the contributing source for each mix.
6.	The MGC can have a separate mix for each listener
7.	Each listener shall be able to control the level of each talker
individually. This is part of floor control
8.	Each listener shall be able to control the level of the mail
conference and each side conference it participates in. This is part of
floor control
9.	It shall be possible to control an MG that only provides one set of
levels per conference with minimum messages. This may be basic
functionality.

Video

1.	Support video switching mode where each participant may receive a
different video stream controlled by the MGC. The switching can be according
to the following modes
a.	Voice activated - Everyone sees the active speaker and he sees the
previous speaker. In this mode the switching may be done by the MG
b.	Lecture mode - Everyone sees the lecturer while the lecturer can see
all students switched each N seconds. 
c.	Forced mode - The MGC define the outgoing streams for each
participant.
2.	Support simple video mix - 1,2 or 4 participants with the same
capabilities (line rate, frame rate, resolution) with simple layout. Support
different view per participant. The stream in each sub window can be by
voice activated or forced.
3.	Support complicated video mix - any number of participants any
layout built from rectangular windows. Each window will contain a
panned/scaled/cropped version of an input stream. Support overlaid windows.
Support different view per participant. The stream in each sub window can be
by voice activated or forced. The video stream parameters of each
participant can be different.
4.	Support video mute on outgoing and incoming directions.
5.	It shall be possible to support separate output view for each
participant, although an implementation may only support one or a limited
number of output views. It shall be possible to specify which input streams
are mapped to each window; this can be controlled by the participant and
will be reported to each participant. The MGC shall be able to dynamically
change the mapping.
6.	Voice activated switching can be done by the MG or by the MGC
dependent on MGC policy. The MG will report the current viewed stream even
if the MG does the switching.

**********************************************
Roni Even
VP Product Planning
Polycom Israel
Tel: +972-3-9251200
Fax: +972-3-9211571
Email: [email-masked]

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco