Subject: RE: [Megaco] conferencing requirements

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Aug 2001 11:32:11 -0400

Roni

One of my (many) faults is that I can't stop myself from rewriting things
that
are close, but, to my mind, not quite right.

> -----Original Message-----
> From: Even ,Roni [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 10:52 AM
> To: [email-masked]'
> Cc: 'Rosen, Brian'; 'Christian Groves'; 'Danny Levin'
> Subject: [Megaco] conferencing requirements
> 
> 
> 
> 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 MGC will be able to command the MG to support the conferencing modes
described in H.323 (reference) and SIP (reference)

> 	.	The MG will be able to signal the MGC about it 
> capabilities
> and limits.
The MGC shall be able to audit the MG to determine the capabilities
and capacity of the MG to support conferencing.
 
> 	.	Support for audio, video and T.120. 
Specific support for simultaneous audio, video and T.120 data conferencing
> 	.	Support dial-in and dial-out
[I believe this is a non-requirement; that is, the current protocol
defines mechanisms suitable to support physical dial in/dial out ports,
as well as mechanisms by which an MGC could support dial in/dial out
by combining a conferencing MG with a physical port MG]

> 	.	The system will be able to support a simple 
> conference where
> all participants must have a pre defined conference capability set.
[I might argue that this requirement doesn't really mean anything, at most
it could be]
Further requirements describe mechanisms to support complex functionality
conferencing systems.  A design goal shall be that simple fixed function
conference bridges shall be controllable with relatively simple, relatively
compact commands.
[My usual dictum in this regard is that simple things should be simple,
complicated things should be possible]

> 	.	The system will be able to support a conference 
> with dynamic
> conference capability set based on highest common.
[I think this is also a non-requirement; the interMGC signalling deals with
negotiation of capability, combined with the SDP negotiation of bearer.
The mechanisms we are discussing are built on that base]

> 	.	The system will be able to support a transcode 
> conference
> where the MGC will decide what codecs will be used in each connection
[also a non requirement, as I have indicated in another message] 
> 
> 
> 
> 
> 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.
A participant (termination) shall be controlled such that it
can:
	Listen to the main conference and any number of side
		conversations
	Talk in either the main conference or ONE side conversation

> 	.	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
[All above]
Each listener shall be able to control the level of each
talker individually
Each listener shall be able to control the level of the main
conference and each side conference in which it participates 
(sub master level)
Each listener shall be able to control the level of the
entire mix (master level)
It shall be possible to control an MG that only provides one
set of levels per conference with a minimum of messaging.

> 
> 
> 
> 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.
> 
Video mixing shall support a variety of different output views.
Each output view shall consist of a number of rectangular, non-overlapping
windows.  Each window contains a panned/scaled/cropped version of
an input stream. The package shall support an arbitrary MGC
defined window/view layout, although an implementation may only
support a finite set of predetermined layouts.

The package shall support a separate output view
for each participant, although an implementation may only support
one, or a limited number of output views.  Controls shall be
provided to specify which input streams are mapped to which windows.
The MGC shall be able to dynamically change this mapping.

The package shall support MG controlled switching of input streams
to windows based on talker volume.  The package shall support
mapping of a designated window to the loudest talker, or the
previous loudest talker.

[I don't think we need to discuss transcoding - the existing mechanisms
handle that]

Brian

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 23 Aug 2001 14:20:51 +1000

G'Day Brian and Roni,

A high level comment first. I think Brian that you are starting to move
from Requirement specification to protocol solution. I believe the
requirements as Roni has stated are fairly solution agnostic. Thus the
requirements remain despite the fact that they may already have a
protocol solution.

Once we have identified the requirements then we can probably group them
into functional groups. These functional groups could be the basis of a
packages. 

Specific comments below.

Christian

> and capacity of the MG to support conferencing.

[CHG] This is proposing a solution. It may be desirable also for the MGC
to signal the MG about the limits it should work in. Thus I think Roni's
description should remain.

> by combining a conferencing MG with a physical port MG]

[CHG] I believe this is still a requirement - it needs to be specified
how this is actually supported at some stage. Could isn't enough for
good interoperability.

> complicated things should be possible]

[CHG] A requirement worth stating - whether this is handled in the MGC
or MG is solution again.

> The mechanisms we are discussing are built on that base]

[CHG] As per above comments. Roni: what exactly is meant by highest
common? Is it the capbility that is used by the most number of
participants? There could be some interesting procedures that need to be
documented.

>         Talk in either the main conference or ONE side conversation

[CHG] Can the speaker talk in the main conference and a side
conversation? Can the speaker listen to only the side conversation?

> set of levels per conference with a minimum of messaging.

[CHG] I think these requirements are addition ones to Roni's. His are
very specific to what is available to the MGC. The above requirements
seem to be more related to the user.
> support a finite set of predetermined layouts.

[CHG] I think these are additional requirements to Roni's. I think the
shalls should be changed to mays.

> The MGC shall be able to dynamically change this mapping.

[CHG] I think its too early to talk about packages. I think the input
stream to window mapping is a worthwhile extra requirement.

> mapping of a designated window to the loudest talker, or the

[CHG] Again we can can probably strike "package".