Network Working Group                                         C. Boulton
Internet-Draft                                           NS-Technologies
Intended status: Standards Track                              L. Miniero
Expires: June 18, August 14, 2010                            University of Napoli
                                                       December 15, 2009
                                                       February 10, 2010

                        Media Resource Brokering
                      draft-ietf-mediactrl-mrb-02
                      draft-ietf-mediactrl-mrb-03

Abstract

   The MediaCtrl work group in the IETF has proposed an architecture for
   controlling media services.  The Session Initiation Protocol (SIP) is
   used as the signalling protocol which provides many inherent
   capabilities for message routing.  In addition to such signalling
   properties, a need exists for intelligent, application level media
   service selection based on non-static signalling properties.  This is
   especially true when considered in conjunction with deployment
   architectures that include 1:M and M:M M:N combinations of Application
   Servers and Media Servers.  This document introduces a Media Resource
   Broker (MRB) entity which manages the availability of Media Servers
   and the media resource demands of Application Servers.  The document
   includes potential deployment options for an MRB and appropriate
   interfaces to Application Servers and Media Servers.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 18, August 14, 2010.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   7
   3.  Problem Discussion  . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Deployment Scenario Options . . . . . . . . . . . . . . . . .   9
     4.1.  Query MRB . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  Hybrid Query MRB  . . . . . . . . . . . . . . . . . . .  10
     4.2.  In-Line MRB . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  MRB Interface Definitions . . . . . . . . . . . . . . . . . .  14
     5.1.  Media Server Resource Publishing Publish Interface . . . . . . . . .  14
       5.1.1.  Control Package Definition  . . . . . . . . . . . . . .  15
       5.1.2.  Element Definitions . . . . . . . . . . . . . . . . . 17  16
       5.1.3.  <mrbrequest>  . . . . . . . . . . . . . . . . . . . . .  17
       5.1.4.  <mrbnotification> . . . . . . . . . . . . . . . . . .  18
       5.1.5.  <mrbresponse> . . . . . . . . . . . . . . . . . . . .  27
     5.2.  Media Service Resource Consumer Interface . . . . . . . . 28  27
       5.2.1.  HTTP Consumer Interface Usage . . . . . . . . . . . .  28
       5.2.2.  SIP Consumer Interface Usage  . . . . . . . . . . . . . 29  28
       5.2.3.  Consumer Interface Lease Mechanism  . . . . . . . . . .  30
       5.2.4.  Media Service Resource Request  . . . . . . . . . . . .  32
       5.2.5.  Media Service Resource Response . . . . . . . . . . .  42
     5.3.  In-Line MRB Interface . . . . . . . . . . . . . . . . . .  44
       5.3.1.  In-line Unaware MRB Mode  . . . . . . . . . . . . . . .  44
       5.3.2.  In-line Aware MRB Mode  . . . . . . . . . . . . . . . . 45  44
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  46
     6.1.  Publish Example . . . . . . . . . . . . . . . . . . . . .  46
     6.2.  Consumer Example  . . . . . . . . . . . . . . . . . . . .  51
       6.2.1.  Query Example . . . . . . . . . . . . . . . . . . . .  51
       6.2.2.  IAMM Example  . . . . . . . . . . . . . . . . . . . .  54
   7.  Media Service Resource Publisher Interface XML Schema . . . . 47
   7.  60
   8.  Media Service Resource Consumer Interface XML Schema  . . . . . 71
   8.  82
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 92
   9. 103
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
     9.1. 104
     10.1. application/mrb-publish+xml MIME Type . . . . . . . . . . 93
     9.2. 104
     10.2. application/mrb-consumer+xml MIME Type  . . . . . . . . . . 94
   10. 105
   11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
     10.1. 106
     11.1. Changes from 02 Version . . . . . . . . . . . . . . . . . 106
     11.2. Changes from 01 Version . . . . . . . . . . . . . . . . . 95
     10.2. 106
     11.3. Changes from 00 Version . . . . . . . . . . . . . . . . . 95
   11. 106
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
   12. 107
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 97
     12.1. 108
     13.1. Normative References  . . . . . . . . . . . . . . . . . . . 97
     12.2. 108
     13.2. Informative References  . . . . . . . . . . . . . . . . . . 98 109
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 99 110

1.  Introduction

   The topic of Media Resource management has been in discussion for a
   number of years with varying proprietary solutions being used today.
   It is clear that, as we move towards a consistent architecture and
   protocol for Media Server Control, a standard mechanism is required
   for accurate media resource location. selection.

   As IP based multimedia infrastructures mature, the complexity and
   demands from deployments increase.  Such complexity will result in a
   wide variety of capabilities from a range of vendors that should all
   be interoperable using the architecture and protocols produced by the
   MediaCtrl work group.  It should be possible for a controlling entity
   to be assisted in Media Server selection so that the most appropriate
   resource is selected for a particular operation.  The importance
   increases when you introduce a flexible level of deployment
   scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567
   [RFC5567] documents.  These documents make statements like "it should
   be possible to have a many-to-many relationship between Application
   Servers and Media Servers that use this protocol".  This leads to the
   following deployment architectures being possible when considering
   media resources.

   The simplest deployment view is illustrated in Figure 1.

   +---+-----+---+                         +---+-----+---+
   | Application |                         |    Media    |
   |   Server    |<-------MS Control------>|    Server   |
   +-------------+                         +-------------+

                       Figure 1: Basic Architecture

   This simply involves a single Application Server and Media Server.
   Expanding on this view, it is also possible for an Application Server
   to control multiple (greater that 1) Media Server instances at any
   one time.  This deployment view is illustrated in Figure 2.
   Typically, such architectures are associated with application logic
   that requires high demand media services.  It is more than possible
   that each media server possesses a different media capability set.
   Media servers may offer different media services as specified in the
   Mediactrl architecture document.  A Media server may have similar
   media functionality but may have different capacity or media codec
   support.

                                           +---+-----+---+
                                           |    Media    |
                                    +----->|    Server   |
                                    |      +-------------+
                                    |
   +---+-----+---+                  |      +---+-----+---+
   | Application |                  |      |    Media    |
   |   Server    |<--MS Control-----+----->|    Server   |
   +-------------+                  |      +-------------+
                                    |
                                    |      +---+-----+---+
                                    +----->|    Media    |
                                           |    Server   |
                                           +-------------+

                     Figure 2: Multiple Media Servers

   Figure 3 conveys the opposite view to that in Figure 2.  In this
   model there are a number of (greater than 1) application servers servers,
   possibly supporting dissimilar applications, controlling a single
   media server.  Typically, such architectures are associated with
   application logic that requires low demand media services.

   +---+-----+---+
   | Application |
   |   Server    |<-----+
   +-------------+      |
                        |
   +---+-----+---+      |                  +---+-----+---+
   | Application |      |                  |    Media    |
   |   Server    |<-----+-----MS Control-->|    Server   |
   +-------------+      |                  +-------------+
                        |
   +---+-----+---+      |
   | Application |      |
   |   Server    |<-----+
   +-------------+

                  Figure 3: Multiple Application Servers

   The final deployment view is the most complex.  In this model (M:M) (M:N)
   there exists any number of Application Servers and any number of
   Media Servers.  It is again possible in this model that media servers
   might not be homogenous and have different capability sets and
   capacity.

   +---+-----+---+                         +---+-----+---+
   | Application |                         |    Media    |
   |   Server    |<-----+            +---->|    Server   |
   +-------------+      |            |     +-------------+
                        |            |
   +---+-----+---+      |            |     +---+-----+---+
   | Application |      |            |     |    Media    |
   |   Server    |<-----+-MS Control-+---->|    Server   |
   +-------------+      |            |     +-------------+
                        |            |
   +---+-----+---+      |            |     +---+-----+---+
   | Application |      |            +---->|    Media    |
   |   Server    |<-----+                  |    Server   |
   +-------------+                         +---+-----+---+

                       Figure 4: Basic Architecture

   This document will take a look at the specific problem areas related
   to such deployment architectures.  It is recognised that the
   solutions proposed in this document should be equally adaptable to
   all of the previously described deployment models.  It is also
   recognised that the solution is far more relevant to some of the
   previously discussed deployment models and can almost be viewed as
   redundant on others.

2.  Conventions and Terminology

   In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL".  In addition, BCP 15 indicates requirement levels for
   compliant implementations.

   This document inherits terminology proposed in RFC 5567 [RFC5567] and
   Media Control Channel Framework
   [I-D.ietf-mediactrl-sip-control-framework] documents.  In addition,
   the following terms are defined for use in this document and for use
   in the context of the MediaCtrl Work group in the IETF:

   Media Resource Broker (MRB)  A logical entity that is responsible for
      both collection of appropriate published Media Server (MS)
      information and supplying of selecting appropriate MS information to resources on behalf of
      consuming entities.

   Query MRB  An instantiation of an MRB (See previous definition) that
      provides an interface for an Application Server to retrieve the
      location
      address of an appropriate Media Server.  The result returned to
      the Application Server can be influenced by information contained
      in the query request.

   In-line MRB  An instantiation of an MRB (See definition) that
      directly receives requests on the signalling path.  The decision
      making process  There is totally delegated to the MRB. no
      separate query.

3.  Problem Discussion

   It is clear from Section 1 that the MediaCtrl group will be producing
   a solution that must service a wide variety of deployment
   architectures.  These range from the simplest 1:1 relationship
   between Media Servers and Application Servers to potentially linearly
   scaling 1:M, M:1 and M:M M:N deployments.

   This still does not seem like a major issue for the proposed solution
   until you add a number of additional factors into the equation that
   increase complexity.  As Media Servers evolve it must be taken into
   consideration that, where many can exist in a deployment, they may
   not have been produced by the same vendor and may not have the same
   capability set.  It should be possible for an Application Server that
   exists in a deployment to select a Media Service based on a common,
   appropriate capability set.  In conjunction with capabilities, it is
   also important to take available resources into consideration.  The
   ability to select an appropriate Media Service function is an
   extremely useful feature but becomes even more powerful when
   considered with available resources for servicing a request.

   In conclusion, the intention is to create a tool set that allows
   MediaCtrl deployments to effectively utilize the available media
   resources.  It should be noted that in the simplest deployments where
   only a single media server exists, an MRB function is probably not
   required.  Only a single capability set exists and resource
   unavailability can be handled using the appropriate underlying
   signalling e.g.  SIP response.  This document does not prohibit such
   uses of an MRB, it simply provides the tools for various entities to
   interact where appropriate.  It is also worth noting that the tools
   provided in this document aim to provide a 'best effort' view of
   media resources at the time of request for initial Media Server
   routing decisions.  Any dramatic change in media capabilities after a
   request has taken place should be handled by the underlying protocol.

   Please note that, while the MRB is supposed to provided ASs with as
   much relevant information as possible, there are information pieces that ASs there may be interested additional information that it is
   desirable for the MRB to which are out of scope in this
   document, as have for instance purposes of selecting an MS
   resource, such as resource allocation rules, rules across different
   applications, planned or unplanned downtime of Media Server
   resources, the planned addition of future Media Server resources.

4.  Deployment Scenario Options

   On researching Media Resource Brokering it became clear that a resources, or
   MS resource capacity models.  How the MRB acquires such information
   is outside the scope of this document.  The techniques used for
   selecting an appropriate Media Resource by an MRB is outside the
   scope of this document.

4.  Deployment Scenario Options

   On researching Media Resource Brokering it became clear that a couple
   of high level models exist.  The general principles of "in-line" and
   "query" MRB concepts are discussed in the rest of this section.

4.1.  Query MRB

   The "Query" model for MRB interactions provides the ability for a
   client of media services (for example an Application Server) to "ask"
   an MRB for an appropriate Media Server, as illustrated in Figure 5.

                        +---+-----+---+
          +------------>|     MRB     |<----------+----<-----+---+
          |             +-------------+        (1)|          |   |
          |                                       |          |   |
          |(2)                             +---+--+--+---+   |   |
          |                                |    Media    |   |   |
          |                          +---->|    Server   |   |   |
          |                          |     +-------------+   |   |
          |                          |                    (1)|   |
   +---+--+--+---+                   |     +---+-----+---+   |   |
   | Application |                   |     |    Media    |   |   |
   |   Server    |<-----+-MS Control-+---->|    Server   |->-+   |
   +-------------+          (3)      |     +-------------+       |
                                     |                           |
                                     |     +---+-----+---+    (1)|
                                     +---->|    Media    |       |
                                           |    Server   |--->---+
                                           +---+-----+---+

                            Figure 5: Query MRB

   In this deployment, the Media Servers use the "Media Server Resource
   Publishing
   Publish Interface", as discussed in Section 5.1, to convey capability
   sets as well as resource information.  This is depicted by (1) in
   Figure 5.  It is then the MRB's responsibility to accumulate all
   appropriate information relating to media services in the logical
   deployment cluster.  The Application Server (or other media services
   client) is then able to query the MRB for an appropriate resource (as
   identified by (2) in Figure 5).  Such a query would carry specific
   information related to the Media Service required and enable the MRB
   to provide an increased accuracy in its response.  This particular
   interface is discussed in "Media Resource Consumer Interface" in
   Section 5.2.  The Application Server is then able to direct control
   commands (for example create conference) and Media Dialogs to the
   appropriate Media Server, as shown by (3) in Figure 5.  Additionally,
   with Query MRB, the MRB is not in the signaling path between the AS
   and the selected MS resource.

4.1.1.  Hybrid Query MRB

   As mentioned previously, it is the intention that a tool kit is
   provided for MRB functionality within a MediaCtrl architecture.  It
   is expected that in specific deployment scenarios the role of the MRB
   might be co-hosted as a hybrid logical entity with an Application
   Server, as shown in Figure 6.

          +------------<----------------<---------+----<-----+---+
          |                     (1)               |          |   |
          |                                       |          |   |
          |                                +---+--+--+---+   |   |
          |                                |    Media    |   |   |
          V                          +---->|    Server   |   |   |
   +------+------+                   |     +-------------+   |   |
   |     MRB     |                   |                       |   |
   +---+--+--+---+                   |     +---+-----+---+   |   |
   | Application |                   |     |    Media    |   |   |
   |   Server    |<-----+-MS Control-+---->|    Server   |->-+   |
   +-------------+                   |     +-------------+       |
                                     |                           |
                                     |     +---+-----+---+       |
                                     +---->|    Media    |       |
                                           |    Server   |--->---+
                                           +---+-----+---+

                  Figure 6: Hybrid Query MRB - AS Hosted

   This diagram is identical to that in Figure 5 with the exception that
   the MRB is now hosted on the Application Server.  The "Media Server
   Publishing
   Publish Interface" is still being used to accumulate resource
   information at the MRB but as it is co-hosted on the Application
   Server, the "Media Server Consumer Interface" has collapsed.  It
   might still exist within the Application Server/MRB interaction but
   this is an implementation issue.  This type of deployment suits a
   single Application Server environment but it should be noted that a
   "Media Server Consumer Interface" could then be offered from the
   hybrid if required.

   In a similar manner, the Media Server could also act as a hybrid for
   the deployment cluster, as illustrated in Figure 7.

                                   (1)                 +---+-----+---+
   +---+---+------------->---------------->----------->|     MRB     |
   |   |   |   +---+--+--+---+                         +---+-----+---+
   |   |   +-<-| Application |                         |    Media    |
   |   |       |   Server    |<--+-MS Control-+------->|    Server   |
   |   |       +-------------+                   |     +-------------+
   |   |                                         |
   |   |       +---+--+--+---+                   |
   |   +---<---| Application |                   |
   |           |   Server    |<--+-MS Control-+--+
   |           +-------------+                   |
   |                                             |
   |           +---+--+--+---+                   |
   +---<-------| Application |                   |
               |   Server    |<--+-MS Control-+--+
               +-------------+

                  Figure 7: Hybrid Query MRB - MS Hosted

   This time the MRB has collapsed and is co-hosted by the Media Server.
   The "Media Server Consumer Interface" is still available to the
   Application Servers (1) to query Media Server resources.  This time
   the "Media Server Publishing Publish Interface" has collapsed onto the Media
   Server.  It might still exist within the Media Server/MRB interaction
   but this is an implementation issue.  This type of deployment suits a
   single Media Server environment but it should be noted that a "Media
   Server Publishing Publish Interface" could then be offered from the hybrid if
   required.  A typical use case scenario for such a topology would be a
   single MS representing a pool of MSs in a cluster.  In that case, the
   MRB would actually be handling a cluster of MSs, rather than one.

