Subject: [Megaco] Conferencing Requirements

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Aug 2001 06:22:51 -0400

Here is a start on a set of requirements I have:

First of all, I want to support multimedia bridges at the first release.
Secondly, I have listed a lot of "difficult" requirements below.  
I don't anticipate any bridge would do all of these, none are 
"mandatory to implement"; I want the controls designed to allow 
such capability to be controlled. 

Audio
    Support for multiple side conversations with conference monitoring
		Each participant may be a member of at most one side
			conversation as a talker, plus any number of side
			conversations as a listener.
		Each participant should be able to control the relative
			volumes of the main conference and any of the side
			conversations he monitors
		Side conversations must be able to include talkers and
			listeners who are not main conference participants
    Support for "floor control"
		The conference controller should have a way to designate
			the current talker (maybe more than one?)

Video
    Support for per participant choice of output format
		Each participant (potentially) sees a clipped, scaled
			and positioned view of each participant (including
himself)
		It may be most useful to have a set of views (up to one
			per participant), each of which is an overlayed set
			of output windows, each window being a
clipped/scaled/positioned
			view of a participant.  This allows systems with
limited
			numbers of views to be controlled.  A participant
would
			be connected to one such view. (I don't need
overlapped
			views, does anyone else need them?)
 Note: I think the basic termination capability of Megaco allows any input
codec and any output codec for each participant.  Thus we don't need 
additional requirements to support transcoding of audio or video.  The
scaling
operation discussed suffices to control line doubling, subsampling, etc.
Of course any specific bridge may have limits on such operations, which
would
have to be discoverable.

	Support for "video follows audio" controls
		This includes support for more than one output window, with
choices
		for last two talkers or two loudest talkers.  Probably need
some
		parameters to control such functions (for example, hold
time,
		threshold values, ...)

		I would be satisfied if instead of the MG doing everything,
that
		it provided events for "loudest" talker detection, with the
		MGC changing views in response to such events.  Others may
require
		the bridge to do the whole task.  We may have to support
both 
		models.
	
	Support for T.120 

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Aug 2001 15:21:14 -0400

> 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.
There is some value in identifying what we want to do with the result.
That is what Roni did.  However, they aren't really requirements.
What I wrote are requirements.
You can argue that I wrote them too narrowly, imposing the direction of
a solution.  Probably true, but maybe not so bad.

> 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.
Agree.  I didn't mean to imply anything about the structure of the packages.

