XCON BOF R. Mahy
Internet-Draft N. Ismail
Expires: December 22, 2003 Cisco Systems, Inc.
June 23, 2003
Media Policy Manipulation in the Conference Policy Control Protocol
draft-mahy-xcon-media-policy-control-00.txt
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 December 22, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The SIP conferencing framework defines a model for tightly-coupled
conferencing signaled via the Session Initiation Protocol (SIP), in
which a Conference Policy Control Protocol is used to manipulate
policies relevant to a specific conference, such as conference
membership policy, authorization policy, and media layout. This
document describes a logical model, which can apply to any session
setup protocol, to describe media processing in a tightly-coupled
conference. It also defines specific protocol semantics and a
specific syntax to manipulate that model.
Mahy & Ismail Expires December 22, 2003 [Page 1]
Internet-Draft XCON Media Policy June 2003
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Groups and Bundles . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Collections . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Using these Elements . . . . . . . . . . . . . . . . . . . . . 8
3. Some Standard Operators . . . . . . . . . . . . . . . . . . . 10
4. More about Collections . . . . . . . . . . . . . . . . . . . . 14
4.1 The Basic Audio Collection . . . . . . . . . . . . . . . . . . 15
4.2 Basic Video MP Collection . . . . . . . . . . . . . . . . . . 16
4.3 Basic Audio Collection with Floor Control . . . . . . . . . . 17
4.4 Basic Video Collection with Floor Control . . . . . . . . . . 18
4.5 Sidebar Audio Collection . . . . . . . . . . . . . . . . . . . 19
5. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Notifications of media policy changes . . . . . . . . . . . . 23
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
Normative References . . . . . . . . . . . . . . . . . . . . . 31
Informational References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
A. Standard Tile Order . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 34
Mahy & Ismail Expires December 22, 2003 [Page 2]
Internet-Draft XCON Media Policy June 2003
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. Overview
The SIP conferencing framework [13] defines a model for
tightly-coupled conferences setup via SIP [8], in which a Conference
Policy Control Protocol is used to manipulate policies which are
relevant to a specific conference instance, such as conference
membership policy, authorization policy, and media layout. (As
discussed later, the bulk of this model is applicable to
tightly-coupled conferences accessed using almost any session setup
protocol.) While the conference policy control protocol provides many
non-media specific functions [4] such as membership policy and
authorization policy, this document specifically addresses
requirements [3] to manipulate the way in which media in such a
conference is selected, combined, and modified. It defines a logical
model of media processing using a "media topology graph". By
manipulating the graph, authorized users can change the media
processing behavior of the mixers associated with a specific
conference.
Here we will briefly summarize the terminology used in SIP
conferencing framework in protocol-inspecific terms. Each
"conference" is an instance of a multi-media conversation which has a
unique protocol-specific identifier. Other (optional) identifiers
can represent a conference-factory (an identifier which creates new
conferences when contacted). Conferences can contain
sub-conferences, which have a unique identifier within the
conference, and optionally a unique, protocol-specific, external
identifier as well. Each conference identifier is managed by a
logical role called a focus, which manages session state for all
sessions in the conference. The focus is responsible for
coordinating media combining through logical mixers. Mixers perform
the actual selection and combination operations. A logical
Conference Policy server manages creation and deletion of
conferences, authorization, conference longevity, and the media
layout or topology. In addition, the focus can use protocol-specific
notification mechanisms to provide access to a basic roster and
changes in media or non-media aspects of conference policy. Finally,
the conference policy may be configured such that mixers use the
information returned dynamically by Floor control server(s) to affect
media selection.
A media topology graph is a loop-free graph which consists of
Mahy & Ismail Expires December 22, 2003 [Page 3]
Internet-Draft XCON Media Policy June 2003
individual media streams, logical groups of media streams, and
functions or "operations" performed on those streams. These elements
are typically associated with a specific subconference. A
subconference simply defines a context which allows different groups
of users to share a media topology and participant roster with a
subset of the participants in a conference. Subconferences are
defined in the conferencing framework, and are typically used to
enable conferencing sidebars. For convenience purposes,
subgraphs--called collections--of connected operators can be defined,
instantiated, and manipulated just like individual elements. These
elements and their properties are described below.
2.1 Streams
In the beginning there were Streams. These 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 [9]
media lines in the offer/answer [10] exchange between the
participants and the focus, or the analogous exchange in other
protocols (ex: H.245 [12] logical channel establishment). Within the
media topology graph, 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 participant. Stream identifiers can be
network identifiers or aliases. Network identifiers consist of an
address family (IPv4 or IPv6), an IP address, and a port number.
Aliases can also be created for any of the streams, either
automatically or when created manually. One such automatic alias
consists of a participant identifier and a media stream instance (for
example, in SDP, either the media stream identification "mid" as
specified in RFC3388 [11] or the position of the media line
describing the stream in SDP). Another set of automatic aliases can
be created automatically when per media line i-lines (description
lines) appear in the SDP.
Conference Policy servers provide clients with lists of stream
descriptions as part of protocol-specific notification mechanisms
such as the SIP conference package [15] and in response to inventory
requests as specified in Section 5.3. Clients use the stream
identifier that is part of a stream description to associate and
connect (or disconnect) a specific stream with a specific group.
(Stream identifiers also play an important role in the naming of the
logical internal streams which make up the "bundles" described later
Mahy & Ismail Expires December 22, 2003 [Page 4]
Internet-Draft XCON Media Policy June 2003
in this section.)
Editors Note: The distinction between external streams and
internal (logical) streams may be confusing. If this becomes a
problem, one or both terms will be renamed.
2.2 Groups and Bundles
Media groups (hereafter just "groups") are created automatically by
servers within the context of a sub-conference as specified in
Section 5.3 and have a media type and a direction. Input groups
take individual streams and aggregate them into a bundle of named
streams. Likewise, output groups accept a bundle of named streams,
and distribute these as appropriate to individual output streams.
One motivation for naming streams in a bundle is described shortly.
Also, the process used to distribute output streams is described in
the server behavior section. Groups do not connect directly to other
groups.
Bundles are a logical concept which represent a set of individually
tagged (named) logical streams. Input bundles contain tags which
describe which identifier or participant is contributing to a logical
stream. Output bundles contain tags which describe which identifiers
or participants should receive a logical stream. This distinction
allows participants to receive different streams even when their
logical description of the topology is the same. For example, in
most audio conferences participants do not hear their own input.
Most output bundles also contain a default logical stream.
2.3 Operators
Next are Operators. Operators are basic elements that perform simple
media operations. They select among media streams, combine streams,
or perform other media processing. Each operator has a type, one or
more inputs, one logical output, and an optional set of parameters.
The type uniquely identifies the operator and specifies the media
service offered.
Selection operators typically accept an input bundle and generate an
ordered Set of names of logical streams. These sets can be further
manipulated by other operators, but typically they are used as input
to a mixing or combining operator. Mixing operators typically
receive an input bundle and an ordered list and generate an output
bundle. Obviously at least one mixer in the topology graph must be
present which can switch the orientation of the streams. Other types
of mixers may receive one or more output bundles, perform the
appropriate content manipulation, and return a bundle which preserves
Mahy & Ismail Expires December 22, 2003 [Page 5]
Internet-Draft XCON Media Policy June 2003
the sense of the original tags.
For example, the simplest type of mixer is a promiscuous media mux.
It receives an input bundle and generates a bundle consisting of a
single default stream (all of the original streams appended to each
other). In another simple variation, a media mux generates a named
output stream in the output bundle which contains all the other
output except that of the sender, for each named input stream in the
input bundle. Most mixing operations actually combine input streams
in some media-specific way (for example: tiling for video). Other
types of operators can provide other arbitrary media or set
manipulations such as adjust volume, cross-fade, etc. Operators
cannot connect directly to input or output streams. Each type of
operator defines the semantics of the operation and any parameters.
Parameters define aspects of the operator's function that can differ
from one instance of the operator to another.
This document defines a set of standard operators (see Section 3 ).
Each standard operator has a unique type registered with IANA and an
XML schema describing the operator. Server implementations can
support any of the set of standard operators. As well, implementors
can define their own operators and operator types. Clients can
discover which operators are supported by making inventory requests
to the Server. Authorized clients can then instantiate operators
using the method specified in Section 5.2.
2.4 Collections
Finally there are Collections. Collections are subgraphs created by
connecting different operators together. Each collection can provide
a specific, potentially sophisticated, media service. Like
operators, a collection has a type that uniquely identifies it and
specifies its function. Each collection has one or more inputs, one
logical output and an optional set of parameters. As with operators,
this specification defines a set of standard collections that offer
the most common mixing and switching media functions available. Each
standard collection has a unique type that will be registered with
IANA and an XML schema describing the collection. Server
implementations can support any of the set of standard collections
and they can also define their own proprietary collections. Each
newly defined collection needs a unique type and a published XML
schema. Clients can make inventory requests to Servers to get the set
of collections supported by the server. Clients can then instantiate
collections using the method specified in Section 5.2. Clients can
also make their own collections to provide new media services by
using the method specified in Section 4.
Below follows an example diagram of a media topology graph for a
Mahy & Ismail Expires December 22, 2003 [Page 6]
Internet-Draft XCON Media Policy June 2003
simple audio conference using the default audio collection.
Input Streams
A B C D E
| | | | |
| | | | |
v v v v v
+----------------------------------+
| |
| Subconference 0 (Main conf) |
| Audio Input Group |
| |
+----------------------------------+
||
\/
.............................................
: || || :
: Input || Input || :
: Bundle || Bundle || :
: || \/ :
: || +-------------+ :
: || | Speaker | :
: || | Selection | :
: || | Operator | :
Default : || | | :
Audio : || +-------------+ :
Collec- : || / :
tion : || / Ordered List of :
: \/ / Speakers :
: +---------------+ :
: | Audio | :
: | MixMinus | :
: | Operator | :
: | | :
: +---------------+ :
: || :
: || Output Bundle :
: \/ :
.............................................
||
\/
+----------------------------------+
| |
| Subconference 0 (Main conf) |
| Audio Input Group |
| |
Mahy & Ismail Expires December 22, 2003 [Page 7]
Internet-Draft XCON Media Policy June 2003
+----------------------------------+
| | | | |
| | | | |
v v v v v
A B C D E
Output Streams
2.5 Using these Elements
This document defines numerous standard operators (in Section 3) to
facilitate interoperability. Implementors are free to extend this
list of operators, and an IANA registration process is defined for
this purpose. Note that specific conference servers may (MAY) support
as few or as many operators as they choose, however each conference
server needs to (MUST) support at least one standard collection per
media type (these are defined in Section 4) which the conference
server is capable of handling.
Media manipulation is generally media-specific. When a subconference
is created, an input group and an output group are automatically
created for each media type supported by the conference server, and a
specific collection can be instantiated (again, for each media type).
Once instantiated, collections are simply a subgraph of operators
connected in some specific way. The resulting graph can be modified,
attached, detached, and deleted without affecting the collection from
which the graph was copied. Note also that more than one collection
can be incorporated into the topology graph for a given subconference
and media type.
Manipulating the topology graph for a tightly-coupled conference
enables a number of useful features, many of which are described in
the XCON scenarios [16] and SIP conferencing high-level requirements
[14] documents.
For example, noisy participants can be "muted" from a conference by
disconnecting their audio from the appropriate input group.
Participants can be moved to a sidebar by disconnecting their media
streams (some or all of them) and reconnecting them to the input and
output groups created for the corresponding subconference.
Interaction with floor control [17] is coordinated by including an
operator which selects only media streams corresponding to
participants who have the appropriate floor. The resulting logical
output stream or group of streams can be connected to a suitable
filtering, mixing, or combining operator (for example tiling for
video).
Mahy & Ismail Expires December 22, 2003 [Page 8]
Internet-Draft XCON Media Policy June 2003
Obviously, authorization is required to allow manipulation of media
topology by multiple parties (participants and non-participants
alike). The effects of manipulating the media topology graph can
range from simple, benign changes which only affect the participant
requesting the change, to complete failure of the conference. Clearly
no one-size-fits-all policy can be applied. However it is useful to
recognize several different categories or severities of impact.
o connecting and disconnecting your own streams to a group
o connecting and disconnecting another participants streams
o creating subconferences
o instantiating arbitrary operators or collections
o connecting and disconnecting operators and collections to your own
groups
o connecting and disconnecting operators and collections which
affect an existing conference or subconference
The rest of the functions of the Conference Policy Control Protocol
(CPCP for brevity) are mostly orthogonal to media manipulation and so
they are described in a separate document [4]. However it is
important to mention the interaction between the media
topology-specific and other aspects of the policy. Conferences and
subconferences can be created and deleted by CPCP. Although not
topology dependent, when these are created the media topology will
change automatically to reflect this. Also, one participant may wish
to invite several other participants to a subconference (sidebar),
but the initiating participant may not have permission to change the
stream connection properties of all of the participants. In this
case, the initiator places the participant in a pending state. This
informs the participant that the initiator would like the participant
to join the sidebar. Then the participant (or an agent acting on his
or her behalf) either makes the requested change to the media
topology by connecting his or her streams to the appropriate groups
(a media topology task), or removes himself or herself from the
pending list (a non-media related task). Finally, in many cases
authorized users can set authorization policy related to a variety of
aspects of conference policy. While setting these policies is
non-media related, many uses of these policies do affect the media
topology. Note that because of this separation, it is possible to
produce an implementation of CPCP which runs on two separate servers,
one responsible for media topology and the other responsible for the
balance of conference policy functions.
Mahy & Ismail Expires December 22, 2003 [Page 9]
Internet-Draft XCON Media Policy June 2003
3. Some Standard Operators
This sections specifies a set of operators that are needed to provide
the most common media processing operators used in conferencing
today. Each operator performs a specific function. Each type of
operator is registerd with IANA and has an XML Schema [7] that
defines how to use the operator. Server implementations are free to
support any number of these operators (or none of them) as well as
define their own operators.
The operators described below are logical operators which are useful
for describing conference features. Implementations may use any
internal representation which generates externally identical
functionality. The formal syntax for using these operators is
described in Section 6.
The "audioSelectSpeakers" operator takes an audio input bundle and
generates an ordered list of names of streams. This list is ordered
by the priority for including them in an audio mix. No specific
algorithm is specified for selecting which speakers are the "best",
but commercial implementations typically use a combination of last,
loudest, and longest speakers. The actual list of selected speakers
is dynamically calculated by a conference mixer. A generically vague
definition was intentionally chosen to allow most implementations to
offer this operator.
The "audioMixMinus" operator takes an audio input bundle and an
ordered list of names of streams and generates an audio output
bundle. It selects the first <n> of the streams from the ordered
list, where <n> is an implementation-specific integer. The output
bundle contains a default stream (which mixes all <n> logical
streams) and one logical stream for each stream present in the
original input bundle which contains a mix of all <n> logical streams
except for input streams corresponding to the same participant as
that output stream. In general this property of a mixer is called an
exclusive property because it causes participant ouputs to be
excluded from their own inputs. With these two operators, you can
build the default audio collection described in Section 4.1 and
illustrated in the figure in Section 2.4.
The "allParticipantsSet" operator takes an input bundle and generates
an unordered list of all the stream names which could conceivably
contribute to that bundle.
The "videoSelectSpeakers" operator takes an audio input bundle (to
determine who is speaking) and generates an ordered list of names of
streams. This list is ordered by the priority for including any
corresponding video streams in a video mix. Note that at a given
Mahy & Ismail Expires December 22, 2003 [Page 10]
Internet-Draft XCON Media Policy June 2003
instant the output of videoSelectSpeakers and audioSelectSpeakers may
be different. For example, video speaker selection algorithms
typically delay their selection to avoid swapping speakers in the
presence of noise such as coughs.
The "setIntersection" operator takes an (optionally) ordered list and
an unordered list and generates a new list in the same order as the
first list. The new list contains the intersection of the members of
the two lists.
The "streamMux" operator takes an input bundle and an ordered list of
streams, and generates an output bundle where each output stream
contains at least <n> and at most <m> of the input streams muxed in
priority order. (<n> and <m> are attributes which specify the
minimum and maximum number of streams respectively). This operator
also takes an attribute which indicates if the operator should
include input streams corresponding to the output stream's
participant. With these additional four operators you can build the
default multipoint video collection described in Section 4.2. A
client using these operators directly to create the same effect would
follow these steps. (Note that in most cases the correct "connector"
to use is implicit from the direction and type of the connection.)
1. Instantiate a streamMux operator with the following parameters:
n=1, m=1, exclusive=true.
2. Instantiate an allParticipants operator, a setIntersection
operator, and a videoSelectSpeakers operator.
3. Connect the video input group for this conference to the
allParticipants operator
4. Connect the audio input group for this conference to the
videoSpeakerSelection operator
5. Connect the allParticipants operator to the "unordered" input of
the setIntersection operator
6. Connect the videoSelectSpeakers operator to the "ordered" input
of the setIntersection operator
7. Connect the video input group for this conference to the
streamMux operator
8. Connect the (output of the) setIntersection operator to the
streamMux operator
9. Connect the streamMux operator to the video output group for this
Mahy & Ismail Expires December 22, 2003 [Page 11]
Internet-Draft XCON Media Policy June 2003
conference
The "selectFloorHolders" operator takes an input bundle and a
mandatory attribute which names the floor, and generates an unordered
list of names of streams which have been granted the named floor.
With this additional operator you can build the floor controlled
audio collection in Section 4.3 and the floor controlled video
collection in Section 4.4.
The "volume" operator takes an audio bundle and generates an audio
bundle which has been adjusted to modify the volume of all streams
according to the attributes provided. Either a qualitative or
quantitative attribute can be provided. The quantitative attribute
is an integer percentage compared to the input volume. The
qualitative attributes are "normal", "soft", "softer", "very soft",
"loud", "louder", and "very loud".
The "audioMix" operator takes in one or more output bundles and
generates a new output bundle. This operator preserves tags. In
other words, the output bundle contains streams for each member in
the intersection of the participants in the input bundles. With these
additional two operators, you can build the audio sidebar collection
in Section 4.5 which addresses both sidebar and coaching scenarios.
The "tile" operator takes at least one input video bundle and an
ordered list of names of streams. It generates a video output bundle
where each output stream consists of tiled windows with a fixed
orientation and in priority order as described in Appendix A. One
attribute to this operator selects the number of tiles, and another
selects if the tile operator is an exclusive or non-exclusive mix.
If an exclusive operator is chosen, whenever a tile would display the
input of the current participant the next video source is selected
instead from the ordered list. Bundles can be connected to a
specific tile of the tile operator. For example, tile 4 may be
connected to a bundle which shows one of the current floor holders,
or to a stream corresponding to a named participant in an input
bundle. With this additional operator, you can build a fixed tile
continuous presence video layout.
Is there anyway to do this with one input bundle and set or list
manipulation? Possibly use weighted lists or position-based
manipulation? We should be able to use setSubtraction and/or
subSets to enable this functionality.
The "autotile" operator dynamically selects a number of tiles between
a minimum and maximum number of streams and incorporates them in a
tiled layout automatically. Like the tile operator, this operator can
be exclusive or non-exclusive and specific bundles may be connected
Mahy & Ismail Expires December 22, 2003 [Page 12]
Internet-Draft XCON Media Policy June 2003
to specific tiles. With this additional operator, you can build the
an automatically tiled continuous presence video layout.
In addition to those operators just listed, future versions of this
document will contain additional standard operators. Some other
operators for consideration are listed below.
o textMux
o textMuxExclusive
o explicitList
o explicitWeightedList
o sortSet
o setIntersection
o setAddition
o setSubtraction
o subSet
o volumeWeighted
o smilLayout (apply a W3C SMIL stylesheet)
o textStylesheet
o xsltLayout
o selectExplicitParticipants
o containsContributor
o doesNotContainContributor
o crossFade
o invertSet
o playUrl
o selectLast
o selectLoudest
Mahy & Ismail Expires December 22, 2003 [Page 13]
Internet-Draft XCON Media Policy June 2003
o selectLongest
o stereo2mono
o pan
o text2speech
o speech2text
o speech2gesture
o speech2signlanguage
4. More about Collections
To create a new collection, a client defines a list of "connectors"
which form the interface between the collection and external graphs.
These connectors are strongly typed as input or output bundles or
sets, and may be further restricted to media type. Then the
"interior" subgraph is created by connecting operators and these
connectors to each other. It is even possible to make use of existing
collections inside a collection, although this makes loop detection
more difficult for the server. Once a new collection is defined, the
XML description is stored on the conference policy server as a
collection template. These are stored in a context completely removed
from individual conferences. Templates persist until they are
removed.
Collections are instantiated just like operators. In some cases
however, the conference policy server may hide the internal structure
of a collection. Also, some conference policy servers may choose to
implement only collections (individual operators cannot be
instantiated). Conference policy server MUST implement at least one
standard collection for each media type they support. Of course they
MAY implement as many other standard or vendor-specific collections
as desired.
Below we list some of these standard collections. For each
collection we give a short textual description and describe the media
topology subgraph which describes the behavior of that collection.
o The basicAudioCollection (see Section 4.1)
o basicMpVideoCollection (see Section 4.2)
o sidebarAudioCollection (see Section 4.5)
Mahy & Ismail Expires December 22, 2003 [Page 14]
Internet-Draft XCON Media Policy June 2003
o audioStreamSelectionCollection
o videoStreamSelectionCollection
o basicTextCollection
o textWithStylesheetCollection
o smilLayoutVideoCollection
o stereoAudioCollection
And a subset of these collections which are floor control enabled...
o audioWithFloorControlCollection (see Section 4.3)
o mpVideoWithFloorControlCollection (see Section 4.4)
o audioStreamSelectionWithFloorControlCollection
o videoStreamSelectionWithFloorControlCollection
o textWithFloorControlCollection
o textWithStylesheetWithFloorControlCollection
4.1 The Basic Audio Collection
<connectionTemplate name="basicAudioCollection">
<connectors>
<connector name="input" type="bundle"
media="audio" direction="in"/>
<connector name="output" type="bundle"
media="audio" direction="out"/>
</connectors>
<operators>
<operator type="audioSelectSpeakers"/>
<operator type="audioMixMinus"/>
</operators>
<connections>
<connection>
<from element="connector" name="input"/>
<to element="operator" type="audioSelectSpeakers"/>
</connection>
<connection>
<from element="connector" name="input"/>
<to element="operator" type="audioMixMinus"/>
Mahy & Ismail Expires December 22, 2003 [Page 15]
Internet-Draft XCON Media Policy June 2003
</connection>
<connection>
<front element="operator" type="audioSelectSpeakers"/>
<to element="operator" type="audioMixMinus"/>
</connection>
<connection>
<from element="operator" type="audioMixMinus"/>
<to element="connector" name="output"/>
</connection>
</connections>
</connectionTemplate>
4.2 Basic Video MP Collection
<connectionTemplate name="basicMpVideoCollection">
<connectors>
<connector name="in.audio" type="bundle"
media="audio" direction="in"/>
<connector name="in.video" type="bundle"
media="video" direction="in"/>
<connector name="output" type="bundle"
media="video" direction="out"/>
</connectors>
<operators>
<operator type="allParticipants"/>
<operator type="videoSelectSpeakers"/>
<operator type="setIntersection"/>
<operator type="streamMux" n="1" m="1" exclusive="true"/>
</operators>
<connections>
<connection>
<from element="connector" name="in.audio"/>
<to element="operator" type="videoSelectSpeakers"/>
</connection>
<connection>
<from element="connector" name="in.video"/>
<to element="operator" type="allParticipants"/>
</connection>
<connection>
<from element="connector" name="in.video"/>
<to element="operator" type="streamMux"/>
</connection>
<connection>
<front element="operator" type="videoSelectSpeakers"/>
<to element="operator" type="setIntersection"
Mahy & Ismail Expires December 22, 2003 [Page 16]
Internet-Draft XCON Media Policy June 2003
port="ordered"/>
</connection>
<connection>
<front element="operator" type="allParticipants"/>
<to element="operator" type="setIntersection"
port="unordered"/>
</connection>
<connection>
<front element="operator" type="setIntersection"/>
<to element="operator" type="streamMux"/>
</connection>
<connection>
<from element="operator" type="streamMux"/>
<to element="connector" name="output"/>
</connection>
</connections>
</connectionTemplate>
4.3 Basic Audio Collection with Floor Control
OPEN ISSUE: How do we pass parameters (like the name of the floor)
into the interior of a collection?
<connectionTemplate name="audioWithFloorControlCollection">
<connectors>
<connector name="input" type="bundle"
media="audio" direction="in"/>
<parameter name="floor" value="$floor"/>
<connector name="output" type="bundle"
media="audio" direction="out"/>
</connectors>
<operators>
<operator type="audioSelectSpeakers"/>
<operator type="selectFloorHolders" floor="$floor"/>
<operator type="setIntersection"/>
<operator type="audioMixMinus"/>
</operators>
<connections>
<connection>
<from element="connector" name="input"/>
<to element="operator" type="audioSelectSpeakers"/>
</connection>
<connection>
<from element="connector" name="input"/>
<to element="operator" type="selectFloorHolders"/>
Mahy & Ismail Expires December 22, 2003 [Page 17]
Internet-Draft XCON Media Policy June 2003
</connection>
<connection>
<from element="connector" name="input"/>
<to element="operator" type="audioMixMinus"/>
</connection>
<connection>
<front element="operator" type="audioSelectSpeakers"/>
<to element="operator" type="setIntersection"
port="ordered"/>
</connection>
<connection>
<front element="operator" type="selectFloorHolders"/>
<to element="operator" type="setIntersection"
port="unordered"/>
</connection>
<connection>
<front element="operator" type="setIntersection"/>
<to element="operator" type="audioMixMinus"/>
</connection>
<connection>
<from element="operator" type="audioMixMinus"/>
<to element="connector" name="output"/>
</connection>
</connections>
</connectionTemplate>
4.4 Basic Video Collection with Floor Control
<connectionTemplate name="mpVideoWithFloorControlCollection">
<connectors>
<connector name="in.audio" type="bundle"
media="audio" direction="in"/>
<connector name="in.video" type="bundle"
media="video" direction="in"/>
<parameter name="floor" value="$floor"/>
<connector name="output" type="bundle"
media="video" direction="out"/>
</connectors>
<operators>
<operator type="allParticipants"/>
<operator type="selectFloorHolders" floor="$floor"/>
<operator type="videoSelectSpeakers"/>
<operator type="setIntersection" instance="1"/>
<operator type="setIntersection" instance="2"/>
<operator type="streamMux" n="1" m="1" exclusive="true"/>
Mahy & Ismail Expires December 22, 2003 [Page 18]
Internet-Draft XCON Media Policy June 2003
</operators>
<connections>
<connection>
<from element="connector" name="in.audio"/>
<to element="operator" type="videoSelectSpeakers"/>
</connection>
<connection>
<from element="connector" name="in.video"/>
<to element="operator" type="allParticipants"/>
</connection>
<connection>
<from element="connector" name="in.video"/>
<to element="operator" type="streamMux"/>
</connection>
<connection>
<front element="operator" type="videoSelectSpeakers"/>
<to element="operator" type="setIntersection"
port="ordered" instance="1"/>
</connection>
<connection>
<front element="operator" type="allParticipants"/>
<to element="operator" type="setIntersection" instance="2"/>
</connection>
<connection>
<front element="operator" type="selectFloorHolders"/>
<to element="operator" type="setIntersection" instance="2"/>
</connection>
<connection>
<front element="operator" type="setIntersection" instance="2"/>
<to element="operator" type="setIntersection"
port="unordered" instance="1"/>
</connection>
<connection>
<front element="operator" type="setIntersection" instance="1"/>
<to element="operator" type="streamMux"/>
</connection>
<connection>
<from element="operator" type="streamMux"/>
<to element="connector" name="output"/>
</connection>
</connections>
</connectionTemplate>
4.5 Sidebar Audio Collection
Mahy & Ismail Expires December 22, 2003 [Page 19]
Internet-Draft XCON Media Policy June 2003
<connectionTemplate name="sidebarAudioCollection">
<connectors>
<connector name="in.thisconf" type="bundle"
media="audio" direction="in"/>
<connector name="in.mainconf" type="bundle"
media="audio" direction="in"/>
<parameter name="volume" value="$vol"/>
<connector name="output" type="bundle"
media="audio" direction="out"/>
</connectors>
<operators>
<operator type="volume" level="$vol"/>
<operator type="audioSelectSpeakers"/>
<operator type="audioMixMinus"/>
<operator type="audioMix"/>
</operators>
<connections>
<connection>
<from element="connector" name="in.thisconf"/>
<to element="operator" type="audioSelectSpeakers"/>
</connection>
<connection>
<from element="connector" name="in.mainconf"/>
<to element="operator" type="volume"/>
</connection>
<connection>
<front element="operator" type="audioSelectSpeakers"/>
<to element="operator" type="audioMixMinus"/>
</connection>
<connection>
<front element="operator" type="audioMixMinus"/>
<to element="operator" type="audioMix"/>
</connection>
<connection>
<front element="operator" type="volume"/>
<to element="operator" type="audioMix"/>
</connection>
<connection>
<from element="operator" type="audioMix"/>
<to element="connector" name="output"/>
</connection>
</connections>
</connectionTemplate>
Mahy & Ismail Expires December 22, 2003 [Page 20]
Internet-Draft XCON Media Policy June 2003
5. Semantics
5.1 Transactions
Manipulations of a "live" media topology graph are performed as
transactions. This insures that the media graph transitions from one
consistent state to another. It should never be in a partially
connected or disconnected state. Loop detection is always performed
by the server before a transaction is accepted.
Note that operators are automatically deleted unless they have at
least one input connection and at least one output connection. As a
result, a transaction which instantiates an operator must connect it
to an input source and an output source during the same transaction,
otherwise adding the operator would have no effect.
A transaction encloses one or more topology graph manipulations which
must all succeed or all fail. Within the transaction, individual
steps consist of either creating or instantiating elements or
connecting them together. Note that there is an important
distinction between groups and aliases and collections and operators.
Groups and aliases are created (they don't exist before they are
created), while collections and operators are instantiated (a copy of
the original is placed in the media topology graph).
While nearly any RPC-style protocol could be used to express media
policy transactions, this document describes an XCAP [2] profile for
manipulating media policy. XCAP is a usage of HTTP [5] which uses
XPath [6] to address fragments of an XML document in the Request URI.
Two XML schemas are defined--one for managing collections for later
use, and another for real-time manipulation of media policy graphs.
Note that support for transactions is currently an open issue in
XCAP.
5.2 Client Behavior
To query the media policy for a particular conference, a client
merely fetches the media policy document (or document fragment) of
interest. In some cases the document will be filtered to remove
hidden or private information. Similarly, if the client is
authorized, it can view the internal structure of a collection
template by just fetching its definition document. When filtered, a
collection template may just describe the connectors associated with
it and a textual description.
A client connects a stream to a group merely by writing the stream
Mahy & Ismail Expires December 22, 2003 [Page 21]
Internet-Draft XCON Media Policy June 2003
into the appropriate group structure in the target conference or
subconference. Likewise a client disconnects a stream by deleting the
stream from the appropriate group structure. The client permissions
determine if this request fails, requires confirmation from the
affected target, or succeeds immediately. Since a stream can only
exist in one group at a time, if a write operation succeeds and the
stream is already connected it results in a reassignment rather than
the same stream in multiple groups.
To instantiate a new operator or collection, just append an XML
fragment of code which describes the parameters for that operator to
the appropriate XPath (the operators or collections XPath). To make a
connection, just append the appropriate XML fragment describing that
connection to the connections XPath. Deleting an XPath, removes the
operation, collection, or connection. Once an connection is removed
this may cause one or more operations to be automatically deleted.
Likewise, when an operation is deleted, all its connections are
deleted as well. Just using these simple mechanisms allow authorized
clients to perform arbitrary manipulations of the media topology.
Finally, to create a new collection, the client writes an XML
description of the collection into the collectionTemplates XPath.
5.3 Server Behavior
Servers must maintain a list of all operator and collection types
that can be used by Clients within a conference. Servers must return
such a list to all authorized Clients in response to inventory
queries. For operators and collections that have parameters, a list
of acceptable parameter values must also be specified for each
parameter.
For each transaction received by the Server it must proceed with the
steps that follow. For each request within the transaction the Server
must verify that the party initiating the request is authorized to
initiate this specific request in the context of the sub-conference
specified within the request. If the initiator is not authorized, the
Server must not execute any part of the transaction and return the
appropriate "Authorization Failure" response to the initiator. An
example if user A requests to connect the input audio stream of user
B to group X in sub-conference "sidebar-1" and the output audio
stream of user B to group Y in sub-conference "sidebar-1". The Server
must verify that user A is authorized to manipulate the media policy
of user B and is authorized to manipulate "sidebar-1".
For each request the Server must verify that any changes in the media
policy of any participant as a result of the execution of the request
is authorized by the conference policy. If any party is not
Mahy & Ismail Expires December 22, 2003 [Page 22]
Internet-Draft XCON Media Policy June 2003
authorized for the media policy changes that result from the
execution of any request within the transaction then the server must
not execute any part of the transaction and return the appropriate
"Authorization Failure" response to the initiator. In the example
used in the previous point, the Server must verify that user B is
authorized to join "sidebar-1".
The Server should verify that all requests to instantiate, create
and/or connect elements are conforming to the XML schema and
descriptions of the elements. If any request does not conform to the
XML schema of the elements that it is operating on then the Server
must not execute any part of the transaction and return the
appropriate "XML Schema Error" response to the initiator. For example
an operator that takes one video input bundle can not be connected to
an audio bundle.
The Server should verify that all the relevant mixers have enough
resources to perform the actual media processing required as a result
of the execution of the transaction. If not enough resources are
available the Server must not execute any part of the transaction and
return the appropriate "No Available Resources" response to the
initiator. Note that resources needed for trans-coding and
trans-rating should be accounted for. Editor Note: More details and
some examples need to be provided to explain this section and
specifically the last bullet.
5.4 Notifications of media policy changes
Media topology changes should result in an appropriate
protocol-specific notification to those (authorized) parties who have
requested (subscribed for) them. In the case of SIP, this
notification will be a notification from the SIP conference package,
but will send an application/media-policy+xml MIME type in the
notification body in addition to, or instead of the basic roster
information normally provided by that event package. Note that the
protocol should allow hidden transactions for which no notifications
will be sent as a result of the media policy change.
Editors Note: Need to describe how pending operations are handled
with notifications.
6. Formal Syntax
Below is an XCAP encoding (using XML Schema) for media-topology
manipulation of an active conference (or subconference):
<?xml version="1.0" encoding="UTF-8"?>
Mahy & Ismail Expires December 22, 2003 [Page 23]
Internet-Draft XCON Media Policy June 2003
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="media-policy">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="0"
name="groups" type="groupsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="collections" type="collectionsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="operators" type="operatorsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="connections" type="connectionsType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="groupsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="group" type="groupType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="groupType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="stream" type="streamType"/>
</xs:sequence>
<xs:attribute name="direction" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="in"/>
<xs:enumeration value="out"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="media" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="audio"/>
<xs:enumeration value="video"/>
<xs:enumeration value="text"/>
<!-- add extensibility of the media type? -->
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="streamType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
Mahy & Ismail Expires December 22, 2003 [Page 24]
Internet-Draft XCON Media Policy June 2003
name="alias" type="xs:string"/>
</xs:sequence>
<xs:attribute name="fam" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="ipv4"/>
<xs:enumeration value="ipv6"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="addr" type="xs:string" use="required"/>
<xs:attribute name="proto" type="xs:string" use="optional"/>
<xs:attribute name="sock" type="xs:integer" use="optional"/>
<xs:attribute name="demux" type="xs:string"/>
</xs:complexType>
<xs:complexType name="collectionsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="collection" type="operatorType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="operatorsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="collection" type="operatorType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="operatorType">
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="connectionsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="connection" type="connectionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="connectionType">
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="1"
name="to" type="connectType"/>
<xs:element maxOccurs="1" minOccurs="1"
name="from" type="connectType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="connectType">
<xs:attribute name="element" use="required">
<xs:simpleType>
Mahy & Ismail Expires December 22, 2003 [Page 25]
Internet-Draft XCON Media Policy June 2003
<xs:restriction base="xs:string">
<xs:enumeration value="group"/>
<xs:enumeration value="collection"/>
<xs:enumeration value="operator"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type" type="xs:string" use="optional"/>
<xs:attribute name="conf" type="xs:string" use="optional"/>
<xs:attribute name="media" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="audio"/>
<xs:enumeration value="video"/>
<xs:enumeration value="text"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="in"/>
<xs:enumeration value="out"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="port" type="xs:string" use="optional"/>
<xs:attribute name="instance" type="xs:string" use="optional"/>
</xs:complexType>
</xs:schema>
And here is an XML schema for describing collection templates:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="collectionTemplates">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="0"
name="connectors" type="connectorsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="collections" type="collectionsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="operators" type="operatorsType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="connections" type="connectionsType"/>
Mahy & Ismail Expires December 22, 2003 [Page 26]
Internet-Draft XCON Media Policy June 2003
</xs:sequence>
<xs:attribute name="name" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:complexType name="connectorsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="connector" type="connectorType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="connectorType">
<xs:attribute name="name" use="required"/>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="bundle"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="direction" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="in"/>
<xs:enumeration value="out"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="collectionsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="collection" type="operatorType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="operatorsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="collection" type="operatorType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="operatorType">
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="connectionsType">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
Mahy & Ismail Expires December 22, 2003 [Page 27]
Internet-Draft XCON Media Policy June 2003
name="connection" type="connectionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="connectionType">
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="1"
name="to" type="connectType"/>
<xs:element maxOccurs="1" minOccurs="1"
name="from" type="connectType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="connectType">
<xs:attribute name="element" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="connector"/>
<xs:enumeration value="collection"/>
<xs:enumeration value="operator"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type" type="xs:string" use="optional"/>
<xs:attribute name="conf" type="xs:string" use="optional"/>
<xs:attribute name="media" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="audio"/>
<xs:enumeration value="video"/>
<xs:enumeration value="text"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="in"/>
<xs:enumeration value="out"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="port" type="xs:string" use="optional"/>
<xs:attribute name="instance" type="xs:string" use="optional"/>
</xs:complexType>
</xs:schema>
Mahy & Ismail Expires December 22, 2003 [Page 28]
Internet-Draft XCON Media Policy June 2003
7. Examples
Below is a diagram which shows a sample media topology (with streams,
collections, and groups) for an audio and video conference with an
audio sidebar.
Audio and Video Conference with one Audio Sidebar
(streams) (streams) (streams)
A B D E F H J A C D F G H I B E J
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
V V V V V V V V V V V V V V V V V
+------------------+ +------------------+ +-------------------+
| Main Video In | | Main Audio In | | Sidebar Audio Out |
| (group) | | (group) | | (group) |
+------------------+ +------------------+ +-------------------+
|| // || ||
|| // || +------+ ||
|| // || |+----+| ||
|| // || || || ||
\/ // \/ || \/ \/
...................V. ................... || ..................
: : : : || : :
: : : : || : :
: vendor : : standard : || : standard :
: defined : : conference : || : sidebar :
: video : : audio : || : audio :
: collection : : collection : || : collection :
: : : : || : :
: : : : || : :
..................... ................... || ..................
|| || || || ||
|| || |+---+| ||
|| || +-----+ ||
\/ \/ \/
+------------------+ +------------------+ +-------------------+
| Main Video Out | | Main Audio Out | | Sidebar Audio Out |
| (group) | | (group) | | (group) |
+------------------+ +------------------+ +-------------------+
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
V V V V V V V V V V V V V V V V V V
A B C D E F H J A C D F G H I B E J
(streams) (streams) (streams)
Mahy & Ismail Expires December 22, 2003 [Page 29]
Internet-Draft XCON Media Policy June 2003
Here we have the media topologies description documents for the
combined audio/video conference in the figure above. The first media
topology is for the main conference, and the second is for the
subconference used by the audio sidebar. Specific streams are
omitted for brevity.
<media-topology>
<groups>
<group dir="in" media="audio"/>
<group dir="out" media="audio"/>
<group dir="in" media="video"/>
<group dir="out" media="video"/>
</groups>
<collections>
<collection type="basicAudioCollection"/>
<collection type="example.com.videoCollection" size="7"/>
</collections>
<connections>
<connection>
<from element="group" direction="in" media="audio"/>
<to element="collection" type="basicAudioCollection"/>
</connection>
<connection>
<from element="group" direction="in" media="video"/>
<to element="collection" type="example.com.videoCollection"/>
</connection>
<connection>
<from element="collection" type="basicAudioCollection"/>
<to element="group" direction="out" media="audio"/>
</connection>
<connection>
<from element="collection" type="example.com.videoCollection"/>
<to element="group" direction="out" media="video"/>
</connection>
</connections>
</media-topology>
Below is the media topology description document for the
subconference. Note that conf=".." refers to the parent of the
current conference
<media-topology>
<groups>
<group dir="in" media="audio"/>
<group dir="out" media="audio"/>
</groups>
<collections>
<collection type="sidebarAudioCollection" volume="soft"/>
Mahy & Ismail Expires December 22, 2003 [Page 30]
Internet-Draft XCON Media Policy June 2003
</collections>
<connections>
<connection>
<from element="group" direction="in" media="audio"/>
<to element="collection" type="sidebarAudioCollection"
port="in.thisconf"/>
</connection>
<connection>
<from element="group" direction="out" media="audio" conf=".."/>
<to element="collection" type="sidebarAudioCollection"
port="in.mainconf"/>
</connection>
<connection>
<from element="collection" type="sidebarAudioCollection"/>
<to element="group" direction="out" media="audio"/>
</connection>
</connections>
</media-topology>
8. Security Considerations
Much needs to be written here. Authorization rules will be discussed
in Section 5.3. Privacy and filtering rules will be discussed there
as well.
9. IANA Considerations
This document defines an IANA registry of Media Operators, and
another of Media Collections.
10. Acknowledgments
This work was the result of discussions among the SIP Conferencing
Design Team.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-rosenberg-simple-xcap-00 (work in progress), May 2003.
[3] Even, R., Levin, O. and N. Ismail, "Conferencing media policy
Requirements", draft-even-xcon-media-policy-requirements-00.txt
(work in progress), June 2003.
Mahy & Ismail Expires December 22, 2003 [Page 31]
Internet-Draft XCON Media Policy June 2003
[4] Koskelainen, P. and H. Khartabil, "XCAP Usage for Conference
Policy Manipulation",
draft-koskelainen-xcon-xcap-cpcp-usage-00.txt (work in
progress), June 2003.
[5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C Recommendation xpath, November 1999, <http://
www.w3.org/TR/xpath>.
[7] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>.
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[9] Jacobson, V., Perkins, C. and M. Handley, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-13 (work in
progress), May 2003.
[10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[12] International Telecommunications Union, "CONTROL PROTOCOL FOR
MULTIMEDIA COMMUNICATION", ITU Recommendation H.245, 1998.
Informational References
[13] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in
progress), May 2003.
[14] Levin, O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing",
draft-ietf-sipping-conferencing-requirements-00 (work in
progress), April 2003.
[15] Rosenberg, J. and H. Schulzrinne, "A Session Initiation
Mahy & Ismail Expires December 22, 2003 [Page 32]
Internet-Draft XCON Media Policy June 2003
Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-00 (work in progress),
June 2002.
[16] Even, R. and N. Ismail, "Conferencing Scenarios",
draft-even-xcon-conference-scenarios-00.txt (work in progress),
June 2003.
[17] Koskelainen, P., "Floor Control Requirements",
draft-koskelainen-xcon-floor-control-reqs-00.txt (work in
progress), June 2003.
Authors' Addresses
Rohan Mahy
Cisco Systems, Inc.
101 Cooper St
Santa Cruz, CA 95060
USA
EMail: rohan@cisco.com
Nermeen Ismail
Cisco Systems, Inc.
170 W Tasman Dr
San Jose, CA 95134
USA
EMail: nismail@cisco.com
Appendix A. Standard Tile Order
Mahy & Ismail Expires December 22, 2003 [Page 33]
Internet-Draft XCON Media Policy June 2003
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 (2003). 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
Mahy & Ismail Expires December 22, 2003 [Page 34]
Internet-Draft XCON Media Policy June 2003
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.
Mahy & Ismail Expires December 22, 2003 [Page 35]