[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
XCON WG                                                      C. Jennings
Internet-Draft                                             Cisco Systems
Expires: January 17, 2006                                       B. Rosen
                                                           July 16, 2005

                Media Conference Server Control for XCON

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Conference servers have many controls that change how the media is
   combined for the various conference participants.  It is necessary to
   describe these controls to the clients connected to a centralized
   conference, so that the clients can render a user interface and allow
   the user to manipulate them.

   This work is being discussed on the xcon@ietf.org mailing list.  This

Jennings & Rosen        Expires January 17, 2006                [Page 1]

Internet-Draft             Media Mixer Control                 July 2005

   draft has not changed since the 02 version.

Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   TODO Items . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Non Problems . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1  Templates  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2  Controls . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.3  Parameters . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.4  Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.5  Streams  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1  Simple Audio Example . . . . . . . . . . . . . . . . . . .  10
     6.2  Simple Audio Video Example . . . . . . . . . . . . . . . .  11
   7.   Types of Controls  . . . . . . . . . . . . . . . . . . . . .  14
     7.1  Strings  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.2  Integer  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.3  Boolean  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.4  Selection  . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.5  Multiple Selection . . . . . . . . . . . . . . . . . . . .  16
     7.6  Control Array  . . . . . . . . . . . . . . . . . . . . . .  16
     7.7  Layout . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.8  Panel  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   8.   Template Registry  . . . . . . . . . . . . . . . . . . . . .  17
   9.   IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10.  Security . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  18
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  18
     12.1   Normative References . . . . . . . . . . . . . . . . . .  18
     12.2   Informative References . . . . . . . . . . . . . . . . .  18
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  20

Jennings & Rosen        Expires January 17, 2006                [Page 2]

Internet-Draft             Media Mixer Control                 July 2005

1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [4].

2.  TODO Items

   Note - the issue of switching from presenter mode to Q and A mode
   (etc.) is essentially one of floor control?  Need much more on how
   MPCP and floor control work.

   Note - using panel for now - may later replace with media neutral
   term such as placement

3.  Introduction

   This work tries to solve the problem of how a conference participant
   should manipulate the media flow in a conference server.  It defines
   a protocol between the centralized conference server and the end
   user's software that manipulates the conference.  This protocol needs
   to be rich enough for a conference server to express what information
   it wants, yet simple enough to allow the client to render a useful
   user interface.  This work takes into account that real conference
   servers have constraints on what media flows are possible and that
   UIs have buttons, knobs, etc. that users manipulate.  The goal is for
   a conferencing end point made by one vendor to work with conference
   servers or conference systems made by other vendors.

   Someone wishing to create a conference uses CPCP (or some other
   means) to create a conference and obtain a Conference URI.  The
   conference creator can query the server to find out its media
   capabilities, information such as the set of templates that a server
   supports.  A template defines a type of conferencing service that a
   conference server can provide.  It includes what media streams can
   flow in and out of the conference, the roles that are possible in the
   conference, and most importantly, what controls a client can
   manipulate on the conference to affect the media mix.  A set of
   standardized templates that a server may support is defined, and in
   addition, conference servers that support the flow graphs work in
   TODO REF can dynamically define new templates.  Note that templates
   contain media specific information, so to know which templates are
   supported is also to know what media types are supported.  Each
   template lists a number of parameters that must be set to initialize
   the conference and can have limits imposed by the conference server.
   Parameters are typically maximum values that are hardware or software
   (or policy) hard limits that constrain what is possible in a
   conference.  Parameters can only be set when the conference is

Jennings & Rosen        Expires January 17, 2006                [Page 3]

Internet-Draft             Media Mixer Control                 July 2005

   instantiated and can not be changed after that.  For things that are
   changed as the conference progresses, controls are used.  The point
   of the parameters in the templates is simply to reduce the number of
   templates needed.

   The conference creator can then choose a template, populate the
   parameter values and upload using CPCP to the server.  If the chosen
   parameter values are acceptable to the server, the update is accepted
   and the media policy created.  If not, an error message indicating
   the failure is returned.

   The simplest template will have just a single role: Participant.  By
   default, each participant will join a conference as a Participant.
   More interesting templates will have multiple roles.  For example, a
   template might have two roles: Lecturer and Participant.  A template
   role definition will indicate if there can be more than one
   participant having that role.  For this example, there can be only
   one Lecturer but many Participants.

   The conference creator can assign roles to participants.  This can be
   done in advance of the conference or dynamically during the
   conference.  For example, the conference creator can assign the role
   of Lecturer in advance, if it is known.  When this participant joins
   the conference, they will be automatically assigned the role of
   Lecturer.  This is Conference Policy not Media Policy but it does
   relate to the templates.  The conference package TODO REF includes
   the Role of each participant in the conference.

   Once a conference starts, a participant can find out the media policy
   template.  They can also download the set of controls for each role
   they may assume during the conference.  This template may also have
   controls that allow a participant to control their view of/input to
   the conference.  These controls may be rendered to the participant,
   and any changes to the controls result in commands being sent to the
   conference server.  A template may define different controls for
   different roles.  For example, a Participant may have only a very
   small set of controls, a Lecturer a larger set, and the Floor Holder
   an even larger set.  If a participant's role changes during a
   conference, their set of controls may change, and the user interface
   needs to be updated accordingly.

   An advanced conference server may support the definition of custom
   templates using flow graphs.  If so, the conference policy will
   indicate this capability.  If it is supported, a conference creator
   may upload a flow graph using CPCP.  This flow graph will contain
   enough information for the conference server to create a custom
   template: it will contain stream level media mixing information and
   information about parameters, roles, controls, and support for floor

Jennings & Rosen        Expires January 17, 2006                [Page 4]

Internet-Draft             Media Mixer Control                 July 2005

   control.  If the server can process the flow graph and support the
   mixing defined by the template, the server returns a success
   response.  If it is not able, it returns an error indicating how the
   flow graph might be fixed.  A custom template created using flow
   graphs will be identical to the set of standardized templates - it
   will just have a different name, roles, parameters, controls, etc.
   The same methods that allow a participant to render an unknown
   standardized template will be used to render a custom template.

   Once a conference begins, the template and parameters are fixed and
   MAY NOT be manipulated during the conference.  As a result, flow
   graphs can only be uploaded prior to the start of the conference,
   although they could be downloaded by a participant during a
   conference using CPCP.  In general, however, flow graphs will only be
   used by the creator of the conference prior to the start of the

   A conference client can request the conference object from the focus.
   This allows the client to discover what the current media policy is
   and what controls it can manipulate.  The client can then send an
   update to the focus to change the controls to manipulate media policy
   for various participants.

   The conference has a set of physical streams that get contributed to
   the conference and a set of streams that are sent to the client.  The
   streams coming into the conference feed into an input stream group,
   and the streams coming out of a conference come from an output stream

   A template may define various logical stream lists.  For example, one
   video stream may contain video of the active presenter, and another
   video stream may have the presentation that the presenter is showing.
   Media from a participant is contributed to one of the input stream
   groups.  Various controls, such as gain, may be attached to each
   physical input stream, to logical stream groups, or to a top-level
   conference or sidebar.

   Each conference also has output stream groups that represent media
   being sent to the client.  Output streams to a client are named and
   may have complex controls that affect which streams are selected to
   contribute to the result.  Output streams may be formed using
   multiple input component streams.  This is typically done for video
   when the output is some composited form of the input component
   streams, but it can also be done for audio, e.g. when selecting
   multiple mono audio streams and defining how they are composited into
   a stereo stream.

Jennings & Rosen        Expires January 17, 2006                [Page 5]

Internet-Draft             Media Mixer Control                 July 2005

4.  Non Problems

   There are several topics that are completely internal to the
   conference systems and are out of scope of this work.  These include:
      how the focus manipulates the conference server
      how one describes what a conference server is capable of doing;
      managing resource allocation and how busy a given DSP is, and
      checking whether more work can be allocated to a media processor.

5.  Terminology

5.1  Templates

   TODO - one template instantiated per conference.  Changing a template
   is close to stopping a conference and starting a new one.

   A template defines a model for the reception, manipulation and
   transmission of streams.  A template provides enough information that
   the client can intelligently render a useful GUI to the end user to
   manipulate the model.  There is a registry of well known templates,
   but a conference server can define new ones.  A convener can find all
   the templates a conference server supports and select one to use when
   creating the conference.

   Templates contain a list of logical stream, input and output stream,
   roles for participants, and controls for the conference.

   A template for a very basic audio conference, for example, may
   indicate that there is one audio stream for each participant, and one
   output stream group named "main".  Each participant in the stream has
   a single binary control called "Mute".  There is only one Role that
   can be used, called "participant".

5.2  Controls

   Controls are variables in a conference object that participants may
   manipulate to control the media streams of the conference.  The
   Control has information about what type of inputs it accepts that
   help the client render a user interface.  Conferences can have
   controls, participants in a conference can have controls, and streams
   in a conference can have controls.  A control has a name, a value,
   and constraints on its value.  The controls that are available are
   defined in the template.

   A control can be defined as being part of a role.  In that case, all
   participants who assume that role have an instance of the control.  A
   control may also be defined as part of an input stream group, in

Jennings & Rosen        Expires January 17, 2006                [Page 6]

Internet-Draft             Media Mixer Control                 July 2005

   which case all contributors of that stream will have an instance of
   the control; or an output stream, in which case each output stream
   will have an instance of the control.  There can be global controls
   that change values for the whole conference.

   A control can be inside the template, participant, or stream group.
   The control will apply to the appropriate context.  By including
   stream definitions in multiple roles that have the same name,
   different controls can be provided to different roles affecting
   streams contributed or sunk from multiple roles.  For example, a
   moderator may be given a set of input volume controls controlling a
   mix, and every participant can be given an output master mix control
   for the output stream sent to him.

5.3  Parameters

   TODO - need better name for Parameters.  Perhaps Instantiation Values

   Parameters are variables in the template that are set when the
   conference is created.  The point of a Parameter is simply to reduce
   the number of templates required.  For example, in the audio
   conference, whether or not sidebars are supported might be a
   parameter.  The template can indicate the valid range for parameters.
   Parameters can also be used for an application instantiating a
   conference to limit what capabilities it will use.

   Parameters are variables that modify the function of the template.
   They are fixed when the conference object is instantiated and can not
   be changed after that.  Parameters allow a single template definition
   to describe a range of possible conference server capabilities.

   Parameters have a name, a type, a value and, optionally, a min and
   max value.

   The parameters in the templates customize a generic template for a
   specific conference.  Parameters have name, type, value, and
   optionally min/max.  Parameters are defined in the template
   description.  Only conveners can set template parameters.

   One typical template parameter is "max-sidebars".  When the CS
   generates the template for the client, it can customize the min and
   max value of this parameter to match what it is capable of, which
   might range from zero or one to infinite.  When the client
   instantiates the template and creates the conference, it can specify
   the value that has been requested.  The value typically represents
   the limits the conference server is capable of.  Resource
   availability may limit the actual value that can be achieved.

Jennings & Rosen        Expires January 17, 2006                [Page 7]

Internet-Draft             Media Mixer Control                 July 2005

   Parameter names are strings.

   Parameter Types:

   Values of course are constrained to the type.  Min and Max, if
   defined, also constrain the the value.

   TODO - need to be able to make the limits of controls be parameters.

5.4  Roles

   Participants in a conference can take on multiple different Roles
   that will change what controls they may manipulate and which media
   streams they have access to.  The template defines what Roles are
   available for the client.  Manipulation of Roles is not directly part
   of MPCP, but the various Roles that are possible are found in the
   template.  Some common roles include:

   OPEN ISSUE - decide if we want Role so a single participant can
   simultaneously have multiple roles

   Roles are defined as part of Conference Policy but are used here so
   that the Media Policy can define separate streams and controls
   depending on role.  Roles are defined by in the template.  Some
   templates may allow a participant to take on more than one role at a
   time.  Each template must define a role named "Participant", which is
   the default role.  "Moderator" is a typical role, but templates do
   not intrinsically define or require such roles.  A given user will
   only be able to access parts of the template that are not inside a
   Role or are inside a Role that the this user is a member of.

   Templates define all the Roles that a participant can take and
   (optionally) the max number of participants of each role.  Each role
   is defined in a role element.  A Role element includes a name and
   optionally a "max-participants" value.  Role elements may also
   contain stream elements, which define per-participant-in-role
   streams.  The first stream list of a given media type inside a Role
   is the default location for that type of media.

Jennings & Rosen        Expires January 17, 2006                [Page 8]

Internet-Draft             Media Mixer Control                 July 2005

5.5  Streams

   Streams correspond to a given flow of media.  They are named and can
   be selected by controls.  The conference package is used to
   understand the relationships between users or participants, dialog or
   session, and streams.

   The physical streams are the actual media streams sent and/or
   received by or on behalf of conference participants.  Media streams
   are typically established when conference participants join a
   conference and are described by the SDP media lines in the offer/
   answer exchange between the participants and the focus, or the
   analogous exchange in other protocols (ex: H.245 logical channel
   establishment).  Each stream is described by a media type, direction
   and at least one identifier.  Initially media types considered
   include audio, video or text.  (Other media types can also be
   considered in the future.)  The direction "in" corresponds to streams
   originating from the conference participants to the conference, and
   "out" for streams originating from the conference and terminating at
   the conference participants.  A stream-id is an integer assigned by
   the focus to each physical input and output stream.  This integer is
   unique to all streams in a specific conference (and all its sub-

   Logical streams are names that are defined in the template and can be
   used like other streams but correspond to some virtual stream that
   the conference is creating.  Logical streams often change dynamically
   and potentially very quickly during the lifetime of a conference.
   For example, one logical set is the set of input video streams
   corresponding to the current speaker or speakers.  Logical stream
   lists are discussed in more detail in the following section.

   Streams have types.  These correspond to the major MIME types of the
   media the stream carries.

   Audio Streams originate as participant contributions (dir is "in")
      that are mixed using some kind of algorithm.  Controls commonly
      available on audio streams include input or output faders (volume
      controls), stereo balance, and mute.
   Video Streams originate as participant contributions (dir is "in"),
      which are combined with some kind of algorithm.  Intermediate
      streams may be created, which are subsequently combined with other
      streams to yield streams that are sent to participants (dir is
      "out").  Controls commonly available on video streams might
      include selectors for choosing a tiling format, selectors that
      choose which input stream is rendered on an output tile, and video
      freeze and blank.

Jennings & Rosen        Expires January 17, 2006                [Page 9]

Internet-Draft             Media Mixer Control                 July 2005

   Text Streams originate as participant contributions (dir is "in")
      (Instant Messages).  Messages from all participants are combined
      using some algorithm.  Intermediate streams may be created, which
      are subsequently combined with other text streams to yield streams
      that are sent to participants (dir is "out").

   The stream id correlates the stream with a particular RTP session or
   media session for non RTP based media.  The client can learn the
   correlation of stream ID to the particular media streams it is
   sending by TBD (TODO could be subscribing to the conference package).

   A stream-id is an integer assigned by the focus to each physical
   input and output stream.  For RTP media, this corresponds to a single
   RTP session.  This integer is unique to all streams in a specific
   conference (and all its sub-conferences).

6.  Examples

6.1  Simple Audio Example

   The examples in this section will all be moved to XML, but to help
   make them easier to understand and focus on the semantics instead of
   the syntax, they are currently just some text with indentation
   representing containment.

   The client selects the basic audio template that looks like:

   Template BasicAudio
     PhysicalStream direction=input type=audio name=main-audio-in
        control type=bool name=mute label="Mute"

     PhysicalStream direction=output type=audio name=main-audio-out
        control type=real name=gain label="Volume"

   This templates defines that this conference has one input stream
   group called main-audio and one output stream group called main-
   audio.  There is a single control, called mute, for each physical
   input stream, and a gain for each output stream.

   After Alice and Bob have joined, the conference server informs Bob
   that the current state of the conference object is as shown in the
   xml below.

Jennings & Rosen        Expires January 17, 2006               [Page 10]

Internet-Draft             Media Mixer Control                 July 2005

   Conference BasicAudio
     PhysicalStream name=main-audio-in stream-id=1
        control bool mute=false

     PhysicalStream name=main-audio-out stream-id=3
        control bool mute=false

     PhysicalStream name=main-oudio-out stream-id=2
        control real gain=0.0

     PhysicalStream name=main-audio-out stream-id=4
        control real gain=0.0

   There are two participants, Alice and Bob, who both contribute input
   streams and receive output streams, and neither is muted.

   A key part of this is that Bob's client may have known about this
   basic audio template and what the semantics of the "mute" control
   implied.  The client may have connected this up with a button of the
   client's that was labeled mute.  On the other hand, Bob's client may
   not have known anything about this template and simply rendered a
   button on the screen and labeled it "mute" with no idea what this
   would do.  A third client may not have been able to deal with the
   control at all and may have just ignored it.  Clearly the user
   interface can be better if the client understands the semantics of
   what the template means, but the user interface is still functional
   when the client does not.

6.2  Simple Audio Video Example

   A more complex video example is given below.

Jennings & Rosen        Expires January 17, 2006               [Page 11]

Internet-Draft             Media Mixer Control                 July 2005

   Template basicAudioVideo
     LogicalStream type=video name=activeSpeaker-video
     LogicalStream type=video name=presenter-video
     LogicalStream type=video name=presentation-video

     Floor name=presenter-floor

     Control type=bool name=eCan label="Echo Cancelation"

     Role name=listener
        PhysicalStream direction=output type=audio name=main-audio-out
        PhysicalStream direction=output type=video name=main-video-out

     Role name=participant
       PhysicalStream direction=input type=audio name=main-audio-in
          Control type=bool name=mute label="Mute"
       PhysicalStream direction-input type=video name=main-video-in
          Control type=choice name=video-mute
       PhysicalStream direction-input type=video name=presentation
          Control type=choice name=video-mute
                  choices=" normal, blank, freeze"

      PhysicalStream direction=output type=audio name=main-audio-out
         Control type=real name=gain label="Volume"

      PhysicalStream direction=output type=video name=main-video-out

      Control name=main-laoyout type=layout choices=1x1,2x2,1x2,

        Control name=mainConfVolume type=real
        PhysicalStream direction=input type=audio name=side-audio-in
          control type=bool name=mute label="Mute"
        PhysicalStream direction=output type=audio name=side-audio-out
          control type=real name=gain label="Volume"

      Role name=moderator
        controllArray index=main-audio
          control type=bool name=mute label="Mute"

   This template has some logical streams that can be used for selecting
   in the layout.  It defines a control called eCan that applies to the
   whole conference.  It defines a Listener role that can only receive
   input and a Participant role.  There is also a moderator role that
   has everything a participant has along with an additional set of
   controls to mute any of the contributors to the main-audio.  The

Jennings & Rosen        Expires January 17, 2006               [Page 12]

Internet-Draft             Media Mixer Control                 July 2005

   participants share a single layout control that defines the video
   layout.  The conference supports sidebars but they can only have
   audio media.

   The instantiated value of the conference object for this might look

   ConferenceObject type=basicAudioVideo name=conf1234
    Role Participant
     PhysicalStream name=main-audio-in  stream-id=22
        Control name=mute value=false
     PhysicalStream name=main-video-in  stream-id=23
        Control name=video-mute value=normal
     PhysicalStream name=main-audio-out stream-id=24
        Control name=gain value=0
     PhysicalStream name=main-video-out stream-id=25

     PhysicalStream name=main-audio-in  stream-id=32
        Control name=mute value=false
     PhysicalStream name=main-video-in  stream-id=33
        Control name=video-mute value=normal
     PhysicalStream name=main-audio-out stream-id=34
        Control name=gain value=0
     PhysicalStream name=main-video-out stream-id=35

     PhysicalStream name=main-audio-in  stream-id=42
        Control name=mute value=false
     PhysicalStream name=main-video-in  stream-id=43
        Control name=video-mute value=normal
     PhysicalStream name=main-audio-out stream-id=44
        Control name=gain value=0
     PhysicalStream name=main-video-out stream-id=45

     Control name=main-layout value="3x1+16"
       Pannel input=presenter-video postion=1 selectionQ=0.8 exGrp=1
       Pannel input=presentation    postion=2 selectionQ=1.0 exGrp=1
       Pannel input=active-speaker  postion=3 selectionQ=0.9 exGrp=1
       Pannel input=main-video-in   postion=4 selectionQ=0.5 exGrp=2

   In the example above three participants have joined.  All the video
   participants are watching the same video composition, which has the
   presenter in position 1, the presentation in position 2, the active
   speaker in position 3; followed by all the video from participants
   contributed to the main input group.  The streams that are in the
   positions after the first three are not in the same exclusivity group
   as the first three, so streams could repeat even if they were being
   shown in the first three positions.  The active speaker position 3 is

Jennings & Rosen        Expires January 17, 2006               [Page 13]

Internet-Draft             Media Mixer Control                 July 2005

   in the same exclusion group as the presenter in position 1, so if the
   primary active speaker was the presenter, this would not be shown in
   position 3 and instead the previous active speaker would be shown.

7.  Types of Controls

   Controls need to collect information of several different types.  It
   should be possible to provide default values, a name for the control
   and text it displays, help text, control if a value is required, and
   control of whether or not the value is editable.  It should be
   possible to express constraints on the form an input can take by
   specifying a minimum or maximum for types where that makes sense, or
   specifying a regular expression that must be satisfied.  For numeric
   values in a constrained range, it should be possible to provide an
   increment value used by the control.  For strings it should be
   possible to indicate that they should not be displayed when they are
   entered for things like passwords.  These controls are necessary to
   make it possible to internationalize any text that is displayed to
   the user.

   There are control types for:
      Multi-line Strings
      Date Time
      Select Single
      Select Multiple
      Select Stream - TODO ADD THIS
      Layout - video layout object
      Panel - a portion of a Layout

   If an unknown control is encountered, it should be treated as a
   string type.  The <label> element controls what is displayed to the
   user and the <value> element contains the current setting of the
   control.  If set in the template definition, it represents the
   default value.  An optional <description> element provides some text
   that can be used as help text for the control.

7.1  Strings

   This is typically rendered as a text input field.

Jennings & Rosen        Expires January 17, 2006               [Page 14]

Internet-Draft             Media Mixer Control                 July 2005

   <control type="string" name="Host" private="true" >
      <label> Meeting Host </label>
      <description>Host for this weeks meeting</description>

   The "private" attribute indicates that the string should not be
   displayed as it is entered.

7.2  Integer

   This can be rendered as a slider or volume knob if it has a
   constrained range; otherwise it is a text field.  The text field may
   have increment or decrement buttons.

           <control type="integer" name="gain">
                   <label> Volume </label>
                   <range min="-18" max="6" increment="3"/>

7.3  Boolean

   This is typically rendered as a toggle button.

           <control type="boolean" name="mute">
                   <label> Mute </label>

7.4  Selection

   This is typically rendered as a pull down menu or as a radio button

Jennings & Rosen        Expires January 17, 2006               [Page 15]

Internet-Draft             Media Mixer Control                 July 2005

           <control type="select1" name="foo">
                   <label> the thing </label>

   The list of items that can be selected is contained in <item>
   elements.  Each item has a label that is displayed and a value that
   is returned when it is selected.

7.5  Multiple Selection

   This is typically rendered as a combo box or list.

   This is the same as a selection, except that the type is selected and
   the initial value is a space-separated list of values.

7.6  Control Array

   The control array is a way of defining a logical group with a
   variable number of related controls.  When the control array is
   defined in the template, it is associated with some group of streams.
   Then in n the actual conference object, there will be one instance of
   the control for each of the actual streams in the stream group.
   Inside the control array in the template is a single control.  A
   typical use of this would be to form a separate mute control for each
   of the audio stream correctly contributing to a conference.

7.7  Layout

   Layouts provide a control for compositing multiple video streams.  A
   layout uses several windows that each contain one video stream.  Each
   of these individual windows is referred to as a panel.  Generally the
   windows are rectangles arranged in some grid, but they do not have to
   be this way if the conference service has some other way of laying
   them out, such as warping them so they look like talking heads
   arranged in a circle.

   A layout control allows the selection of an enumerated type of
   layout.  This might include things like "2x1", "2x2", "5+1", "auto",
   "vendor X special layout 10".  Some of the layouts are well

Jennings & Rosen        Expires January 17, 2006               [Page 16]

Internet-Draft             Media Mixer Control                 July 2005

   understood, some may be customized.  There are also a number of
   panels that are being selected into this layout.  The layout will
   support some compositing of a number of streams, like 4 for a 2x2
   layout.  However, there may be more than 4 streams competing to get
   shown.  The first thing the layout group does is select which 4
   streams will get shown.  It then figures out where to display these
   streams in the layout.  Each panel inside the layout has a selection
   Q value.  This is used to order the streams to figure out if they
   will be selected or not.  Q values range from 0.0 to 1.0 and higher
   values are selected over lower values.  In addition, panels can be
   grouped into exclusion groups.  If an exclusion group has the same
   stream more than once, the type of the exclusion group will determine
   whether the stream is displayed once or twice.  If the exclusion
   group is set at no repeat, the repeat stream with the highest Q value
   is selected and the rest are removed from the selection set.

   Once the set of selected streams is formed, they need to be put in
   the appropriate place in the layout.  Each "window" in the layout has
   a position number.  Generally these increment left to right and then
   top to bottom.  If a panel sets its position attribute, then it gets
   that location in the layout.  For panels where the position is not
   set, the selected streams are sorted, with a the primary key of the
   position Q value and a secondary key of the selection Q value then
   placed into the remaining positions in this order.  The streams may
   be further ordered to minimize streams moving their location in the
   rendered output as the conference server sees fit.

   TODO - need to work back in way of dealing with exclusivity groups.
   Suggest using a exclusivity set value for each panel so that if two
   things have the same set value, they will not both display the same

7.8  Panel

   Panels are a control to select some streams to display in a layout.
   They are a control that can select any stream or list of streams in
   the conference, be they logical or physical.  They can select a
   specific physical stream using the stream id.  The client can
   correlate this with participants using the conference package.  They
   can select a stream out of a logical group such as "active-speaker".

8.  Template Registry

   An IANA registry will be created for commonly encountered template
   definitions.  This document will include some starter templates

   [Still need TODO this].

Jennings & Rosen        Expires January 17, 2006               [Page 17]

Internet-Draft             Media Mixer Control                 July 2005

9.  IANA

   TODO - will need template registry

10.  Security


11.  Acknowledgments

   Many thanks to Rohan Mahy, Nermeen Ishmail, Alan Johnson, Orit Levin,
   Roni Evin, and Lyndsay Campbell for many helpful comments.  Rohan in
   particular has spent a huge amount of time improving this document.
   Large chunks of text were contributed by Alan Johnson.

12.  References

12.1  Normative References

   [1]  Even, R., "Conferencing media policy requirements",
        draft-even-xcon-media-policy-requirements-00 (work in progress),
        June 2003.

   [2]  Boulton, C. and U. Chandra, "Media Policy Templates for XCON",
        draft-boulton-xcon-media-template-00 (work in progress),
        October 2004.

   [3]  Barnes, M. and C. Boulton, "A Framework and Data Model for
        Centralized Conferencingg", draft-barnes-xcon-framework-01 (work
        in progress), December 2004.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

12.2  Informative References

   [5]  Mahy, R. and N. Ismail, "Media Policy Manipulation in the
        Conference Policy Control Protocol",
        draft-mahy-xcon-media-policy-control-00 (work in progress),
        June 2003.

   [6]  Even, R., "Conferencing Scenarios",
        draft-even-xcon-conference-scenarios-00 (work in progress),
        June 2003.

   [7]  Rosenberg, J., "A Framework for Conferencing with the Session
        Initiation Protocol",
        draft-ietf-sipping-conferencing-framework-00 (work in progress),

Jennings & Rosen        Expires January 17, 2006               [Page 18]

Internet-Draft             Media Mixer Control                 July 2005

        May 2003.

Authors' Addresses

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   Mailstop SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 421 9990
   Email: fluffy@cisco.com

   Brian Rosen
   470 Conrad Dr.
   Mars, PA  16046

   Phone: +1 724 382 1051
   Email: br@brianrosen.net

Jennings & Rosen        Expires January 17, 2006               [Page 19]

Internet-Draft             Media Mixer Control                 July 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Jennings & Rosen        Expires January 17, 2006               [Page 20]