> 
> Specific comments below.
> 
> Christian
> 
> "Rosen, Brian" wrote:
> > 
> > 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.
> 
> [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.
[br] I don't agree.  Megaco uses audit to determine capabilities
and limits, and there is no requirement to do something different.

> 
> > 
> > >       .       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]
> 
> [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.
[br] while there is room for someone to write a document on this, there
is no reason to require any extension to Megaco to accomplish this.
The mechanisms are already there, and should not be modified.
So, I think we are agreeing on principles, perhaps not in direction.
I don't think the IETF need write the document, which could be a
one line statement:

> 
> > 
> > >       .       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]
> 
> [CHG] A requirement worth stating - whether this is handled in the MGC
> or MG is solution again.
> 
> > 
> > >       .       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]
> 
> [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.
[br] I interpreted it as "highest common denominator", that is
the most complex operations that ALL participants can do.
I want the requirement to cover the case where each participant
gets the best possible result regardless of what other participants
can do.  For example, if two participants can do 6M MPEG II and
two can only do 384k H.263, then the two MPEG participants see
each other in high fidelity, while the other two see them in
lower fidelity.   This is all dependent, of course, on what the
MG can do.  Again, I think this is really only a function of the
codecs and not of the conferencing controls, and thus is already
possible.

> 
> > 
> > >       .       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
> 
> [CHG] Can the speaker talk in the main conference and a side
> conversation? Can the speaker listen to only the side conversation?
[br]I don't think it's practical to allow a talker to talk in both, but
if someone wants that possibility, I don't object.

The talker's listen side is not constrained - it has all the capabilities
of any listener.  Thus the speaker can listen to multiple side conversations
and the main 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.
> 
> [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.
[br] I think what I wrote covers all of what Roni wants, plus more.
They all refer to what the MGC can do (that is, in my terms,
the MGC can control the level of each talker at each listener 
termination).  So, for example, one way to implement this is to
have an array of levels, one per talker, on each listener, plus an
array of submasters, one per listener, plus an overall level per
listener at each termination.

> > 
> > >
> > >
> > >
> > > 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.
> 
> [CHG] I think these are additional requirements to Roni's. I think the
> shalls should be changed to mays.
[br] again, I think what I wrote covers all of what Roni wants, plus.
The shalls are what has to be defined in the package, not what the
MG has to implement.

> 
> > 
> > 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.
> 
> [CHG] I think its too early to talk about packages. I think the input
> stream to window mapping is a worthwhile extra requirement.
[br] I agree it's too soon to talk about packages. How about "It shall
be possible to support..."
> 
> > 
> > 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.
> 
> [CHG] Again we can can probably strike "package".
[br] Yes.
> 
> > 
> > [I don't think we need to discuss transcoding - the 
> existing mechanisms
> > handle that]

---

From: "Even ,Roni" <[email-masked]>
Date: Sun, 26 Aug 2001 21:47:18 +0200

Brian,
I like your rewrite. I will use it. 

As for dial in and dial out. there is an issue who allocates the dial in
numbers is it the MG or the MGC. There is a need to support different
services like dial out using one PRI line instead of the others. I think
that is what I mean about dial in and dial out support.

The conferencing types I used are for having a basic functionality as Danny
Levine asked and to make sure that when we build the packages we can support
all these modes, define the conference and to control it from the MGC

Regards
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 5:32 PM
To: 'Even ,Roni'; [email-masked]'
Subject: RE: [Megaco] conferencing requirements

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.

> must support. I would also like to divide it to base functionality and
> 	.	 The system will support all the conferencing modes as
The MGC will be able to command the MG to support the conferencing modes
described in H.323 (reference) and SIP (reference)

> 	.	Support for audio, video and T.120. 
Specific support for simultaneous audio, video and T.120 data conferencing
[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]

> 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]

> 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]

> where the MGC will decide what codecs will be used in each connection

> 	.	The level of the received audio will be available to the
> MGC.
[All above]

> 
> 
> 
> Video
> 
> 	.	Support video switching mode where each participant may
> 	.	Support video mute on outgoing and incoming directions.
> 
Each output view shall consist of a number of rectangular, non-overlapping

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

Brian

---

From: "Even ,Roni" <[email-masked]>
Date: Sun, 26 Aug 2001 21:47:22 +0200

Christian,

Highest common is to enable the conference to have a common mode the current
highest common denominator of all participants. For example, the conference
starts at 384 kbit/sec for audio and video using H.263 and G.722. A new
participant joins and he can only support 128 kbit/sec and G.711/H.261 the
conference will drop to 128kbit and G.711/H.261 (all participants) now this
party drops the conference will go back up to H.263 and G.722 at 384.

As for the requirements. I may have some English problem not my mother
tongue) I would like to see requirements that can be verified later against
the solution. I will rewrite the requirements and would like to start with
the architecture and to define the parameters we want to have before putting
them in packages. ( We will need a basic level and enhanced capabilities ,
what about having an audio bridge with the requirements to have a robust
support of side conferences)
regards
Roni Even

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 6:21 AM
To: Rosen, Brian
Cc: 'Even ,Roni'; [email-masked]'
Subject: Re: [Megaco] conferencing requirements

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.

