draft-ietf-mediactrl-mixer-control-package-08.txt   draft-ietf-mediactrl-mixer-control-package-09.txt 
Network Working Group S. McGlashan Network Working Group S. McGlashan
Internet-Draft Hewlett-Packard Internet-Draft Hewlett-Packard
Intended status: Standards Track T. Melanchuk Intended status: Standards Track T. Melanchuk
Expires: May 29, 2010 Rain Willow Communications Expires: July 15, 2010 Rain Willow Communications
C. Boulton C. Boulton
NS-Technologies NS-Technologies
November 25, 2009 January 11, 2010
A Mixer Control Package for the Media Control Channel Framework A Mixer Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-mixer-control-package-08 draft-ietf-mediactrl-mixer-control-package-09
Abstract Abstract
This document defines a Media Control Channel Framework Package for This document defines a Media Control Channel Framework Package for
managing mixers for media conferences and connections. The package managing mixers for media conferences and connections. The package
defines request elements for managing conference mixers, managing defines request elements for managing conference mixers, managing
mixers between conferences and/or connections, as well as associated mixers between conferences and/or connections, as well as associated
responses and notifications. The package also defines elements for responses and notifications. The package also defines elements for
auditing package capabilities and mixers. auditing package capabilities and mixers.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 29, 2010. This Internet-Draft will expire on July 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 11, line 17 skipping to change at page 11, line 17
This section defines the XML elements for this package. The elements This section defines the XML elements for this package. The elements
are defined in the XML namespace specified in Section 8.2. are defined in the XML namespace specified in Section 8.2.
The root element is <mscmixer> (Section 4.1). All other XML elements The root element is <mscmixer> (Section 4.1). All other XML elements
(requests, responses and notification elements) are contained within (requests, responses and notification elements) are contained within
it. Child elements describe mixer management (Section 4.2) and audit it. Child elements describe mixer management (Section 4.2) and audit
(Section 4.3) functionality. Response status codes are defined in (Section 4.3) functionality. Response status codes are defined in
Section 4.5 and type definitions in Section 4.6. Section 4.5 and type definitions in Section 4.6.
Implementation of this control package MUST address the Security Implementation of this control package MUST address the Security
Considerations described in Section 7 ). Considerations described in Section 7.
Implementation of this control package MUST adhere to the syntax and Implementation of this control package MUST adhere to the syntax and
semantics of XML elements defined in this section and the schema semantics of XML elements defined in this section and the schema
(Section 5). The XML schema supports extensibility by allowing (Section 5). The XML schema supports extensibility by allowing
attributes and elements from other namespaces. Implementations MAY attributes and elements from other namespaces. Implementations MAY
support attributes and elements from other (foreign) namespaces. If support attributes and elements from other (foreign) namespaces. If
an MS implementation receives a <mscmixer> element containing an MS implementation receives a <mscmixer> element containing
attributes or elements from another namespace which it does not attributes or elements from another namespace which it does not
support, the MS sends a 428 response (Section 4.5). support, the MS sends a 428 response (Section 4.5).
skipping to change at page 20, line 30 skipping to change at page 20, line 30
The <video-layout> element has a content model specifying the name of The <video-layout> element has a content model specifying the name of
the video layout. the video layout.
An MS MAY support the predefined video layouts defined in the XCON An MS MAY support the predefined video layouts defined in the XCON
conference information data model conference information data model
([I-D.ietf-xcon-common-data-model]). The MS MAY support other video ([I-D.ietf-xcon-common-data-model]). The MS MAY support other video
layouts. Non-XCON layouts MUST be prefixed with a label; for layouts. Non-XCON layouts MUST be prefixed with a label; for
example, <video-layout>mylayout:single-view<video-layout>. example, <video-layout>mylayout:single-view<video-layout>.
Each video layout has associated with it one or more regions. The Each video layout has associated with it one or more regions. The
XCON layouts have associated the following named regions: XCON layouts are associated with the following named regions:
single-view layout with one stream in a single region as shown in single-view layout with one stream in a single region as shown in
Figure 1. Figure 1.
+-----------+ +-----------+
| | | |
| | | |
| 1 | | 1 |
| | | |
| | | |
+-----------+ +-----------+
Figure 1: single-view video layout Figure 1: single-view video layout
dual-view layout presenting two streams side-by-side in two regions dual-view layout presenting two streams side-by-side in two regions
as shown in Figure 2. The MS MUST NOT alter the aspect ratio of as shown in Figure 2. The MS MUST NOT alter the aspect ratio of
each stream to fit the region and hence the MS could have to blank each stream to fit the region and hence the MS might need to blank
part of each region. out part of each region.
+-----------+-----------+ +-----------+-----------+
| | | | | |
| | | | | |
| 1 | 2 | | 1 | 2 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
Figure 2: dual-view video layout Figure 2: dual-view video layout
skipping to change at page 21, line 32 skipping to change at page 21, line 32
| 1 | 2 | | 1 | 2 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
Figure 3: dual-view-crop video layout Figure 3: dual-view-crop video layout
dual-view-2x1 layout presenting two streams one above the other in dual-view-2x1 layout presenting two streams one above the other in
two regions as shown in Figure 4. The MS MUST NOT alter the two regions as shown in Figure 4. The MS MUST NOT alter the
aspect ratio of each stream to fit its region and hence the MS aspect ratio of each stream to fit its region and hence the MS
could have to blank part of each region. might need to blank out part of each region.
+-----------+ +-----------+
| | | |
| | | |
| 1 | | 1 |
| | | |
| | | |
+-----------+ +-----------+
| | | |
| | | |
skipping to change at page 27, line 40 skipping to change at page 27, line 40
1. Each participant has an (positive integer) priority value: the 1. Each participant has an (positive integer) priority value: the
lower the value, the higher the priority. The priority value is lower the value, the higher the priority. The priority value is
determined by the <priority> child element (Section 4.2.2.5.4) of determined by the <priority> child element (Section 4.2.2.5.4) of
<stream>. If not explicitly specified, the default priority <stream>. If not explicitly specified, the default priority
value is 100. value is 100.
2. The MS uses priority values to assign participants to regions in 2. The MS uses priority values to assign participants to regions in
the video layout which remain unfilled after application of the the video layout which remain unfilled after application of the
video switching policy. The MS MUST dedicate larger and/or more video switching policy. The MS MUST dedicate larger and/or more
prominent portions of the layout to participants with higher prominent portions of the layout to participants with higher
priority values first (e.g. first all participants with priority priority values first (e.g. first, all participants with priority
1, then those with 2, 3, etc). 1, then those with 2, 3, etc).
3. The policy for displaying participants with the same priority is 3. The policy for displaying participants with the same priority is
implementation-specific. implementation-specific.
The MS applies this priority policy each time the video layout is The MS applies this priority policy each time the video layout is
changed or updated. It is RECOMMENDED that the MS does not move a changed or updated. It is RECOMMENDED that the MS does not move a
participant from one region to another unless required by the video participant from one region to another unless required by the video
switching policy when an active video layout is updated. switching policy when an active video layout is updated.
skipping to change at page 29, line 47 skipping to change at page 29, line 47
sometimes referred to as a whisper announcement. An alternative to a sometimes referred to as a whisper announcement. An alternative to a
whisper announcement is to have the announcement pre-empt the whisper announcement is to have the announcement pre-empt the
conference media. conference media.
Another common case is the call center coaching scenario where a Another common case is the call center coaching scenario where a
supervisor can listen to the conversation between an agent and a supervisor can listen to the conversation between an agent and a
customer, and provide hints to the agent, which are not heard by the customer, and provide hints to the agent, which are not heard by the
customer. customer.
Both of these cases can be solved by having the controlling AS create Both of these cases can be solved by having the controlling AS create
one or more conferences for audio mixing and to join and unjoin the one or more conferences for audio mixing, and then join and unjoin
media streams as required. A better solution is to have the media the media streams as required. A better solution is to have the
server automatically mix media streams that are requested to be media server automatically mix media streams that are requested to be
joined to a common input when only the simple summing of audio joined to a common input when only the simple summing of audio
signals as described above is required. This is the case for both signals as described above is required. This is the case for both
the use cases presented above. the use cases presented above.
Automatically mixing streams has several benefits. Conceptually, it Automatically mixing streams has several benefits. Conceptually, it
is straight forward and simple, requiring no indirect requests on the is straight forward and simple, requiring no indirect requests on the
part of the controlling AS. This increases transport efficiency and part of the controlling AS. This increases transport efficiency and
reduces the coordination complexity and the latency of the overall reduces the coordination complexity and the latency of the overall
operation. Therefore, it is RECOMMENDED that a media server be able operation. Therefore, it is RECOMMENDED that a media server be able
to automatically mix at least two audio streams where only the simple to automatically mix at least two audio streams where only the simple
skipping to change at page 30, line 30 skipping to change at page 30, line 30
complex mixing algorithm is required. complex mixing algorithm is required.
Specifications which extend this package to handle additional media Specifications which extend this package to handle additional media
types such as text, MUST define the semantics of the join operation types such as text, MUST define the semantics of the join operation
when multiple streams are requested to be joined to a single input, when multiple streams are requested to be joined to a single input,
such as that for a connection with a single RTP session per media such as that for a connection with a single RTP session per media
type. type.
4.2.2.2. <join> 4.2.2.2. <join>
The <join> element is sent to the MS to request creation one or more The <join> element is sent to the MS to request creation of one or
media streams either between a connection and a conference, between more media streams either between a connection and a conference,
connections, or between conferences. The two entities to join are between connections, or between conferences. The two entities to
specified by the attributes of <join>. join are specified by the attributes of <join>.
Streams can be of any media type, and can be bi-directional or uni- Streams can be of any media type, and can be bi-directional or uni-
directional. A bi-directional stream is implicitly composed of two directional. A bi-directional stream is implicitly composed of two
uni-directional streams that can be manipulated independently. The uni-directional streams that can be manipulated independently. The
streams to be established are specified by child <stream> elements streams to be established are specified by child <stream> elements
(see Section 4.2.2.5). (see Section 4.2.2.5).
The <join> element has the following attributes: The <join> element has the following attributes:
id1: an identifier for either a connection or a conference. The id1: an identifier for either a connection or a conference. The
skipping to change at page 40, line 34 skipping to change at page 40, line 34
The <active-talkers-notify> element describes zero or more speakers The <active-talkers-notify> element describes zero or more speakers
that have been active in a conference during the specified interval that have been active in a conference during the specified interval
(see Section 4.2.1.4.4.1). (see Section 4.2.1.4.4.1).
The <active-talkers-notify> element has the following attributes: The <active-talkers-notify> element has the following attributes:
conferenceid: string indicating the name of the conference from conferenceid: string indicating the name of the conference from
which the event originated. This attribute is mandatory. which the event originated. This attribute is mandatory.
The <active-talkers-notify> element has the following sequence of The <active-talkers-notify> element has the following sequence of
child elements (0 or more occurrence's): child elements (0 or more occurrences):
<active-talker> element describing an active talker <active-talker> element describing an active talker
(Section 4.2.4.1.1). (Section 4.2.4.1.1).
4.2.4.1.1. <active-talker> 4.2.4.1.1. <active-talker>
The <active-talker> element describes an active talker, associated The <active-talker> element describes an active talker, associated
with either a connection or conference participant in a conference. with either a connection or conference participant in a conference.
The <active-talker> element has the following attributes: The <active-talker> element has the following attributes:
connectionid: string indicating the connectionid of the active connectionid: string indicating the connectionid of the active
talker. This attribute is optional. There is no default value. talker. This attribute is optional. There is no default value.
conferenceid: string indicating the conferenceid of the active conferenceid: string indicating the conferenceid of the active
talker. This attribute is optional. There is no default value. talker. This attribute is optional. There is no default value.
It is an error (400) if both the connectionid and conferenceid Note that the element does not describe an active talker if both the
attributes are specified. connectionid and conferenceid attributes are specified, or if neither
attribute is specified.
The <active-talker> element has no child elements. The <active-talker> element has no child elements.
4.2.4.2. <unjoin-notify> 4.2.4.2. <unjoin-notify>
The <unjoin-notify> element describes a notification event where a The <unjoin-notify> element describes a notification event where a
connection and/or conference have been completely unjoined. connection and/or conference have been completely unjoined.
The <unjoin-notify> element has the following attributes: The <unjoin-notify> element has the following attributes:
skipping to change at page 84, line 52 skipping to change at page 84, line 52
The Media Control Channel Framework permits additional policy The Media Control Channel Framework permits additional policy
management, including resource access and control channel usage, to management, including resource access and control channel usage, to
be specified at the control package level beyond that specified for be specified at the control package level beyond that specified for
the Media Control Channel Framework (see Section 11.3 of the Media Control Channel Framework (see Section 11.3 of
[I-D.ietf-mediactrl-sip-control-framework]). [I-D.ietf-mediactrl-sip-control-framework]).
Since creation of conference and join mixers is associated with media Since creation of conference and join mixers is associated with media
mixing resources on the MS, the security policy for this control mixing resources on the MS, the security policy for this control
package needs to address how such mixers are securely managed across package needs to address how such mixers are securely managed across
more than one control channels. Such a security policy is only more than one control channel. Such a security policy is only useful
useful for secure, confidential and integrity protected channels. for secure, confidential and integrity protected channels. The
The identity of control channels is determined by the channel identity of control channels is determined by the channel identifier:
identifier: i.e. the value of the cfw-id attribute in the SDP and i.e. the value of the cfw-id attribute in the SDP and Dialog-ID
Dialog-ID header in the channel protocol (see header in the channel protocol (see
[I-D.ietf-mediactrl-sip-control-framework]). Channels are the same [I-D.ietf-mediactrl-sip-control-framework]). Channels are the same
if they have the same identifier; otherwise, they are different. if they have the same identifier; otherwise, they are different.
This control package imposes the following additional security This control package imposes the following additional security
policies: policies:
Responses: The MS MUST only send a response to a mixer management or Responses: The MS MUST only send a response to a mixer management or
audit request using the same control channel as the one used to audit request using the same control channel as the one used to
send the request. send the request.
Notifications: The MS MUST only send notification events for Notifications: The MS MUST only send notification events for
skipping to change at page 88, line 5 skipping to change at page 88, line 5
Person & email address to contact for further information: Person & email address to contact for further information:
IETF, MEDIACTRL working group, (mediactrl@ietf.org), IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Scott McGlashan (smcg.stds01@mcglashan.org). Scott McGlashan (smcg.stds01@mcglashan.org).
8.2. URN Sub-Namespace Registration 8.2. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688 "urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:msc-mixer URI: urn:ietf:params:xml:ns:msc-mixer
Registrant Contact: IETF, MEDIACTRL working group, Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Scott McGlashan (smcg.stds01@mcglashan.org). (mediactrl@ietf.org), Scott McGlashan
XML: (smcg.stds01@mcglashan.org).
BEGIN XML:
<?xml version="1.0"?> BEGIN
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <?xml version="1.0"?>
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<head> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<title>Media Control Channel Framework Mixer <head>
Package attributes</title> <title>Media Control Channel Framework Mixer
</head> Package attributes</title>
<body> </head>
<h1>Namespace for Media Control Channel <body>
Framework Mixer Package attributes</h1> <h1>Namespace for Media Control Channel
<h2>urn:ietf:params:xml:ns:msc-mixer</h2> Framework Mixer Package attributes</h1>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX <h2>urn:ietf:params:xml:ns:msc-mixer</h2>
with the RFC number for this specification.] [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
<p>See RFCXXXX</p> with the RFC number for this specification.]
</body> <p>See RFCXXXX</p>
</html> </body>
END </html>
END
8.3. XML Schema Registration 8.3. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688]. 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:msc-mixer URI: urn:ietf:params:xml:ns:msc-mixer
Registrant Contact: IETF, MEDIACTRL working group, Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Scott McGlashan (smcg.stds01@mcglashan.org). (mediactrl@ietf.org), Scott McGlashan
Schema: The XML for this schema can be found in (smcg.stds01@mcglashan.org).
Section 5 of this document. Schema: The XML for this schema can be found in
Section 5 of this document.
8.4. MIME Media Type Registration for 'application/msc-mixer+xml' 8.4. MIME Media Type Registration for 'application/msc-mixer+xml'
This section registers the "application/msc-mixer+xml" MIME type. This section registers the "application/msc-mixer+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type Subject: Registration of MIME media type
application/msc-mixer+xml application/msc-mixer+xml
MIME media type name: application MIME media type name: application
MIME subtype name: msc-mixer+xml MIME subtype name: msc-mixer+xml
skipping to change at page 90, line 9 skipping to change at page 90, line 9
Person & email address to contact for further information: Scott Person & email address to contact for further information: Scott
McGlashan <smcg.stds01@mcglashan.org> McGlashan <smcg.stds01@mcglashan.org>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: None. Other information: None.
9. Change Summary 9. Change Summary
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
The following are the changes between the -09 and -08 versions
following shepherd writeup:
o 4.2.4.1.1: <active-talker>: Removed the statement that it is an
error if an <active-talker> element has both connectionid and
conferenceid attributes specified because the AS always sends a
framework 200 in response to notification events, including active
talker events. Instead, clarified that no active talker is
described if both attributes are specified or if neither attribute
is specified.
o Various spelling and grammatical errors fixed.
The following are the changes between the -08 and -07 versions. The following are the changes between the -08 and -07 versions.
o 8.4: Changed file extension from '.xml' to (none) o 8.4: Changed file extension from '.xml' to (none)
o Changed "~" to a ":" for connectionid o Changed "~" to a ":" for connectionid
o 4.2.6.1: Clarified that <param> can contain an XML value. o 4.2.6.1: Clarified that <param> can contain an XML value.
o 4.2.4.2: Changed <unjoin-notify> status codes so that only 0-2 o 4.2.4.2: Changed <unjoin-notify> status codes so that only 0-2
defined and all others are reserved for future use requiring a defined and all others are reserved for future use requiring a
 End of changes. 18 change blocks. 
54 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/