Subject: RE: [XCON] Comments on draft-evan-sipping-media-policy-requiremen ts-00

From: "Even, Roni" <[email-masked]>
Date: Thu, 4 Mar 2004 02:10:57 +0200

Eric,

see inline
Roni

*************************************
Roni Even

Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099
email:[email-masked]
*******************************************

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Thursday, March 04, 2004 12:00 AM
To: IETF XCON Discussion List (E-mail)
Subject: [XCON] Comments on draft-evan-sipping-media-policy-requirements-00

First and foremost, this is NOT a requirements document.  It proposes a
solution and then wraps requirements around that solution.

I will not comment on the solution.  I will, however, comment on the
requirements.  These are all in section 6.

   REQ-GP1: A participant MUST be able to specify its own unique
   topology.

OK, so long as we recognize this is a property of the protocol, not of the
media resource.  In fact, I would offer this as a requirement:  
RE: Is the sentence "The protocol must enable a participant to create his
own topology"

REQ-GP1': A media resource MUST be able to reject a policy request.

   REQ-GP2: It must be possible for a group of users to receive the same
   mix.  This mix may be a conference common mix.

Isn't this the definition of a conference?  I suppose that it is OK to spell
this out, in case someone forgot why we are here.

RE: I think this is a  more general requirement since it allows, for
example, to have two different mixes and each group will get a different
mix.

   REQ-GP3:It MUST be possible to dynamically modify the number of
   contributing streams associated with a mixer.

Is "number of contributing streams" the number of active talkers physically
in the mix, or the number of active talkers in the conference.  If it is the
latter, the requirement is OK, but needs to be clearer.  If it is the
former, then requirement is NOT OK.  What is the use case?

RE: It is the former, this is media policy and not conference policy. The
cases are: for audio - start with mixing the 3 loudest speakers and change
to mixing only 2 loudest. For video - start with a layout of 2x2 and move to
layout of 1.

Assuming the latter, how about:
REQ-GP3: It MUST be possible to dynamically set the size of the conference.
RE: this is conference policy

   REQ-GP4: It MUST be possible to define the mixing function for each
   participant in the conference.

This is written in the terms of the solution.  What is the requirement here?
RE: the requirement is that if there are 5 participants in the call each can
have a different combination of the mix of the other participants. It is
obvious for video where each participant may see different participants. You
could look at the video mix as two dimensional one is that each participant
may see window composed of n*m sub-windows where n and m are per
participant. The second dimension is that the content of each sub-window is
different for each participant. This enable the participants to force their
own view of the conference. the requirement is general since it may be used
for other media though I would see less use for it in audio

   REQ-GP6: It SHOULD be possible to send a participant multiple streams
   from one mixer.  This requirement is to enable support for end- point
   mixing.

NO.  REQ-GP6 is clearly out of scope for the charter of XCON.
This requirement for supporting end point mixing was there. I think that I
have to look back at how we defined a mixer to see if it from one mixer (I
think the framework define one mixer that receive all the same sources
(people video, audio, presentation video) and creates the specific streams
for each of the participants.

   REQ-GP7: It SHOULD be possible to define relationships between
   different mixers.  The relationships can be time synchronized such as
   specifying that the audio mixer and video mixer is a pair to
   establish lip-synchs.

NO!  This again is written in terms of the solution, not the requirement.
This is only a problem BECAUSE the solution is written in terms of DSP
resources.  The requirement is:

REQ-GP7: It MUST be possible to request synchronization between related
media streams.  [Don't forget REQ-GP1' -- the media resource can always say
it cannot do synchronization.]
RE: OK, I agree.

   REQ-GP8: It SHOULD be possible to define the number of different
   topologies and the number of streams in each of them that will be
   mixed in a mixer.  For example the conference will support only one
   video topology that will go to all the participants, the video
   topology will support 2x2 display, or each participant will be able
   to receive his own audio topology that will include up to 4
   contributing sources.

I do not understand this requirement at all.  Please elaborate.
RE: Since a mixer receives all the sources (see my answer for GP6) and may
create more then one different mix it must be possible to the participant to
limit the number of the different mixes allowed to be created. An example is
that I want to start a video conference and would like to limit the
conference to allow only one video mix for all the participants since I am
getting billed by the number of different mixes I use (mixing resource cost
money)

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon