Subject: [Megaco] RE: conferencing requirements

From: "Even ,Roni" <[email-masked]>
Date: Thu, 16 Aug 2001 11:53:21 +0200

Christian,
See my comment in the text. A general comment is that I was specifying
requirements for the exchange between the MG and MGC and not from the use to
the MGC.
Roni

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 3:46 AM
To: Even ,Roni
Cc: [email-masked]'; 'Rosen, Brian'; 'Danny Levin'; Frans Standaert
Subject: Re: conferencing requirements

G'Day Roni and Brian,

I think the list is looking good and I definately support the layered
approach. We have the following suggestions that should be included:

1. Use of analysis function for selecting active speaker. 
The mentioned idea of "loudest" talker detection (see support for "video
follows audio" controls) is not general
enough. For instance, a conferee may indicate that he is very eagerly to
speak by pushing a red button on his screen
(instead of shouting). Moreover, the analysis function might be
seperated from the conference bridge.
*** This is what I call as force in the requirement. The MGC somehow get
this information from the user and force a specific user in the video or
audio mix, the requirement is to enable the MGC to force a party into the
mix.

2. Synchronization of audio and video. This might be less of a problem
if audio and video are on the same
termination, but then this should be stated/required explicitly. 
** OK I will add this one

3. It's mentioned that each participant (potentially) sees a clipped,
scaled and positioned view of each
participant. 
It should be made explicit that highlighted view(s) of active speaker(s)
should be possible.
***** I think this is a mixer implementation issue, but I can add a
requirement that will enable the MGC to tell the MG to turn an active
speaker marker on.  This remind me a requirement to enable the support of
tones for party joined or left the conference.

Another question: who will be collating these requirements? Roni? Brian?
**** I am willing to do the final list. Do you want it as part of a
contribution to the next ITU meeting

Tom?

Regards, Christian

"Even ,Roni" wrote:
> 
> Hi,
> This is the initial list of requirements that the decomposition of the MCU
> must support. I would also like to divide it to base functionality and
> extended so that the packages will be built accordingly. Please give me
your
> feedback
> 
> The MG will be able to support the following requirements as seen from the
> MGC
> 
> General
> 
>         .        The system will support all the conferencing modes as
> defined in H.323 or SIP. (Centralized, multicast, loosely coupled etc.)
>         .       The MG will be able to signal the MGC about it
capabilities
> and limits.
>         .       Support for audio, video and T.120.
>         .       Support dial-in and dial-out
>         .       The system will be able to support a simple conference
where
> all participants must have a pre defined conference capability set.
>         .       The system will be able to support a conference with
dynamic
> conference capability set based on highest common.
>         .       The system will be able to support a transcode conference
> where the MGC will decide what codecs will be used in each connection
> 
> Audio
> 
>         .       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.
>         .       The volume level of each participant can be controlled
from
> the MGC.
>         .       The level of the received audio will be available to the
> MGC.
>         .       The MGC will be able to define the mix level and let the
MG
> mix the N loudest speakers.
>         .       The MGC will be able to define the contributing source for
> each mix.
>         .       The MGC can have a separate mix for each listener
> 
> Video
> 
>         .       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
>                         .       Voice activated - Everyone sees the active
> speaker and he sees the previous speaker. In this mode the switching may
be
> done by the MG
>                         .       Lecture mode - Everyone sees the lecturer
> while the lecturer can see all students switched each N seconds.
>                         .       Forced mode - The MGC define the outgoing
> streams for each participant.
>         .       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.
>         .       Support complicated video mix - any number of participants
> any layout. Support overlays. Support different view per participant. The
> stream in each sub window can be by voice activated or forced. The video
> parameters of each participant can be different.
>         .       Support video mute on outgoing and incoming directions.
> 
> Roni Even
> 
> **********************************************
> 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

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Aug 2001 11:07:54 +1000

G'Day Roni,

I think a cony=tribution with these requirements into the SG16 meeting
would be good as SG16 are in the business of defining MCUs.

...
> audio mix, the requirement is to enable the MGC to force a party into the

[CHG] The MGC could get this indication via the MG. ie. a u-plane event
is detected. I think this should be included.

Cheers, Christian