4.2.  In-Line MRB

   The "In-line" MRB is architecturally different from the "Query" model
   that was discussed in the previous section.  The Concept concept of a "Media
   Server Consumer Interface"
   separate query disappears.  The client of the MRB simply uses the
   media resource control and media dialog signalling to offload involve the decision making process - this
   applies to both media server Control and Media dialogs.
   MRB.  This type of deployment is illustrated in Figure 8.

                               +-------<----------+----<-------+---+
                               |                  | (1)        |   |
                               |                  |            |   |
                               |             +---+--+--+---+   |   |
                               |             |    Media    |   |   |
                               |     +------>|    Server   |   |   |
                               |     |(3)    +-------------+   |   |
                               |     |                      (1)|   |
   +---+--+--+---+             |     |       +---+-----+---+   |   |
   | Application |  (2) +---+--V--+---+  (3) |    Media    |   |   |
   |   Server    |----->|     MRB     |----->|    Server   |->-+   |
   +-------------+      +---+-----+---+      +-------------+       |
                                     |                             |
                                     |   (3) +---+-----+---+    (1)|
                                     +------>|    Media    |       |
                                             |    Server   |--->---+
                                             +---+-----+---+

                           Figure 8: In-line MRB

   The Media Servers still use the 'Media Server Publishing Publish Interface' to
   convey capabilities and resources to the MRB - as illustrated by (1).
   The media server Control and (and Media dialogs are as well, if required) is
   sent to the MRB (2) which then selects an appropriate Media Server (3).  The result
   of such an architecture is that the signalling decision is left
   entirely to the MRB
   (3) and the Application Server has no choice in the
   final selection process.  This is the opposite to the "Query" model
   which provided information that would help influence the Media Server
   decision making process on the application server and resulted stay in it
   directly contacting an appropriate Media Server instance.  As a by-
   product of this decision shift, a lot more emphasis is placed on the
   intelligence of the MRB to interpret the required capabilities of the
   request.  The MRB will actually have to inspect both signaling path between the SIP
   signalling AS and the media server control protocol PDUs for the purpose
   of Media Server selection.  This includes, for example, looking MS
   resource for
   explicit capabilities in the signalling and session details such as
   media types, codecs and bandwidth requirements.  Ultimately the
   decision making and policy enforcement is removed from the
   Application Server and shifted to the MRB logical entity. handled dialogs.

   In-line MRB can be split into two distinct logical roles which can be
   applied on a per request basis.  They are:

   In-line Unaware MRB Mode (IUMM):  Allows an MRB to act on behalf of
      clients requiring media services who are not aware of an MRB or
      its operation.

   In-line Aware MRB Mode (IAMM):  Allows an MRB to act on behalf of
      clients requiring media services who  In this case the AS does not provide explicit
      information on the kind of MS resource it needs (as in
      Section 5.2) and the MRB is left to deduce it by potentially
      inspecting other information in the request from the AS; for
      example, SDP content, or address of the requesting AS, or
      additional Request-URI parameters as per RFC 4240 [RFC4240].

   In-line Aware MRB Mode (IAMM):  Allows an MRB to act on behalf of
      clients requiring media services who are aware of an MRB and its
      operation.  In particular it allows the AS to explicitly the
      convey the same kinds of MS characteristics desired as does the
      Query MRB mode (as in Section 5.2).

   In either role, the MRB would deduce that the selected MS resources
   are no longer needed when the AS terminates the corresponding dialog.

   The two modes are discussed in more detail in Section 5.3.

5.  MRB Interface Definitions

   As discussed in previous sections in this document, the intention is
   to provide a toolkit for a variety of deployment architectures where
   media resource brokering can take place.  As a result, two main
   interfaces are required to support the differing requirements.  The
   two interfaces are described in the remainder of this section and
   have been named the 'Media Server Resource Publishing' Publish' and 'Media Server
   Resource Consumer' interfaces.  These two interfaces have extremely
   differing responsibilities and usages which is reflected in the
   choice of solutions.

   It is beyond the scope of this document to define exactly how to
   construct an MRB.  This includes interpreting the data for the Media
   Service Consumer interface supplied by the Media Server Publishing Publish
   interface.  It is, however, important that the two interfaces are
   complimentary so that development of appropriate MRB functionality is
   supported.

