Network Working Group                                         C. Boulton
Internet-Draft                                           NS-Technologies
Intended status: Standards Track                              L. Miniero
Expires: November 22, 2009 March 29, 2010                             University of Napoli
                                                            May 21,
                                                      September 25, 2009

                        Media Resource Brokering
                      draft-ietf-mediactrl-mrb-00
                      draft-ietf-mediactrl-mrb-01

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 November 22, 2009. March 29, 2010.

Copyright Notice

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

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

Abstract

   The MediaCtrl work group in the IETF is currently proposing an
   architecture for controlling media services.  The Session Initiation
   Protocol (SIP) will be 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 combinations
   of Application Servers and Media Servers.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  6
   3.  Problem Discussion . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Deployment Scenario Options  . . . . . . . . . . . . . . . . .  8
     4.1.  Query MRB  . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Hybrid Query MRB . . . . . . . . . . . . . . . . . . .  9
     4.2.  In-Line MRB  . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  MRB Interface Definition . . . Definitions  . . . . . . . . . . . . . . . . . . 12 13
     5.1.  Media Server Resource Publishing Interface . . . . . . . . 12 13
       5.1.1.  Control Package Definition . . . . . . . . . . . . . . 13 14
       5.1.2.  Element Definitions  . . . . . . . . . . . . . . . . . 14 16
       5.1.3.  Responses  .  <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 16
       5.1.4.  <mrbnotification>  . . . . . . . . . . . . . . . . . . 17
       5.1.5.  <mrbresponse>  . . . . . . . . . . . . . . . . . . . . 24
     5.2.  Media Service Resource Consumer Interface  . . . . . . . . 17 25
       5.2.1.  Media Service Resource Request . . . . . . . . . . . . 17 25
       5.2.2.  Media Service Resource Response  . . . . . . . . . . . 18 26
     5.3.  In-Line MRB Interface  . . . . . . . . . . . . . . . . . . 27
       5.3.1.  In-line Unaware MRB Mode . . . . . . . . . . . . . . . 27
       5.3.2.  In-line Aware MRB Mode . . . . . . . . . . . . . . . . 27
   6.  Media Service Resource Publisher Interface XML Schema  . . . . 19 30
   7.  Media Service Resource Consumer Interface XML Schema . . . . . 20 47
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22 49
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23 50
   10. Acknowledgments Changes  . . . . . . . . . . . . . . . . . . . . . . . 24 . . . . 51
     10.1. Changes from 01 Version  . . . . . . . . . . . . . . . . . 51
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 52
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     11.1. 53
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     11.2. 53
     12.2. Informative References . . . . . . . . . . . . . . . . . . 26 54
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 55

1.  Introduction

   The topic of Media Resources 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.

   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 MediaCtrl Requirements
   [I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture
   [I-D.ietf-mediactrl-architecture] 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
   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)
   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 the MediaCtrl
   Architecture [I-D.ietf-mediactrl-architecture] 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 appropriate MS information to
      consuming entities.

   Query MRB  An instantiation of an MRB (See previous definition) that
      provides an interface for an Application Server to retrieve the
      location 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 is totally delegated to the MRB.

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 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 may be interested to which are out of scope in this
   document, as for instance reservation requests, MS resource
   allocation rules, planned or unplanned downtime of MS resources, the
   planned addition of future MS resources and the like.

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

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 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 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 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 of a "Media
   Server Consumer Interface" disappears.  The client of the MRB simply
   uses the signalling to offload the decision making process - this
   applies to both media server Control and Media Dialogs. dialogs.  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 Interface'
   to convey capabilities and resources to the MRB - as illustrated by
   (1).  The media server Control and Media dialogs are blindly 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 and the Application Server has no input into 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. server and resulted in it
   directly contacting an appropriate Media Server instance.  As a by-product 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.  It  The MRB will actually have to inspect both the SIP
   signalling and the media server control protocol PDUs for the purpose
   of Media Server selection.  This includes, for example, looking 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.

