Subject: RE: [Megaco] conferencing requirements

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

Hi,
See my comments in  the text
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 9:21 PM
To: 'Christian Groves'
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.
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.
[RE] I think that the MGC shall be able to audit and the MG will be able to
signal changes in capabilities and limits. I will have two requirements

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

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

[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

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

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

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

[RE] I think this is what I meant but I looked at it from MGC to MG

> > Each listener shall be able to control the level of the main
> > conference and each side conference in which it participates
> > (sub master level)

[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

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

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

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

[RE] I forgot about being able to send the mapping of streams to windows. I
will add it
> 
> > 
> > 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.

[RE] I think that this is in my first video requirement. Maybe except being
able to have the MG do it without MGC command and just report the switch. I
will add it
> 
> > 
> > [I don't think we need to discuss transcoding - the 
> existing mechanisms
> > handle that]

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Aug 2001 16:32:50 +1000

G'Day Brian and Roni,

Please see my comments below.

Christian

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