[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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2001 14:40:39 -0400

I think Roni wants "best possible result that all can do"
and I want "best possible result for each individual participant".
I believe we can do both with current capability, and I'll
say again that a specific MG may not be able to do what I want.

I hope to have an MG that can :)

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 2:33 AM
> To: Even ,Roni
> Cc: Rosen, Brian; [email-masked]'
> Please see my comments below.
> 
> Christian
> 
> ..snip..
> > [RE] The transcoding conference is the mode for having each 
> user have the
> > best possible communication mode. I will add it to the 
> requirements text
> > 
> [CHG] What I was trying to get at is that there are different
> interpretations of highest common denominator. It may be that you
> require that each termination offer the highest service possible. or
> that it may be that you require the MG to choose the mode that most
> participants support (could be lower quality) to lessen the amount of
> transcoding you require.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2001 14:40:09 -0400

> [RE] I will try to have the right text. There is a question 
> who allocate
> dial in number in ISDN cases or URIs or conference names. Is 
> it the MGC or
> the MG
The MGC. A call comes it on a particular number.  The MGC 
knows what conference this number equates to.   The MG doesn't
know the number, it only knows the channel.  It can't figure out
what conference that channel is supposed to be connected to.
The MGC can.

> [RE] In order for the user to listen to more then one side 
> conference he
> needs to have more then one stream coming to him. Choosing 
> one is part of
> floor control. if he needs more then one stream coming to him 
> he needs to
> signal capability to get more then one audio stream (possible 
> in H.323, not
> in H.320 or SIP)

[BR] it isn't necessary for the listener to have more than one
stream coming to him to listen to more than one side conference.
What is necessary is that each participant in the conference
have a "custom" stream from the bridge.  You send one stream in,
you get one stream out.  Each output stream could have different 
contents/levels, etc.  There is of course a big signalling issue 
(how does the listener indicate to the MGC what he wants), but that 
is not a concern of Megaco.
> [RE] I think this is what I meant but I looked at it from MGC to MG
[BR] I agree, the MGC can set the level of each talker at each listener.
Think of this as a two dimensional array of level controls, summing to
a one dimensional vector of output streams.  The MGC can set each of
these levels (one per talker at each listener).

> [RE] I think this is part of floor control functionality , I 
> will add this
> one and the next ones but mention them as floor control. I 
> think the first
> one gives the tool to support these requirements
[BR] I don't understand what this has to do with floor control.
The older model was that there was ONE output from the bridge
which everyone gets.  I'm pushing a model where there is
one output from the bridge for every participant which is
different from every other participant.

The full level control gives you the two dimensional array of controls
described above

The submaster allows you to build a bridge that has less capability.
You get one level per main or side conference, not one level per
participant, but each listener gets to listen to as many side conversations
as he wants to.  This is also equivalent to a multitrack mix desk;
you get a submaster for each channel.

> [RE] I agree that you give more options. I need also support 
> for overlaid
> windows, for example a quad view with a window in the middle 
> overlaying the
> center part of the screen.
> I can write it this way but we will have to look at a good 
> way to describe
> this capability both in the MGC to MG as well as for the 
> participant control
> (how to describe the capability, currently there are some 
> predefined views
> in H.320 and H.323. The MCU needs to have a way to define the 
> view and list
> which party is in the view)
I was hoping to avoid non overlapping windows, but actually, the
descriptive part in the package doesn't change (it's just more
complicated to support in the general case).

One way to do it (yes Christian, this would be the answer, not
the requirement) would be to describe the input windows
as width/height, and the output viewports as x,y,width,height
You have one input window per participant.  Potentially,
you have one output viewport per input window per viewer.
You could possibly have separate "screens" that had
a set of mappings from window to viewport and select
between them, or just specify the mapping dynamically.
This is old 2D/3D computer graphics stuff from way back.
Of course, a given implementation could have limits on:
	how many input windows
	how many output viewports
	whether viewports are constant or variable
	whether the mapping from window to viewport was fixed
		or variable
An audit capabilities of the relevant properties would 
reveal this straighforwardly.