5.  Interface Definition

   As discussed in previous sections in this document, the intention is
   to provide a toolkit for

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

   In-line Unaware MRB Mode (IUMM))  Allows an MRB to act on behalf of deployment architectures where
      clients requiring media resource brokering can take place.  As a result, two main
   interfaces services who are required to 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 are aware of an MRB and its
      operation.

   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' 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
   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 Interface

   The Media Server Resource Publishing 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 fulfill 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 resource
   availability will never be exact due to several reasons which include
   timing issues, computed as opposed to reserved resource consumption
   (e.g., DSP's with a fixed number of streams versus GPU's with CPU
   availability), and licensing (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 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, the
   reporting of resources availability has no relation to predictive
   resource allocation.  A typical example 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 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 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 fulfills 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 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.

   The XML elements in this package are split into requests, responses
   and event notifications.  Requests are carried in CONTROL message
   bodies; *TODO* elements are <mrbrequest> element is defined as a package requests. request.  Event
   notifications are also carried in CONTROL message bodies; the
   <notification>
   <mrbnotification> element is defined for package event notifications.
   Responses are carried either in REPORT message or Control Framework
   200 response bodies; the <response> <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.3. 5.1.5.

5.1.1.3.  Common XML Support

   The Control Framework requires a Control Package definition to
   specify if the attributes for media dialog or conference references
   are required.

   *TODO*.

   [Editors Note: *TODO*.]

5.1.1.4.  CONTROL Message Body

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

5.1.1.5.  REPORT Message Body

   A valid REPORT body MUST conform to the schema defined in Section 6
   and described in Section 5.1.2.  XML messages appearing in REPORT
   messages MUST contain a <response> (**Add ref when completed**) <mrbresponse> element.

5.1.1.6.  Audit

   *TODO*.

   [Editors Note: do we really need an Audit section for this package?
   Auditing is not a mandatory operation in a package, but the framework
   encourages its use.  If we add this here, are we saying that there
   are things a MRB may or may not do, and auditing tells you about it?
   Or could it be used as a monitoring entity?]

5.1.1.7.  Examples

   [Editors Note: TODO].

5.1.2.  Element Definitions

   EDITORS NOTE: Need to map resources to a control

   This section defines the XML elements for the Publish interface Media
   Control Channel package and define
   appropriately. defined in Section 5.1.  The following information has been taken from
   feedback from formal XML
   schema definition for the community.  Please comment on existing entries and
   any other that you feel should Publish interface can be added to the list.  Note that some
   of the publishing topics would naturally be included found in
   Section 6.

   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 'AS
   Request to MRB' section that follows.  At following attributes:

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

   The <mrbpublish> elements has the following child elements, only
   included in one place for further discussion:

   o  Active RTP sessions (including codec information).  For example,
      10 G711 RTP sessions, 3 H.264 sessions.

   o  [MRB-04] This may not be required, since the purpose
   of the MRB which is allowed to check occur.

      <mrbrequest> for available resources rather than occupied resources.
      Or do you think such details might be useful sending an MRB request.  See Section 5.1.3.

      <mrbresponse> for complementary
      functionality as debugging and monitoring inside the MRB?

   o  Active Mixers.  For example F4: (2 G711, 3 G729), (second mixer
      and 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 codecs), (third mixer), ...).

   o  Non Active sessions - so sessions available on this MS (based on
      codecs supported).  For example, 80 G711 RTP session,120 G729
      sessions,30 H.264 sessions.

   o  MS Uptime.

   o  Codecs/media supported (could just be bundled with above 'Non
      Active Sessions'.

   o  In addition <mrbrequest> element used to initiate
   requests from an MRB to a Media Server.  The element is a container
   for information relevant for the generic interrogation of a media processing related information,
      there are definitely cases where server.

   The <mrbrequest> element has no defined attributes.

   The <mrbrequest> element has the AS will want to specify
      application-level criteria, following sub-elements which will be application-specific,
      and difficult to enumerate are
   defined in advance.  So I'm thinking we need the remainder of this section:

      <subscription> for initiating a
      way subscription to express arbitrary application specific criteria a Media Server
      from an MRB.  See Section 5.1.3.1.

5.1.3.1.  <subscription>

   The <subscription> element is included in addition a request from an MRB to a
   Media Server to provide the generic media processing criteria.  For example, details relating to the AS may
      need an MS which is capable configuration of prompting and performing speech
      recognition in Swahili.  Or, an MS which has
   updates.  The MRB will inform the capability to
      invoke some application-specific functionality.

   o  File formats supported for announcement.  E.g.: MP3, WAW etc...
      May be this information is enough to determine announcement format
      supported i.e. audio or video.

   o  Maximum duration for an announcement. Media servers can have
      restrictions on memory Server how long it wishes to play the announcements
   receive updates for very long
      durations.

   o  Variable announcements.  Where and the substitution variable can frequency that updates should be
      time, date, cost etc.

   o  DTMF detection sent.
   Updates are sent using the <mrbnotification> element.

   [Editors Note: Include more detail on subscription mechanism
   including responses/reject from MS + polling (not including expires
   and generation support.

   o  Types frequency elements constitutes a poll of mixing (conference supported) audio, video.

   o  Supported tone types in the Media Server.  Different countries may
      have Server using a
   different characteristics for 'id')].

   The <subscription> element has the same tone.  So following attributes:

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

   seqnumber:  indicates a sequence number to be configured used in conjunction
      with the media server or can be
      downloaded.  Capability session id to play identify a specific subscription command.
      The attribute is mandatory

   The <subscription> element has the following child elements:

   expires:   Provides the tone amount of time in both directions may seconds that a subscription
      should be
      required installed for conferencing applications.  E.g. playing a tone when
      a new participant joins in notifications at the conference. Media Server.  The tone needs to be
      played towards the existing participants and also towards
      element is optional.

   frequency:   Provides the new
      participant.

   o  Audio RTSP streaming.  Audio conferencing.  Audio record.  Audio
      transcoding.

   o  ASR/TTS usage.  ASR grammar complexity.  Language complexity.

   o  Speaker verification/recognition.

   o  Music recognition.

   o  Audio transformation (mask voice, raise tone, add echo, effects
      etc.)

   o  VoiceXML dialogs and their complexity.

   o  Encryption of audio/video media streams.

   o  Video transcoding.

   o  Dynamic or static video frame rate, bit rate or picture size
      adaptation per multimedia stream.

   o  Video record.

   o  Video RTSP streaming.

   o  Media insertion (audio, video, text, picture, logo, avatar or
      background/ambiance) frequency in a multimedia stream.

   o  Video mixing.

   o  Video broadcasting.

   o  Face/shape/image detection/removal.

5.1.3.  Responses

   Responses seconds that the MRB wishes to requests are indicated by a <response> element
      receive notifications from
   Section 6. the MRB.  The <response> element has following attributes:

   status:  numeric code indicating is optional.

   [Editors Note: Next version of the response status.  The attribute document will have exclude/include
   lists in MRB requests; the default behaviour is mandatory.

   The following status codes are defined:

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   +-----------+-------------------------------------------------------+

                     Table 1: <response> status codes

   [Editors Note: more status codes "subscribe me to be added + an example.]

5.2.  Media Service Resource Consumer Interface

   The Media Server Consumer interface provides
   everything you have", and the ability MRB package will trigger events saying
   everything it knows; we could envisage more drill-down requests like:
   1) tell me everything (default) 2) tell me everything except...
   (exclude list) 3) tell me only... (include list) this would only
   require a change in 'subscriptionType' and optional occurrences in
   'mrbnotificationType' for clients the reported elements; this could allow for
   more lightweight notifications for entities only interested in a
   subset of an MRB, such as Application Servers, info, or for entities which want different transactions for
   different info (e.g.  "I only need to know about RTP stuff, I don't
   care about the rest");].

5.1.4.  <mrbnotification>

   The <mrbnotification> element is included in a request an appropriate from a Media
   Server to satisfy specific criteria.  The interface allows a
   client to pass detailed meta-information an MRB to provide the details relating current status.  The
   Media Server will inform the MRB to help select of its current status as defined by
   the information in the <subscription> element.  Updates are sent
   using the <mrbnotification> element contained in an
   appropriate Media Server. <mrbrequest>
   element.

   The <mrbnotification> element has the following attributes:

   id:  indicates a unique token representing the session between the
      MRB is then able to make and informed
   decision the Media Server and provide is the client with an appropriate media server
   resource.

   It appears same as the most appropriate interface for such a 'query' style
   interface is one appearing in fact
      the <subscription> element.  The attribute is mandatory.

   seqnumber:  indicates a HTTP usage.  Using HTTP and XML combined
   reduces complexity and encourages use of common tools that are widely
   available sequence number to be used in conjunction
      with the industry today. session id to identify a specific notification update.
      The attribute is mandatory

   The following subsections explain provide details on the main operations required to request and then receive information
   from child elements that
   are contained within an MRB.  The following description will describe <mrbnotification> element.

   [Editors Note: What is mandatory to support by Media Servers?  Do we
   want to specify that MS MUST support all elements in the use mrbrequest
   OR should we specify a minumum number of HTTP
   RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for elements].

5.1.4.1.  <media-server-id>

   The <media-server-id> element provides a
   query unique system wide
   identifier for media resource and the appropriate response.  Examples of
   the interface can be seen in section [ref examples section].

5.2.1. a Media Service Resource Request Server instance.  The media resource query element is carried in the body of an HTTP/HTTPS POST
   request. mandatory.

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

5.1.4.2.  <active-rtp-sessions>

   The MIME type contained in the HTTP/HTTPS request/reponse
   should be 'application/mrb+xml'.  This value MUST be reflected in <active-rtp-sessions> element provides information detailing the
   appropriate HTTP headers like 'Content-Type' and 'Accept'.
   current active Real-time Transport Protocol(RTP) sessions.  The body
   of the POST request MUST only contain the 'mediaResourceRequest'
   element as defined in Section 7. is optional.

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

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

   rtp-codec:   Is a container of information related to which representing a media resource
   request supported codec and
      the active sessions.  The <rtp-codec> element has one attribute.
      The attribute 'name' represents the following child elements which specify name of the
   request parameters:

5.2.1.1.  <mediaResourceRequest> codec being
      represented.  The <rtp-codec> element has two child elements.  The <mediaResourceRequest>
      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.3.  <active-mixer-sessions>

   The <active-mixer-sessions> element provides a container for clients
   wishing to query an external MRB entity. information detailing
   the current active mixed RTP sessions.  The <mediaResourceRequest> element is optional.

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

   The <active-mixer-sessions> element has the following child elements that are used to provide
   appropriate contextual information relating to the request: [Editors
   Note: Convert groups input into appropriate XML schema.]

   o elements:

   active-mix:   Is a container which representing a mixed active RTP requirements - including media/codec type, codec priority.

   o  Conference requirements - number of users.

5.2.2.  Media Service Resource Response
      session.  The use <active-mix> element has one attribute.  The
      attribute 'conferenceid' represents the name of HTTP/HTTPS for carrying the media service resource
   information mix being
      represented.  The <active-mix> element has no impact on one child elements.
      The child element, <rtp-codec>, contains the protocol.  If protocol level
   operations and errors occur then they should be signalled same information
      relating to RTP sessions as
   specified defined in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119].  A
   successful response to a HTTP POST request containing the
   'mediaResourceRequest' MUST be responded to with a 200 OK HTTP/HTTPS
   response message.  This signifies that the request was received, was
   valid and could be responded to appropriately.  If the receiving MRB
   wishes to generate information for the requesting entity it MUST
   include a 'mediaResourceResponse' Section 5.1.4.2.  The
      element in the 200 OK HTTP/HTTPS
   response (as discussed later in this section).  An MRB can
   alternatively return an application level error by including a
   'mediaResourceError' is optional.

