6.  Examples

   This section provides examples of the Mixer Control Package.

6.1.  AS-MS Framework Interaction Examples

   The following example assumes a Control Channel has been established
   and synced as described in the Media Control Channel Framework
   ([RFC6230]).

   The XML messages are in angled brackets (with the root <mscmixer> and
   other details omitted for clarity); the REPORT status is in
   parentheses.  Other aspects of the protocol are omitted for
   readability.

6.1.1.  Creating a Conference Mixer and Joining a Participant

   A conference mixer is created successfully and a participant is
   joined.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <createconference>       |
                |  ---------------------------------------->  |
                |                                             |
                |       (2) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |                                             |
                |       (3) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
                |       (5) CONTROL: <join id1=.. id2=..>     |
                |  ---------------------------------------->  |
                |                                             |
                |       (6) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |       (7) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (8) 200                               |
                |  ---------------------------------------->  |

6.1.2.  Receiving Active Talker Notifications

   An active talker notification event is sent by the MS.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <event ...>              |
                |  <---------------------------------------   |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |

6.1.3.  Conference Termination

   The MS receives a request to terminate the conference, resulting in
   conferenceexit and participant unjoined notifications.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <destroyconference>      |
                |  ---------------------------------------->  |
                |                                             |
                |       (2) 200: <response status="200"/>     |
                |  <---------------------------------------   |
                |                                             |
                |       (3) CONTROL: <event ..>               |
                |                   (unjoin-notify)           |
                |  <----------------------------------------  |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
                |       (5) CONTROL:  <event ..>              |
                |                   (conferenceexit)          |
                |  <----------------------------------------  |
                |                                             |
                |       (6) 200                               |
                |  ---------------------------------------->  |

6.2.  Mixing Examples

   The following examples show how the mixing package can be used to
   create audio conferences, bridge connections, and video conferences.

   The examples do not specify all messages between the AS and MS.

6.2.1.  Audio Conferencing

   The AS sends a request to create a conference mixer:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference conferenceid="conf1"
     reserved-talkers="2" reserved-listeners="3">
     <audio-mixing type="nbest"/>
     <subscribe>
      <active-talkers-sub interval="5"/>
     </subscribe>
    </createconference>
   </mscmixer>

   The request specifies that the conference is assigned the conference
   id "conf1" and is configured with 2 reserved talkers, 3 reserved
   listener slots, audio-mixing policy set to nbest, and with active
   talkers notifications set to 5 seconds.

   If the MS is able to create this conference mixer, it sends a 200
   response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" reason="conference created"
              conferenceid="conf1"/>
   </mscmixer>

   The AS is now able to join connections to the conference as
   participants.  A participant able to contribute to the audio mix
   would be joined as follows:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="1536067209:913cd14c" id2="conf1">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If the MS can join the participant 1536067209:913cd14c to the
   conference conf1 with audio in both directions, then it sends a
   successful response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" reason="join successful"/>
   </mscmixer>

   The AS could also join listener-only participants to the conference
   by setting the stream direction to receive only:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="9936067209:914cd14c" id2="conf1">
     <stream media="audio" direction="recvonly"/>
    </join>
   </mscmixer>

   If the MS can join the participant 9936067209:914cd14c to the
   conference conf1, then it would send a successful response (not
   shown).

   As the active talker changes, the MS sends an active talker
   notification to the AS:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <active-talkers-notify conferenceid="conf1">
      <active-talker connectionid="1536067209:913cd14c"/>
     </active-talkers-notify>
    </event>
   </mscmixer>

   The AS could decide to change the status of a talker connection so
   that they can only listen:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <modifyjoin id1="1536067209:913cd14c" id2="conf1">
     <stream media="audio" direction="recvonly"/>
    </modifyjoin>
   </mscmixer>

   Where the participant 1536067209:913cd14c is no longer 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.

   The AS could decide to remove this participant from the conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <unjoin id1="1536067209:913cd14c" id2="conf1"/>
   </mscmixer>

   Again, if the MS can execute this request, a 200 response would be
   sent.

   Finally, the AS terminates the conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <destroyconference conferenceid="conf1"/>
   </mscmixer>

   If the MS is able to destroy the conference conf1, it sends a 200
   response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" conferenceid="conf1"/>
   </mscmixer>

   For each participant attached to the conference when it is destroyed,
   the MS sends an unjoin notification event:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <unjoin-notify status="2" id1="9936067209:914cd14c"
         id2="conf1"/>
    </event>
   </mscmixer>

   And the MS sends a conferenceexit notification event when the
   conference finally exits:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <conferenceexit status="0" conferenceid="conf1"/>
    </event>
   </mscmixer>

