draft-ietf-mediactrl-mixer-control-package-03.txt   draft-ietf-mediactrl-mixer-control-package-04.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: June 1, 2009 Rain Willow Communications Expires: July 31, 2009 Rain Willow Communications
C. Boulton C. Boulton
Avaya Avaya
November 28, 2008 January 27, 2009
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-03 draft-ietf-mediactrl-mixer-control-package-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 1, 2009. This Internet-Draft will expire on July 31, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 2, line 45 skipping to change at page 2, line 45
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> . . . . . . . . . . . . . . . . . . . . . 33 4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . . 34
4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . . 34 4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . . 35
4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . . 36 4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 36 4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . . 36 4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . . 36 4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . . 38
4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . . 37 4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 38 4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39
4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 38 4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 39
4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 38 4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40
4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . . 40 4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . . 41
4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 41 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 43 4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 44
4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . . 44 4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . . 45
4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . . 45 4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . . 46
4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 45 4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 46
4.3.2.2.1.1. <participants> . . . . . . . . . . . . . . 46 4.3.2.2.1.1. <participants> . . . . . . . . . . . . . . 47
4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 46 4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 47
4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 47 4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48
4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49
4.5. <params> . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.5. <params> . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5.1. <param> . . . . . . . . . . . . . . . . . . . . . . . 49 4.5.1. <param> . . . . . . . . . . . . . . . . . . . . . . . 50
4.6. Response Status Codes . . . . . . . . . . . . . . . . . . 49 4.6. Response Status Codes . . . . . . . . . . . . . . . . . . 50
4.7. Type Definitions . . . . . . . . . . . . . . . . . . . . . 55 4.7. Type Definitions . . . . . . . . . . . . . . . . . . . . . 56
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 56 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1. AS-MS Framework Interaction Examples . . . . . . . . . . . 75 6.1. AS-MS Framework Interaction Examples . . . . . . . . . . . 76
6.1.1. Creating a conference mixer and joining a 6.1.1. Creating a conference mixer and joining a
participant . . . . . . . . . . . . . . . . . . . . . 75 participant . . . . . . . . . . . . . . . . . . . . . 76
6.1.2. Receiving active talker notifications . . . . . . . . 76 6.1.2. Receiving active talker notifications . . . . . . . . 77
6.1.3. Conference termination . . . . . . . . . . . . . . . . 76 6.1.3. Conference termination . . . . . . . . . . . . . . . . 77
6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 76 6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 77
6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . . 77 6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . . 78
6.2.2. Bridging connections . . . . . . . . . . . . . . . . . 79 6.2.2. Bridging connections . . . . . . . . . . . . . . . . . 80
6.2.3. Video conferencing . . . . . . . . . . . . . . . . . . 80 6.2.3. Video conferencing . . . . . . . . . . . . . . . . . . 81
7. Security Considerations . . . . . . . . . . . . . . . . . . . 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
8.1. Control Package Registration . . . . . . . . . . . . . . . 85 8.1. Control Package Registration . . . . . . . . . . . . . . . 86
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 85 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 86
8.3. MIME Registration . . . . . . . . . . . . . . . . . . . . 85 8.3. MIME Registration . . . . . . . . . . . . . . . . . . . . 86
9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 86 9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 87
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 93
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95
12.1. Normative References . . . . . . . . . . . . . . . . . . . 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 95
12.2. Informative References . . . . . . . . . . . . . . . . . . 93 12.2. Informative References . . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97
Intellectual Property and Copyright Statements . . . . . . . . . . 96
1. Introduction 1. Introduction
The Media Control Channel Framework The Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] provides a generic [I-D.ietf-mediactrl-sip-control-framework] provides a generic
approach for establishment and reporting capabilities of remotely approach for establishment and reporting capabilities of remotely
initiated commands. The Framework utilizes many functions provided initiated commands. The Framework utilizes many functions provided
by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous
and establishment of a reliable channel for control interactions. and establishment of a reliable channel for control interactions.
The Control Framework also introduces the concept of a Control The Control Framework also introduces the concept of a Control
skipping to change at page 25, line 47 skipping to change at page 25, line 47
receive the same video mix. The attribute is optional. The receive the same video mix. The attribute is optional. The
default value is false. If the type attribute is not set to default value is false. If the type attribute is not set to
'vas', the MS ignores this attribute. 'vas', the MS ignores this attribute.
If the MS does not support the specified video switching policy or If the MS does not support the specified video switching policy or
other configuration parameters (including separate active speaker other configuration parameters (including separate active speaker
video mixes), then MS reports a 409 error (Section 4.6) in the video mixes), then MS reports a 409 error (Section 4.6) in the
response to the request element containing the <video-switch> response to the request element containing the <video-switch>
element. element.
If the MS receives a <join> or <modifyjoin> request containing a a If the MS receives a <join> or <modifyjoin> request containing a
<stream> element (Section 4.2.2.5) specifying a region and the <stream> element (Section 4.2.2.5) specifying a region and the
conference video switching policy is set to 'vas', then the MS conference video switching policy is set to 'vas', then the MS
ignores the region (i.e. conference switching policy takes ignores the region (i.e. conference switching policy takes
precedence). precedence).
If the MS receives a <join> or <modifyjoin> request containing a If the MS receives a <join> or <modifyjoin> request containing a
<stream> element (Section 4.2.2.5) specifying a region which is not <stream> element (Section 4.2.2.5) specifying a region which is not
defined for the currently active video layout, the MS MUST NOT report defined for the currently active video layout, the MS MUST NOT report
an error. Even though the participant is not currently visible, the an error. Even though the participant is not currently visible, the
MS displays the participant if the layout changes to one which MS displays the participant if the layout changes to one which
skipping to change at page 32, line 25 skipping to change at page 32, line 25
The <modifyjoin> element has the following child elements (1 or The <modifyjoin> element has the following child elements (1 or
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 media server 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. It MUST NOT
change the configuration of any streams not included as child change the configuration of any streams not included as child
elements. 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 or (c) with a SDP label value as part of the capabilities or (c) with a SDP label value as part of the
connection-id (see Section 17.1 of connection-id (see Section 17.1 of
[I-D.ietf-mediactrl-sip-control-framework]), then the MS reports an [I-D.ietf-mediactrl-sip-control-framework]), then the MS reports an
skipping to change at page 33, line 5 skipping to change at page 33, line 5
If the specified entities are not already joined, then the MS reports If the specified entities are not already joined, then the MS reports
an error (408). an error (408).
If the MS is unable to modify the join between the specified entities If the MS is unable to modify the join between the specified entities
for any other reason, the MS reports an error (411). for any other reason, the MS reports an error (411).
When an MS has finished processing a <modifyjoin> request, it MUST When an MS has finished processing a <modifyjoin> request, it MUST
reply with an appropriate <response> element (Section 4.2.3). reply with an appropriate <response> element (Section 4.2.3).
In cases where stream characteristics are controlled independently
for each direction, then a <modifyjoin> request needs to specify a
child element for each direction in order to retain the original
stream directionality. For the example, if a <join> request
establishes independent control for each direction of an audio stream
(see Section 4.2.2.5):
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1536067209~913cd14c" id2="conference1">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/>
</stream>
<stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/>
</stream>
</join>
</mscmixer>
then the following <modifyjoin> request
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conference1">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="0"/>
</stream>
</modifyjoin>
</mscmixer>
would cause, in addition to the sendonly volume being modified, that
the overall stream directionality changes from sendrecv to sendonly
since there is no <stream> element in this <modifyjoin> request for
the recvonly direction. The following would change the sendonly
volume and retain the recvonly stream together with its original
characteristics such as volume:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conference1">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="0"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
4.2.2.4. <unjoin> 4.2.2.4. <unjoin>
The <unjoin> element is sent to the MS to request removal of The <unjoin> element is sent to the MS to request removal of
previously established media stream(s) from between a connection and previously established media stream(s) from between a connection and
a conference, between two connections, or between two conferences. a conference, between two connections, or between two conferences.
The <unjoin> element has the following attributes: The <unjoin> 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
identifier MUST conform to the syntax defined in Section 17.1 of identifier MUST conform to the syntax defined in Section 17.1 of
skipping to change at page 35, line 23 skipping to change at page 36, line 23
MS ignores <volume> and <clamp> elements. MS ignores <volume> and <clamp> elements.
If the "media" attribute does not have the value of "video", then the If the "media" attribute does not have the value of "video", then the
MS ignores a <region> element. MS ignores a <region> element.
For example, a request to join a connection to conference in both For example, a request to join a connection to conference in both
directions with volume control: directions with volume control:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1536067209~913cd14c" id2="conference1"> <join id1="1536067209~913cd14c" id2="conference1">
<stream type="audio" direction="sendrecv"> <stream media="audio" direction="sendrecv">
<volume controltype="setgain" value="-3"/> <volume controltype="setgain" value="-3"/>
</stream> </stream>
</join> </join>
</mscmixer> </mscmixer>
where audio flow from the connection (id1) to the conference (id2) where audio flow from the connection (id1) to the conference (id2)
has the volume lowered by 3dB, and likewise the volume of the audio has the volume lowered by 3dB, and likewise the volume of the audio
flow from the conference to the connection is lowered by 3 dB. flow from the conference to the connection is lowered by 3 dB.
In this example, the volume is independently controlled for each In this example, the volume is independently controlled for each
direction. direction.
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1536067209~913cd14c" id2="conference1"> <join id1="1536067209~913cd14c" id2="conference1">
<stream type="audio" direction="sendonly"> <stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/> <volume controltype="setgain" value="-3"/>
</stream> </stream>
<stream type="audio" direction="recvonly"> <stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/> <volume controltype="setgain" value="+3"/>
</stream> </stream>
</join> </join>
</mscmixer> </mscmixer>
where audio flow from the connection (id1) to the conference (id2) where audio flow from the connection (id1) to the conference (id2)
has the volume lowered by 3dB, but the volume of the audio flow from has the volume lowered by 3dB, but the volume of the audio flow from
the conference to the connection is raised by 3 dB. the conference to the connection is raised by 3 dB.
4.2.2.5.1. <volume> 4.2.2.5.1. <volume>
skipping to change at page 36, line 27 skipping to change at page 37, line 27
be adjusted automatically to the level specified by the "value" be adjusted automatically to the level specified by the "value"
attribute), "setgain" (use the value of the "value" attribute as a attribute), "setgain" (use the value of the "value" attribute as a
specific gain measured in dB to apply), "setstate" (set the state specific gain measured in dB to apply), "setstate" (set the state
of the stream to "mute" or "unmute" as specified by the value of of the stream to "mute" or "unmute" as specified by the value of
the "value" attribute). The attribute is mandatory. the "value" attribute). The attribute is mandatory.
value: a string specifying the amount or state for the volume value: a string specifying the amount or state for the volume
control defined by the value of the "controltype" attribute. The control defined by the value of the "controltype" attribute. The
attribute is optional. There is no default value. attribute is optional. There is no default value.
If the audio media stream is in a muted state, then the MS also
changes automatically the state to unmuted with an "automatic" or
"setgain" volume control. For the example, assume an audio stream
has been muted with <volume controltype="setstate" value="mute"/>.
If the gain on the same stream is changed with <volume
controltype="setgain" value="+3"/>, then the volume is increased and
stream state is also changed to unmuted.
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 mandatory.
skipping to change at page 82, line 28 skipping to change at page 83, line 28
Adequate transport protection and authentication are critical, Adequate transport protection and authentication are critical,
especially when the implementation is deployed in open networks. If especially when the implementation is deployed in open networks. If
the implementation fails to correctly address these issues, it risks the implementation fails to correctly address these issues, it risks
exposure to malicious attacks, including (but not limited to): exposure to malicious attacks, including (but not limited to):
Denial of Service: An attacker could insert a request message into Denial of Service: An attacker could insert a request message into
the transport stream causing specific conferences or join mixers the transport stream causing specific conferences or join mixers
on the MS to be destroyed. For example, <destroyconference on the MS to be destroyed. For example, <destroyconference
conferenceid="XXXX">, where the value of "XXXX" could be guessed conferenceid="XXXX">, where the value of "XXXX" could be guessed
or discovered by auditing active mixers on the MS using an <audit> or discovered by auditing active mixers on the MS using an <audit>
request. request. Likewise, an attacker could impersonate the MS and
insert error responses into the transport stream so denying the AS
access to package capabilities.
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 11.3 of
[I-D.ietf-mediactrl-sip-control-framework]). [I-D.ietf-mediactrl-sip-control-framework]).
Since creation of conferences and other mixers is associated with Since creation of conference and join mixers is associated with media
media mixing resources on the MS, the security policy for this mixing resources on the MS, the security policy for this control
control package needs to address how such mixers are securely managed package needs to address how such mixers are securely managed across
across more than one control channels. The identity of control more than one control channels. Such a security policy is only
channels is determined by the channel identifier: i.e. the value of useful for secure, confidential and integrity protected channels.
the cfw-id attribute in the SDP and Dialog-ID header in the channel The identity of control channels is determined by the channel
protocol (see [I-D.ietf-mediactrl-sip-control-framework]). Channels identifier: i.e. the value of the cfw-id attribute in the SDP and
are the same if they have the same identifier; otherwise, they are Dialog-ID header in the channel protocol (see
different. This control package imposes the following additional [I-D.ietf-mediactrl-sip-control-framework]). Channels are the same
security policies: if they have the same identifier; otherwise, they are different.
This control package imposes the following additional security
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 a Notifications: The MS MUST only send notification events for
conference mixer using the same control channel as it received the conference and join mixers using the same control channel as it
request creating the conference mixer. received the request creating the mixer.
Auditing: The MS MUST only provide audit information about mixers Auditing: The MS MUST only provide audit information about
which have been created on the same control channel as the one conference and join mixers which have been created on the same
upon the <audit> request is sent. control channel as the one upon the <audit> request is sent. For
example, if a join between two connections has been created on one
channel, then a request on another channel to audit all mixers -
<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 mixer on the MS if the channel is not the same as the one existing conference or join mixer on the MS if the channel is not
used when the mixer was created. The MS rejects a request by the same as the one used when the mixer was created. The MS
sending a Control Framework 403 response (see Section 7.4 and rejects a request by sending a Control Framework 403 response (see
Section 11.3 of [I-D.ietf-mediactrl-sip-control-framework]). For Section 7.4 and Section 11.3 of
example, if a channel with identifier 'cfw1234' has been used to [I-D.ietf-mediactrl-sip-control-framework]). For example, if a
send a request to create a particular conference and the MS channel with identifier 'cfw1234' has been used to send a request
receives on channel 'cfw98969' a request to audit or destroy that to create a particular conference and the MS receives on channel
'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
system users and to terminate mixers consuming excessive system system users and to terminate mixers consuming excessive system
resources. Alternatively, a system monitor or resource broker might resources. Alternatively, a system monitor or resource broker might
require a separate channel to audit mixers managed by this package on require a separate channel to audit mixers managed by this package on
a MS. However, the full implications need to be understood by the a MS. However, the full implications need to be understood by the
skipping to change at page 86, line 9 skipping to change at page 87, line 9
XML namspace: urn:ietf:params:xml:ns:msc-mixer XML namspace: urn:ietf:params:xml:ns:msc-mixer
8.3. MIME Registration 8.3. MIME Registration
Mime type: application/msc-mixer+xml Mime type: application/msc-mixer+xml
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 -04 and -03 versions.
o 4.2.1.4.3: corrected typo
o 4.2.2.3: Clarified the behavior of <modifyjoin> for cases where
each direction of a stream is independently controlled.
o 4.2.2.5: Corrected syntax error in examples.
o 4.2.2.5.1: Clarified that when an audio stream is in the muted
state, then a <volume> automatic or setgain control causes the
state to change automatically to unmuted.
o 7 Security: Clarified that both conference and join mixers are
covered by the package security policies.
o 7 Security: Added a denial of service example where the attacker
impersonates the MS.
o 7 Security: Clarified that the package security policy for
multiple channels is only useful if the channels themselves are
secured.
o Updated acknowledgements.
The following are the major changes between the -03 and -02 versions. The following are the major changes between the -03 and -02 versions.
o Corrected various typos and nits. o Corrected various typos and nits.
o Conformance language: Removed unnecessary MUSTs, especially for o Conformance language: Removed unnecessary MUSTs, especially for
error codes. Changed most RECOMMENDEDs to MUST or MAY. Removed error codes. Changed most RECOMMENDEDs to MUST or MAY. Removed
lowercase 'should', 'must' and 'may'. lowercase 'should', 'must' and 'may'.
o Tidied up Abstract o Tidied up Abstract
skipping to change at page 93, line 5 skipping to change at page 94, line 10
The authors would like to thank the Mixer design team consisting of The authors would like to thank the Mixer design team consisting of
Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan and Mary Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan and Mary
Barnes who provided valuable feedback, input, diagrams and text to Barnes who provided valuable feedback, input, diagrams and text to
this document. this document.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Roni Even, Lorenzo Miniero and Steve The authors would like to thank Roni Even, Lorenzo Miniero and Steve
Buko for expert reviews of this work. Buko for expert reviews of this work.
Shawn Emery carried out a thorough security review.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-07 (work in draft-ietf-mediactrl-sip-control-framework-08 (work in
progress), November 2008. progress), December 2008.
[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.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
skipping to change at page 96, line 4 skipping to change at line 4127
Email: tim.melanchuk@gmail.com Email: tim.melanchuk@gmail.com
Chris Boulton Chris Boulton
Avaya Avaya
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: cboulton@avaya.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 23 change blocks. 
89 lines changed or deleted 185 lines changed or added

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