5.1.  Media Server Resource Publishing Publish Interface

   The Media Server Resource Publishing Publish interface is responsible for
   providing an MRB with appropriate Media Server resource information.
   It is generally accepted that this interface provides both general
   and specific details related to Media Server resources.  This
   information needs to be conveyed using an industry standard mechanism
   to provide increased levels of adoption and interoperability.  A
   Control Package for the Media Control Channel Framework will be
   specified to fulfil this interface requirement.  It provides the
   perfect establishment and monitoring mechanism to enable a Media
   Server to report appropriate statistics to an MRB.  The Publish
   interface is used with both Query and In-line modes of MRB operation.

   As already anticipated in the introduction, the information provided
   by the Media Server is to be considered a best effort.  This means
   that while the information is assumed to be as exact as possible, it
   can only be considered a good approximation rather than the exact
   information.  It is clear, in fact, that the accuracy of MRB view of MS
   resource availability will never in practice be exact due to several reasons which include
   timing issues, approximate - i.e., partial
   and imperfect.  The MRB Publish interface does not provide an
   exhaustive view of current MS resource consumption, the MS may in
   some cases provide a best-effort computed as opposed to reserved view of resource
   consumption parameters conveyed in the Publish interface (e.g., DSP's
   with a fixed number of streams versus GPU's with CPU availability), and
   there may be licensing constraints not factored in (e.g., even if
   lots of CPU and memory are available, licensing or other
   configuration elements may restrict the number of stream types).  This implies that the types), and
   MS resource information may only way an
   Application Server can be sure a specific resource is available is to
   reserve it by establishing a session.  For the same reason, reported periodically over the
   reporting of resources availability has no relation
   Publish interface to predictive
   resource allocation.  A typical example MRB.  Nevertheless, despite such limitations and
   with the aid of that is a conference
   bridge that allows for oversubscription.  The oversubscription must
   be taken care of at the application layer in the Application Server,
   since requests to the Media Server must be for the actual number of
   streams requested.

   It good engineering the MRB can still perform its
   function well.

   It is also worth noting that, while the scope of the MRB is
   definitely on providing interested Application Servers with the
   available resources, the MRB also allows for the retrieval of
   information about the currently occupied resources.  While this is of
   course a relevant piece of information (e.g. for monitoring
   purposes), such a functionality inevitably raises security
   considerations, and implementations should take this into account.
   See Section 8 9 for more details.

   The MRB Publish interface uses the Media Control Channel Framework
   ([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
   interaction between a Media Server and an MRB.  The Media Control
   Channel Framework uses an extension mechanism to allow specific
   usages which are known as control packages.  Section 5.1.1 defines
   the control package that MUST be implemented by any Media Server
   wanting to interact with an MRB entity.

5.1.1.  Control Package Definition

   This section fulfils the mandatory requirement for information that
   MUST be specified during the definition of a Control Framework
   Package, as detailed in Section 8 of
   [I-D.ietf-mediactrl-sip-control-framework].

5.1.1.1.  Control Package Name

   The Media Channel Control Framework requires a Control Package
   definition to specify and register a unique name and version.

   The name and version of this Control Package is "mrb-publish/1.0".

5.1.1.2.  Framework Message Usage

   The MRB publishing publish interface allows a media server to convey available
   capabilities and resources to an MRB entity.

   This package defines XML elements in Section 5.1.2 and provides an
   XML Schema in Section 6. 7.

   The XML elements in this package are split into requests, responses
   and event notifications.  Requests are carried in CONTROL message
   bodies; <mrbrequest> element is defined as a package request.  This
   request can be used for creating new subscriptions and update/remove updating/
   removing existing subscriptions.  Event notifications are also
   carried in CONTROL message bodies; the <mrbnotification> element is
   defined for package event notifications.  Responses are carried
   either in REPORT message or Control Framework 200 response bodies;
   the <mrbresponse> element is defined as a package level response.

   Note that package responses are different from framework response
   codes.  Framework error response codes (see Section 7 of
   [I-D.ietf-mediactrl-sip-control-framework]) are used when the request
   or event notification is invalid; for example, a request has invalid
   XML (400), or is not understood (500).  Package level responses are
   carried in framework 200 response or REPORT message bodies.  This
   package's response codes are defined in Section 5.1.5.

5.1.1.3.  Common XML Support

   The Media Control Channel Framework
   [I-D.ietf-mediactrl-sip-control-framework] requires a Control Package
   definition to specify if the attributes for media dialog or
   conference references are required.

   The Publish interface defined in Section 6 7 does import and make use
   of the common XML schema defined in the Media Control Channel
   Framework.

   The Consumer interface defined in Section 7 8 does import and make use
   of the common XML schema defined in the Media Control Channel
   Framework.

5.1.1.4.  CONTROL Message Body

   A valid CONTROL body message MUST conform to the schema defined in
   Section 6 7 and described in Section 5.1.2.  XML messages appearing in
   CONTROL messages MUST contain either a <mrbrequest> or
   <mrbnotification> element.

5.1.1.5.  REPORT Message Body

   A valid REPORT body MUST conform to the schema defined in Section 6 7
   and described in Section 5.1.2.  XML messages appearing in REPORT
   messages MUST contain a <mrbresponse> element.

5.1.1.6.  Audit

   The 'mrb-publish/1.0' Media Control Channel Framework package does
   not require any additional auditing capability.

5.1.1.7.  Examples

   [Editors' Note: The Authors will post and review appropriate examples
   to the list that will be included in the final version.]

5.1.2.  Element Definitions

   This section defines the XML elements for the Publish interface Media
   Control Channel package defined in Section 5.1.  The formal XML
   schema definition for the Publish interface can be found in
   Section 6. 7.

   The root element is <mrbpublish>.  All other XML elements (requests,
   responses, notifications) are contained within it.  The MRB Publish
   interface request element is detailed in Section 5.1.3.  The MRB
   Publish interface notification element is detailed in Section 5.1.4.
   MRB Publish interface response element is contained in Section 5.1.5.

   The <mrbpublish> element has the following attributes:

   Version:  a token specifying the mrb-publish package version.  The
      value is fixed as '1.0' for this version of the package.  The
      attribute is mandatory.

   The <mrbpublish> element has the following child element, only one of
   which is allowed to occur in a request.

      <mrbrequest> for sending an MRB request.  See Section 5.1.3.

      <mrbresponse> for sending an MRB response.  See Section 5.1.5.

      <mrbnotification> for sending an MRB notification.  See
      Section 5.1.4.

5.1.3.  <mrbrequest>

   This section defines the <mrbrequest> element used to initiate
   requests from an MRB to a Media Server.  The element is a container
   for information relevant for the interrogation of a media server.

   The <mrbrequest> element has no defined attributes.

   The <mrbrequest> element has the following sub-elements which are
   defined in the remainder of this section:

      <subscription> for initiating a subscription to a Media Server
      from an MRB.  See Section 5.1.3.1.

5.1.3.1.  <subscription>

   The <subscription> element is included in a request from an MRB to a
   Media Server to provide the details relating to the configuration of
   updates.  This element can be used either to request a new
   subscription or to update an existing one (e.g. to change the
   frequency of the updates), and to remove ongoing subscriptions as
   well (e.g. to stop an indefinite update).  The MRB will inform the
   Media Server how long it wishes to receive updates for and the
   frequency that updates should be sent.  Updates are sent using the
   <mrbnotification> element.

   The <subscription> element has the following attributes:

   id:  indicates a unique token representing the session between the
      MRB and the Media Server.  The attribute is mandatory.

   seqnumber:  indicates a sequence number to be used in conjunction
      with the session id to identify a specific subscription command.
      The attribute is mandatory.

   action:  provides the operation that should be carried out on the
      subscription.  The value of 'create' instructs the MS to attempt
      to setup a new subscription.  The value of 'update' instructs the
      MS to attempt to update an existing subscription.  The value of
      'remove' instructs the MS to attempt to remove an existing
      subscription and consequently stop any ongoing related
      notification.  The attribute is mandatory.

   The <subscription> element has the following child elements:

   expires:   Provides the amount of time in seconds that a subscription
      should be installed for notifications at the Media Server.  The
      element is optional.

   frequency:   Provides the frequency in seconds that the MRB wishes to
      receive notifications from the MRB.  The element is optional.

5.1.4.  <mrbnotification>

   The <mrbnotification> element is included in a request from a Media
   Server to an MRB to provide the details relating current status.  The
   Media Server will inform the MRB of its current status as defined by
   the information in the <subscription> element.  Updates are sent
   using the <mrbnotification> element contained in an <mrbrequest>
   element.

   The <mrbnotification> element has the following attributes:

   id:  indicates a unique token representing the session between the
      MRB and the Media Server and is the same as the one appearing in
      the <subscription> element.  The attribute is mandatory.

   seqnumber:  indicates a sequence number to be used in conjunction
      with the session id to identify a specific notification update.
      The attribute is mandatory

   The following subsections provide details on the child elements that
   are contained within an <mrbnotification> element.

5.1.4.1.  <media-server-id>

   The <media-server-id> element provides a unique system wide
   identifier for a Media Server instance.  The element is mandatory.

   [Editors Note: Need to talk more about unique property.]

5.1.4.2.  <supported-packages>

   The <supported-packages> element provides the list of Media Control
   Channel Packages supported by the media server.  The element is
   optional.

   The <supported-packages> element has no attributes.

   The <supported-packages> element has no child elements:

   package:   The <package> element represents the name of a package
      supported by the media server.  The <package> element has a single
      attribute, 'name', which represents the name of the supported
      Media Control Channel Framework package.

5.1.4.3.  <active-rtp-sessions>

   The <active-rtp-sessions> element provides information detailing the
   current active Real-time Transport Protocol(RTP) sessions.  The
   element is optional.

   The <active-rtp-sessions> element has no attributes.

   The <active-rtp-sessions> element has the following child element:

   rtp-codec:   Is a container which represents a supported codec and
      the associated active sessions.  The <rtp-codec> element has one
      attribute.  The attribute 'name' represents the name of the codec
      being represented.  The <rtp-codec> element has two child
      elements.  The child element, <decoding>, represents the number of
      RTP sessions for the specified codec being decoded.  The child
      element, <encoding>, represents the number of RTP sessions for the
      specified codec being encoded.

5.1.4.4.  <active-mixer-sessions>

   The <active-mixer-sessions> element provides information detailing
   the current active mixed RTP sessions.  The element is optional.

   The <active-mixer-sessions> element has no attributes.

   The <active-mixer-sessions> element has the following child element:

   active-mix:   Is a container which representing represents a mixed active RTP
      session.  The <active-mix> element has one attribute.  The
      attribute 'conferenceid' represents the name of the mix being
      represented.  The <active-mix> element has one child elements.
      The child element, <rtp-codec>, contains the same information
      relating to RTP sessions as defined in Section 5.1.4.3.  The
      element is optional.

5.1.4.5.  <non-active-rtp-sessions>

   The <non-active-rtp-sessions> element provides information detailing
   the currently available inactive RTP sessions.  The element is
   optional.

   The <non-active-rtp-sessions> element has no attributes.

   The <non-active-rtp-sessions> element has the following child
   element:

   rtp-codec:   Is a container which represents a supported codec and
      the inactive sessions.  The <rtp-codec> element has one attribute.
      The attribute 'name' represents the name of the codec being
      represented.  The <rtp-codec> element has two child elements.  The
      first child element, <decoding>, represents the number of
      available RTP session for the specified codec being decoded.  The
      second child element, <encoding>, represents the number of
      available RTP sessions for the specified codec being encoded.  The
      element is optional.

5.1.4.6.  <non-active-mixer-sessions>

   The <non-active-mixer-sessions> element provides information
   detailing the current inactive mixed RTP sessions.  The element is
   optional.

   The <non-active-rtp-sessions> element has no attributes.

   The <non-active-mixer-sessions> element has the following child
   element:

   non-active-mix:   Is a container which representing an available
      mixed RTP session.  The <non-active-mix> element has one
      attribute.  The attribute 'available' represents the number of
      mixes that could be used using that profile.  The <non-active-mix>
      element has one child elements.  The child element, <rtp-codec>,
      contains the same information relating to RTP sessions as defined
      in Section 5.1.4.5.  The element is optional.

5.1.4.7.  <media-server-status>

   The <media-server-status> element provides information detailing the
   current status of the media server.  The element is mandatory.  It
   can return one of the following values:

   active:   Indicating that the Media Server is available for service.

   deactivated:   Indicating that the Media Server has been withdrawn
      from service.

   unavailable:   Indicating that the Media Server can not process new
      requests.

   The <media-server-status> element has no attributes.

   The <media-server-status> element has no child elements.

5.1.4.8.  <supported-codecs>

   The <supported-codecs> element provides information detailing the
   current codecs supported by a media server and associated actions.
   The element is optional.

   The <supported-codecs> element has no attributes.

   The <supported-codecs> element has the following child element:

   supported-codec:   has a single attribute, 'name', which provides the
      name of the codec providing information.  The <supported-codec>
      element then has a further child element, <supported-codec-
      package>.  The <supported-codec-package> element has a single
      attribute, 'name', which provides the name of the Media Control
      Channel Framework package for which the codec support applies.
      The <supported-codec-package> element has one further child
      element, <supported-actions>, which provide the actions that a
      Media Server can apply to this codec (decode, encode,
      passthrough).

5.1.4.9.  <application-data>

   The <application-data> element provides application level data.  The
   element is optional.

   The <application-data> element has no attributes.

   The <application-data> element has no child elements.

5.1.4.10.  <file-formats>

   The <file-formats> element provides a list of file formats supported
   for the purpose of making announcements.  The element is optional.

   The <file-formats> element has no attributes.

   The <file-formats> element has the following child element:

   supported-format:   has a single attribute, 'name', which provides
      the type of file format that is supported.  The <supported-format>
      element then has a further child element, <supported-file-
      package>.  The <supported-file-package> element provides the name
      of the Media Control Channel Framework package for which the file
      format support applies.

5.1.4.11.  <max-prepared-duration>

   The <max-prepared-duration> element provides the amount of time a
   media dialog cane can be prepared in the system before it is executed.
   The element is optional.

   The <max-prepared-duration> element has no attributes.

   The <max-prepared-duration> element has the following child element:

   max-time:   has a single attribute, 'max-time-seconds', which
      provides the amount of time in seconds that a media dialog can be
      in the prepared state.  The <max-time> element then has a further
      child element, <max-time-package>.  The <max-time-package> element
      provides the name of the Media Control Channel Framework package
      for which the time period applies.

5.1.4.12.  <dtmf-support>

   The <dtmf-support> element supplies the supported methods to detect
   DTMF tones and to generate them.  The element is optional.

   The <dtmf-support> element has no attributes.

   The <dtmf-support> element has the following child elements:

   detect:   has no attributes.  The <detect> element then has a further
      child element, <dtmf-type>.  The <dtmf-type> element has two
      attributes, 'name' and 'package.  The 'name' attribute provides
      the type of DTMF being used.  The 'package' attribute provides the
      name of the Media Control Channel Framework package for which the
      DTMF type applies.

   generate:   has no attributes.  The <generate> element then has a
      further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF being used.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

   passthrough:   has no attributes.  The <passthrough> element then has
      a further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF being used.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

5.1.4.13.  <mixing-modes>

   The <mixing-modes> element provides information about the support for
   audio and video mixing of a Media Server, specifically a list of
   supported algorithms to mix audio and a list of supported video
   presentation layouts.  The element is optional.

   The <mixing-modes> element has no attributes.

   The <mixing-modes> element has the following child elements:

   audio-mixing-modes:   Is a container representing the available
      algorithms for audio mixing.  The <audio-mixing-modes> element has
      no attributes.  The <audio-mixing-modes> element has one child
      element.  The child element, <audio-mixing-mode>, contains a
      specific available algorithm.  It has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package for which the algorithm support
      applies.

   video-mixing-modes:   Is a container representing the available video
      presentation layouts and the supported functionality for what
      concerns video mixing.  The <video-mixing-modes> element has two
      attributes, 'vas' and 'activespeakermix'.  The 'vas' attribute is
      of type boolean with a value of 'true' indicating the Media Server
      supports automatic Voice Activated Switching.  The
      'activespeakermix' is of type boolean with a value of 'true'
      indicating that the Media Server is able to prepare an additional
      video stream for the loudest speaker participant without its
      contribution.  The <video-mixing-modes> element has one child
      element.  The child element, <video-mixing-mode>, contains a
      specific video presentation layout.  It has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package for which the algorithm support
      applies.

5.1.4.14.  <supported-tones>

   The <supported-tones> element provides information about which tones
   a media server support. supports.  In particular, the support is reported
   referring to both country codes support (ISO 3166-1) and supported
   functionality (H.248.1v3/ITU-T Q.1950/..).  The element is optional.

   The <supported-tones> element has no attributes.

   The <supported-tones> element has the following child elements:

   supported-country-codes:   Is a container representing the supported
      country codes with respect to tones.  The <supported-country-
      codes> element has no attributes.  The <supported-country-codes>
      has one child element.  The child element, <country-code>, reports
      support for a specific country code, compliant with the ISO 3166-1
      specification.  The <country-code> element has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package in which the tones from the
      specified country code are supported.

   supported-h248-codes:   Is a container representing the supported
      H.248 codes with respect to tones.  The <supported-h248-codes>
      element has no attributes.  The <supported-h248-codes> has one
      child element.  The child element, <h248-code>, reports support
      for a specific H.248 code, compliant with the H.248.1v3/ITU-T
      Q.1950/... specification.  The codes can be either specific (e.g.
      cg/dt to only report the Dial Tone from the Call Progress Tones
      package) or generic (e.g. cg/* to report all the tones from the
      Call Progress Tones package) using wildcards.  The <h248-code>
      element has a single attribute, 'package'.  The attribute
      'package' provides the name of the Media Control Channel Framework
      package in which the specified codes are supported.

5.1.4.15.  <streaming-modes>

   The <streaming-modes> element allows the Media Server to specify
   which protocols are supported for streaming to a Media Server for
   each Media Control Channel Framework package type.  For example,
   whether the Media Server supports audio streaming via RTSP, HTTP,
   NFS, etc protocols.  The element is optional.

   The <streaming-modes> element has no attributes.

   The <streaming-modes> element has the following child element:

   stream-mode:   has two attributes, 'name' and 'package'.  The 'name'
      attribute provides the type of protocol that can be used for
      streaming.  The 'package' attribute provides the name of the Media
      Control Channel Framework package for which the streaming protocol
      applies.

5.1.4.16.  <asr-tts-support>

   The <asr-tts-support> element provides information about the support
   for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
   functionality in a media server.  The functionality are reported by
   referring to the supported languages (using ISO-639-1 [ISO.639.1988]
   codes) for what regards both ASR and TTS.  The <asr-tts-support>
   element has no attributes.  The <asr-tts-support> element has the
   following child elements:

   asr-support:   Is a container representing the available languages
      for ASR.  The <asr-support> element has no attributes.  The <asr-
      support> has one child element.  The child element, <language>,
      reports the MS supports ASR for a specific language.  The
      <language> element has a single attribute, 'xml:lang'.  The
      attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
      the supported language.

   tts-support:   Is a container representing the available languages
      for TTS.  The <tts-support> element has no attributes.  The <tts-
      support> has one child element.  The child element, <language>,
      reports the MS supports tts for a specific language.  The
      <language> element has a single attribute, 'xml:lang'.  The
      attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
      the supported language.

5.1.4.17.  <vxml-support>

   The <vxml-support> element specifies if the Media Server supports
   VoiceXML and if it does which protocols the support is exposed
   through (e.g. via the control framework, or RFC5552).  The element is
   optional.

   The <vxml-support> element has a single attribute 'support'.  The
   'support' attribute is of type boolean with a value of 'true'
   indicating that the media server does support VXML, and a value of
   'false' indicating it does not support VXML.  The default value is
   'false'.

   The <vxml-support> element has the following child element:

   vxml-mode:   has two attributes, 'package' and 'support'.  The
      'package' attribute provides the name of the Media Control Channel
      Framework package for which the VXML support applies.  The
      'support' attribute provides the type of VXML support provided by
      the Media Server (RFC5552 or IVR-Package).

5.1.4.18.  <media-server-location>

   The <media-server-location> element provides information about the
   civic location of a media server.  Its description makes use of the
   Civic Address Schema standardized in RFC5139.  The element is
   optional.

   The <media-server-location> element has no attributes.

   The <media-server-location> element one child element:

   civicAddress:   Is a container representing the civic address
      location of the media server, whose representation refers to the
      Section 4 of RFC 5139 [RFC5139].

5.1.4.19.  <label>

   The <label> element allows a Media Server to declare a piece of
   information that will be understood by the MRB.  For example, the
   Media Server can declare if it's a blue or green. green one.  It's a string
   to allow arbitrary values to be returned to allow arbitrary
   classification.  Its arbitrary as opposed to doing it purely on
   features.  The element is optional.

   The <label> element has no attributes.

   The <label> element has no child elements.

5.1.4.20.  <media-server-address>

   The <media-server-address> element allows a Media Server to provide a
   direct URI address.  The element is optional.

   The <media-server-address> element has no attributes.

   The <media-server-address> element has no child elements.

5.1.4.21.  <encryption>

   The <encyption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  A value of
   'true' indicates that a Media Server does support RFC 3711 [RFC3711]
   for RTP.  A value of 'false' indicates that a Media Server does not
   support RFC 3711 [RFC3711] for RTP.  The element is optional.

   The <encryption> element has no attributes.

   The <application-data> element has no child elements.

5.1.5.  <mrbresponse>

   Responses to requests are indicated by a <response> element from
   Section 6. 7.

   The <response> element has following attributes:

   status:  numeric code indicating the response status.  The attribute
      is mandatory.

   The following status codes are defined:

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   |           |                                                       |
   | 400       | Syntax error                                          |
   |           |                                                       |
   | 401       | Unable to create Subscription                         |
   |           |                                                       |
   | 402       | Unable to update Subscription                         |
   |           |                                                       |
   | 403       | Unable to remove Subscription                         |
   |           |                                                       |
   | 404       | Subscription does not exist                           |
   |           |                                                       |
   | 405       | Subscription already exists                           |
   |           |                                                       |
   | 420       | Unsupported attribute or element                      |
   +-----------+-------------------------------------------------------+

                     Table 1: <response> status codes

5.2.  Media Service Resource Consumer Interface

   The Media Server Consumer interface provides the ability for clients
   of an MRB, such as Application Servers, to request an appropriate
   Media Server to satisfy specific criteria.  The interface allows a
   client to pass detailed meta-information to the MRB to help select an
   appropriate Media Server.  The MRB is then able to make an informed
   decision and provide the client with an appropriate media server
   resource.  The MRB Consumer interface can be used in association with
   both the Session Initiation Protocol (SIP) and the Hypertext Transfer
   Protocol (HTTP) [RFC2616].  The following subsections provide
   guidance on using the Consumer interface, as defined by the
   'application/mrb-consumer+xml MIME type in Section 7, 8, with HTTP and
   SIP.

5.2.1.  HTTP Consumer Interface Usage

   An appropriate interface for such a 'query' style interface is in
   fact a HTTP usage.  Using HTTP and XML combined reduces complexity
   and encourages use of common tools that are widely available in the
   industry today.  The following information explains the primary
   operations required to request and then receive information from an
   MRB.  The following description will describe the use of HTTP
   [RFC2616] and HTTPS [RFC2818] as transport for a query for media
   resource and the appropriate response.

   The media resource query, as defined by the <mediaResourceRequest>
   element from Section 7, 8, MUST be carried in the body of an HTTP/HTTPS
   POST request.  The MIME type contained in the HTTP/HTTPS request/
   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
   reflected in the appropriate HTTP headers like 'Content-Type' and
   'Accept'.  The body of the HTTP/HTTPS POST request MUST only contain
   the 'mediaResourceRequest' element as defined in Section 7. 8.  The
   'mediaResourceRequest' element is the primary container of
   information related to a media resource request.

   The media resource response to a query, as defined by the
   <mediaResourceResponse> element from Section 7, 8, MUST be carried in
   the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
   POST request.  The MIME type contained in the HTTP/HTTPS request/
   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
   reflected in the appropriate HTTP headers like 'Content-Type' and
   'Accept'.  The body of the HTTP/HTTPS 200 response MUST only contain
   the 'mediaResourceResponse' element as defined in Section 7. 8.  The
   'mediaResourceResponse' element is the primary container of
   information related to a media resource response.

5.2.2.  SIP Consumer Interface Usage

   This document provides a complete toolkit for MRB deployment which
   includes the ability to interact with an MRB using SIP for the
   Consumer interface.  The following information explains the primary
   operations required to request and then receive information from an
   MRB.  The following description will describe the use of SIP
   [RFC3261] as transport for a query for media resource and the
   appropriate response when used with IAMM of operation (as discussed
   in Section 5.3.2).

   The media resource query, as defined by the <mediaResourceRequest>
   element from Section 7, 8, MUST be carried in a SIP INVITE request.  The
   INVITE request will be constructed as it would have been to connect
   to a media server, as defined by the Media Control Channel Framework
   [I-D.ietf-mediactrl-sip-control-framework].  The following additional
   steps MUST be followed when using the Consumer interface:

   o  Include a payload in the SIP INVITE request of type 'multipart/
      mixed'[RFC2046].  The first part to be included in the 'mixed'
      payload MUST be the 'application/sdp' format which is constructed
      as specified in the Media Control Channel Framework
      [I-D.ietf-mediactrl-sip-control-framework].

   o  The second part of the 'multipart/mixed payload MUST be of type
      'application/mrb-consumer+xml', as specified in this document and
      defined in Section 7. 8.  Only the <mediaResourceRequest> and its
      child elements can be included in the payload.

   o  The INVITE request will then be dispatched to the MRB, as defined
      by [I-D.ietf-mediactrl-sip-control-framework].

   The media resource response to a query, as defined by the
   <mediaResourceResponse> element from Section 7, MUST 8, SHOULD be carried in
   the payload of a SIP 2xx class response to the original SIP INVITE
   request.  It MAY be carried in the payload of a SIP 3xx response.  It
   should be noted that the use of a SIP 3xx response aligns with the
   request/response query approach used by HTTP in Section 5.2.1.  Using
   2xx aligns with the 'in-line' approach where the MRB sits in the
   signaling path between the client and the media resource.  The 2xx
   class response will be constructed as it would have been to connect
   from a media server, as defined by the Media Control Channel
   Framework [I-D.ietf-mediactrl-sip-control-framework].  A standard 3xx
   response can also be generated.  The following additional steps MUST
   be followed when using the Consumer interface:

   o  Include a payload in the SIP 2xx class response of type
      'multipart/mixed'RFC 2046 [RFC2046].  The first part to be
      included in the 'mixed' payload MUST be the 'application/sdp'
      format which is constructed as specified in the Media Control
      Channel Framework [I-D.ietf-mediactrl-sip-control-framework].  A
      3xx response will not include payload of type 'multipart/mixed'
      and will only include a single payload of type 'application/
      mrb-consumer+xml', as discussed in the next point.

   o  The second part of the 'multipart/mixed payload MUST be of type
      'application/mrb-consumer+xml', as specified in this document and
      defined in Section 7. 8.  Only the <mediaResourceResponse> and its
      child elements can be included in the payload.

   o  The SIP 2xx 2xx/3xx class response will then be dispatched from the MRB,
      as defined by [I-D.ietf-mediactrl-sip-control-framework].
      MRB.

5.2.3.  Consumer Interface Lease Mechanism

   The Consumer interface defined in Section 7 8 and Section 7 8 allows a
   client to request an appropriate media resource based on information
   included in the request (either a HTTP POST or SIP INVITE message).
   In case of success, the response that is returned to the client MUST
   contain a <session-info> element in either the SIP 2xx class or HTTP
   200 response.  The information contained in the <session-info>
   element allows a Consumer client to monitor the life time of the
   resources it has successfully requested, as well as amending them.

   The <mediaResourceResponse> element returned from the MRB contains a
   <session-info> element if the request is successful.  The <session-
   info> element has the following child elements which provide the
   appropriate resource session information:

   o  <session-id> is a unique identifier that enables a Consumer client
      and MRB to correlate future media resource requests related to an
      initial media resource request.  The <session-id> MUST be included
      in all future related requests (see <session-id> use later in this
      section when constructing a subsequent request).

   o  <seq> is a numeric value returned to the Consumer client.  On
      issuing any future requests related to the media resource session
      (as determined by the <session-id> element) the consumer client
      MUST increment the value returned in the <seq> element and include
      in the request (see <seq> use later in this section when
      constructing a subsequent request).

   o  <expires> provide a value which represents the number of seconds
      the request for media resources is deemed alive.  The Consumer
      client should issue a refresh of the request, as discussed later
      in this section, if the expires timer is due to fire and the media
      resources are still required.

   The <mediaResourceRequest> element is used in subsequent Consumer
   interface requests if the client wishes to manipulate the session.
   The Consumer client MUST include the <session-info> element which
   enables the receiving MRB to determine an existing media resource
   allocation session.  The <session-info> element has the following
   child elements which provide the appropriate resource session
   information to the MRB:

   o  <session-id> is a unique identifier that allows a Consumer client
      to indicate the appropriate existing media resource session to be
      manipulated by the MRB for this request.  The value was provided
      by the MRB in the initial request for media resources, as
      discussed earlier in this section (<session-id> element included
      as part of the <session-info> element in the initial
      <mediaResourceResponse>).

   o  <seq> is a numeric value returned to Consumer client in the
      initial request for media resources, as discussed earlier in this
      section (<seq> element included as part of the <session-info>
      element in the initial <mediaResourceResponse>).  On issuing any
      future requests related to the specific media resource session (as
      determined by the <session-id> element) the consumer client MUST
      increment the value returned in the <seq> element from the initial
      response (contained in the <mediaResourceResponse>) for every new
      request.  The value of the <seq> element in requests acts as a
      counter to and in conjunction with the unique <session-id> allows
      for unique identification of a request.

   o  <action> element provides the operation to be carried out by the
      MRB on receiving the request.  The value of 'update' is a request
      by the Consumer client to update the existing session at the MRB
      with information alternate requirements which are contained in the remainder
      of the request.  If the requested resource information is
      identical as to the existing request, MRB session, the MRB will attempt a
      session refresh.  If the information has changed, the MRB will
      attempt to update the existing session with the new information.
      If the operation is successful, the 200 response is returned in
      the status attribute of the <mediaResourceResponseType> element.
      If the operation is not successful, a 409 response is returned in
      the status attribute of the <mediaResourceResponseType> element.
      The value of 'remove' is a request by the Consumer client to
      remove the session at the MRB.  This provides a mechanism for
      Consumer clients to release unwanted resources before they expire.
      If the operation is successful, a 200 response is returned in the
      status attribute of the <mediaResourceResponseType> element.  If
      the operation is not successful, a 410 response is returned in the XXX
      status attribute of the <mediaResourceResponseType> element.

   When used with SIP the <session-info> element MUST be included in
   either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as
   defined in[RFC3311]) request.  When used with HTTP the <session-info>
   element MUST be included in a HTTP POST message (as defined in
   [RFC2616]).

5.2.4.  Media Service Resource Request

   This section defines the XML elements for the Consumer interface.
   The formal XML schema definition for the Consumer interface can be
   found in Section 7. 8.

   The root element is <mrbconsumer>.  All other XML elements (requests,
   responses) are contained within it.  The MRB Consumer interface
   request element is detailed in Section 5.2.4.1.  MRB Consumer
   interface response element is contained in Section 5.2.5.1.

   The <mrbconsumer> element has the following attributes:

   Version)  a token specifying the mrb-consumer package version.  The
      value is fixed as '1.0' for this version of the package.  The
      attribute is mandatory.

   The <mrbconsumer> element has the following child elements, only one
   of which is allowed to occur.

      <mediaResourceRequest> for sending a Consumer request.  See
      Section 5.2.4.1.

      <mediaResourceResponse> for sending a Consumer response.  See
      Section 5.2.5.1.

5.2.4.1.  <mediaResourceRequest> element

   The <mediaResourceRequest> element provides a container for clients
   wishing to query an external MRB entity.  The <mediaResourceRequest>
   element has <generalInfo>, <ivrInfo> and <mixerInfo> as child
   elements.  These three elements are used to describe the requirements
   of a client requesting a Media Server and are covered in the
   following sub-sections.

5.2.4.1.1.  <generalInfo> element

   The <generalInfo> element provides a container for general Consumer
   request information that is neither IVR or Mixer specific.  This
   includes session information that can be used for subsequent requests
   as part of the leasing mechanism described in Section 5.2.3.  The
   <generalInfo> element has <session-info> and <packages> as child
   elements and are described in the following sub-sections.

5.2.4.1.1.1.  <session-info> element

   The <session-info> element is included in Consumer requests when an
   update is being made to an existing media resource session.  The
   ability to change and remove an existing media resource session is
   described in more detail in Section 5.2.3.  The element is optional.

   The <max-prepared-duration> element has no attributes.

   The <max-prepared-duration> element has the following child elements:

   session-id:   is a unique identifier that explicitly references an
      existing media resource session on the MRB.  The identifier is
      included to update the existing session and is described in more
      detail in Section 5.2.3.

   seq:   is used in association with the <session-id> element in a
      subsequent request to update an existing media resource session on
      an MRB.  The <seq> number is incremented from its original value
      returned in response to the initial request for media resources.
      More information about its use is provided in Section 5.2.3.

   action:   provides the operation that should be carried out on an
      existing media resource session on an MRB.  The value of 'update'
      instructs the MRB to attempt to update the existing media resource
      session with the information contained in the <ivrInfo> and
      <mixerInfo> elements.  The value of 'remove' instructs the MRB to
      attempt to remove the existing media resource session.  More
      information on its use is provided in Section 5.2.3.

5.2.4.1.1.2.  <packages> element

   The <packages> element provides a list of Media Control Channel
   Framework compliant packages that are required by the Consumer
   client.  The element is optional.

   The <packages> element has no attributes.

   The <packages> element has the following child element:

   package:   child element contains a string representing the Media
      Control Channel Framework package required by the Consumer client.
      The <package> element can appear multiple times.

5.2.4.1.2.  <ivrInfo> element

   The <ivrInfo> element provides a container for general Consumer
   request information that is IVR specific.  The <ivrInfo> element has
   <ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>,
   <location>, <encryption>, <application-data>, <max-prepared-duration>
   and <stream-mode> as child elements and are described in the
   following sub-sections.

5.2.4.1.2.1.  <ivr-sessions> element

   The <ivr-sessions> element indicates the number of IVR sessions a
   Consumer client requires from a media resource.  The element is
   optional.

   The <ivr-sessions> element has no attributes.

   The <ivr-sessions> element has the following child element:

   rtp-codec:   child element contains has a single attribute, 'name'.
      The 'name' attribute provides the name of the codec required for
      an IVR session and is an appropriately registered token.  The
      <rtp-codec> element has two child elements.  The child element,
      <decoding>, represents the number of RTP sessions for which
      decoding using the specified codec is requested.  The child
      element, <encoding>, represents the number of RTP sessions for
      which encoding using the specified codec is requested.

5.2.4.1.2.2.  <file-formats> element

   The <file-formats> element provides a list of file formats required
   for the purpose of making announcements.  The element is optional.

   The <file-formats> element has no attributes.

   The <file-formats> element has the following child element:

   supported-format:   has a single attribute, 'name', which provides
      the type of file format that is supported.  The <supported-format>
      element then has a further child element, <supported-file-
      package>.  The <supported-file-package> element provides the name
      of the Media Control Channel Framework package for which the file
      format support applies.

5.2.4.1.2.3.  <dtmf> element

   The <dtmf> element supplies the required methods to detect DTMF tones
   and to generate them.  The element is optional.

   The <dtmf> element has no attributes.

   The <dtmf> element has the following child elements:

   detect:   has no attributes.  The <detect> element then has a further
      child element, <dtmf-type>.  The <dtmf-type> element has two
      attributes, 'name' and 'package.  The 'name' attribute provides
      the type of DTMF required.  The 'package' attribute provides the
      name of the Media Control Channel Framework package for which the
      DTMF type applies.

   generate:   has no attributes.  The <generate> element then has a
      further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF required.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

   passthrough:   has no attributes.  The <passthrough> element then has
      a further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF required.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

5.2.4.1.2.4.  <tones>

   The <tones> element provides requested tones a media server must
   support for IVR.  In particular, the request refers to both country
   codes support (ISO 3166-1) and requested functionality (H.248.1v3/
   ITU-T Q.1950/..).  The element is optional.

   The <tones> element has no attributes.

   The <tones> element has the following child elements:

   country-codes:   Is a container representing the requested country
      codes with respect to tones.  The <country-codes> element has no
      attributes.  The <country-codes> has one child element.  The child
      element, <country-code>, requests a specific country code,
      compliant with the ISO 3166-1 specification.  The <country-code>
      element has a single attribute, 'package'.  The attribute
      'package' provides the name of the Media Control Channel Framework
      package in which the tones from the specified country code are
      requested.

   h248-codes:   Is a container representing the requested H.248 codes
      with respect to tones.  The <h248-codes> element has no
      attributes.  The <h248-codes> has one child element.  The child
      element, <h248-code>, requests a specific H.248 code, compliant
      with the H.248.1v3/ITU-T Q.1950/... specification.  The codes can
      be either specific (e.g. cg/dt to only report the Dial Tone from
      the Call Progress Tones package) or generic (e.g. cg/* to report
      all the tones from the Call Progress Tones package) using
      wildcards.  The <h248-code> element has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package in which the specified codes are
      requested.

5.2.4.1.2.5.  <asr-tts>

   The <asr-tts-support> element requests information about the support
   for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
   functionality in a media server.  The functionality is requested by
   referring to the supported languages (using ISO-639-1 [ISO.639.1988]
   codes) for what regards both ASR and TTS.  The <asr-tts-support>
   element has no attributes.  The <asr-tts-support> element has the
   following child elements:

   asr-support:   Is a container representing the available languages
      for ASR.  The <asr-support> element has no attributes.  The <asr-
      support> has one child element.  The child element, <language>,
      requests the MS supports ASR for a specific language.  The
      <language> element has a single attribute, 'xml:lang'.  The
      attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
      the supported language.

   tts-support:   Is a container requesting the available languages for
      TTS.  The <tts-support> element has no attributes.  The <tts-
      support> has one child element.  The child element, <language>,
      requests the MS supports tts for a specific language.  The
      <language> element has a single attribute, 'xml:lang'.  The
      attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
      the supported language.

5.2.4.1.2.6.  <vxml> element

   The <vxml> element specifies if the Consumer client required VoiceXML
   and if it does which protocols the support is exposed through (e.g.
   via the control framework, or RFC5552).  The element is optional.

   The <vxml> element has a single attribute 'support'.  The 'support'
   attribute is of type boolean with a value of 'true' indicating that
   the Consumer client requires VXML support, and a value of 'false'
   indicating it does not require VXML support.  The default value is
   'false'.

   The <vxml> element has the following child element:

   vxml-mode:   has two attributes, 'package' and 'require'.  The
      'package' attribute provides the name of the Media Control Channel
      Framework package for which the VXML support applies.  The
      'require' attribute specifies the type of VXML support required by
      the Consumer client (RFC5552 or IVR-Package).

5.2.4.1.2.7.  <location>

   The <location> element requests a civic location for an IVR media
   server.  The request makes use of the Civic Address Schema
   standardized in RFC 5139 [RFC5139].  The element is optional.

   The <location> element has no attributes.

   The <location> element one child element:

   civicAddress:   Is a container representing the civic address
      location of the requested media server, whose representation
      refers to Section 4 of RFC 5139 [RFC5139].

5.2.4.1.2.8.  <encryption>

   The <encryption> element allows a Consumer client to request support
   for encrypting RTP media streams using RFC 3711 [RFC3711].  A value
   of 'true' indicates that Consumer client requires support of RFC 3711
   [RFC3711] for RTP.  A value of 'false' indicates that a Consumer
   client does not require support of RFC 3711 [RFC3711] for RTP.  The
   element is optional.  The default value is 'false'

   The <encryption> element has no attributes.

   The <application-data> element has no child elements.

5.2.4.1.2.9.  <application-data>

   The <application-data> element provides IVR application level data.
   The element is optional.

   The <application-data> element has no attributes.

   The <application-data> element has no child elements.

5.2.4.1.2.10.  <max-prepared-duration>

   The <max-prepared-duration> element provides the amount of time
   required by the Consumer client that a media dialog can be prepared
   in the system before it is executed.  The element is optional.

   The <max-prepared-duration> element has no attributes.

   The <max-prepared-duration> element has the following child element:

   max-time:   has a single attribute, 'max-time-seconds', which
      provides the amount of time in seconds that a media dialog can be
      in the prepared state.  The <max-time> element then has a further
      child element, <max-time-package>.  The <max-time-package> element
      provides the name of the Media Control Channel Framework package
      for which the time period applies.

5.2.4.1.2.11.  <streaming-modes>

   The <streaming-modes> element allows the Consumer client to specify
   which protocols are required for streaming to a Media Server for each
   Media Control Channel Framework package type.  For example does the
   Media Server supports audio streaming via RTSP, HTTP, NFS, etc
   protocols.  The element is optional.

   The <streaming-modes> element has no attributes.

   The <streaming-modes> element has the following child element:

   stream-mode:   has two attributes, 'name' and 'package'.  The 'name'
      attribute provides the type of protocol required for streaming.
      The 'package' attribute provides the name of the Media Control
      Channel Framework package for which the streaming protocol
      applies.

5.2.4.1.3.  <mixerInfo> element

   The <mixerInfo> element provides a container for general Consumer
   request information that is Mixer specific.  The <mixerInfo> element
   has <mixers>, <file-formats>, <dtmf-type>, <tones>, <mixing-mode>,
   <application-data>, <location> and <encryption> are described in the
   following sub-sections.

5.2.4.1.3.1.  <mixers>

   The <mixers> element provides information detailing the required
   mixed RTP sessions.  The element is optional.

   The <mixers> element has no attributes.

   The <mixers> element has the following child element:

   mix:   Is a container which representing represents a required mixed RTP session.
      The <mix> element has one attribute.  The attribute 'users'
      represents the number of participants required in the mix.  The
      <mix> element has one child elements.  The child element, <codec>,
      contains the same information relating to RTP sessions as defined
      in Section 5.1.4.3.  The element is optional.

5.2.4.1.3.2.  <file-formats>

   The <file-formats> element provides a list of file formats required
   by the Consumer client for the purpose of making announcements to a
   mix.  The element is optional.

   The <file-formats> element has no attributes.

   The <file-formats> element has the following child element:

   required-format:   has a single attribute, 'name', which provides the
      type of file format that is supported.  The <required-format>
      element then has a further child element, <required-file-package>.
      The <required-file-package> element provides the name of the Media
      Control Channel Framework package for which the file format
      support applies.

5.2.4.1.3.3.  <dtmf> element

   The <dtmf> element supplies the required methods to detect DTMF tones
   and to generate them in a mix.  The element is optional.

   The <dtmf> element has no attributes.

   The <dtmf> element has the following child elements:

   detect:   has no attributes.  The <detect> element then has a further
      child element, <dtmf-type>.  The <dtmf-type> element has two
      attributes, 'name' and 'package.  The 'name' attribute provides
      the type of DTMF required.  The 'package' attribute provides the
      name of the Media Control Channel Framework package for which the
      DTMF type applies.

   generate:   has no attributes.  The <generate> element then has a
      further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF required.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

   passthrough:   has no attributes.  The <passthrough> element then has
      a further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes, 'name' and 'package.  The 'name' attribute
      provides the type of DTMF required.  The 'package' attribute
      provides the name of the Media Control Channel Framework package
      for which the DTMF type applies.

5.2.4.1.3.4.  <tones>

   The <tones> element provides requested tones a media server must
   support for a mix.  In particular, the request refers to both country
   codes support (ISO 3166-1) and requested functionality (H.248.1v3/
   ITU-T Q.1950/..).  The element is optional.

   The <tones> element has no attributes.

   The <tones> element has the following child elements:

   country-codes:   Is a container representing the requested country
      codes with respect to tones.  The <country-codes> element has no
      attributes.  The <country-codes> has one child element.  The child
      element, <country-code>, requests a specific country code,
      compliant with the ISO 3166-1 specification.  The <country-code>
      element has a single attribute, 'package'.  The attribute
      'package' provides the name of the Media Control Channel Framework
      package in which the tones from the specified country code are
      requested.

   h248-codes:   Is a container representing the requested H.248 codes
      with respect to tones.  The <h248-codes> element has no
      attributes.  The <h248-codes> has one child element.  The child
      element, <h248-code>, requests a specific H.248 code, compliant
      with the H.248.1v3/ITU-T Q.1950/... specification.  The codes can
      be either specific (e.g. cg/dt to only report the Dial Tone from
      the Call Progress Tones package) or generic (e.g. cg/* to report
      all the tones from the Call Progress Tones package) using
      wildcards.  The <h248-code> element has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package in which the specified codes are
      requested.

5.2.4.1.3.5.  <mixing-modes>

   The <mixing-modes> element requests information about the support for
   audio and video mixing of a Media Server, specifically a list of
   supported algorithms to mix audio and a list of supported video
   presentation layouts.  The element is optional.

   The <mixing-modes> element has no attributes.

   The <mixing-modes> element has the following child elements:

   audio-mixing-modes:   Is a container representing the requested
      algorithms for audio mixing.  The <audio-mixing-modes> element has
      no attributes.  The <audio-mixing-modes> element has one child
      element.  The child element, <audio-mixing-mode>, contains a
      specific requested algorithm.  It has a single attribute,
      'package'.  The attribute 'package' provides the name of the Media
      Control Channel Framework package for which the algorithm support
      is requested.

   video-mixing-modes:   Is a container representing the requested video
      presentation layouts for video mixing.  The <video-mixing-modes>
      element has two attributes, 'vas' and 'activespeakermix'.  The
      'vas' attribute is of type boolean with a value of 'true'
      indicating that the Consumer Client requires automatic Voice
      Activated Switching.  The 'activespeakermix' attribute is of type
      boolean with a value of 'true' indicating that the Consumer Client
      requires an additional video stream for the loudest speaker
      participant without its contribution.  The <video-mixing-modes>
      element has one child element.  The child element, <video-mixing-
      mode>, contains a requested video presentation layout.  It has a
      single attribute, 'package'.  The attribute 'package' provides the
      name of the Media Control Channel Framework package for which the
      algorithm support is requested.

5.2.4.1.3.6.  <application-data>

   The <application-data> element provides IVR application level data.
   The element is optional.

   The <application-data> element has no attributes.

   The <application-data> element has no child elements.

5.2.4.1.3.7.  <location>

   The <location> element requests a civic location for a mixer media
   server.  The request makes use of the Civic Address Schema
   standardized in RFC 5139 [RFC5139].  The element is optional.

   The <location> element has no attributes.

   The <location> element one child element:

   civicAddress:   Is a container representing the civic address
      location of the requested media server, whose representation
      refers to Section 4 of RFC 5139 [RFC5139].

5.2.4.1.3.8.  <encryption>

   The <encryption> element allows a Consumer client to request support
   for encrypting mixed RTP media streams using RFC 3711 [RFC3711].  A
   value of 'true' indicates that Consumer client requires support of
   RFC 3711 [RFC3711] for RTP.  A value of 'false' indicates that a
   Consumer client does not require support of RFC 3711 [RFC3711] for
   RTP.  The element is optional.  The default value is 'false'

   The <encryption> element has no attributes.

   The <application-data> element has no child elements.

5.2.5.  Media Service Resource Response

   This section provides the element definitions for use in Consumer
   interface responses.  The responses are carried in the
   <mediaResourceResponse> container element.

5.2.5.1.  <mediaResourceResponse> element

   The <mediaResourceResponse> element provides a container for clients
   receiving query information from an external MRB entity.

   The <mediaResourceResponse> element has a single attribute 'status'
   which indicates the status code of the operation.  The following
   status codes are defined:

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   |           |                                                       |
   | 400       | Syntax error                                          |
   |           |                                                       |
   | 408       | Unable to find Resource                               |
   |           |                                                       |
   | 409       | Unable to update Resource                             |
   |           |                                                       |
   | 410       | Unable to remove Resource                             |
   |           |                                                       |
   | 420       | Unsupported attribute or element                      |
   +-----------+-------------------------------------------------------+

                     Table 2: <response> status codes

   The <mediaResourceResponse> element only has <response-session-info>
   as a child element.  This element is used to describe the response of
   a Consumer interface query and is covered in the following sub-
   section.

5.2.5.1.1.  <response-session-info> element

   The <response-session-info> element is included in Consumer responses
   when an update has been made to an existing media resource session.
   The ability to change and remove an existing media resource session
   is described in more detail in Section 5.2.3.  The element is
   optional.

   The <max-prepared-duration> element has no attributes.

   The <max-prepared-duration> element has the following child elements:

   session-id:   is a unique identifier that explicitly references an
      existing media resource session on the MRB.  The identifier is
      included to update the existing session and is described in more
      detail in Section 5.2.3.

   seq:   is used in association with the <session-id> element in a
      subsequent request to update an existing media resource session on
      an MRB.  The <seq> number is incremented from its original value
      returned in response to the initial request for media resources.
      More information its use is provided in Section 5.2.3.

   expires:   includes the number of seconds that the media resources
      are reserved as part of this interaction.  If the lease is not
      refreshed before expiry, the MRB will re-claim the resources and
      they will no longer be guaranteed.  It is RECOMMENDED that a
      minimum value of 300 seconds be used for the value of the
      'expires' attribute.  It is also RECOMMENDED that a Consumer
      client refresh the lease at an interval that is not too close to
      the expiry time.  A value of 80% of the timeout period could be
      used.  For example, if the timeout period is 300 seconds, the
      Server would refresh the transaction at 240 seconds.  More
      information on its use is provided in Section 5.2.3.

   media-server-address:   is the SIP URI to reach the MS handling the
      requested media resource.

   [Editors' Note: this response should also include a way for the
   Consumer Client to contact the MS able to fulfil the request, at
   least in case of the HTTP usage of the Consumer interface.  Such info
   wouldn't be needed in the IAMM case.  At the moment this is reported
   by means of the <media-server-address> element, which is also used in
   the publishing publish interface.  Is this SIP URI enough?  Do we need to
   provide additional details?]

5.3.  In-Line MRB Interface

   An entity acting as an In-Line MRB can act in one of two roles for a
   request, as introduced in Section 4.2.  The following sub sections
   provide details for using In-Line Unaware MRB Mode (IUMM) of
   operation and In-Line Aware MRB Mode (IAMM) of operation.

5.3.1.  In-line Unaware MRB Mode

   It should be noted that the introduction of an MRB entity into the
   network, as specified in this document, requires interfaces to be
   implemented by those requesting media server resources (for example
   an application server).  This applies when using both the Consumer
   interface as discussed in Section 5.2.1 and IAMM Section 5.2.2.
   Nevertheless, an MRB is conceived to also be able to act in a client
   unaware mode when it is deployed into the network.  This allows any
   SIP compliant client entity, as defined by RFC 3261 [RFC3261] and its
   extensions, to send requests to an MRB which in turn will select an
   appropriate media server based on knowledge of media server resources
   it currently has available transparently to the client entity.
   Mechanisms used to connect to media servers are detailed in the Media
   Channel Control Framework [I-D.ietf-mediactrl-sip-control-framework].
   Using an MRB in this mode allows for easy migration of current
   applications and services that are unaware of the MRB concept and
   would simply require a configuration change resulting in the MRB
   being set as a SIP outbound proxy for clients requiring media
   services.  Any client of media services wishing to take advantage of
   the advanced techniques detailed in this document when using In-line
   mode would implement IAMM which is covered in Section 5.3.2.  The
   techniques used for selecting an appropriate Media Server by an MRB
   acting in IUMM is outside the scope of this document.

5.3.2.  In-line Aware MRB Mode

   An In-Line Aware Mode MRB (IAMM) is one that complies to the extended
   functionality provided in this section.  A client entity, such as an
   application server, wishing to use advanced MRB functionality can
   provide additional contextual information to an MRB.  This
   information is identical to that used in the Consumer interface in
   Section 5.2 with the only difference being the underlying transport
   mechanism of the contextual information, as specified by the
   'application/mrb-consumer+xml' payload in Section 7. 8.  A client of an
   IAMM, as anticipated in Section 5.2.2, uses SIP signalling to convey
   the 'application/mrb-consumer+xml' payload to the IAMM, unlike the
   Consumer interface presented in Section 5.2.1, which instead uses
   HTTP as a transport.  A client of an IAMM requiring media services,
   as well as creating a standard SIP complaint request, MUST use the
   following steps (also presented in Section 5.2.2) to ensure that the
   request is dealt with appropriately:

   o  The client of the IAMM constructs a SIP INVITE request to connect
      to a Media Server as detailed in the Media Channel Control
      Framework [I-D.ietf-mediactrl-sip-control-framework] with one
      exception.

   o  The client of the IAMM includes a MIME content type of multipart/
      mixed as defined in RFC 2046 [RFC2046].  As part of this mixed
      payload, the client MUST at least include a content-type of type
      'application/sdp' and a content type of type 'application/
      mrb-consumer+xml'.  The part of type application/sdp represents
      the media server connection details and MUST adhere to the Media
      Channel Control Framework
      [I-D.ietf-mediactrl-sip-control-framework].  The part of type
      'application/mrb-consumer+xml' represents the IAMM contextual
      information and MUST adhere to the schema defined in Section 7. 8.

   o  Once the SIP INVITE request is constructed, it is sent to the
      recipient as per RFC 3261 [RFC3261].

   On receiving a SIP INVITE request containing the multipart mixed
   payload as specified previously, the IAMM will complete a number of
   steps to fulfil the request.  It will:

   o  Extract the multipart MIME payload from the SIP INVITE request.
      It will then use the contextual information provided by the client
      in the 'application/mrb-consumer+xml' part to determine which
      media server should be selected to service the request.

   o  Extract the 'application/sdp' part from the payload and use it to
      populate a new SIP INVITE request for connecting the client to the
      selected media server, as defined in the Media Channel Control
      Framework [I-D.ietf-mediactrl-sip-control-framework].  The IAMM
      acts as a Back-to-Back-UA (B2BUA) that extracts IAMM
      acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
      mrb-consumer+xml' information from the SIP INVITE request and then
      forwards to the selected Media Server.

6.  Examples

   This section provides examples of both the Publish and Consumer
   interfaces.  For what concerns the Consumer interface, both Query and
   Inline modes are addressed.

6.1.  Publish Example

   The following example assumes a control channel has been established
   and synced as described in the Media Control Channel Framework
   ([I-D.ietf-mediactrl-sip-control-framework]).

   Figure 9 shows the subscription/notification mechanism the Publish
   interface is based on, as defined in Section 5.1.  The MRB subscribes
   for information at the MS (message A1.), and the MS accepts the
   subscription (A2).  Notifications are triggered by the MS (A3.) and
   acknowledged by the MRB (A4.).

         MRB                                            MS
          |                                              |
          | A1. CONTROL (MRB subscription)               |
          |--------------------------------------------->|
          |                                   A2. 200 OK |
          |<---------------------------------------------|
          |                                              |
          .                                              .
          .                                              .
          |                                              |
          |                                              |--+ collect
          |                                              |  | up-to-date
          |                                              |<-+ info
          |               B1. CONTROL (MRB notification) |
          |<---------------------------------------------|
          | B2. 200 OK                                   |
          |--------------------------------------------->|
          |                                              |
          .                                              .
          .                                              .

                Figure 9: Publish Example: Sequence Diagram

   The rest of this section includes a full dump of the messages
   associated with the previous sequence diagram, specifically:

   1.  the subscription (A1), in an <mrbrequest> (CFW CONTROL);

   2.  the MS accepting the subscription (A2), in an <mrbresponse> (CFW
       200);

   3.  a notification (A3), in a <mrbnotification> (CFW CONTROL event);

   4.  the ack to the notification (A4), in a framework level 200
       message (CFW 200);

A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbrequest>
        <subscription action="create" seqnumber="1" id="p0T65U">
            <expires>600</expires>
            <frequency>20</frequency>
        </subscription>
    </mrbrequest>
</mrbpublish>

A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139

<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
        <mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>

B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4242

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish" \
            xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
    <mrbnotification seqnumber="1" id="QQ6J3c">
        <media-server-id>a1b2c3d4</media-server-id>
        <supported-packages>
            <package name="msc-ivr/1.0"/>
            <package name="msc-mixer/1.0"/>
            <package name="mrb-publish/1.0"/>
            <package name="msc-example-pkg/1.0"/>
        </supported-packages>
        <active-rtp-sessions>
            <rtp-codec name="G.711">
                <decoding>10</decoding>
                <encoding>20</encoding>
            </rtp-codec>
        </active-rtp-sessions>
        <active-mixer-sessions>
            <active-mix conferenceid="7cfgs43">
                <rtp-codec name="G.711">
                    <decoding>3</decoding>
                    <encoding>3</encoding>
                </rtp-codec>
            </active-mix>
        </active-mixer-sessions>
        <non-active-rtp-sessions>
            <rtp-codec name="G.711">
                <decoding>50</decoding>
                <encoding>40</encoding>
            </rtp-codec>
        </non-active-rtp-sessions>
        <non-active-mixer-sessions>
            <non-active-mix available="15">
                <rtp-codec name="G.711"/>
            </non-active-mix>
        </non-active-mixer-sessions>
        <media-server-status>active</media-server-status>
        <supported-codecs>
            <supported-codecs name="G.711">
                <supported-codec-package name="msc-ivr">
                    <supported-actions>encoding</supported-actions>
                    <supported-actions>decoding</supported-actions>
                </supported-codec-package>
                <supported-codec-package name="msc-mixer">
                    <supported-actions>encoding</supported-actions>
                    <supported-actions>decoding</supported-actions>
                </supported-codec-package>
            </supported-codecs>
        </supported-codecs>
        <application-data>Testbed Prototype</application-data>
        <file-formats>
            <supported-format name="audio/x-wav">
                <supported-file-package/>
            </supported-format>
        </file-formats>
        <max-prepared-duration>
            <max-time max-time-seconds="3600">
                <max-time-package>msc-ivr</max-time-package>
            </max-time>
        </max-prepared-duration>
        <dtmf-support>
            <detect>
                <dtmf-type package="msc-ivr" name="RFC4733"/>
                <dtmf-type package="msc-mixer" name="RFC4733"/>
            </detect>
            <generate>
                <dtmf-type package="msc-ivr" name="RFC4733"/>
                <dtmf-type package="msc-mixer" name="RFC4733"/>
            </generate>
            <passthrough>
                <dtmf-type package="msc-ivr" name="RFC4733"/>
                <dtmf-type package="msc-mixer" name="RFC4733"/>
            </passthrough>
        </dtmf-support>
        <mixing-modes>
            <audio-mixing-modes>
                <audio-mixing-mode package="msc-ivr">
                     nbest
                </audio-mixing-mode>
            </audio-mixing-modes>
            <video-mixing-modes activespeakermix="true" vas="true">
                <video-mixing-mode package="msc-mixer">
                     single-view
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     dual-view
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     dual-view-crop
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     dual-view-2x1
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     dual-view-2x1-crop
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     quad-view
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     multiple-5x1
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     multiple-3x3
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer">
                     multiple-4x4
                </video-mixing-mode>
            </video-mixing-modes>
        </mixing-modes>
        <supported-tones>
            <supported-country-codes>
                <country-code package="msc-ivr">GB</country-code>
                <country-code package="msc-ivr">IT</country-code>
                <country-code package="msc-ivr">US</country-code>
            </supported-country-codes>
            <supported-h248-codes>
                <h248-code package="msc-ivr">cg/*</h248-code>
                <h248-code package="msc-ivr">biztn/ofque</h248-code>
                <h248-code package="msc-ivr">biztn/erwt</h248-code>
                <h248-code package="msc-mixer">conftn/*</h248-code>
            </supported-h248-codes>
        </supported-tones>
        <streaming-modes>
            <stream-mode package="msc-ivr" name="HTTP"/>
        </streaming-modes>
        <asr-tts-support>
            <asr-support>
                <language xml:lang="en"/>
            </asr-support>
            <tts-support>
                <language xml:lang="en"/>
            </tts-support>
        </asr-tts-support>
        <vxml-support support="false">
            <vxml-mode package="msc-ivr"/>
        </vxml-support>
        <media-server-location>
           <ca:civicAddress xml:lang="it">
             <ca:country>IT</ca:country>
             <ca:A1>Campania</ca:A1>
             <ca:A3>Napoli</ca:A3>
             <ca:A6>Via Claudio</ca:A6>
             <ca:HNO>21</ca:HNO>
             <ca:LMK>University of Napoli Federico II</ca:LMK>
             <ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM>
             <ca:PC>80210</ca:PC>
           </ca:civicAddress>
        </media-server-location>
        <label>TestbedPrototype-01</label>
        <media-server-address>
                 sip:MediaServer@ms.example.com:5080
        </media-server-address>
        <encryption>false</encryption>
    </mrbnotification>
</mrbpublish>

B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200

6.2.  Consumer Example

   As specified in Section 5.2, the Consumer interface can be involved
   in two different modes: Query and Inline-aware.  When in Query mode,
   Consumer messages are transported in HTTP messages: an example of
   such an approach is presented in Section 6.2.1.  When in Inline-aware
   mode, messages are transported as part of SIP negotiations: an
   example of such an approach is presented in Section 6.2.2.

6.2.1.  Query Example

   The following example assumes the interested AS already knows the
   HTTP URL where an MRB is listening for Consumer messages.

   Figure 10 shows the HTTP-based transaction between the AS and the
   MRB.  The AS sends a consumer request as payload of an HTTP POST
   message (1.), and the MRB provides an answer in an HTTP 200 OK
   message (2.).

     AS                                             MRB
      |                                              |
      | 1. HTTP POST (Consumer request)              |
      |--------------------------------------------->|
      |                                              |
      |                                              |
      |                                              |--+ Parse request
      |                                              |  | and see if any
      |                                              |<-+ MS applies
      |                                              |
      |                2. 200 OK (Consumer response) |
      |<---------------------------------------------|
      |                                              |
      |--+ Parse response and                        |
      |  | start session (SIP/COMEDIA/CFW)           |
      |<-+ with MS reported by MRB                   |
      |                                              |
      .                                              .
      .                                              .

           Figure 10: Consumer Example (Query): Sequence Diagram

   The rest of this section includes a full dump of the messages
   associated with the previous sequence diagram, specifically:

   1.  the Consumer request (1), in a <mediaResourceRequest> (HTTP POST,
       Content-Type 'application/mrb-consumer+xml');

   2.  the Consumer response (2), in an <mediaResourceResponse> (HTTP
       200 OK, Content-Type 'application/mrb-consumer+xml').

1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------
POST /Mrb/Consumer HTTP/1.1
Content-Length: 1008
Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceRequest>
        <generalInfo>
            <session-info>
                <session-id>0GX1jCYZ8WBa</session-id>
                <seq>1</seq>
            </session-info>
            <packages>
                <package>msc-ivr/1.0</package>
                <package>msc-mixer/1.0</package>
            </packages>
        </generalInfo>
        <ivrInfo>
            <ivr-sessions>
                <rtp-codec name="PCMU">
                    <decoding>10</decoding>
                    <encoding>10</encoding>
                </rtp-codec>
            </ivr-sessions>
            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>
            <streaming-modes>
                <stream-mode package="msc-ivr/1.0" name="HTTP"/>
            </streaming-modes>
        </ivrInfo>
    </mediaResourceRequest>
</mrbconsumer>

2. AS <- MRB (200 to POST, Consumer response)
---------------------------------------------
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 506
Date: Mon, 08 Feb 2010 16:53:34 GMT

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
    <mediaResourceResponse reason="Resource found" status="200">
        <response-session-info>
            <session-id>0GX1jCYZ8WBa</session-id>
            <seq>1</seq>
            <expires>3600</expires>
            <media-server-address>
                sip:MediaServer@ms.example.com:5080
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
</mrbconsumer>
   The rest of the scenario is omitted for brevity.  After having
   received the 'mediaResourceResponse', the AS has the address of a MS
   able to fulfil its media requirements, and can start a Control Dialog
   with it.

6.2.2.  IAMM Example

   The following example assumes the interested AS already knows the SIP
   URI where an MRB is listening as an UAS.

   Figure 10 shows the SIP-based transactions involving the AS, the MRB
   and the MS that will be chosen eventually.  The diagram is more
   complex than before.  This is basically a scenario envisaging the MRB
   as a B2BUA.  The AS sends a SIP INVITE (1.), containing both a CFW-
   related SDP and a Consumer request (multipart body).  The MRB sends a
   provisional response to the AS (2.) and starts working on the
   request.  First of all, it makes use of the Consumer request from the
   AS to determine which MS should be exploited.  Once the right MS has
   been chosen, the MRB sends a new SIP INVITE to this MS by just
   including the SDP part of the original request (3.).  The MS
   negotiates this INVITE as specified in
   [I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing
   the MRB with its own CFW-related SDP.  The MRB replies to the
   original AS INVITE preparing a SIP 200 OK with another multipart body
   (7.): this multipart body includes the Consumer response used by the
   MRB to determine the right MS and the SDP returned by the MS in 5.
   The AS finally acknowledges the 200 OK (8.), and can start a CFW
   connection towards the MS.

   AS                  MRB                          MS
    |                       |                           |
    | 1. INVITE             |                           |
    | (multipart/mixed)     |                           |
    |---------------------->|                           |
    |       2. 100 (Trying) |                           |
    |<----------------------|                           |
    |                       |--+ Extract SDP and        |
    |                       |  | MRB payloads; handle   |
    |                       |<-+ Consumer request to    |
    |                       |    know MS to use         |
    |                       |                           |
    |                       | 3. INVITE                 |
    |                       | (only copy SDP from 1.)   |
    |                       |-------------------------->|
    |                       |           4. 100 (Trying) |
    |                       |<--------------------------|
    |                       |                           |--+ Negotiate
    |                       |                           |  | CFW Control
    |                       |                           |<-+ Channel
    |                       |                 5. 200 OK |
    |                       |<--------------------------|
    |                       | 6. ACK                    |
    |                       |-------------------------->|
    |        Prepare new +--|                           |
    |       payload with |  |                           |
    |    SDP from MS and +->|                           |
    |     Consumer reply    |                           |
    |                       |                           |
    |             7. 200 OK |                           |
    |     (multipart/mixed) |                           |
    |<----------------------|                           |
    | 8. ACK                |                           |
    |---------------------->|                           |
    |                       |                           |
    |--+ Read Cons. reply   |                           |
    |  | and use SDP to     |                           |
    |<-+ create CFW Chn.    |                           |
    |                       |                           |
    |                                                   |
    |<<############## TCP CONNECTION #################>>|
    |                                                   |
    | CFW SYNC                                          |
    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
    |                                                   |
    .                       .                           .
    .                       .                           .

           Figure 11: Consumer Example (IAMM): Sequence Diagram

   The rest of this section includes an almost full dump of the messages
   associated with the previous sequence diagram.  Only the relevant SIP
   messages are shown (both the INVITEs and the 200 OKs), and only the
   relevant headers are preserved for brevity (Content-Type and
   multipart-related information).  Specifically:

   1.  the original INVITE (1), containing both a CFW-related SDP
       (COMEDIA information to negotiate a new Control Channel) and a
       Consumer <mediaResourceRequest>;

   2.  the INVITE sent by the MRB to the MS as a B2BUA (3.), containing
       only the CFW-related SDP from the original INVITE;.

   3.  the 200 OK sent by the MS back to the MRB (5.), to complete the
       CFW-related negotiation (SDP only);

   4.  the 200 OK sent by the MRB back to the AS in response to the
       original INVITE (7.), containing both the CFW-related information
       sent by the MS and a Consumer <mediaResourceRequest> documenting
       the MRB's decision to use that MS.

1. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
   [..]
   Content-Type: multipart/mixed; \
                          boundary="----=_Part_0_19138361.1261662356915"

   ------=_Part_0_19138361.1261662356915
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2890842807 IN IP4 as.example.com
   s=MediaCtrl
   c=IN IP4 as.example.com
   t=0 0
   m=application 48035 TCP cfw
   a=connection:new
   a=setup:active
   a=cfw-id:vF0zD4xzUAW9
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0

   ------=_Part_0_19138361.1261662356915
   Content-Type: application/mrb-consumer+xml
   <mrbconsumer version="1.0" \
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceRequest>
        <generalInfo>
            <session-info>
                <session-id>q79OYY0q4M6M</session-id>
                <seq>1</seq>
            </session-info>
            <packages>
                <package>msc-ivr/1.0</package>
                <package>msc-mixer/1.0</package>
            </packages>
        </generalInfo>
        <ivrInfo>
            <ivr-sessions>
                <rtp-codec name="PCMU">
                    <decoding>10</decoding>
                    <encoding>10</encoding>
                </rtp-codec>
            </ivr-sessions>
            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>
            <streaming-modes>
                <stream-mode package="msc-ivr/1.0" name="HTTP"/>
            </streaming-modes>
        </ivrInfo>
    </mediaResourceRequest>
   </mrbconsumer>

   ------=_Part_0_19138361.1261662356915--

3. MRB -> MS (INVITE sdp only)
------------------------------
   [..]
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2890842807 IN IP4 as.example.com
   s=MediaCtrl
   c=IN IP4 as.example.com
   t=0 0
   m=application 48035 TCP cfw
   a=connection:new
   a=setup:active
   a=cfw-id:vF0zD4xzUAW9
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0

5. MRB <- MS (200 OK sdp)
-------------------------
   [..]
   Content-Type: application/sdp

   v=0
   o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
   s=MediaCtrl
   c=IN IP4 ms.example.net
   t=0 0
   m=application 7575 TCP cfw
   a=connection:new
   a=setup:passive
   a=cfw-id:vF0zD4xzUAW9
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0
   a=ctrl-package:mrb-publish/1.0
   a=ctrl-package:msc-example-pkg/1.0

7. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
   [..]
   Content-Type: multipart/mixed; \
                           boundary="----=_Part_1_3022359.1261662358037"

   ------=_Part_1_3022359.1261662358037
   Content-Type: application/sdp

   v=0
   o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
   s=MediaCtrl
   c=IN IP4 ms.example.net
   t=0 0
   m=application 7575 TCP cfw
   a=connection:new
   a=setup:passive
   a=cfw-id:vF0zD4xzUAW9
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0
   a=ctrl-package:mrb-publish/1.0
   a=ctrl-package:msc-example-pkg/1.0
   ------=_Part_1_3022359.1261662358037
   Content-Type: application/mrb-consumer+xml

   <mrbconsumer version="1.0" \
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceResponse reason="Resource found" status="200">
        <response-session-info>
            <session-id>q79OYY0q4M6M</session-id>
            <seq>1</seq>
            <expires>3600</expires>
            <media-server-address>
                  sip:MediaServer@ms.example.net
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
   </mrbconsumer>

------=_Part_1_3022359.1261662358037--

   The continuation of the 'application/
      mrb-consumer+xml' information from scenario (the AS connecting to the SIP INVITE request and then
      forwards MS to
   start the selected Media Server.

6. Control Channel, the SYNC message, etc.) are omitted for
   brevity.

7.  Media Service Resource Publisher Interface XML Schema

   This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
   20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
   mrb-publish+xml" format.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
 elementFormDefault="qualified" blockDefault="#all"
 xmlns="urn:ietf:params:xml:ns:mrb-publish"
 xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <xsd:annotation>
  <xsd:documentation>
   IETF MediaCtrl MRB 1.0

   This is the schema of the IETF MediaCtrl MRB package.

   The schema namespace is urn:ietf:params:xml:ns:mrb-publish

  </xsd:documentation>
 </xsd:annotation>

 <!--
  #############################################################

  SCHEMA IMPORTS

  #############################################################
 -->

 <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd">
  <xsd:annotation>
   <xsd:documentation>
    This import brings in the XML attributes for
    xml:base, xml:lang, etc
   </xsd:documentation>
  </xsd:annotation>
 </xsd:import>

<xsd:import
  namespace="urn:ietf:params:xml:ns:control:framework-attributes"
  schemaLocation="framework.xsd">
  <xsd:annotation>
   <xsd:documentation>
    This import brings in the framework attributes for
    conferenceid and connectionid.
   </xsd:documentation>
  </xsd:annotation>
</xsd:import>

<xsd:import
  namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
  schemaLocation="civicAddress.xsd">
  <xsd:annotation>
   <xsd:documentation>
    This import brings in the civicAddress specification
    from RFC5139.
   </xsd:documentation>
  </xsd:annotation>
</xsd:import>

<!--
  #####################################################

  Extensible core type

  #####################################################
 -->

 <xsd:complexType name="Tcore">
  <xsd:annotation>
   <xsd:documentation>
    This type is extended by other (non-mixed) component types to
    allow attributes from other namespaces.
   </xsd:documentation>
  </xsd:annotation>
  <xsd:sequence/>
  <xsd:anyAttribute namespace="##other" processContents="lax" />
 </xsd:complexType>

<!--
  #####################################################

  TOP LEVEL ELEMENT: mrbpublish

  #####################################################
 -->

<xsd:complexType name="mrbpublishType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="mrbrequest" />
      <xsd:element ref="mrbresponse" />
      <xsd:element ref="mrbnotification" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:attribute name="version" type="version.datatype"
      use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="mrbpublish" type="mrbpublishType" />

<!--
  #####################################################

  mrbrequest TYPE

  #####################################################
 -->

<!--  mrbrequest -->

 <xsd:complexType name="mrbrequestType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:element ref="subscription" />
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="mrbrequest" type="mrbrequestType" />

<!--  subscription -->
<xsd:complexType name="subscriptionType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:element name="expires" type="xsd:nonNegativeInteger"
      minOccurs="0" maxOccurs="1" />
     <xsd:element name="frequency" type="xsd:nonNegativeInteger"
      minOccurs="0" maxOccurs="1" />
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="id" type="id.datatype" use="required" />
    <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
      use="required" />
    <xsd:attribute name="action" type="action.datatype"
      use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="subscription" type="subscriptionType" />

<!--
  #####################################################

  mrbresponse TYPE

  #####################################################
 -->

<!--  mrbresponse -->

 <xsd:complexType name="mrbresponseType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="status" type="status.datatype"
     use="required" />
    <xsd:attribute name="reason" type="xsd:string" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
 <xsd:element name="mrbresponse" type="mrbresponseType" />

<!--
  #####################################################

  mrbnotification TYPE

  #####################################################
 -->

<!--  mrbnotification -->

<xsd:complexType name="mrbnotificationType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:element name="media-server-id"
        type="subscriptionid.datatype"/>
     <xsd:element ref="supported-packages" minOccurs="0" />
     <xsd:element ref="active-rtp-sessions" minOccurs="0" />
     <xsd:element ref="active-mixer-sessions" minOccurs="0" />
     <xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
     <xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
     <xsd:element ref="media-server-status" minOccurs="0" />
     <xsd:element ref="supported-codecs" minOccurs="0" />
     <xsd:element ref="application-data" minOccurs="0"
      maxOccurs="unbounded" />
     <xsd:element ref="file-formats" minOccurs="0" />
     <xsd:element ref="max-prepared-duration" minOccurs="0" />
     <xsd:element ref="dtmf-support" minOccurs="0" />
     <xsd:element ref="mixing-modes" minOccurs="0" />
     <xsd:element ref="supported-tones" minOccurs="0" />
     <xsd:element ref="streaming-modes" minOccurs="0" />
     <xsd:element ref="asr-tts-support" minOccurs="0" />
     <xsd:element ref="vxml-support" minOccurs="0" />
     <xsd:element ref="media-server-location" minOccurs="0" />
     <xsd:element ref="label" minOccurs="0" />
     <xsd:element ref="media-server-address" minOccurs="0" />
     <xsd:element ref="encryption" minOccurs="0" />
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
     <xsd:attribute name="id" type="subscriptionid.datatype"
      use="required" />
     <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
      use="required" />
     <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>

  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="mrbnotification" type="mrbnotificationType" />

<!--  supported-packages -->

 <xsd:complexType name="supported-packagesType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="package" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="supported-packages" type="supported-packagesType"/>

 <xsd:complexType name="packageType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="package" type="packageType" />

<!--  active-rtp-sessions -->

 <xsd:complexType name="active-rtp-sessionsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="rtp-codec" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>

 <xsd:complexType name="rtp-codecType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
      <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="rtp-codec" type="rtp-codecType" />

<!--  active-mixer-sessions -->

<xsd:complexType name="active-mixer-sessionsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="active-mix" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="active-mixer-sessions"
  type="active-mixer-sessionsType" />

<xsd:complexType name="active-mixType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="rtp-codec" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attributeGroup ref="fw:framework-attributes" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="active-mix" type="active-mixType" />

<!--  non-active-rtp-sessions -->

<xsd:complexType name="non-active-rtp-sessionsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="rtp-codec" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="non-active-rtp-sessions"
  type="non-active-rtp-sessionsType" />

<!--  non-active-mixer-sessions -->

<xsd:complexType name="non-active-mixer-sessionsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="non-active-mix" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="non-active-mixer-sessions"
  type="non-active-mixer-sessionsType" />

 <xsd:complexType name="non-active-mixType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="rtp-codec" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="available" type="xsd:nonNegativeInteger"
      use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="non-active-mix" type="non-active-mixType" />

<!--  media-server-status -->

 <xsd:element name="media-server-status" type="msstatus.datatype" />

<!--  supported-codecs -->

<xsd:complexType name="supported-codecsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="supported-codec"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="supported-codecs" type="supported-codecsType" />

 <xsd:complexType name="supported-codecType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="supported-codec-package"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="supported-codec" type="supported-codecType" />

 <xsd:complexType name="supported-codec-packageType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element name="supported-actions" type="actions.datatype"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="supported-codec-package"
  type="supported-codec-packageType" />

<!--  application-data -->

<xsd:element name="application-data" type="appdata.datatype" />

<!--  file-formats -->

<xsd:complexType name="file-formatsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="supported-format"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="file-formats" type="file-formatsType" />

 <xsd:complexType name="supported-formatType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="supported-file-package"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="supported-format" type="supported-formatType" />

 <xsd:complexType name="supported-file-packageType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element name="supported-file-package-name" type="xsd:string"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="supported-file-package"
  type="supported-file-packageType"
  type="xsd:string" />

<!--  max-prepared-duration -->

<xsd:complexType name="max-prepared-durationType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="max-time" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="max-prepared-duration"
  type="max-prepared-durationType" />

 <xsd:complexType name="max-timeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="max-time-package" type="xsd:string" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
     use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="max-time" type="max-timeType" />

<!--  dtmf-support -->

<xsd:complexType name="dtmf-supportType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="detect" />
       <xsd:element ref="generate" />
       <xsd:element ref="passthrough" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="dtmf-support" type="dtmf-supportType" />

 <xsd:complexType name="detectType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>

 </xsd:complexType>

 <xsd:element name="detect" type="detectType" />

 <xsd:complexType name="generateType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="generate" type="generateType" />

 <xsd:complexType name="passthroughType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="passthrough" type="passthroughType" />

 <xsd:complexType name="dtmf-typeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="dtmf.datatype" use="required" />
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>

  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="dtmf-type" type="dtmf-typeType" />

<!--  mixing-modes -->

<xsd:complexType name="mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="audio-mixing-modes"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="video-mixing-modes"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="mixing-modes" type="mixing-modesType" />

<xsd:complexType name="audio-mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="audio-mixing-mode"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />

<xsd:complexType name="audio-mixing-modeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="audio-mixing-modeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />

<xsd:complexType name="video-mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="video-mixing-mode"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute name="vas" type="boolean.datatype"
     default="false" />
   <xsd:attribute name="activespeakermix" type="boolean.datatype"
     default="false" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />

<xsd:complexType name="video-mixing-modeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="video-mixing-modeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />

<!--  supported-tones -->

<xsd:complexType name="supported-tonesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="supported-country-codes"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="supported-h248-codes"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="supported-tones" type="supported-tonesType" />

<xsd:complexType name="supported-country-codesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="country-code"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="supported-country-codes"
  type="supported-country-codesType" />

<xsd:complexType name="country-codeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="country-codeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="country-code" type="country-codeType" />

<xsd:complexType name="supported-h248-codesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="h248-code"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>

 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="supported-h248-codes"
  type="supported-h248-codesType" />

<xsd:complexType name="h248-codeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="h248-codeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="h248-code" type="h248-codeType" />

<!--  streaming-modes -->

 <xsd:complexType name="streaming-modesType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="stream-mode"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="streaming-modes" type="streaming-modesType" />

 <xsd:complexType name="stream-modeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="streammode.datatype"
     use="required" />
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>

  </xsd:complexContent>
 </xsd:complexType>
 <xsd:element name="stream-mode" type="stream-modeType" />

<!--  asr-tts-support -->

<xsd:complexType name="asr-tts-supportType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="asr-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="tts-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="asr-tts-support" type="asr-tts-supportType" />

<xsd:complexType name="asr-supportType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="language"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="asr-support" type="asr-supportType" />

<xsd:complexType name="tts-supportType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="language"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="tts-support" type="tts-supportType" />

<xsd:complexType name="languageType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute ref="xml:lang" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="language" type="languageType" />

<!--  media-server-location -->

<xsd:complexType name="media-server-locationType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element name="civicAddress" type="ca:civicAddress"
                        minOccurs="1" maxOccurs="1" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="media-server-location"
  type="media-server-locationType" />

<!--  vxml-support -->

 <xsd:complexType name="vxml-supportType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="vxml-mode"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="support" type="boolean.datatype"
     default="false" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="vxml-support" type="vxml-supportType" />

 <xsd:complexType name="vxml-modeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:attribute name="support" type="vxml.datatype" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="vxml-mode" type="vxml-modeType" />

<!--  label -->

 <xsd:element name="label" type="label.datatype" />

<!-- media-server-address -->

 <xsd:element name="media-server-address" type="xsd:anyURI" />

<!--  encryption -->

<xsd:complexType name="encryptionType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="encryption-codec"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="encryption" type="encryptionType" />

<xsd:complexType name="encryption-codecType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="encryption-codec-package"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute name="name" type="xsd:string" use="required" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="encryption-codec" type="encryption-codecType" />

<xsd:complexType name="encryption-codec-package">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute name="name" type="xsd:string" use="required" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="encryption-codec-package"
 type="supported-codec-packageType" type="boolean.datatype" />
<!--
  ####################################################

  DATATYPES

  ####################################################
 -->

 <xsd:simpleType name="version.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="1.0" />
  </xsd:restriction>
 </xsd:simpleType>

<xsd:simpleType name="id.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

 <xsd:simpleType name="status.datatype">
  <xsd:restriction base="xsd:positiveInteger">
   <xsd:pattern value="[0-9][0-9][0-9]" />
  </xsd:restriction>
 </xsd:simpleType>

 <xsd:simpleType name="msstatus.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="active" />
   <xsd:enumeration value="deactivated" />
   <xsd:enumeration value="unavailable" />
  </xsd:restriction>
 </xsd:simpleType>

 <xsd:simpleType name="action.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="create" />
   <xsd:enumeration value="update" />
   <xsd:enumeration value="remove" />
  </xsd:restriction>
 </xsd:simpleType>

 <xsd:simpleType name="actions.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="encoding" />
   <xsd:enumeration value="decoding" />
   <xsd:enumeration value="passthrough" />
  </xsd:restriction>
 </xsd:simpleType>
 <xsd:simpleType name="appdata.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

 <xsd:simpleType name="dtmf.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="INFO" />
   <xsd:enumeration value="RFC4733" />
   <xsd:enumeration value="Media" />
  </xsd:restriction>
 </xsd:simpleType>

 <xsd:simpleType name="streammode.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

 <xsd:simpleType name="boolean.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="true" />
   <xsd:enumeration value="false" />
  </xsd:restriction>
 </xsd:simpleType>

  <xsd:simpleType name="vxml.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="RFC5552" />
   <xsd:enumeration value="IVR-Package" />
  </xsd:restriction>
 </xsd:simpleType>

 <xsd:simpleType name="label.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

 <xsd:simpleType name="subscriptionid.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

</xsd:schema>

                                 Figure 9

7. 12

8.  Media Service Resource Consumer Interface XML Schema

   This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
   20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
   mrb-consumer+xml" format.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
 elementFormDefault="qualified" blockDefault="#all"
 xmlns="urn:ietf:params:xml:ns:mrb-consumer"
 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <xsd:annotation>
  <xsd:documentation>
   IETF MediaCtrl MRB 1.0

   This is the schema of the IETF MediaCtrl MRB Consumer interface.

   The schema namespace is urn:ietf:params:xml:ns:mrb-consumer

  </xsd:documentation>
 </xsd:annotation>

 <!--
  #############################################################

  SCHEMA IMPORTS

  #############################################################
 -->

 <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd">
  <xsd:annotation>
   <xsd:documentation>
    This import brings in the XML attributes for
    xml:base, xml:lang, etc
   </xsd:documentation>
  </xsd:annotation>
 </xsd:import>

<xsd:import
  namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
  schemaLocation="civicAddress.xsd">
  <xsd:annotation>
   <xsd:documentation>
    This import brings in the civicAddress specification
    from RFC5139.
   </xsd:documentation>
  </xsd:annotation>
</xsd:import>

<!--
  #####################################################

  Extensible core type

  #####################################################
 -->

 <xsd:complexType name="Tcore">
  <xsd:annotation>
   <xsd:documentation>
    This type is extended by other (non-mixed) component types to
    allow attributes from other namespaces.
   </xsd:documentation>
  </xsd:annotation>
  <xsd:sequence/>
  <xsd:anyAttribute namespace="##other" processContents="lax" />
 </xsd:complexType>

<!--
  #####################################################

  TOP LEVEL ELEMENT: mrbconsumer

  #####################################################
 -->

<xsd:complexType name="mrbconsumerType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="mediaResourceRequest" />
      <xsd:element ref="mediaResourceResponse" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:attribute name="version" type="version.datatype"
      use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

 <xsd:element name="mrbconsumer" type="mrbconsumerType" />

<!--
  #####################################################

  mediaResourceRequest TYPE

  #####################################################
 -->

<!--  mediaResourceRequst -->

 <xsd:complexType name="mediaResourceRequestType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="generalInfo" minOccurs="0" />
      <xsd:element ref="ivrInfo" minOccurs="0" />
      <xsd:element ref="mixerInfo" minOccurs="0" />
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="mediaResourceRequest"
         type="mediaResourceRequestType" />

<!--
  #####################################################

  generalInfo TYPE

  #####################################################
-->

<!--  generalInfo -->

<xsd:complexType name="generalInfoType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="session-info" minOccurs="0" />
      <xsd:element ref="packages" minOccurs="0" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="generalInfo" type="generalInfoType" />

<!--  session-info -->

<xsd:complexType name="session-infoType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
       <xsd:element name="session-id" type="id.datatype"/>
       <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
       <xsd:element name="action" type="action.datatype"/>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="session-info" type="session-infoType" />

<!--  packages -->

<xsd:complexType name="packagesType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="package" type="xsd:string" minOccurs="0"
        maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />

    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="packages" type="packagesType"/>

<!--
  #####################################################

  ivrInfo TYPE

  #####################################################
-->

<!--  ivrInfo -->

<xsd:complexType name="ivrInfoType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="ivr-sessions" />
      <xsd:element ref="file-formats" />
      <xsd:element ref="dtmf-type" />
      <xsd:element ref="tones" />
      <xsd:element ref="asr-tts" />
      <xsd:element ref="vxml" />
      <xsd:element ref="location" />
      <xsd:element ref="encryption" />
      <xsd:element ref="application-data" />
      <xsd:element ref="max-prepared-duration" />
      <xsd:element ref="streaming-modes" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="ivrInfo" type="ivrInfoType" />

<!--
  #####################################################

  mixerInfo TYPE

  #####################################################
-->

<!--  mixerInfo -->

<xsd:complexType name="mixerInfoType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="mixers" />
      <xsd:element ref="file-formats" />
      <xsd:element ref="dtmf-type" />
      <xsd:element ref="tones" />
      <xsd:element ref="mixing-modes" />
      <xsd:element ref="application-data" />
      <xsd:element ref="location" />
      <xsd:element ref="encryption" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="mixerInfo" type="mixerInfoType" />

<!--
  #####################################################

  mediaResourceResponse TYPE

  #####################################################
 -->

<!--  mediaResourceResponse -->

 <xsd:complexType name="mediaResourceResponseType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="response-session-info" minOccurs="0" />
       <xsd:any namespace="##other" minOccurs="0"
          maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="status" type="status.datatype"
     use="required" />
    <xsd:attribute name="reason" type="xsd:string" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 <xsd:element name="mediaResourceResponse"
         type="mediaResourceResponseType" />

<!--
  ####################################################

  ELEMENTS

  ####################################################
 -->

<!--  session-info -->

<xsd:complexType name="response-session-infoType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
     <xsd:choice>
       <xsd:element name="session-id" type="id.datatype"/>
       <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
       <xsd:element name="expires" type="xsd:nonNegativeInteger"/>
       <xsd:element ref="media-server-address" minOccurs="0" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="response-session-info"
   type="response-session-infoType" />

<!-- media-server-address -->

 <xsd:element name="media-server-address" type="xsd:anyURI" />

<!--  ivr-sessions -->

<xsd:complexType name="ivr-sessionsType">
 <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="rtp-codec" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="ivr-sessions" type="ivr-sessionsType" />

<xsd:complexType name="rtp-codecType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
      <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="rtp-codec" type="rtp-codecType" />

<!-- file-format -->

<xsd:complexType name="file-formatsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="required-format"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="file-formats" type="file-formatsType" />

<xsd:complexType name="required-formatType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="required-file-package"
         minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="required-format" type="required-formatType" />

<xsd:complexType name="required-file-packageType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element name="required-file-package-name" type="xsd:string"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="required-file-package"
  type="required-file-packageType" />

<!--  dtmf-type -->

<xsd:complexType name="dtmfType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="detect" />
       <xsd:element ref="generate" />
       <xsd:element ref="passthrough" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="dtmf" type="dtmfType" />

<xsd:complexType name="detectType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="detect" type="detectType" />

<xsd:complexType name="generateType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="dtmf-type"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="passthrough" type="passthroughType" />

<xsd:complexType name="dtmf-typeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="dtmf.datatype" use="required" />
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="dtmf-type" type="dtmf-typeType" />

<!--  tones -->

<xsd:complexType name="required-tonesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="country-codes"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="h248-codes"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>

</xsd:complexType>

<xsd:element name="tones" type="required-tonesType" />

<xsd:complexType name="required-country-codesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="country-code"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="country-codes"
   type="required-country-codesType" />

<xsd:complexType name="country-codeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="country-codeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="country-code" type="country-codeType" />

<xsd:complexType name="required-h248-codesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="h248-code"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="h248-codes"
   type="required-h248-codesType" />

<xsd:complexType name="h248-codeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="h248-codeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="h248-code" type="h248-codeType" />

<!--  asr-tts -->

<xsd:complexType name="asr-ttsType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="asr-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="tts-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="asr-tts" type="asr-ttsType" />

<xsd:complexType name="asr-supportType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="language"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="asr-support" type="asr-supportType" />

<xsd:complexType name="tts-supportType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="language"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="tts-support" type="tts-supportType" />

<xsd:complexType name="languageType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute ref="xml:lang" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="language" type="languageType" />

<!--  vxml -->

<xsd:complexType name="vxmlType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="vxml-mode"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="support" type="boolean.datatype"
     default="false" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml" type="vxmlType" />

<xsd:complexType name="vxml-modeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:attribute name="require" type="vxml.datatype" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="vxml-mode" type="vxml-modeType" />

<!--  location -->

<xsd:complexType name="locationType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="ca:civicAddress"
                        minOccurs="1" maxOccurs="1" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

<xsd:element name="location" type="locationType" />

<!--  encryption -->

<xsd:element name="encryption" type="boolean.datatype" />

<!--  application-data -->

<xsd:element name="application-data" type="appdata.datatype" />

<!--  max-prepared-duration -->

<xsd:complexType name="max-prepared-durationType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="max-time" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="max-prepared-duration"
  type="max-prepared-durationType" />

<xsd:complexType name="max-timeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="max-time-package" type="xsd:string" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
     use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="max-time" type="max-timeType" />

<!--  stream-mode -->

<xsd:complexType name="streaming-modesType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="stream-mode"
        minOccurs="0" maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>

</xsd:complexType>

<xsd:element name="streaming-modes" type="streaming-modesType" />

<xsd:complexType name="stream-modeType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="streammode.datatype"
     use="required" />
    <xsd:attribute name="package" type="xsd:string" use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="stream-mode" type="stream-modeType" />

<!--  mixers -->

<xsd:complexType name="mixerssessionsType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element ref="mix" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="mixers" type="mixerssessionsType" />

<xsd:complexType name="mixType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="codec" type="xsd:string" minOccurs="0"
        maxOccurs="unbounded" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="users" type="xsd:nonNegativeInteger"
     use="required" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:element name="mix" type="mixType" />

<!--  mixing-modes -->

<xsd:complexType name="mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
      <xsd:element ref="audio-mixing-modes"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="video-mixing-modes"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="mixing-modes" type="mixing-modesType" />

<xsd:complexType name="audio-mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="audio-mixing-mode"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />

<xsd:complexType name="audio-mixing-modeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="audio-mixing-modeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />

<xsd:complexType name="video-mixing-modesType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:element ref="video-mixing-mode"
        minOccurs="0" maxOccurs="unbounded" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute name="vas" type="boolean.datatype"
     default="false" />
   <xsd:attribute name="activespeakermix" type="boolean.datatype"
     default="false" />
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />

<xsd:complexType name="video-mixing-modeType">
 <xsd:complexContent>
  <xsd:extension base="Tcore"> name="video-mixing-modeType" mixed="true">
 <xsd:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="package" type="xsd:string" use="required" />
 <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />

<!--
  ####################################################

  DATATYPES

  ####################################################
 -->

<xsd:simpleType name="version.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="1.0" />
  </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="id.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>

<xsd:simpleType name="status.datatype">
  <xsd:restriction base="xsd:positiveInteger">
   <xsd:pattern value="[0-9][0-9][0-9]" />
  </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="streammode.datatype">
  <xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>

<xsd:simpleType name="action.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="remove" />
   <xsd:enumeration value="update" />
  </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="dtmf.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="INFO" />
   <xsd:enumeration value="RFC4733" />
   <xsd:enumeration value="Media" />
  </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="boolean.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="true" />
   <xsd:enumeration value="false" />
  </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="vxml.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="RFC5552" />
   <xsd:enumeration value="IVR-Package" />
  </xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

</xsd:schema>

                                 Figure 10

8. 13

9.  Security Considerations

   The MRB network entity has two primary interfaces, Publish and
   Consumer, that carry sensitive information and must therefore be
   appropriately protected and secured.

   The Publish interface, as defined in and described in Section 5.1,
   uses the Media Control Channel Framework
   [I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect
   an MRB to a media server.  The appropriate Security Considerations
   included in the Media Control Channel Framework specification MUST be
   used in conjunction with this specification to protect interactions
   between an MRB and a media server.

   The Consumer interface, as defined in and described in Section 5.2,
   uses either the Hypertext Transfer Protocol (HTTP) or Session
   Initiation Protocol (SIP) as the mechanism for clients to connect to
   an MRB to request media resources.  In the case of the HTTP use, any
   binding using the Consumer interface MUST be capable of being
   transacted over TLS, as described in RFC 2818 [RFC2818].  In the case
   of the SIP use, the appropriate security considerations included in
   the Media Control Channel Framework specification MUST be used in
   conjunction with this specification to protect interactions between a
   client requesting media resources and an MRB.

9.

10.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

9.1.

10.1.  application/mrb-publish+xml MIME Type

    MIME media type name: application

    MIME subtype name: mrb-publish+xml

    Mandatory parameters: none

    Optional parameters: Same as charset parameter application/xml as
    specified in RFC 3023 [RFC3023].

    Encoding considerations: Same as encoding considerations of
    application/xml as specified in RFC 3023 [RFC3023].

    Security considerations: See Section 10 of RFC 3023 [RFC3023] and
    Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
    XXXX with the RFC number of this specification.]].

    Interoperability considerations: none.

    Published specification: This document.

    Applications which use this media type: This document type has
    been used to support a Media Resource Broker (MRB) entity.

    Additional Information:

    Magic Number: None

    File Extension: .xdf

    Macintosh file type code: "TEXT"

    Personal and email address for further information: Chris
    Boulton, chris@ns-technologies.com

    Intended usage: COMMON

    Author/Change controller: The IETF.

                                 Figure 11

9.2. 14

10.2.  application/mrb-consumer+xml MIME Type

    MIME media type name: application

    MIME subtype name: mrb-consumer+xml

    Mandatory parameters: none

    Optional parameters: Same as charset parameter application/xml as
    specified in RFC 3023 [RFC3023].

    Encoding considerations: Same as encoding considerations of
    application/xml as specified in RFC 3023 [RFC3023].

    Security considerations: See Section 10 of RFC 3023 [RFC3023] and
    Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
    XXXX with the RFC number of this specification.]].

    Interoperability considerations: none.

    Published specification: This document.

    Applications which use this media type: This document type has
    been used to support a Media Resource Broker (MRB) entity.

    Additional Information:

    Magic Number: None

    File Extension: .xdf

    Macintosh file type code: "TEXT"

    Personal and email address for further information: Chris
    Boulton, chris@ns-technologies.com

    Intended usage: COMMON

    Author/Change controller: The IETF.

                                 Figure 12

10. 15

11.  Changes

   Note to RFC Editor: Please remove this whole section.

10.1.

11.1.  Changes from 02 Version

   o  Added examples in Section 6.

   o  Fixed some nits in the schemas (encryption and required mixed=true
      elements).

   o  Completed review nit review comments from Gary Munson.

11.2.  Changes from 01 Version

   o  Added description of lease mechanism.

   o  Added specific HTTP and SIP usage of Consumer interface.

   o  Completed Publish interface schema + associated text.

   o  Included Consumer interface schema + associated text.

   o  Included supported-packages element.

   o  Removed announce-var element from doc.

   o  Expanded Abstract.

   o  General scrub of text - input from Simon Romano.

   o  Added IANA Considerations section.

   o  Added Security Considerations section.

10.2.

11.3.  Changes from 00 Version

   o  Included In-line text based on strawman proposal.

   o  Included first attempt at publish interface based on design team
      work.

11.

12.  Acknowledgments

   The authors would like to thank the members of the Publish Interface
   design team who provided valuable input into this document.  The
   design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
   Victor Paulsamy, Martin Dolly, and Scott McGlashan.  The authors
   would also like to thank John Dally, Simon Romano, Henry Lum and
   Christian Groves for input into this specification.

12.

13.  References

12.1.

13.1.  Normative References

   [ISO.639.1988]
              International Organization for Standardization, "Code for
              the representation of names of languages, 1st edition",
              ISO Standard 639, 1988.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [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.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [W3C.CR-wsdl20-20051215]
              Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
              "Web Services Description Language (WSDL) Version 2.0 Part
              1: Core Language", W3C CR CR-wsdl20-20051215,
              December 2005.

   [W3C.REC-soap12-part1-20030624]
              Nielsen, H., Gudgin, M., Mendelsohn, N., Hadley, M., Moreau, J., Nielsen, H., and
              M. Hadley, N.
              Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
              Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-
              20030624, REC-
              soap12-part1-20030624, June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.

   [W3C.REC-soap12-part2-20030624]
              Mendelsohn, N., Moreau, J.,
              Hadley, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
              M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
              Web Consortium FirstEdition REC-soap12-part2-20030624,
              June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.

12.2.

13.2.  Informative References

   [I-D.ietf-mediactrl-call-flows]
              Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
              "Media Control Channel Framework (CFW) Call Flow
              Examples", draft-ietf-mediactrl-call-flows-02 (work in
              progress), October 2009.

   [I-D.ietf-mediactrl-sip-control-framework]
              Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework",
              draft-ietf-mediactrl-sip-control-framework-11 (work in
              progress), October 2009.

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

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

   [RFC5567]  Melanchuk, T., "An Architectural Framework for Media
              Server Control", RFC 5567, June 2009.

Authors' Addresses

   Chris Boulton
   NS-Technologies

   Email: chris@ns-technologies.com

   Lorenzo Miniero
   University of Napoli

   Email: lorenzo.miniero@unina.it