6.2.2.  Bridging Connections

   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
   up and modify connections between a caller, agent, and supervisor.

   A caller is joined to an agent with bidirectional audio:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="caller:001" id2="agent:002">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If the MS is able to establish this connection, then it would send a
   200 response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200"/>
   </mscmixer>

   Now assume that the AS wants a supervisor to listen into the agent
   conversation with the caller and provide whispered guidance to the
   agent.  First, the AS would send a request to join the supervisor and
   the caller connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join  id1="supervisor:003" id2="caller:001">
     <stream media="audio" direction="recvonly"/>
    </join>
   </mscmixer>

   If this request was successful, audio output from the caller
   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
   agent connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="supervisor:001" id2="agent:002">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If this request was successful, the audio mixing would occur on both
   the agent and supervisor connections: the agent would hear the 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
   and mix connections in this way, it would send a 426 response.

6.2.3.  Video Conferencing

   In this example, an audio-video conference is created where the
   loudest participant has the most prominent region in the video
   layout.

   The AS sends a request to create an audio-video conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference conferenceid="conf2">
     <audio-mixing type="nbest"/>
     <video-layouts>
      <video-layout min-participants="1"><single-view/></video-layout>
      <video-layout min-participants="2"><dual-view/></video-layout>
      <video-layout min-participants="3"><quad-view/></video-layout>
      <video-layout min-participants="5"><multiple-5x1/></video-layout>
     </video-layouts>
     <video-switch><vas/></video-switch>
    </createconference>
   </mscmixer>

   In this configuration, the conference uses a nbest audio mixing
   policy and a <vas/> video-switching policy, so that the loudest
   speaker receives the most prominent region in the layout.  Multiple
   video layouts are specified and the active one depends on the number
   of participants.

   Assume that 4 participants are already joined to the conference.  In
   that case, the video layout will be quad-view (Figure 6) with the
   most active speaker displayed in region 1.  When a fifth participant
   joins, the video layout automatically switches to a multiple-5x1
   layout (Figure 9), again with the most active speaker in region 1.

   The AS can manipulate which participants are displayed in the
   remaining regions.  For example, it could force an existing
   conference participant to be displayed in region 2:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <modifyjoin id1="1536067209:913cd14c" id2="conf2">
     <stream media="video">
      <region>2</region>
     </stream>
    </modifyjoin>
   </mscmixer>

