draft-ietf-mediactrl-mixer-control-package-10.txt   draft-ietf-mediactrl-mixer-control-package-11.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: August 1, 2010 Rain Willow Communications Expires: August 29, 2010 Rain Willow Communications
C. Boulton C. Boulton
NS-Technologies NS-Technologies
January 28, 2010 February 25, 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-10 draft-ietf-mediactrl-mixer-control-package-11
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 August 1, 2010. This Internet-Draft will expire on August 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 17 4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 17
4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 19 4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 19
4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 24 4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 24
4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 26 4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 26
4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 27 4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 27
4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 27 4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 27
4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 27 4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 27
4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 27 4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 27
4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 29 4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 29
4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 31 4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 31
4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 34 4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 33
4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 35 4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 35
4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 37 4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 36
4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 37 4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 37 4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 37
4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 38 4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 37
4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 38 4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 38
4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39 4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39
4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 39 4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 39
4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40 4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40
4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 41 4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 40
4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 42 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 44 4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 43
4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 45 4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 45
4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 46 4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 46
4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 46 4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 46
4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 47 4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 47
4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 47 4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 47
4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48 4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48
4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1.1. <subtype> . . . . . . . . . . . . . . . . . . . . 50 4.4.1.1. <subtype> . . . . . . . . . . . . . . . . . . . . 50
4.4.1.2. <params> . . . . . . . . . . . . . . . . . . . . 50 4.4.1.2. <params> . . . . . . . . . . . . . . . . . . . . 50
skipping to change at page 5, line 32 skipping to change at page 5, line 32
conferences (including mixers between connections), as well as conferences (including mixers between connections), as well as
associated responses and notifications. The package also defines associated responses and notifications. The package also defines
elements for auditing package capabilities and mixers. elements for auditing package capabilities and mixers.
This package has been designed to satisfy media mixing requirements This package has been designed to satisfy media mixing requirements
documented in the Media Server Control Protocol Requirements document documented in the Media Server Control Protocol Requirements document
([RFC5167]); more specifically REQ-MCP-22, REQ-MCP-23, REQ-MCP-24, ([RFC5167]); more specifically REQ-MCP-22, REQ-MCP-23, REQ-MCP-24,
REQ-MCP-25, REQ-MCP-26 and REQ-MCP-27. REQ-MCP-25, REQ-MCP-26 and REQ-MCP-27.
The package provides the major conferencing functionality of SIP The package provides the major conferencing functionality of SIP
Media Server languages such as MSCML ([RFC5022]) and MSML ([MSML]). Media Server languages such as MSCML ([RFC5022]) and MSML
A key differentiator is that this package provides such functionality ([RFC5707]). A key differentiator is that this package provides such
using the Media Control Channel Framework. functionality using the Media Control Channel Framework.
Out of scope for this mixer package are more advanced functions Out of scope for this mixer package are more advanced functions
including personalized video mixes for conference participants, including personalized video mixes for conference participants,
support for floor control protocols, as well as support for video support for floor control protocols, as well as support for video
overlays and text insertion. Such functionality can be addressed by overlays and text insertion. Such functionality can be addressed by
extensions to this package (through addition of foreign elements or extensions to this package (through addition of foreign elements or
attributes from another namespace) or use of other control packages attributes from another namespace) or use of other control packages
which could build upon this package. which could build upon this package.
The functionality of this package is defined by messages, containing The functionality of this package is defined by messages, containing
skipping to change at page 13, line 32 skipping to change at page 13, line 32
<unjoin> delete a media stream (for example, remove a participant <unjoin> delete a media stream (for example, remove a participant
from a conference). See Section 4.2.2.4 from a conference). See Section 4.2.2.4
Responses from the MS describe the status of the requested operation. Responses from the MS describe the status of the requested operation.
Responses are specified in a <response> element (Section 4.2.3) which Responses are specified in a <response> element (Section 4.2.3) which
includes a mandatory attribute describing the status in terms of a includes a mandatory attribute describing the status in terms of a
numeric code. Response status codes are defined in Section 4.5. The numeric code. Response status codes are defined in Section 4.5. The
MS MUST respond to a request message with a response message. If the MS MUST respond to a request message with a response message. If the
MS is not able to process the request and carry out the mixer MS is not able to process the request and carry out the mixer
operation (in whole or in part), then the request has failed: the MS operation (in whole or in part), then the request has failed: the MS
MUST ensure that no part of the requested mixer operaton is carried MUST ensure that no part of the requested mixer operation is carried
out, and the MS MUST indicate the class of failure using an out, and the MS MUST indicate the class of failure using an
appropriate 4xx response code. Unless an error response code is appropriate 4xx response code. Unless an error response code is
specified for a class of error within this section, implementations specified for a class of error within this section, implementations
follow Section 4.5 in determining the appropriate status code for the follow Section 4.5 in determining the appropriate status code for the
response. response.
Notifications are sent from the MS to provide updates on the status Notifications are sent from the MS to provide updates on the status
of a mixer operation or subscription. Notifications are specified in of a mixer operation or subscription. Notifications are specified in
an <event> element (Section 4.2.4). an <event> element (Section 4.2.4).
skipping to change at page 18, line 25 skipping to change at page 18, line 25
The <audio-mixing> element has the following attributes: The <audio-mixing> element has the following attributes:
type: is a string indicating the audio stream mixing policy. type: is a string indicating the audio stream mixing policy.
Defined values are: "nbest" (where the N best (loudest) Defined values are: "nbest" (where the N best (loudest)
participant signals are mixed) and "controller" (where the participant signals are mixed) and "controller" (where the
contributing participant(s) is/are selected by the controlling AS contributing participant(s) is/are selected by the controlling AS
via an external floor control protocol). The attribute is via an external floor control protocol). The attribute is
optional. The default value is "nbest". optional. The default value is "nbest".
n: indicates the number of eligible participants included in the n: indicates the number of eligible participants included in the
conference audio mix. An eligible participant is a partipicant conference audio mix. An eligible participant is a participant
who contributes audio to the conference. Inclusion is based on who contributes audio to the conference. Inclusion is based on
having the greatest audio energy. A valid value is a non-negative having the greatest audio energy. A valid value is a non-negative
integer (see Section 4.6.2). A value of 0 indicates that all integer (see Section 4.6.2). A value of 0 indicates that all
participants contributing audio to the conference are included in participants contributing audio to the conference are included in
the audio mix. The default value is 0. The element is optional. the audio mix. The default value is 0. The element is optional.
If the type attribute does not have the value "nbest", the MS ignores If the type attribute does not have the value "nbest", the MS ignores
the "n" attribute. the "n" attribute.
The <audio-mixing> element has no child elements. The <audio-mixing> element has no child elements.
For example, a fragment where the audio mixing policy is set to For example, a fragment where the audio mixing policy is set to
"nbest" with 3 participants to be included: "nbest" with 3 participants to be included:
<audio-mixing type="nbest" n="3"/> <audio-mixing type="nbest" n="3"/>
If the conference had 200 participants of whom 30 contributed audio, If the conference had 200 participants of whom 30 contributed audio,
then there would be 30 eligible participants for the audio mix. Of then there would be 30 eligible participants for the audio mix. Of
these, the 3 loudest partipicants would have their audio included in these, the 3 loudest participants would have their audio included in
the conference. the conference.
4.2.1.4.2. <video-layouts> 4.2.1.4.2. <video-layouts>
The <video-layouts> element describe the video presentation layout The <video-layouts> element describe the video presentation layout
configuration for participants providing a video input stream to the configuration for participants providing a video input stream to the
conference. This element allows multiple video layouts to be conference. This element allows multiple video layouts to be
specified so that the MS automatically changes layout depending on specified so that the MS automatically changes layout depending on
the number of video-enabled participants. the number of video-enabled participants.
skipping to change at page 33, line 26 skipping to change at page 33, line 26
more): more):
<stream>: an element that both identifies the media streams to <stream>: an element that both identifies the media streams to
modify and defines the way that each stream is now to be modify and defines the way that each stream is now to be
configured (see Section 4.2.2.5). configured (see Section 4.2.2.5).
The MS MUST support <modifyjoin> for any stream that was established The MS MUST support <modifyjoin> for any stream that was established
using <join>. using <join>.
The MS MUST configure the streams that are included within The MS MUST configure the streams that are included within
<modifyjoin> to that stated by the child elements. It MUST NOT <modifyjoin> to that stated by the child elements.
change the configuration of any streams not included as child
elements.
If the MS is unable to modify the join as specified in <stream> If the MS is unable to modify the join as specified in <stream>
elements because a <stream> element is in conflict with (a) another elements because a <stream> element is in conflict with (a) another
<stream> element, (b) with specified connection or conference media <stream> element, (b) with specified connection or conference media
capabilities (including supported or available codec information), or capabilities (including supported or available codec information), or
(c) with a SDP label value as part of the connection-id (see Section (c) with a SDP label value as part of the connection-id (see Section
16.1 of [I-D.ietf-mediactrl-sip-control-framework]), then the MS 16.1 of [I-D.ietf-mediactrl-sip-control-framework]), then the MS
reports an error (407) and MUST NOT modify the join between the reports an error (407) and MUST NOT modify the join between the
entities and MUST NOT change existing streams of the entities. entities and MUST NOT change existing streams of the entities.
skipping to change at page 38, line 44 skipping to change at page 38, line 34
4.2.2.5.2. <clamp> 4.2.2.5.2. <clamp>
The <clamp> element is used to configure whether tones are filtered The <clamp> element is used to configure whether tones are filtered
and removed from a media stream. and removed from a media stream.
The <clamp> element has no child elements but has the following The <clamp> element has no child elements but has the following
attributes: attributes:
tones: A space-separated list of the tones to remove. The attribute tones: A space-separated list of the tones to remove. The attribute
is mandatory. is optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C
D" (i.e. all DTMF tones removed).
4.2.2.5.3. <region> 4.2.2.5.3. <region>
The <region> element is used to explicitly specify the region within The <region> element is used to explicitly specify the region within
a video layout where the media stream is displayed. a video layout where the media stream is displayed.
The <region> element has no attributes and its content model The <region> element has no attributes and its content model
specifies the name of the region layout. specifies the name of the region layout.
4.2.2.5.4. <priority> 4.2.2.5.4. <priority>
skipping to change at page 57, line 20 skipping to change at page 57, line 20
A time designation consists of a non-negative real number followed by A time designation consists of a non-negative real number followed by
a time unit identifier. a time unit identifier.
The time unit identifiers are: "ms" (milliseconds) and "s" (seconds). The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).
Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s". Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".
4.6.6. MIME Media Type 4.6.6. MIME Media Type
A string formated as a IANA MIME media type ([MIME.mediatypes]). A string formatted as a IANA MIME media type ([MIME.mediatypes]).
5. Formal Syntax 5. Formal Syntax
This section defines the XML schema for the Mixer Control Package. This section defines the XML schema for the Mixer Control Package.
The schema defines datatypes, attributes, and mixer elements in the The schema defines datatypes, attributes, and mixer elements in the
urn:ietf:params:xml:ns:msc-mixer namespace. In most elements the urn:ietf:params:xml:ns:msc-mixer namespace. In most elements the
order of child elements is significant. The schema is extensible: order of child elements is significant. The schema is extensible:
elements allow attributes and child elements from other namespaces. elements allow attributes and child elements from other namespaces.
Elements from outside this package's namespace can occur after Elements from outside this package's namespace can occur after
skipping to change at page 58, line 30 skipping to change at page 58, line 30
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
elementFormDefault="qualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:msc-mixer" xmlns="urn:ietf:params:xml:ns:msc-mixer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
IETF MediaCtrl Mixer 1.0 (20090220) IETF MediaCtrl Mixer 1.0 (20100225)
This is the schema of the Mixer control package. It This is the schema of the Mixer control package. It
defines request, response and notification elements for defines request, response and notification elements for
mixing. mixing.
The schema namespace is urn:ietf:params:xml:ns:msc-mixer The schema namespace is urn:ietf:params:xml:ns:msc-mixer
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
skipping to change at page 67, line 47 skipping to change at page 67, line 47
<xsd:element name="volume" type="volumeType" /> <xsd:element name="volume" type="volumeType" />
<xsd:complexType name="clampType"> <xsd:complexType name="clampType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="tones" type="xsd:string" <xsd:attribute name="tones" type="xsd:string"
use="required" /> default="1 2 3 4 5 6 7 8 9 0 A B C D"/>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="clamp" type="clampType" /> <xsd:element name="clamp" type="clampType" />
<!-- region --> <!-- region -->
<xsd:simpleType name="regionType"> <xsd:simpleType name="regionType">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
skipping to change at page 84, line 12 skipping to change at page 84, line 12
</modifyjoin> </modifyjoin>
</mscmixer> </mscmixer>
7. Security Considerations 7. Security Considerations
As this control package processes XML markup, implementations MUST As this control package processes XML markup, implementations MUST
address the security considerations of [RFC3023]. address the security considerations of [RFC3023].
As a Control Package of the Media Control Channel Framework, As a Control Package of the Media Control Channel Framework,
security, confidentiality and integrity of messages transported over security, confidentiality and integrity of messages transported over
the control channel MUST be addressed as described in Section 11 of the control channel MUST be addressed as described in Section 12 of
the Media Control channel Framework the Media Control channel Framework
([I-D.ietf-mediactrl-sip-control-framework]), including Transport ([I-D.ietf-mediactrl-sip-control-framework]), including Transport
Level Protection, Control Channel Policy Management and Session Level Protection, Control Channel Policy Management and Session
Establishment. In addition, implementations MUST address security, Establishment. In addition, implementations MUST address security,
confidentiality and integrity of User Agent sessions with the MS, confidentiality and integrity of User Agent sessions with the MS,
both in terms of SIP signaling and associated RTP media flow; see both in terms of SIP signaling and associated RTP media flow; see
[I-D.ietf-mediactrl-sip-control-framework] for further details on [I-D.ietf-mediactrl-sip-control-framework] for further details on
this topic. this topic.
Adequate transport protection and authentication are critical, Adequate transport protection and authentication are critical,
skipping to change at page 84, line 46 skipping to change at page 84, line 46
Resource Exhaustion: An attacker could insert into the control Resource Exhaustion: An attacker could insert into the control
channel new request messages (or modify existing ones) with, for channel new request messages (or modify existing ones) with, for
instance, <createconference> elements causing large numbers of instance, <createconference> elements causing large numbers of
conference mixer resources to be allocated. At some point this conference mixer resources to be allocated. At some point this
will exhaust the number of conference mixers that the MS is able will exhaust the number of conference mixers that the MS is able
to allocate. to allocate.
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 12.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 channel. Such a security policy is only useful more than one control channel. Such a security policy is only useful
for secure, confidential and integrity protected channels. The for secure, confidential and integrity protected channels. The
identity of control channels is determined by the channel identifier: identity of control channels is determined by the channel identifier:
i.e. the value of the cfw-id attribute in the SDP and Dialog-ID i.e. the value of the cfw-id attribute in the SDP and Dialog-ID
header in the channel protocol (see header in the channel protocol (see
skipping to change at page 85, line 32 skipping to change at page 85, line 32
conference and join mixers which have been created on the same conference and join mixers which have been created on the same
control channel as the one upon the <audit> request is sent. For control channel as the one upon the <audit> request is sent. For
example, if a join between two connections has been created on one example, if a join between two connections has been created on one
channel, then a request on another channel to audit all mixers - channel, then a request on another channel to audit all mixers -
<audit mixers="true"/> - would not report on this join mixer. <audit mixers="true"/> - would not report on this join mixer.
Rejection: The MS SHOULD reject requests to audit or manipulate an Rejection: The MS SHOULD reject requests to audit or manipulate an
existing conference or join mixer on the MS if the channel is not existing conference or join mixer on the MS if the channel is not
the same as the one used when the mixer was created. The MS the same as the one used when the mixer was created. The MS
rejects a request by sending a Control Framework 403 response (see rejects a request by sending a Control Framework 403 response (see
Section 7.4 and Section 11.3 of Section 7.4 and Section 12.3 of
[I-D.ietf-mediactrl-sip-control-framework]). For example, if a [I-D.ietf-mediactrl-sip-control-framework]). For example, if a
channel with identifier 'cfw1234' has been used to send a request channel with identifier 'cfw1234' has been used to send a request
to create a particular conference and the MS receives on channel to create a particular conference and the MS receives on channel
'cfw98969' a request to audit or destroy this particular 'cfw98969' a request to audit or destroy this particular
conference, then the MS sends a 403 framework response. conference, then the MS sends a 403 framework response.
There can be valid reasons why an implementation does not reject an There can be valid reasons why an implementation does not reject an
audit or mixer manipulation request on a different channel from the audit or mixer manipulation request on a different channel from the
one which created the mixer. For example, a system administrator one which created the mixer. For example, a system administrator
might require a separate channel to audit mixer resources created by might require a separate channel to audit mixer resources created by
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 -11 and -10 versions
(addressing IETF Last Call comments):
o 4.2.2.3: For <modifyjoin>, removed the statement "It MUST NOT
change the configuration of any streams not included as child
elements." since modifications in stream directionality can affect
other streams of the same type.
o 4.2.2.5.2: Changed definition of tones attribute of <clamp>
element so that if the element is specified, then all DTMF tones
are clamped by default. Updated XML schema.
o 7: Corrected references from Section 11 to Section 12 in Control
Framework.
o Fixed various typos.
The following are the changes between the -10 and -09 versions: The following are the changes between the -10 and -09 versions:
o References: Moved the XCON reference to the Normative References o References: Moved the XCON reference to the Normative References
section. section.
o 4.2: Mixer Elements: clarified that when a requested mixer o 4.2: Mixer Elements: clarified that when a requested mixer
operation (partially) fails, the MS carries out no part of the operation (partially) fails, the MS carries out no part of the
operation and sends an error response. operation and sends an error response.
The following are the changes between the -09 and -08 versions The following are the changes between the -09 and -08 versions
skipping to change at page 100, line 18 skipping to change at page 100, line 18
[I-D.ietf-mediactrl-sip-control-framework] [I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-11 (work in draft-ietf-mediactrl-sip-control-framework-11 (work in
progress), October 2009. progress), October 2009.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-14 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18
(work in progress), November 2009. (work in progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
skipping to change at page 100, line 46 skipping to change at page 100, line 46
12.2. Informative References 12.2. Informative References
[IANA] "IANA registry for RTP Payload Types", [IANA] "IANA registry for RTP Payload Types",
<http://www.iana.org/assignments/rtp-parameters>. <http://www.iana.org/assignments/rtp-parameters>.
[MIME.mediatypes] [MIME.mediatypes]
"IANA registry for MIME Media Types", "IANA registry for MIME Media Types",
<http://www.iana.org/assignments/media-types/>. <http://www.iana.org/assignments/media-types/>.
[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
Markup Language (MSML)", draft-saleem-msml-09 (work in
progress), July 2009.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022, Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007. September 2007.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010.
Authors' Addresses Authors' Addresses
Scott McGlashan Scott McGlashan
Hewlett-Packard Hewlett-Packard
Email: smcg.stds01@mcglashan.org Email: smcg.stds01@mcglashan.org
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rain Willow Communications
 End of changes. 26 change blocks. 
32 lines changed or deleted 47 lines changed or added

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