XCON WG C. Jennings
Internet-Draft Cisco Systems
Expires: August 9, 2004 B. Rosen
Marconi
February 9, 2004
Media Mixer Control for XCON
draft-jennings-xcon-media-control-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-Drafts.
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 http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Conference mixers have many controls that change how the media is
combined for each participant in the conference. There is a need to
describe these to the clients connected to the a centralized
conference so that the clients can render a user interface and allow
the user to manipulate them.
This work is very early and far from complete. This draft sketched
the outline of a solution for consideration. It is being discussed on
the xcon@ietf.org mailing list.
Jennings & Rosen Expires August 9, 2004 [Page 1]
Internet-Draft Media Mixer Control February 2004
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction to the Problem . . . . . . . . . . . . . . . . 4
2.1 Non Problems . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Semantic information in a Conference . . . . . . . . . . . . 5
3.2 The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Templates . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Introductory Example . . . . . . . . . . . . . . . . . . . . 6
4.1 Simple Audio . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Names and terminology . . . . . . . . . . . . . . . . . . . 8
5.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Participants . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1 Stream Types . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.2 Stream URLs . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.3 Stream Priority . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.3 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.4 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.5 Conference State . . . . . . . . . . . . . . . . . . . . . . 12
6.1.6 Transport Protocol . . . . . . . . . . . . . . . . . . . . . 13
6.2 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.3 Integer . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.4 Boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.5 Selection . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.6 Multiple Selection . . . . . . . . . . . . . . . . . . . . . 15
6.2.7 Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Audio Video Presentation . . . . . . . . . . . . . . . . . . 16
8. Template Registry . . . . . . . . . . . . . . . . . . . . . 17
9. Comparison to other solutions . . . . . . . . . . . . . . . 18
10. CPCP vs. MPCP vs. CCP vs. MCP . . . . . . . . . . . . . . . 18
11. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
Jennings & Rosen Expires August 9, 2004 [Page 2]
Internet-Draft Media Mixer Control February 2004
Normative References . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Jennings & Rosen Expires August 9, 2004 [Page 3]
Internet-Draft Media Mixer Control February 2004
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
2. Introduction to the Problem
This work tries to solve the problem of allowing a conference
participant to manipulate the media flow in a mixer. It defines a
protocol between the end user's software manipulating the conference
and the centralized conference mixer. This needs to be rich enough
for a mixer to express what information it wants from a mixer yet
simple enough to allow the client to render a useful user interface
to the user. This work takes into account that real mixers 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 mixers or
conference systems made by another vendor.
2.1 Non Problems
There are several topics that are completely internal to the
conference systems and are out of scope for this this work. These
include:
How the focus manipulates the mixer.
How one describes what a mixer is capable of doing.
3. Overview
When a conference is created, it is instantiated from a template. The
template describes what controls are available for the client to
manipulate the media. The conference also describes roles that the
client can take on, such as Moderator. The template can have
parameters that are set when it is instantiated to allow one template
to describe variations of similar flow models.
This document describes the templates and ways for the client to
understand and manipulate the media in the conference. It allows for
the following:
A conference consists of several participants and multiple streams
of media flowing between the participant and the mixer.
Sidebars are mini conferences that are just like conferences
Jennings & Rosen Expires August 9, 2004 [Page 4]
Internet-Draft Media Mixer Control February 2004
except that a sidebar cannot itself contain sidebars.
Clients can discover the template chosen for use in a conference,
and the Values of the parameters set for the conference
Clients can discover the available streams in a conference.
Clients can send media on a participant stream and receive media
and receive media on a mixer stream.
Clients can discover the Participants in a conference and their
role (this is more conference policy than media policy).
Clients can join a conference as a participant and assume a
particular role.
Conferences, Streams, and Participants can have controls that
manipulate the media sent and received.
The role of the participant will control what view of the
conference they have and which media streams they can manipulate.
3.1 Semantic information in a Conference
The conference has a list of Participants. Each Participant has a set
of Controls That he can manipulate. Each conference has a list of
sidebars. Each conference has a list of Streams. Each Stream has
attributes such as name, type, priority and list of contributing
participants.
3.2 The Protocol
The protocol between the client and the conference server allows the
client to get the semantic information in the conference, find out
when it changes, and make changes to it. It's probably something like
XCAP. [TODO add ref]
3.3 Templates
Templates define 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.
Jennings & Rosen Expires August 9, 2004 [Page 5]
Internet-Draft Media Mixer Control February 2004
A template for a very basic audio conference, for example, may
indicate that there is one audio stream for each participant, and one
output mixer stream named "primary". Each participant in the stream
has a single binary control called "Mute". There is only one Role
that can be used, called "participant".
3.4 Parameters
Parameters are variables in the template that are set when the
conference is created. For example, in the audio conference, the
maximum number of participants might be a parameter. If the value
was set to 10 when the conference is instantiated, then up to 10
participant streams can be accepted into the mixer. The template can
indicate the valid range for max number of participants, perhaps from
2 to 128.
3.5 Controls
Controls are variables participants may manipulate to control the
media streams of the conference. Conferences can have controls,
participants in a conference can have controls, and streams in a
conference can have controls. Controls can also be implicitly created
by stream action, for example a selector control based on the loudest
speaker. Controls have a name, and a value. Controls are defined in
the template.
3.6 Roles
Participants in a conference can take on different Roles that change
what ccontrols they may manipulate. The template defines what Roles
are available for the client. The moderator (which itself is a role)
can change the role of a particular participant.
4. Introductory Example
4.1 Simple Audio
The client selects the basic audio template that looks like:
<template name="basic-audio">
<parameter type="integer" name="max-participants"
min="2" max="128"/>
<role name="Participant">
<stream type="audio" dir="in" name="input[]" priority="1.0">
</stream>
<stream type="audio" dir="out" name="mix[]" priority="1.0">
<control type="boolean" name="mute"/>
</stream>
Jennings & Rosen Expires August 9, 2004 [Page 6]
Internet-Draft Media Mixer Control February 2004
</role>
</template>
The client retrieves this template and uses it to create a conference
where it sets the max-participants to 10. Alice and Bob join this
conference and the conference server tells Bob about the state of the
conference media. There is only one role "participamt". Each
participant contributes one input stream. There is also an output
stream per participant. There is a single control, called mute, for
each participant.
After Alice and Bob have joined, the conference server informs Bob
that the current state of the conference is as shown in the xml
below.
<conference type="basic-audio" name="Weekly Conference">
<parameter type="integer" name="max-participants"> 10
</parameter>
<role name="Participant"/>
<participant name="Alice" role="Participant">
<stream type="audio" dir="in" name="input[Alice]"
url="sip:alice22-audio-primary@cs.example.com"
priority="1.0"/>
<stream type="audio" dir="out" name="mix[Alice]"
url="sip:alice22-audio-primary@cs.example.com"
priority="1.0">
<control type="boolean" name="mute"
perm="readonly"> 0 </control>
</stream>
</participant>
<participant name="Bob" role="Participant">
<stream type="audio" dir="in" name="input[Bob]"
url="sip:bob5-audio-primary@cs.example.com"
priority="1.0"/>
<stream type="audio" dir="out" name="mix[Bob]"
url="sip:bob5-audio-primary@cs.example.com"
priority="1.0">
<control type="boolean" name="mute"
perm="readwrite"> 0 </control>
</stream>
</participant>
</conference>
There are two participants, Alice and Bob, who both contribute input
streams and receive Mix streams and neither is muted.
Bob's client decides to change the Mute state for its audio stream
and sends the following to the conference server to change the state
Jennings & Rosen Expires August 9, 2004 [Page 7]
Internet-Draft Media Mixer Control February 2004
of the conference.
<conference type="basic-audio" name="Weekly Conference">
<stream type="audio" dir = "out" name="mix[Bob]">
<control type="Boolean" name="mute"> 1
</control>
</stream>
</conference>
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 table 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.
5. Names and terminology
5.1 Templates
Templates contain a list of stream, roles for participants,
parameters that need to be set, and controls for the conference.
5.2 Participants
Participants are the logical user entities participating in a
conference.
5.3 Streams
The stream is a named stream of media. An example is a simple audio
conference with 6 participants and a mixer that mixes the loudest
three. Each participant contributes an input stream. There is a
single logical output stream, but every participant gets a "custom"
version of this stream, because, in normal mixers, each participants
can hear all inputs except his own. This is commonly referred to as
"mix-minus". If the output steam also has a control (mute), the
output streams for each participant may also vary depending on the
state of the control.
Streams all have a type, a name, a direction (in or out), one or more
URLs, and a priority. The URL is the source or sink of the stream.
The priority indicates how important this particular stream is to the
Jennings & Rosen Expires August 9, 2004 [Page 8]
Internet-Draft Media Mixer Control February 2004
conference and the type indicates the type of media carried in this
steam.
Streams have types. These correspond to the major MIME types of the
media they send.
5.3.1 Stream Types
5.3.1.1 Audio
Streams originate as participant contributions (dir="in") that are
mixed using some kind of algorithm. Intermediate streams may be
created, which are subsequently mixed with other streams yielding
streams which are sent to participants (dir="out"). Controls
commonly available on audio streams include input or output faders
(volume controls), stereo balance, and mute.
5.3.1.2 Video
Streams originate as participant contributions (dir="in") that are
combined with some kind of algorithm. Intermediate streams may be
created, which are subsequently combined with other streams yielding
streams which are sent to participants (dir="out"). Controls
commonly available on video streams might include selectors for
choosing a tiling format, selectors which input streams appear on
output tiles, and video mutes.
5.3.1.3 Text
Streams originate as participant contributions (dir="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 yielding streams which
are sent to participants (dir="out").
5.3.1.4 Application
At a minimal level, this consist of a URL that defines the
application. Many systems will simply update an http URL that fetches
an HTML page that shows the current presentation.
5.3.2 Stream URLs
Streams have URLs that specify the source or sink of the stream.
These would typically be a SIP, H323 or XMPP URL.
5.3.3 Stream Priority
Jennings & Rosen Expires August 9, 2004 [Page 9]
Internet-Draft Media Mixer Control February 2004
Streams have a priority from 0 to 1. Zero indicates that a client, by
default, should not play/display this stream unless the user
specifically requests it. A priority of 1 indicates that, by default,
the client should render this stream and should warn the user if it
cannot. Other values only define an ordering, and clients should
attempt to use their resources to display the higher priority streams
before the lower.
5.4 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, as is
"Floor-Holder", but templates do not intrinsically define or require
such roles.
5.5 Controls
Controls manipulate the state of the conference while it is
instantiated. All controls have a name, a type, a current value and
permissions that indicate whether or not the current client can
modify them. They may also have, optionally, a min and max value.
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 a stream, in which case all
contributors of that stream (dir="in") have an instance of the
control, or all sinks of the stream (dir="out") have an instance of
the control. There can be global controls, which are available to
all participants. Implicit controls extract values from streams (or
other controls), such as choosing video inputs based on loudest
speakers
5.6 Parameters
Parameters are variables that modify the function of the template.
They are fixed when the conference is instantiated. Parameters allow
a single template definition to describe a range of possible mixer
capabilities.
Parameters have a name, a type, a value and, optionally, a mix and
max value.
6. Solution
Jennings & Rosen Expires August 9, 2004 [Page 10]
Internet-Draft Media Mixer Control February 2004
6.1 Templates
A template is an xml document. The template definition includes a
name, which is a string, for example:
<template name="audio-basic">
6.1.1 Parameters
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-participants". 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. 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 mixer is capable of. Resource availability
may limit the actual value that can be achieved.
Parameter names are strings.
Parameter Types:
Integer
Real
Enumeration
String
Values of course must be conformant to the type. Min and Max, if
defined, must also be conformant to the declared type.
Example:
<parameter name="Master Volume", type="integer", min="0",
max="100">75</parameter>
6.1.2 Roles
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
Jennings & Rosen Expires August 9, 2004 [Page 11]
Internet-Draft Media Mixer Control February 2004
contain stream elements, which define per-participant-in-role
streams.
Example:
<role name="moderator" max-participants="1" />
6.1.3 Streams
Templates also define all the streams available. A stream element has
a name, a type, a direction ("in" or "out"), priority and URL.
Certain streams may actually be a set of streams, for example, one
per participant. A specific member of the set can be referenced
using an array notation with square brackets. For example, if an
input stream is available named foo, and there is a participant named
"Bob", then foo["Bob"] would be the name of the foo stream Bob
contributes. If a stream is defined within a role element, the stream
is a set of streams, one per participant in the role. If a stream is
defined in more than one role with the same name, the stream set is
the same, and participants in any roles that have that stream defined
with that name contribute/sink a stream to the set.
The URL is typically not given a value in the template definition.
The mixer assigns URL values as participants assume roles. Most
implementations would not allow the URL to be changed by the media
policy mechanism. The value of the URL would be included in the
media policy conference state document.
Example:
<stream name="input-audio" type="audio" dir="in" priority="1.0" >
6.1.4 Controls
A control can be inside the template, participant, or stream. 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
6.1.5 Conference State
Conference state can be requested by any participant. A document
will be returned elucidating the complete current conference state,
which would contain all the participants, all the streams, and the
Jennings & Rosen Expires August 9, 2004 [Page 12]
Internet-Draft Media Mixer Control February 2004
values of all the controls. The form of the document mirrors the
template definition. The conference can also contain sidebars.
6.1.5.1 Conference State Update
The client can attempt to change the state of various controls in the
CS by sending a document that contains just the things it wants to
change.
6.1.5.2 Change Notification
The client can request that conference state be automatically sent
when it changes.
6.1.6 Transport Protocol
TODO: Need to define how the information is sent between the client
and the conference server. XCAP?
6.2 Controls
6.2.1 Requirements
Controls need to collect information. This can be classified into
several 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. Need the
ability to internationalize any text that is displayed to the user.
There are control types for:
Strings
Multi-line Strings
Integer
Real
Boolean
Jennings & Rosen Expires August 9, 2004 [Page 13]
Internet-Draft Media Mixer Control February 2004
Date
Time
Date Time
URI
File Selection
Select Single
Select Multiple
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.
6.2.2 Strings
This is typically rendered as a text input field.
<control type="string" name="Host" private="true" >
<label> Meeting Host </label>
<value>Richard</value>
<description>Host for this weeks meeting</description>
<regex>.*[rR].*</regex>
</control>
The "private" attribute indicates that the string should not be
displayed as it is entered.
6.2.3 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>
<value>0</value>
<range min="-18" max="6" increment="3"/>
</control>
Jennings & Rosen Expires August 9, 2004 [Page 14]
Internet-Draft Media Mixer Control February 2004
6.2.4 Boolean
This is typically rendered as a toggle button.
<control type="boolean" name="mute">
<label> Mute </label>
<value>True</value>
</control>
6.2.5 Selection
This is typically rendered as a pull down menu or as a radio button
box.
<control type="select1" name="foo">
<label> the thing </label>
<value>2</value>
<item>
<label>one</label>
<value>1</value>
</item>
<item>
<label>two</label>
<value>2</value>
</item>
</control>
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.
6.2.6 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.
6.2.7 Frame
Provides a hint to groups of controls. Uis are NOT constrained to
follow the frame construct.
<frame name="Address">
<control type="string" name="addr" private="true" >
<label> Street Address </label>
<regex>.*[rR].*</regex>
Jennings & Rosen Expires August 9, 2004 [Page 15]
Internet-Draft Media Mixer Control February 2004
</control>
<control type="string" name="city" private="true" >
<label> City </label>
<regex>.*[rR].*</regex>
</control>
<control type="string" name="state" private="true" >
<label> State </label>
<regex>.*[rR].*</regex>
</control>
</frame>
7. Examples
7.1 Audio Video Presentation
The following is a more complex template with bits of text explaining
it:
In this template, there are three roles, Participant, Presenter and
Moderator. There is an input and output audio stream for each role.
All roles have mute and master volume controls for their outputs.
The moderator has input controls for each input.
The video presentation is "Hollywood Squares". Each role contributes
one video stream. The moderator can select the presentation (tile
format) from an enumeration. All viewers see the same output
presentation.
Finally, there is an application sharing channel which is provided by
the Presenter, and received by all roles.
<template name="audio-video-presentation">
<parameter type="integer" name="max-participants"
min="2" max="16"/>
<role name="Participant">
<parameter type="integer" name="max-participants"
min="0" max="16"/>
<stream type="audio" name="AudioIn" dir="in"/>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out"/>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
Jennings & Rosen Expires August 9, 2004 [Page 16]
Internet-Draft Media Mixer Control February 2004
<role name="Presenter">
<parameter type="integer" name="max-participants"
min="0" max="16"/>
<stream type="audio" name="AudioIn" dir="in"/>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out"/>
<stream type="application" name="AppShareIn" dir="in"/>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
<role name="Moderator">
<parameter type="integer" name="max-participants"
min="0" max="1"/>
<stream type="audio" name="AudioIn" dir="in">
<control type="real" name="gain"
min="-18" max="+6" note="Input Gain in DB"/>
</stream>
<stream type="video" name="VideoIn" dir="in"/>
<stream type="video" name="VideoOut" dir="out">
<control type=selector name="Tile Format">
<item name="1x1" value="0"/>
<item name="2x1" value="1"/>
<item name="2x2" value="2"/>
<item name="3x3" value="3"/>
<item name="4x4" value="4"/>
</control>
<stream type="application" name="AppShare" dir="out"/>
<stream type="audio" name="MixOut" dir="out">
<control type="binary" name="mute"/>
<control type="real" name="master"
min="-18" max="+6" note="Master Gain in DB"/>
</stream>
</role>
</template>
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 August 9, 2004 [Page 17]
Internet-Draft Media Mixer Control February 2004
9. Comparison to other solutions
[TODO]
10. CPCP vs. MPCP vs. CCP vs. MCP
What is the boundary between conference control, media control, and
policy control for both of them.
11. IANA
12. Security
13. Acknowledgments
Many thanks to Nermeen Ishmail and Rohan Mahy
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Informative References
[3] 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.
[4] Even, R., "Conferencing Scenarios",
draft-even-xcon-conference-scenarios-00 (work in progress), June
2003.
[5] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in progress),
May 2003.
Jennings & Rosen Expires August 9, 2004 [Page 18]
Internet-Draft Media Mixer Control February 2004
Authors' Addresses
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Brian Rosen
Marconi
2000 Marconi Drive
Warrendale, PA 15086
USA
Phone: +1 724 742 6826
EMail: brian.rosen@marconi.com
Jennings & Rosen Expires August 9, 2004 [Page 19]
Internet-Draft Media Mixer Control February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jennings & Rosen Expires August 9, 2004 [Page 20]
Internet-Draft Media Mixer Control February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings & Rosen Expires August 9, 2004 [Page 21]