7.  Security Considerations

   As this Control Package processes XML markup, implementations MUST
   address the security considerations of [RFC3023].

   As a Control Package of the Media Control Channel Framework,
   security, confidentiality, and integrity of messages transported over
   the Control Channel MUST be addressed as described in Section 12 of
   the Media Control Channel Framework ([RFC6230]), including transport-
   level protection, Control Channel policy management, and session
   establishment.  In addition, implementations MUST address security,

   confidentiality, and integrity of User Agent sessions with the MS,
   both in terms of SIP signaling and the associated RTP media flow; see
   [RFC6230] for further details on this topic.

   Adequate transport protection and authentication are critical,
   especially when the implementation is deployed in open networks.  If
   the implementation fails to correctly address these issues, it risks
   exposure to malicious attacks, including (but not limited to):

   Denial of Service:  An attacker could insert a request message into
      the transport stream causing specific conferences or join mixers
      on the MS to be destroyed.  For example, <destroyconference
      conferenceid="XXXX">, where the value of "XXXX" could be guessed
      or discovered by auditing active mixers on the MS using an <audit>
      request.  Likewise, an attacker could impersonate the MS and
      insert error responses into the transport stream thereby denying
      the AS access to package capabilities.

   Resource Exhaustion:  An attacker could insert into the Control
      Channel new request messages (or modify existing ones) with, for
      instance, <createconference> elements causing large numbers of
      conference mixer resources to be allocated.  At some point, this
      will exhaust the number of conference mixers that the MS is able
      to allocate.

   The Media Control Channel Framework permits additional policy
   management (beyond that specified for the Media Control Channel
   Framework), including resource access and Control Channel usage, to
   be specified at the Control Package level.  (See Section 12.3 of
   [RFC6230].)

   Since creation of conference and join mixers is associated with
   media-mixing resources on the MS, the security policy for this
   Control Package needs to address how such mixers are securely managed
   across more than one Control Channel.  Such a security policy is only
   useful for secure, confidential, and integrity-protected channels.
   The identity of Control Channels is determined by the channel
   identifier, i.e., the value of the 'cfw-id' attribute in the SDP and
   Dialog-ID header in the channel protocol (see [RFC6230]).  Channels
   are the same 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
      audit request using the same Control Channel as the one used to
      send the request.

   Notifications:  The MS MUST only send notification events for
      conference and join mixers using the same Control Channel as it
      received the request creating the mixer.

   Auditing:  The MS MUST only provide audit information about
      conference and join mixers that have been created on the same
      Control Channel as the one upon which 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
      existing conference or join mixer on the MS if the channel is not
      the same as the one used when the mixer was created.  The MS
      rejects a request by sending a Control Framework 403 response (see
      Sections 7.4 and 12.3 of [RFC6230]).  For example, if a channel
      with identifier 'cfw1234' has been used to send a request 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 Control Framework 403 response.

   There can be valid reasons why an implementation does not reject an
   audit or mixer manipulation request on a different channel from the
   one that created the mixer.  For example, a system administrator
   might require a separate channel to audit mixer resources created by
   system users and to terminate mixers consuming excessive system
   resources.  Alternatively, a system monitor or resource broker might
   require a separate channel to audit mixers managed by this package on
   a MS.  However, the full implications need to be understood by the
   implementation and carefully weighed before accepting these reasons
   as valid.  If the reasons are not valid in their particular
   circumstances, the MS rejects such requests.

   There can also be valid reasons for 'channel handover' including high
   availability support or when one AS needs to take over management of
   mixers after the AS that created them has failed.  This could be
   achieved by the Control Channels using the same channel identifier,
   one after another.  For example, assume a channel is created with the
   identifier 'cfw1234', and the channel is used to create mixers on the
   MS.  This channel (and associated SIP dialog) then terminates due to
   a failure on the AS.  As permitted by the Control Framework, the
   channel identifier 'cfw1234' could then be reused so that another
   channel is created with the same identifier 'cfw1234', allowing it to
   'take over' management of the mixers on the MS.  Again, the
   implementation needs to understand the full implications and
   carefully weigh them before accepting these reasons as valid.  If the
   reasons are not valid for their particular circumstances, the MS uses

   the appropriate SIP mechanisms to prevent session establishment when
   the same channel identifier is used in setting up another Control
   Channel (see Section 4 of [RFC6230]).

8.  IANA Considerations

   Per this specification, IANA has registered a new Media Control
   Channel Framework Package, a new XML namespace, a new XML schema, and
   a new MIME type.

   IANA has further created a new registry for the response codes for
   the MEDIACTRL Mixer Control Package, RFC 6505.