5.1.4.4.  <non-active-rtp-sessions>

   The <non-active-rtp-sessions> element in provides information detailing
   the 200 OK HTTP/HTTPS response (as
   discussed later in this section).

5.2.2.1.  <mediaResourceResponse> currently available inactive RTP sessions.  The element is
   optional.

   The <mediaResourceResponse> <non-active-rtp-sessions> element provides a container for has no attributes.

   The <non-active-rtp-sessions> element has the MRB
   to generate following child
   elements:

   rtp-codec:   Is a response to container which representing a previous query. supported codec and
      the inactive sessions.  The
   <mediaResourceResponse> <rtp-codec> element has one attribute.
      The attribute 'name' represents the following name of the codec being
      represented.  The <rtp-codec> element has two child elements that
   are used to provide appropriate contextual information relating to elements.  The
      first child element, <decoding>, represents the request: [Editors Note: Convert groups input into appropriate XML
   schema.]

   o  list number of appropriate media server resources (include individual
      capabilities).

5.2.2.2.  <mediaResourceError>
      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.5.  <non-active-mixer-sessions>

   The <mediaResourceError> <non-active-mixer-sessions> element provides a container for information
   detailing the MRB to
   generate an error response to a previous query. current inactive mixed RTP sessions.  The
   <mediaResourceError> element is
   optional.

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

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

   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
   are could be used to provide appropriate contextual 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.4.  The element is optional.

