draft-ietf-mediactrl-mixer-control-package-07.txt   draft-ietf-mediactrl-mixer-control-package-08.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: November 29, 2009 Rain Willow Communications Expires: May 29, 2010 Rain Willow Communications
C. Boulton C. Boulton
NS-Technologies NS-Technologies
May 28, 2009 November 25, 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-07 draft-ietf-mediactrl-mixer-control-package-08
Abstract
This document defines a Media Control Channel Framework Package for
managing mixers for media conferences and connections. The package
defines request elements for managing conference mixers, managing
mixers between conferences and/or connections, as well as associated
responses and notifications. The package also defines elements for
auditing package capabilities and mixers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 November 29, 2009. This Internet-Draft will expire on May 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document defines a Media Control Channel Framework Package for This document may contain material from IETF Documents or IETF
managing mixers for media conferences and connections. The package Contributions published or made publicly available before November
defines request elements for managing conference mixers, managing 10, 2008. The person(s) controlling the copyright in some of this
mixers between conferences and/or connections, as well as associated material may not have granted the IETF Trust the right to allow
responses and notifications. The package also defines elements for modifications of such material outside the IETF Standards Process.
auditing package capabilities and mixers. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Control Package Definition . . . . . . . . . . . . . . . . . 8 3. Control Package Definition . . . . . . . . . . . . . . . . . 7
3.1. Control Package Name . . . . . . . . . . . . . . . . . . 8 3.1. Control Package Name . . . . . . . . . . . . . . . . . . 7
3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 8 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7
3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 9 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 8
3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 9 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 8
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 9 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8
3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10
4.1. <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . 12 4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 13 4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 12
4.2.1.1. <createconference> . . . . . . . . . . . . . . . 13 4.2.1.1. <createconference> . . . . . . . . . . . . . . . 12
4.2.1.2. <modifyconference> . . . . . . . . . . . . . . . 16 4.2.1.2. <modifyconference> . . . . . . . . . . . . . . . 15
4.2.1.3. <destroyconference> . . . . . . . . . . . . . . . 17 4.2.1.3. <destroyconference> . . . . . . . . . . . . . . . 16
4.2.1.4. Conference Configuration . . . . . . . . . . . . 18 4.2.1.4. Conference Configuration . . . . . . . . . . . . 17
4.2.1.4.1. <audio-mixing> . . . . . . . . . . . . . . . 18 4.2.1.4.1. <audio-mixing> . . . . . . . . . . . . . . . 17
4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 18 4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 17
4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 20 4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 19
4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 25 4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 24
4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 27 4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 26
4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 28 4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 27
4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 28 4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 27
4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 28 4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 27
4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 28 4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 27
4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 30 4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 29
4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 32 4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 31
4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 35 4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 34
4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 36 4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 35
4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 38 4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 37
4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 38 4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 38 4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 37
4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 39 4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 38
4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 39 4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 38
4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 40 4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39
4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 40 4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 39
4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 41 4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40
4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 42 4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 41
4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 43 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 45 4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 44
4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 46 4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 45
4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 47 4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 46
4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 47 4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 46
4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 48 4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 47
4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 48 4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 47
4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 49 4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48
4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1.1. <subtype> . . . . . . . . . . . . . . . . . . . . 51 4.4.1.1. <subtype> . . . . . . . . . . . . . . . . . . . . 50
4.4.1.2. <params> . . . . . . . . . . . . . . . . . . . . 51 4.4.1.2. <params> . . . . . . . . . . . . . . . . . . . . 50
4.4.1.2.1. <param> . . . . . . . . . . . . . . . . . . . 51 4.4.1.2.1. <param> . . . . . . . . . . . . . . . . . . . 50
4.5. Response Status Codes . . . . . . . . . . . . . . . . . . 52 4.5. Response Status Codes . . . . . . . . . . . . . . . . . . 51
4.6. Type Definitions . . . . . . . . . . . . . . . . . . . . 57 4.6. Type Definitions . . . . . . . . . . . . . . . . . . . . 55
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 59 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1. AS-MS Framework Interaction Examples . . . . . . . . . . 78 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 . . . . . . . . . . . . . . . . . . . . . 78 participant . . . . . . . . . . . . . . . . . . . . . 76
6.1.2. Receiving active talker notifications . . . . . . . . 79 6.1.2. Receiving active talker notifications . . . . . . . . 77
6.1.3. Conference termination . . . . . . . . . . . . . . . 79 6.1.3. Conference termination . . . . . . . . . . . . . . . 77
6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 79 6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 77
6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . 80 6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . 78
6.2.2. Bridging connections . . . . . . . . . . . . . . . . 82 6.2.2. Bridging connections . . . . . . . . . . . . . . . . 80
6.2.3. Video conferencing . . . . . . . . . . . . . . . . . 83 6.2.3. Video conferencing . . . . . . . . . . . . . . . . . 81
7. Security Considerations . . . . . . . . . . . . . . . . . . . 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
8.1. Control Package Registration . . . . . . . . . . . . . . 88 8.1. Control Package Registration . . . . . . . . . . . . . . 86
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 88 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 86
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 89 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 87
8.4. MIME Media Type Registration for 8.4. MIME Media Type Registration for
'application/msc-mixer+xml' . . . . . . . . . . . . . . . 89 'application/msc-mixer+xml' . . . . . . . . . . . . . . . 87
9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 91 9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 89
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
12.1. Normative References . . . . . . . . . . . . . . . . . . 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 98
12.2. Informative References . . . . . . . . . . . . . . . . . 100 12.2. Informative References . . . . . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
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 32, line 31 skipping to change at page 32, line 31
If the MS is unable to join the specified entities for any other If the MS is unable to join the specified entities for any other
reason, the MS reports an error (411). reason, the MS reports an error (411).
When the MS has finished processing a <join> request, it MUST reply When the MS has finished processing a <join> request, it MUST reply
with an <response> element (Section 4.2.3). with an <response> element (Section 4.2.3).
For example, a request to join two connection together: For example, a request to join two connection together:
<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="1536067209~913cd14c"/> <join id1="1536067209:913cd14c" id2="1536067209:913cd14c"/>
</mscmixer> </mscmixer>
and the response if the MS doesn't support joining media streams and the response if the MS doesn't support joining media streams
between connections: between connections:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="426" reason="mixing connections not supported"/> <response status="426" reason="mixing connections not supported"/>
</mscmixer> </mscmixer>
4.2.2.3. <modifyjoin> 4.2.2.3. <modifyjoin>
skipping to change at page 34, line 13 skipping to change at page 34, line 13
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 In cases where stream characteristics are controlled independently
for each direction, then a <modifyjoin> request needs to specify a for each direction, then a <modifyjoin> request needs to specify a
child element for each direction in order to retain the original child element for each direction in order to retain the original
stream directionality. For the example, if a <join> request stream directionality. For the example, if a <join> request
establishes independent control for each direction of an audio stream establishes independent control for each direction of an audio stream
(see Section 4.2.2.5): (see Section 4.2.2.5):
<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 media="audio" direction="sendonly"> <stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/> <volume controltype="setgain" value="-3"/>
</stream> </stream>
<stream media="audio" direction="recvonly"> <stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/> <volume controltype="setgain" value="+3"/>
</stream> </stream>
</join> </join>
</mscmixer> </mscmixer>
then the following <modifyjoin> request then the following <modifyjoin> request
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conference1"> <modifyjoin id1="1536067209:913cd14c" id2="conference1">
<stream media="audio" direction="sendonly"> <stream media="audio" direction="sendonly">
<volume controltype="setgain" value="0"/> <volume controltype="setgain" value="0"/>
</stream> </stream>
</modifyjoin> </modifyjoin>
</mscmixer> </mscmixer>
would cause, in addition to the sendonly volume being modified, that would cause, in addition to the sendonly volume being modified, that
the overall stream directionality changes from sendrecv to sendonly the overall stream directionality changes from sendrecv to sendonly
since there is no <stream> element in this <modifyjoin> request for since there is no <stream> element in this <modifyjoin> request for
the recvonly direction. The following would change the sendonly the recvonly direction. The following would change the sendonly
volume and retain the recvonly stream together with its original volume and retain the recvonly stream together with its original
characteristics such as volume: characteristics such as volume:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conference1"> <modifyjoin id1="1536067209:913cd14c" id2="conference1">
<stream media="audio" direction="sendonly"> <stream media="audio" direction="sendonly">
<volume controltype="setgain" value="0"/> <volume controltype="setgain" value="0"/>
</stream> </stream>
<stream media="audio" direction="recvonly"/> <stream media="audio" direction="recvonly"/>
</modifyjoin> </modifyjoin>
</mscmixer> </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
skipping to change at page 37, line 22 skipping to change at page 37, line 22
If the media attribute does not have the value of "audio", then the If the media attribute does not have the value of "audio", then the
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 media="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 media="audio" direction="sendonly"> <stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/> <volume controltype="setgain" value="-3"/>
</stream> </stream>
<stream media="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)
skipping to change at page 41, line 26 skipping to change at page 41, line 26
value is a non-negative integer (see Section 4.6.2). The MS MUST value is a non-negative integer (see Section 4.6.2). The MS MUST
support the following values: support the following values:
0 indicates the join has been terminated by a <unjoin> request. 0 indicates the join has been terminated by a <unjoin> request.
1 indicates the join terminated due to an execution error. 1 indicates the join terminated due to an execution error.
2 indicates that the join terminated because a connection or 2 indicates that the join terminated because a connection or
conference has terminated. conference has terminated.
3 Reserved for future use. All other valid but undefined values are reserved for future use,
where a standards-track RFC is required to define new status
4 Reserved for future use. codes. The AS MUST treat any status code it does not recognize as
being equivalent to 1 (join execution error). The attribute is
5 Reserved for future use. mandatory.
6 Reserved for future use.
7 Reserved for future use.
8 Reserved for future use.
9 Reserved for future use.
The MS MAY define other values. The AS MUST treat any status code
it does not recognize as being equivalent to 1 (join execution
error). The attribute is mandatory.
reason: a textual description providing a reason for the status reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default Section 4.6.4). The attribute is optional. There is no default
value. value.
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 16.1 of identifier MUST conform to the syntax defined in Section 16.1 of
[I-D.ietf-mediactrl-sip-control-framework] The attribute is [I-D.ietf-mediactrl-sip-control-framework] The attribute is
mandatory. mandatory.
skipping to change at page 42, line 42 skipping to change at page 42, line 30
support the following values: support the following values:
0 indicates the conference has been terminated by a 0 indicates the conference has been terminated by a
<destroyconference> request. <destroyconference> request.
1 indicates the conference terminated due to an execution error. 1 indicates the conference terminated due to an execution error.
2 indicates the conference terminated due to exceeding the 2 indicates the conference terminated due to exceeding the
maximum duration for a conference. maximum duration for a conference.
3 Reserved for future use. All other valid but undefined values are reserved for future use,
where a standards-track RFC is required to define new status
4 Reserved for future use. codes. The AS MUST treat any status code it does not recognize as
being equivalent to 1 (conference execution error). The attribute
5 Reserved for future use. is mandatory.
6 Reserved for future use.
7 Reserved for future use.
8 Reserved for future use.
9 Reserved for future use.
The MS MAY define other values. The AS MUST treat any status code
it does not recognize as being equivalent to 1 (conference
execution error). The attribute is mandatory.
reason: a textual description providing a reason for the status reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default Section 4.6.4). The attribute is optional. There is no default
value. value.
The <conferenceexit> element has no child elements. The <conferenceexit> element has no child elements.
When a MS sends a <conferenceexit> event, the identifier for the When a MS sends a <conferenceexit> event, the identifier for the
conference (conferenceid attribute) is no longer valid on the MS and conference (conferenceid attribute) is no longer valid on the MS and
skipping to change at page 46, line 31 skipping to change at page 46, line 31
</codecs> </codecs>
</capabilities> </capabilities>
<mixers> <mixers>
<conferenceaudit conferenceid="conf1"> <conferenceaudit conferenceid="conf1">
<codecs> <codecs>
<codec> <codec>
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
</codecs> </codecs>
<participants> <participants>
<participant id="1536067209~913cd14c"/> <participant id="1536067209:913cd14c"/>
</participants> </participants>
</conferenceaudit> </conferenceaudit>
<joinaudit id1="1536067209~913cd14c" id2="conf1"/> <joinaudit id1="1536067209:913cd14c" id2="conf1"/>
<joinaudit id1="1636067209~113cd14c" id2="1836067209~313cd14c"/> <joinaudit id1="1636067209:113cd14c" id2="1836067209:313cd14c"/>
<joinaudit id1="1736067209~213cd14c" id2="1936067209~413cd14c"/> <joinaudit id1="1736067209:213cd14c" id2="1936067209:413cd14c"/>
</mixers> </mixers>
</auditresponse> </auditresponse>
</mscmixer> </mscmixer>
4.3.2.1. <capabilities> 4.3.2.1. <capabilities>
The <capabilities> element provides audit information about package The <capabilities> element provides audit information about package
capabilities. capabilities.
The <capabilities> element has no attributes. The <capabilities> element has no attributes.
skipping to change at page 49, line 32 skipping to change at page 49, line 32
identifier MUST conform to the syntax defined in Section 16.1 of identifier MUST conform to the syntax defined in Section 16.1 of
[I-D.ietf-mediactrl-sip-control-framework] The attribute is [I-D.ietf-mediactrl-sip-control-framework] The attribute is
mandatory. mandatory.
The <joinaudit> element has no children. The <joinaudit> element has no children.
For example, a fragment describing an audit of two join mixers, one For example, a fragment describing an audit of two join mixers, one
between connections and the second between conferences: between connections and the second between conferences:
<mixers> <mixers>
<joinaudit id1="1536067209~913cd14" id2="1636067209~413cd14"/> <joinaudit id1="1536067209:913cd14" id2="1636067209:413cd14"/>
<joinaudit id1="conference1" id2="conference2"/> <joinaudit id1="conference1" id2="conference2"/>
</mixers> </mixers>
4.4. <codecs> 4.4. <codecs>
The <codecs> element is a container for one or more codec The <codecs> element is a container for one or more codec
definitions. Codec definitions are used by an AS to specify the definitions. Codec definitions are used by an AS to specify the
codecs allowed for a conference (e.g. when used as a child of codecs allowed for a conference (e.g. when used as a child of
<createconference> or <modifyconference). Codec definitions are used <createconference> or <modifyconference). Codec definitions are used
by an MS to provide audit information about the codecs supported by by an MS to provide audit information about the codecs supported by
skipping to change at page 51, line 46 skipping to change at page 51, line 46
The <param> element has the following attributes: The <param> element has the following attributes:
name: a string indicating the name of the parameter. The attribute name: a string indicating the name of the parameter. The attribute
is mandatory. is mandatory.
type: specifies a type indicating how the inline value of the type: specifies a type indicating how the inline value of the
parameter is to be interpreted. A valid value is a MIME media parameter is to be interpreted. A valid value is a MIME media
type (see Section 4.6.6). The attribute is optional. The default type (see Section 4.6.6). The attribute is optional. The default
value is "text/plain". value is "text/plain".
The <param> element content model is the value of the parameter. The <param> element content model (text and/or XML) is the value of
Note that a value which contains XML characters (e.g. "<") needs to the parameter. Values in XML format MUST use a namespace other than
be escaped following standard XML conventions. the one used in this specification. Note that a text value which
contains XML characters (e.g. "<") needs to be escaped following
standard XML conventions.
4.5. Response Status Codes 4.5. Response Status Codes
This section describes the response codes in Table 1 for the status This section describes the response codes in Table 1 for the status
attribute of mixer management <response> (Section 4.2.3) and audit attribute of mixer management <response> (Section 4.2.3) and audit
<auditresponse> (Section 4.3.2) responses. The MS MUST support these <auditresponse> (Section 4.3.2) responses. The MS MUST support the
status response codes. The MS MAY support other response codes. The status response codes defined here. All other valid but undefined
AS MUST treat any responses it does not recognize as being equivalent values are reserved for future use, where a standards-track RFC is
to the x00 response code for all classes. For example, if an AS required to define new status codes. The AS MUST treat any responses
receives an unrecognized response code of 499, it can safely assume it does not recognize as being equivalent to the x00 response code
that there was something wrong with its request and treat the for all classes. For example, if an AS receives an unrecognized
response as if it had received a 400 (Syntax error) response code. response code of 499, it can safely assume that there was something
wrong with its request and treat the response as if it had received a
400 (Syntax error) response code.
4xx responses are definite failure responses from a particular MS. 4xx responses are definite failure responses from a particular MS.
The reason attribute in the response SHOULD identify the failure in The reason attribute in the response SHOULD identify the failure in
more detail, for example, "Mandatory attribute missing: id2 join more detail, for example, "Mandatory attribute missing: id2 join
element" for a 400 (Syntax error) response code. element" for a 400 (Syntax error) response code.
The AS SHOULD NOT retry the same request without modification (for The AS SHOULD NOT retry the same request without modification (for
example, correcting a syntax error or changing the conferenceid to example, correcting a syntax error or changing the conferenceid to
use one available on the MS). However, the same request to a use one available on the MS). However, the same request to a
different MS might be successful; for example, if another MS supports different MS might be successful; for example, if another MS supports
skipping to change at page 53, line 18 skipping to change at page 53, line 27
| | | to the XML schema | | | | | to the XML schema | |
| | | specified in | | | | | specified in | |
| | | Section 5 or it | | | | | Section 5 or it | |
| | | violates a | | | | | violates a | |
| | | co-occurrence | | | | | co-occurrence | |
| | | constraint for a | | | | | constraint for a | |
| | | request element | | | | | request element | |
| | | defined in | | | | | defined in | |
| | | Section 4. | | | | | Section 4. | |
| | | | | | | | | |
| 401 | Reserved for | | |
| | future use | | |
| | | | |
| 402 | Reserved for | | |
| | future use | | |
| | | | |
| 403 | Reserved for | | |
| | future use | | |
| | | | |
| 404 | Reserved for | | |
| | future use | | |
| | | | |
| 405 | Conference | request uses an | Send an <audit> | | 405 | Conference | request uses an | Send an <audit> |
| | already | identifier to create | request | | | already | identifier to create | request |
| | exists | a new conference | (Section 4.3.1) | | | exists | a new conference | (Section 4.3.1) |
| | | (Section 4.2.1.1) | requesting the | | | | (Section 4.2.1.1) | requesting the |
| | | which is already | list of conference | | | | which is already | list of conference |
| | | used by another | mixer identifiers | | | | used by another | mixer identifiers |
| | | conference on the | already used by | | | | conference on the | already used by |
| | | MS. | the MS and then | | | | MS. | the MS and then |
| | | | use a conference | | | | | use a conference |
| | | | identifier which | | | | | identifier which |
skipping to change at page 55, line 4 skipping to change at page 54, line 40
| | | | and then use | | | | | and then use |
| | | | entities which are | | | | | entities which are |
| | | | listed. | | | | | listed. |
| | | | | | | | | |
| 410 | Unable to | request attempts to | | | 410 | Unable to | request attempts to | |
| | join - | join a participant | | | | join - | join a participant | |
| | conference | to a conference | | | | conference | to a conference | |
| | full | (Section 4.2.2.2) | | | | full | (Section 4.2.2.2) | |
| | | but the conference | | | | | but the conference | |
| | | is already full | | | | | is already full | |
| | | | |
| 411 | Unable to | request attempts to | | | 411 | Unable to | request attempts to | |
| | perform join | create, modify or | | | | perform join | create, modify or | |
| | mixer | delete a join | | | | mixer | delete a join | |
| | operation | between entities but | | | | operation | between entities but | |
| | | fails | | | | | fails | |
| | | | | | | | | |
| 412 | Connection | request uses an | | | 412 | Connection | request uses an | |
| | does not | identifier for a | | | | does not | identifier for a | |
| | exist | connection which | | | | exist | connection which | |
| | | does not exist on | | | | | does not exist on | |
| | | the MS. | | | | | the MS. | |
| | | | |
| 413 | Reserved for | | |
| | future use | | |
| | | | |
| 414 | Reserved for | | |
| | future use | | |
| | | | |
| 415 | Reserved for | | |
| | future use | | |
| | | | |
| 416 | Reserved for | | |
| | future use | | |
| | | | |
| 417 | Reserved for | | |
| | future use | | |
| | | | |
| 418 | Reserved for | | |
| | future use | | |
| | | | |
| 419 | Other | requested operation | | | 419 | Other | requested operation | |
| | execution | cannot be executed | | | | execution | cannot be executed | |
| | error | by the MS. | | | | error | by the MS. | |
| | | | | | | | | |
| 420 | Conference | request to create a | | | 420 | Conference | request to create a | |
| | reservation | new conference | | | | reservation | new conference | |
| | failed | (Section 4.2.1.1) | | | | failed | (Section 4.2.1.1) | |
| | | failed due to | | | | | failed due to | |
| | | unsupported | | | | | unsupported | |
| | | reservation of | | | | | reservation of | |
| | | talkers or | | | | | talkers or | |
| | | listeners. | | | | | listeners. | |
| | | | | | | | | |
| 421 | Unable to | request to create or | | | 421 | Unable to | request to create or | |
| | configure | modify a conference | | | | configure | modify a conference | |
| | audio mix | failed due to | | | | audio mix | failed due to | |
| | | unsupported audio | | | | | unsupported audio | |
| | | mix. | | | | | mix. | |
| | | | |
| 422 | Unsupported | request contains one | | | 422 | Unsupported | request contains one | |
| | media stream | or more <stream> | | | | media stream | or more <stream> | |
| | configuration | elements | | | | configuration | elements | |
| | | (Section 4.2.2.5) | | | | | (Section 4.2.2.5) | |
| | | whose configuration | | | | | whose configuration | |
| | | is not supported by | | | | | is not supported by | |
| | | the MS. | | | | | the MS. | |
| | | | | | | | | |
| 423 | Unable to | request to create or | | | 423 | Unable to | request to create or | |
| | configure | modify a conference | | | | configure | modify a conference | |
skipping to change at page 57, line 4 skipping to change at page 56, line 25
| | | support for mixing | | | | | support for mixing | |
| | | conferences. | | | | | conferences. | |
| | | | | | | | | |
| 428 | Unsupported | the request contains | | | 428 | Unsupported | the request contains | |
| | foreign | attributes or | | | | foreign | attributes or | |
| | namespace | elements from | | | | namespace | elements from | |
| | attribute or | another namespace | | | | attribute or | another namespace | |
| | element | which the MS does | | | | element | which the MS does | |
| | | not support | | | | | not support | |
| | | | | | | | | |
| 429 | Reserved for | | |
| | future use | | |
| | | | |
| 430 | Reserved for | | |
| | future use | | |
| | | | |
| 431 | Reserved for | | |
| | future use | | |
| | | | |
| 432 | Reserved for | | |
| | future use | | |
| | | | |
| 433 | Reserved for | | |
| | future use | | |
| | | | |
| 434 | Reserved for | | |
| | future use | | |
| | | | |
| 435 | Other | request requires | | | 435 | Other | request requires | |
| | unsupported | another capability | | | | unsupported | another capability | |
| | capability | not supported by the | | | | capability | not supported by the | |
| | | MS | | | | | MS | |
+-------+---------------+----------------------+--------------------+ +-------+---------------+----------------------+--------------------+
Table 1: status codes Table 1: status codes
4.6. Type Definitions 4.6. Type Definitions
skipping to change at page 80, line 37 skipping to change at page 79, line 37
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="conference created" <response status="200" reason="conference created"
conferenceid="conf1"/> conferenceid="conf1"/>
</mscmixer> </mscmixer>
The AS is now able to join connections to the conference as The AS is now able to join connections to the conference as
participants. A participant able to contribute to the audio mix participants. A participant able to contribute to the audio mix
would be joined as follows: would be joined as follows:
<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="conf1"> <join id1="1536067209:913cd14c" id2="conf1">
<stream media="audio" direction="sendrecv"/> <stream media="audio" direction="sendrecv"/>
</join> </join>
</mscmixer> </mscmixer>
If the MS can join the participant 1536067209~913cd14c to the If the MS can join the participant 1536067209:913cd14c to the
conference conf1 with audio in both directions, then it sends a conference conf1 with audio in both directions, then it sends a
successful response: successful response:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="join successful"/> <response status="200" reason="join successful"/>
</mscmixer> </mscmixer>
The AS could also join listener-only participants to the conference The AS could also join listener-only participants to the conference
by setting the stream direction to receive only: by setting the stream direction to receive only:
<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="9936067209~914cd14c" id2="conf1"> <join id1="9936067209:914cd14c" id2="conf1">
<stream media="audio" direction="recvonly"/> <stream media="audio" direction="recvonly"/>
</join> </join>
</mscmixer> </mscmixer>
If the MS can join the participant 9936067209~914cd14c to the If the MS can join the participant 9936067209:914cd14c to the
conference conf1 then it would send a successful response (not conference conf1 then it would send a successful response (not
shown). shown).
As the active talker changes, the MS sends an active talker As the active talker changes, the MS sends an active talker
notification to the AS: notification to the AS:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event> <event>
<active-talker-notify conferenceid="conf1"> <active-talker-notify conferenceid="conf1">
<active-talker connectionid="1536067209~913cd14c"/> <active-talker connectionid="1536067209:913cd14c"/>
</active-talker-notify> </active-talker-notify>
</event> </event>
</mscmixer> </mscmixer>
The AS could decide to change the status of a talker connection so The AS could decide to change the status of a talker connection so
that they can only listen: that they can only listen:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conf1"> <modifyjoin id1="1536067209:913cd14c" id2="conf1">
<stream media="audio" direction="recvonly"/> <stream media="audio" direction="recvonly"/>
</modifyjoin> </modifyjoin>
</mscmixer> </mscmixer>
Where the participant 1536067209~913cd14c is no longer able to Where the participant 1536067209:913cd14c is no longer able to
contribute to the audio mix on the conference. If the MS is able to contribute to the audio mix on the conference. If the MS is able to
execute this request, it would send a 200 response. execute this request, it would send a 200 response.
The AS could decide to remove this participant from the conference: The AS could decide to remove this participant from the conference:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<unjoin id1="1536067209~913cd14c" id2="conf1"/> <unjoin id1="1536067209:913cd14c" id2="conf1"/>
</mscmixer> </mscmixer>
Again, if the MS can execute this request, a 200 response would be Again, if the MS can execute this request, a 200 response would be
sent. sent.
Finally, the AS terminates the conference: Finally, the AS terminates the conference:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<destroyconference conferenceid="conf1"/> <destroyconference conferenceid="conf1"/>
</mscmixer> </mscmixer>
skipping to change at page 82, line 16 skipping to change at page 81, line 16
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" conferenceid="conf1"/> <response status="200" conferenceid="conf1"/>
</mscmixer> </mscmixer>
For each participant attached to the conference when it is destroyed, For each participant attached to the conference when it is destroyed,
the MS sends an unjoin notification event: the MS sends an unjoin notification event:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event> <event>
<unjoin-notify status="2" id1="9936067209~914cd14c" <unjoin-notify status="2" id1="9936067209:914cd14c"
id2="conf1"/> id2="conf1"/>
</event> </event>
</mscmixer> </mscmixer>
And the MS sends a conferenceexit notification event when the And the MS sends a conferenceexit notification event when the
conference finally exits: conference finally exits:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event> <event>
<conferenceexit status="0" conferenceid="conf1"/> <conferenceexit status="0" conferenceid="conf1"/>
skipping to change at page 82, line 39 skipping to change at page 81, line 39
6.2.2. Bridging connections 6.2.2. Bridging connections
The mixer package can be used to join connections to one another. In The mixer package can be used to join connections to one another. In
a call center scenario, for example, this package can be used to set a call center scenario, for example, this package can be used to set
up and modify connections between a caller, agent and supervisor. up and modify connections between a caller, agent and supervisor.
A caller is joined to an agent with bi-directional audio: A caller is joined to an agent with bi-directional audio:
<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="caller~001" id2="agent~002"> <join id1="caller:001" id2="agent:002">
<stream media="audio" direction="sendrecv"/> <stream media="audio" direction="sendrecv"/>
</join> </join>
</mscmixer> </mscmixer>
If the MS is able to establish this connection, then it would send a If the MS is able to establish this connection, then it would send a
200 response: 200 response:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200"/> <response status="200"/>
</mscmixer> </mscmixer>
Now assume that the AS wants a supervisor to listen into the agent Now assume that the AS wants a supervisor to listen into the agent
conversation with the caller and provide whispered guidance to the conversation with the caller and provide whispered guidance to the
agent. First the AS would send a request to join the supervisor and agent. First the AS would send a request to join the supervisor and
the caller connections: the caller connections:
<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="supervisor~003" id2="caller~001"> <join id1="supervisor:003" id2="caller:001">
<stream media="audio" direction="recvonly"/> <stream media="audio" direction="recvonly"/>
</join> </join>
</mscmixer> </mscmixer>
If this request was successful, audio output from the caller If this request was successful, audio output from the caller
connection would now be sent to both the agent and the supervisor. connection would now be sent to both the agent and the supervisor.
Second, the AS would send a request to join the supervisor and the Second, the AS would send a request to join the supervisor and the
agent connections: agent connections:
<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="supervisor~001" id2="agent~002"> <join id1="supervisor:001" id2="agent:002">
<stream media="audio" direction="sendrecv"/> <stream media="audio" direction="sendrecv"/>
</join> </join>
</mscmixer> </mscmixer>
If this request was successful, the audio mixing would occur on both If this request was successful, the audio mixing would occur on both
the agent and supervisor connections: the agent would hear the caller the agent and supervisor connections: the agent would hear the caller
and supervisor, and the supervisor would hear the agent and caller. and supervisor, and the supervisor would hear the agent and caller.
The caller would only hear the agent. If the MS is unable to join The caller would only hear the agent. If the MS is unable to join
and mix connections in this way, it would send a 426 response. and mix connections in this way, it would send a 426 response.
skipping to change at page 84, line 21 skipping to change at page 83, line 21
that case, the video layout will be quad-view (Figure 6) with the that case, the video layout will be quad-view (Figure 6) with the
most active speaker displayed in region 1. When a fifth participant most active speaker displayed in region 1. When a fifth participant
joins, the video layout automatically switches to a multiple-5x1 joins, the video layout automatically switches to a multiple-5x1
layout (Figure 9), again with the most active speaker in region 1. layout (Figure 9), again with the most active speaker in region 1.
The AS can manipulate which participants are displayed in the The AS can manipulate which participants are displayed in the
remaining regions. For example, it could force an existing remaining regions. For example, it could force an existing
conference participant to be displayed in region 2: conference participant to be displayed in region 2:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209~913cd14c" id2="conf2"> <modifyjoin id1="1536067209:913cd14c" id2="conf2">
<stream media="video"> <stream media="video">
<region>2</region> <region>2</region>
</stream> </stream>
</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].
skipping to change at page 88, line 25 skipping to change at page 87, line 25
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
To: ietf-sip-control@iana.org To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package Subject: Registration of new Channel Framework package
Package Name: msc-mixer/1.0 Package Name: msc-mixer/1.0
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Published Specification(s): RFCXXXX Published Specification(s): RFCXXXX
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 (scott.mcglashan@hp.com). 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 (scott.mcglashan@hp.com). (mediactrl@ietf.org), Scott McGlashan (smcg.stds01@mcglashan.org).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Media Control Channel Framework Mixer <title>Media Control Channel Framework Mixer
Package attributes</title> Package attributes</title>
</head> </head>
<body> <body>
<h1>Namespace for Media Control Channel <h1>Namespace for Media Control Channel
Framework Mixer Package attributes</h1> Framework Mixer Package attributes</h1>
<h2>urn:ietf:params:xml:ns:msc-mixer</h2> <h2>urn:ietf:params:xml:ns:msc-mixer</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
<p>See RFCXXXX</p> <p>See RFCXXXX</p>
</body> </body>
</html> </html>
END 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 (scott.mcglashan@hp.com). (mediactrl@ietf.org), Scott McGlashan (smcg.stds01@mcglashan.org).
Schema: The XML for this schema can be found in Schema: The XML for this schema can be found in
Section 5 of this document. 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 27 skipping to change at page 89, line 27
Security considerations: No known security considerations outside Security considerations: No known security considerations outside
of those provided by the Media Control Channel Framework Mixer of those provided by the Media Control Channel Framework Mixer
Package. Package.
Interoperability considerations: This content type provides Interoperability considerations: This content type provides
constructs for the Media Control Channel Framework Mixer package. constructs for the Media Control Channel Framework Mixer package.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Implementations of Applications which use this media type: Implementations of
the Media Control Channel Framework Mixer package. the Media Control Channel Framework Mixer package.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): (none)
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Scott Person & email address to contact for further information: Scott
McGlashan <scott.mcglashan@hp.com> 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 -08 and -07 versions.
o 8.4: Changed file extension from '.xml' to (none)
o Changed "~" to a ":" for connectionid
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
defined and all others are reserved for future use requiring a
standard-track RFC.
o 4.2.4.3: Changed <conferenceexit> status codes so that only 0-2
defined and all others are reserved for future use requiring a
standard-track RFC.
o 4.5: Changed status code for <response> and <auditresponse> so
that certain codes are defined and all others are reserved for
future use requiring a standard-track RFC.
The following are the changes between the -07 and -06 versions. The following are the changes between the -07 and -06 versions.
o Generally corrected references from Section 17.1 to Section 16.1 o Generally corrected references from Section 17.1 to Section 16.1
of Control Channel Framework. of Control Channel Framework.
o 4.2.2.2: removed "is" in "unless this is leads to a stream o 4.2.2.2: removed "is" in "unless this is leads to a stream
conflict" conflict"
o 4.2.2.3: corrected error code from 408 to 409 for "If the o 4.2.2.3: corrected error code from 408 to 409 for "If the
specified entities are not already joined, then the MS reports an specified entities are not already joined, then the MS reports an
skipping to change at page 100, line 12 skipping to change at page 99, line 12
Shawn Emery carried out a thorough security review. 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-10 (work in draft-ietf-mediactrl-sip-control-framework-11 (work in
progress), February 2009. progress), October 2009.
[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.
[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.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0 and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", W3C Recommendation, February 2004. (Third Edition)", W3C Recommendation, February 2004.
12.2. Informative References 12.2. Informative References
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., Even, R., and J. Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
Urpalainen, "Conference Information Data Model for "Conference Information Data Model for Centralized
Centralized Conferencing (XCON)", Conferencing (XCON)", draft-ietf-xcon-common-data-model-14
draft-ietf-xcon-common-data-model-12 (work in progress), (work in progress), November 2009.
October 2008.
[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 [MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
Markup Language (MSML)", draft-saleem-msml-08 (work in Markup Language (MSML)", draft-saleem-msml-09 (work in
progress), February 2009. 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.
skipping to change at page 102, line 9 skipping to change at page 101, line 9
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.
Authors' Addresses Authors' Addresses
Scott McGlashan Scott McGlashan
Hewlett-Packard Hewlett-Packard
Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com Email: smcg.stds01@mcglashan.org
Tim Melanchuk Tim Melanchuk
Rain Willow Communications Rain Willow Communications
Email: tim.melanchuk@gmail.com Email: tim.melanchuk@gmail.com
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
 End of changes. 53 change blocks. 
268 lines changed or deleted 223 lines changed or added

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