8.1.  Control Package Registration

   This section registers a new Media Control Channel Framework package,
   per the instructions in Section 13.1 of [RFC6230].

      To: ietf-sip-control@iana.org
      Subject: Registration of new Channel Framework package
      Package Name: msc-mixer/1.0
      Published Specification(s): RFC 6505
      Person & email address to contact for further information:
         IETF MEDIACTRL working group (mediactrl@ietf.org),
         Scott McGlashan (smcg.stds01@mcglashan.org).

8.2.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688
   [RFC3688].

         URI: urn:ietf:params:xml:ns:msc-mixer
         Registrant Contact:
            IETF MEDIACTRL working group (mediactrl@ietf.org),
            Scott McGlashan (smcg.stds01@mcglashan.org).

         XML:
            BEGIN
            <?xml version="1.0"?>
            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
             <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
              <head>
               <title>Media Control Channel Framework Mixer
                      Package attributes</title>
              </head>
              <body>
               <h1>Namespace for Media Control Channel
                   Framework Mixer Package attributes</h1>
               <h2>urn:ietf:params:xml:ns:msc-mixer</h2>
           <p>See <a href="http://www.rfc-editor.org/rfc/rfc6505.txt">
              RFC 6505</a>.</p>
              </body>
             </html>
            END

8.3.  XML Schema Registration

   This section registers an XML schema as per the guidelines in RFC
   3688 [RFC3688].

      URI:  urn:ietf:params:xml:schema:msc-mixer
      Registrant Contact:
         IETF MEDIACTRL working group (mediactrl@ietf.org),
         Scott McGlashan (smcg.stds01@mcglashan.org).
      Schema:  The XML for this schema can be found in
         Section 5 of this document.

8.4.  MIME Media Type Registration for 'application/msc-mixer+xml'

   This section registers the "application/msc-mixer+xml" MIME type.

   To:  ietf-types@iana.org
   Subject:  Registration of MIME media type
             application/msc-mixer+xml
   MIME media type name:  application
   MIME subtype name:  msc-mixer+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], Section 3.2.

   Security considerations:  No known security considerations outside
      of those provided by the Media Control Channel Framework Mixer
      Package.
   Interoperability considerations:  This content type provides
      constructs for the Media Control Channel Framework Mixer Package.
   Published specification:  RFC 6505
   Applications that use this media type:  Implementations of
      the Media Control Channel Framework Mixer package.
   Additional Information:
      Magic Number(s): (none)
      File extension(s): (none)
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:
      Scott McGlashan <smcg.stds01@mcglashan.org>
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information:  None.

8.5.  Mixer Control Package Status Code Registration

   This section creates an IANA registry for the response codes for the
   MEDIACTRL Mixer Control Package.  New status codes are assigned using
   the Standards Action process defined in RFC 5226 [RFC5226].  The
   initial population of the registry is defined in Section 4.6.

   The format of this registry is as follows:

   +----------+----------------+----------------+----------------------+
   | Code     | Summary        | Description    | Reference            |
   +----------+----------------+----------------+----------------------+
   | status   | brief summary  | full           | reference document   |
   | code     | of the status  | description of | defining the status  |
   | number   | code           | the status     | code                 |
   |          |                | code           |                      |
   +----------+----------------+----------------+----------------------+

      Table 2: Fields for Mixer Control Package Status Code Registry

9.  Contributors

   Asher Shiratzky provided valuable support and contributions to early
   draft versions of this document.

   The authors would like to thank the Mixer design team consisting of
   Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan, and Mary
   Barnes who provided valuable feedback, input, diagrams, and text to
   this document.

10.  Acknowledgments

   The authors would like to thank Steve Buko and Stephane Bastien for
   expert reviews of this work.

   Shawn Emery carried out a thorough security review.

11.  References

