Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6505

A Mixer Control Package for the Media Control Channel Framework

Pages: 89
Proposed Standard
Errata
Part 5 of 5 – Pages 75 to 89
First   Prev   None

Top   ToC   RFC6505 - Page 75   prevText

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 | | ----------------------------------------> |
Top   ToC   RFC6505 - Page 76

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.
Top   ToC   RFC6505 - Page 77

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:
Top   ToC   RFC6505 - Page 78
   <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>
Top   ToC   RFC6505 - Page 79
   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>
Top   ToC   RFC6505 - Page 80
   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:
Top   ToC   RFC6505 - Page 81
   <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,
Top   ToC   RFC6505 - Page 82
   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.
Top   ToC   RFC6505 - Page 83
   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
Top   ToC   RFC6505 - Page 84
   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).
Top   ToC   RFC6505 - Page 85
         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.
Top   ToC   RFC6505 - Page 86
   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.
Top   ToC   RFC6505 - Page 87

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.
Top   ToC   RFC6505 - Page 88
   [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.
Top   ToC   RFC6505 - Page 89
   [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