5.1.4.6.  <media-server-status>

   The <media-server-status> element provides information detailing the request: [Editors Note: Convert groups input into appropriate XML
   schema.]

   o  list
   current status of appropriate error response codes.

6. the media server.  The element is mandatory.  It
   can return one of the following values:

   active:   Indicating that the Media Service Resource Publisher Interface XML Schema

   This section gives Server is available for service.

   deactivated:   Indicating that the XML Schema Definition [W3C.REC-xmlschema-1-
   20041028], [W3C.REC-xmlschema-2-20041028] 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.

   [Editors Note: Need to think about status messages and meanings.]

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

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

5.1.4.7.  <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 elements:

   supported-codec:   has a single attribute, 'name', which provides the
      name of the "application/
   mrb-publisher+xml" format. 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 an
      Media Server can apply to this codec (decode, encode,
      passthrough).

5.1.4.8.  <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.9.  <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 elements:

   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 codec
      support applies.

5.1.4.10.  <max-prepared-duration>

   The <max-prepared-duration> element provides the amount of time a
   media dialog cane 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 elements:

   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.11.  <announce-var>

   The <announce-var> element supplies the supported substitution
   variables for variable announcements, including digits, dates, costs,
   etc.  The element is optional.

   The <announce-var> element has no attributes.

   The <announce-var> element has the following child elements:

   param:   has a two attributes, 'name' and 'package'.  The 'name'
      attribute provides the name of the parameter.  The 'package'
      attribute provides the name of the Media Control Channel Framework
      package for which the parameter applies.  The <param> element then
      has a further child element, <param-value>.  The <param-value>
      element provides the value associated with the parameter.

   [Editors Note: TODO - the structure of this needs to change to
   reflect top level of package and the params underneath as a child].

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>

   [Editors Note: TODO after further group discussion].