11.1.  Normative References

   [RFC2045]          Freed, N. and N. Borenstein, "Multipurpose
                      Internet Mail Extensions (MIME) Part One: Format
                      of Internet Message Bodies", RFC 2045,
                      November 1996.

   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

   [RFC3023]          Murata, M., St. Laurent, S., and D. Kohn, "XML
                      Media Types", RFC 3023, January 2001.

   [RFC3688]          Mealling, M., "The IETF XML Registry", BCP 81,
                      RFC 3688, January 2004.

   [RFC4288]          Freed, N. and J. Klensin, "Media Type
                      Specifications and Registration Procedures",
                      BCP 13, RFC 4288, December 2005.

   [RFC4574]          Levin, O. and G. Camarillo, "The Session
                      Description Protocol (SDP) Label Attribute",
                      RFC 4574, August 2006.

   [RFC4647]          Phillips, A. and M. Davis, "Matching of Language
                      Tags", BCP 47, RFC 4647, September 2006.

   [RFC5226]          Narten, T. and H. Alvestrand, "Guidelines for
                      Writing an IANA Considerations Section in RFCs",
                      BCP 26, RFC 5226, May 2008.

   [RFC5234]          Crocker, D. and P. Overell, "Augmented BNF for
                      Syntax Specifications: ABNF", STD 68, RFC 5234,
                      January 2008.

   [RFC5646]          Phillips, A. and M. Davis, "Tags for Identifying
                      Languages", BCP 47, RFC 5646, September 2009.

   [RFC6230]          Boulton, C., Melanchuk, T., and S. McGlashan,
                      "Media Control Channel Framework", RFC 6230,
                      May 2011.

   [RFC6501]          Novo, O., Camarillo, G., Morgan, D., and J.
                      Urpalainen, "Conference Information Data Model for
                      Centralized Conferencing (XCON)", RFC 6501,
                      March 2012.

   [XML]              Bray, T., Paoli, J., Sperberg-McQueen, C., Maler,
                      E., and F. Yergeau, "Extensible Markup Language
                      (XML) 1.0 (Fifth Edition)", World Wide Web
                      Consortium Recommendation REC-xml-20081126,
                      November 2008,
                      <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [XMLSchema:Part2]  Biron, P. and A. Malhotra, "XML Schema Part 2:
                      Datatypes Second Edition", W3C Recommendation,
                      October 2004.

11.2.  Informative References

   [IANA]             IANA, "RTP Payload Types",
                      <http://www.iana.org/assignments/rtp-parameters>.

   [MIME.mediatypes]  IANA, "MIME Media Types",
                      <http://www.iana.org/assignments/media-types>.

   [RFC2277]          Alvestrand, H., "IETF Policy on Character Sets and
                      Languages", BCP 18, RFC 2277, January 1998.

   [RFC3261]          Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                      Johnston, A., Peterson, J., Sparks, R., Handley,
                      M., and E. Schooler, "SIP: Session Initiation
                      Protocol", RFC 3261, June 2002.

   [RFC3550]          Schulzrinne, H., Casner, S., Frederick, R., and V.
                      Jacobson, "RTP: A Transport Protocol for Real-Time
                      Applications", STD 64, RFC 3550, July 2003.

   [RFC5022]          Van Dyke, J., Burger, E., and A. Spitzer, "Media
                      Server Control Markup Language (MSCML) and
                      Protocol", RFC 5022, September 2007.

   [RFC5167]          Dolly, M. and R. Even, "Media Server Control
                      Protocol Requirements", RFC 5167, March 2008.

   [RFC5707]          Saleem, A., Xin, Y., and G. Sharratt, "Media
                      Server Markup Language (MSML)", RFC 5707,
                      February 2010.

Authors' Addresses

   Scott McGlashan
   Hewlett-Packard

   EMail: smcg.stds01@mcglashan.org


   Tim Melanchuk
   Rainwillow

   EMail: timm@rainwillow.com


   Chris Boulton
   NS-Technologies

   EMail: chris@ns-technologies.com