5.1.4.14.  <supported-tones>

   [Editors Note: TODO after further group discussion].

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 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 elements:

   stream-mode:   has a 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>

   [Editors Note: TODO after further group discussion].

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 (eg 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 elements:

   vxml-mode:   has a two attributes, 'package' and 'support'.  The
      'package' attribute provides the name of the Media Control Channel
      Framework package for which the streaming protocol applies.  The
      'support' attribute provides the type of VXML support provided by
      the Media Server (RFC5552 or msc-ivr/1.0).

5.1.4.18.  <media-server-location>

   [Editors Note: TODO after further group discussion].

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 its a blue or green.  Its 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 <application-data> element has no attributes.

   The <application-data> 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 <application-data> element has no attributes.

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

5.1.4.21.  <encryption>

   [Editors Note: TODO after further group discussion].

5.1.5.  <mrbresponse>

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

   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                                                    |
   +-----------+-------------------------------------------------------+

                     Table 1: <response> status codes

   [Editors Note: more status codes to be added + an example.]

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 and informed
   decision and provide the client with an appropriate media server
   resource.

   It appears the most 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 subsections explain
   the main operations required to request and then receive information
   from an MRB.  The following description will describe the use of HTTP
   RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for a
   query for media resource and the appropriate response.  Examples of
   the interface can be seen in section [ref examples section].

   [Editors Note: Need to discuss the updating of a request and proposal
   of having the client supply updates on resources.  For example,
   releasing resources.]

5.2.1.  Media Service Resource Request

   The media resource query is carried in the body of an HTTP/HTTPS POST
   request.  The MIME type contained in the HTTP/HTTPS request/response
   should be 'application/mrb-consumer+xml'.  This value MUST be
   reflected in the appropriate HTTP headers like 'Content-Type' and
   'Accept'.  The body of the POST request MUST only contain the
   'mediaResourceRequest' element as defined in Section 7.  The
   'mediaResourceRequest' element is the primary container of
   information related to a media resource request and has the following
   child elements which specify the request parameters:

5.2.1.1.  <mediaResourceRequest> element

   The <mediaResourceRequest> element provides a container for clients
   wishing to query an external MRB entity.  The <mediaResourceRequest>
   element has the following child elements that are used to provide
   appropriate contextual information relating to the request: [Editors
   Note: Convert groups input into appropriate XML schema.]

   o  RTP requirements - including media/codec type, codec priority.

   o  Conference requirements - number of users.

5.2.2.  Media Service Resource Response

   The use of HTTP/HTTPS for carrying the media service resource
   information has no impact on the protocol.  If protocol level
   operations and errors occur then they should be signalled as
   specified in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119].  A
   successful response to a HTTP POST request containing the
   'mediaResourceRequest' MUST be responded to with a 200 OK HTTP/HTTPS
   response message.  This signifies that the request was received, was
   valid and could be responded to appropriately.  If the receiving MRB
   wishes to generate information for the requesting entity it MUST
   include a 'mediaResourceResponse' element in the 200 OK HTTP/HTTPS
   response (as discussed later in this section).  An MRB can
   alternatively return an application level error by including a
   'mediaResourceError' element in the 200 OK HTTP/HTTPS response (as
   discussed later in this section).

5.2.2.1.  <mediaResourceResponse> element

   The <mediaResourceResponse> element provides a container for the MRB
   to generate a response to a previous query.  The
   <mediaResourceResponse> element has the following child elements that
   are used to provide appropriate contextual information relating to
   the request: [Editors Note: Convert groups input into appropriate XML
   schema.]

   o  list of appropriate media server resources (include individual
      capabilities).

5.2.2.2.  <mediaResourceError> element

   The <mediaResourceError> element provides a container for the MRB to
   generate an error response to a previous query.  The
   <mediaResourceError> has element the following child elements that
   are used to provide appropriate contextual information relating to
   the request: [Editors Note: Convert groups input into appropriate XML
   schema.]

   o  list of appropriate error response codes.

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 (IUAMM) 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 and IAMM.  It is for this
   reason that an MRB is 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 and it will select an appropriate media server
   based on knowledge of media server resources it currently has
   available.  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.  A client of an
   IAMM uses SIP signalling to convey the 'application/mrb-consumer+xml'
   payload to the IAMM.  The Consumer interface, as specified in
   Section 5.2 , uses HTTP.  A client of an IAMM requiring media
   services, as well as creating a standard SIP complaint request, MUST
   use the following steps 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.

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

   [EDITORS NOTE: Include example of valid IAMM payload.]

   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 the 'application/
      mrb-consumer+xml' information from the SIP INVITE request and then
      forwards to the selected Media Server.

   [Editors Note: Consumer interface has a proposal to update a request
   for media services based on HTTP.  There are times when an
   application server might want to override the MS view of resources.
   For example, a conference where participants leave and can rejoin.
   Need to decide if this use of consumer XML should also allow for
   updates using SIP reINVITE and UPDATE.]

6.  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: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>

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

  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: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 ref="media-server-id" type="subscriptionid.datatype"/>
     <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="announce-var" 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" />

<!--  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="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" />

<!--  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" />

<!--  announce-var -->

 <xsd:complexType name="announce-varType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
       <xsd:element ref="param" />
       <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="announce-var" type="announce-varType" />
 <xsd:complexType name="paramType">
  <xsd:complexContent>
   <xsd:extension base="Tcore">
    <xsd:sequence>
      <xsd:element name="param-value" type="xsd:NMTOKEN" />
       <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" 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="param" type="paramType" />

<!--  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 -->

    <!-- **** TODO **** -->

<!--  supported-tones -->

    <!-- **** TODO **** -->

<!--  streaming-modes -->

 <xsd:complexType name="stream-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="stream-modes" type="stream-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 -->

 <!-- **** TODO **** -->

<!--  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" use="required" />
    <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" />

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

 <!-- **** TODO **** -->

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

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

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

<!--  encryption -->

 <!-- **** TODO **** -->

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

  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="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>

 <!-- *** TODO-Look at values **** -->
 <xsd:simpleType name="streammode.datatype">
  <xsd:restriction base="xsd:NMTOKEN">
   <xsd:enumeration value="RTSP" />
   <xsd:enumeration value="HTTP" />
   <xsd:enumeration value="NFS" />
  </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="label.datatype">
  <xsd:restriction base="xsd:NMTOKEN" />
 </xsd:simpleType>

</xsd:schema>

                                 Figure 9

7.  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"?>

   <xsd:schema
     targetNamespace="urn:ietf:params:xml:ns:mediactrl:mrb"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:mrb="urn:ietf:params:xml:ns:mediactrl:mrb"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

   <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
              schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xsd:element name="mrb-message" type="mrb-message-type" />

    <xsd:complexType name="mrb-message-type">
     <xsd:sequence>
     <xsd:choice>
      <xsd:element name="mediaResourceRequest"
                type="mrb:mediaResourceRequestType"/>
      <xsd:element name="mediaResourceResponse"
                type="mrb:mediaResourceResponseType"/>
      <xsd:element name="mediaResourceError"
                type="mrb:mediaResourceErrorType"/>
      <xsd:any namespace="##other" minOccurs="0"
                maxOccurs="unbounded" processContents="lax" />

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

   <xsd:complexType name="mediaResourceRequestType">
     <xsd:complexContent>
         <xsd:sequence>
          <xsd:any namespace="##other" minOccurs="0"
                maxOccurs="unbounded" processContents="lax" />
         </xsd:sequence>
         <xsd:anyAttribute namespace="##other" processContents="lax" />
     </xsd:complexContent>
   </xsd:complexType>
   <xsd:complexType name="mediaResourceResponseType">
     <xsd:complexContent>
         <xsd:sequence>
            <xsd:any namespace="##other" minOccurs="0"
                maxOccurs="unbounded" processContents="lax" />
         </xsd:sequence>
         <xsd:anyAttribute namespace="##other" processContents="lax" />
     </xsd:complexContent>
   </xsd:complexType>

   <xsd:complexType name="mediaResourceErrorType">
     <xsd:complexContent>
         <xsd:choice minOccurs="0" maxOccurs="unbounded">
           <xsd:any namespace="##other" processContents="strict"/>
         </xsd:choice>
         <xsd:attribute name="status" type="status.datatype"
               use="required"/>
         <xsd:anyAttribute namespace="##other" processContents="lax" />
     </xsd:complexContent>
   </xsd:complexType>

    <!-- DATATYPES -->

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

   </xsd:schema>

                                 Figure 9 10

8.  Security Considerations

   Security Considerations to be included in later versions of this
   document.

9.  IANA Considerations

   IANA Considerations to be included in later versions of this
   document.

10.  Changes

   Note to RFC Editor: Please remove this whole section.

10.1.  Changes from 01 Version

   o  Included In-line text based on strawman proposal.

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

11.  Acknowledgments

   The authors would like to thank....

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

12.  References

11.1.

12.1.  Normative References

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

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

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

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [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.,
              Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and N.
              Mendelsohn, H.
              Nielsen, "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]
              Nielsen, H.,
              Hadley, M., Mendelsohn, N., Hadley, Gudgin, M., Moreau, J., and
              M. Gudgin, H.
              Nielsen, "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>.

11.2.

12.2.  Informative References

   [I-D.ietf-mediactrl-architecture]
              Melanchuk, T., "An Architectural Framework for Media
              Server Control", draft-ietf-mediactrl-architecture-04
              (work in progress), November 2008.

   [I-D.ietf-mediactrl-requirements]
              Dolly, M. and R. Even, "Media Server Control Protocol
              Requirements", draft-ietf-mediactrl-requirements-04 (work
              in progress), February 2008.

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

Authors' Addresses

   Chris Boulton
   NS-Technologies

   Email: chris@ns-technologies.com

   Lorenzo Miniero
   University of Napoli

   Email: lorenzo.miniero@unina.it