doc: Add RFC documents

1 files changed, 7619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6917.txt b/doc/rfc/rfc6917.txt
new file mode 100644
index 0000000..1752a0a
--- /dev/null
+++ b/doc/rfc/rfc6917.txt
@@ -0,0 +1,7619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Boulton
+Request for Comments: 6917                               NS-Technologies
+Category: Standards Track                                     L. Miniero
+ISSN: 2070-1721                                                 Meetecho
+                                                               G. Munson
+                                                                    AT&T
+                                                              April 2013
+
+
+                        Media Resource Brokering
+
+Abstract
+
+   The MediaCtrl working group in the IETF has proposed an architecture
+   for controlling media services.  The Session Initiation Protocol
+   (SIP) is used as the signaling protocol that provides many inherent
+   capabilities for message routing.  In addition to such signaling
+   properties, a need exists for intelligent, application-level media
+   service selection based on non-static signaling properties.  This is
+   especially true when considered in conjunction with deployment
+   architectures that include 1:M and M:N combinations of Application
+   Servers and Media Servers.  This document introduces a Media Resource
+   Broker (MRB) entity, which manages the availability of Media Servers
+   and the media resource demands of Application Servers.  The document
+   includes potential deployment options for an MRB and appropriate
+   interfaces to Application Servers and Media Servers.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6917.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 1]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions and Terminology .....................................6
+   3. Problem Discussion ..............................................6
+   4. Deployment Scenario Options .....................................7
+      4.1. Query MRB ..................................................8
+           4.1.1. Hybrid Query MRB ....................................9
+      4.2. In-Line MRB ...............................................11
+   5. MRB Interface Definitions ......................................12
+      5.1. Media Server Resource Publish Interface ...................12
+           5.1.1. Control Package Definition .........................13
+           5.1.2. Element Definitions ................................15
+           5.1.3. <mrbrequest> .......................................15
+           5.1.4. <mrbresponse> ......................................17
+           5.1.5. <mrbnotification> ..................................19
+      5.2. Media Service Resource Consumer Interface .................30
+           5.2.1. Query Mode/HTTP Consumer Interface Usage ...........31
+           5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage ....32
+           5.2.3. Consumer Interface Lease Mechanism .................35
+           5.2.4. <mrbconsumer> ......................................38
+           5.2.5. Media Service Resource Request .....................39
+           5.2.6. Media Service Resource Response ....................51
+      5.3. In-Line Unaware MRB Interface .............................54
+   6. MRB Acting as a B2BUA ..........................................54
+   7. Multimodal MRB Implementations .................................55
+   8. Relative Merits of Query Mode, IAMM, and IUMM ..................56
+   9. Examples .......................................................58
+      9.1. Publish Example ...........................................58
+      9.2. Consumer Examples .........................................64
+           9.2.1. Query Example ......................................64
+           9.2.2. IAMM Examples ......................................68
+   10. Media Service Resource Publisher Interface XML Schema .........83
+
+
+
+Boulton, et al.              Standards Track                    [Page 2]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   11. Media Service Resource Consumer Interface XML Schema .........106
+   12. Security Considerations ......................................127
+   13. IANA Considerations ..........................................130
+      13.1. Media Control Channel Framework Package Registration ....130
+      13.2. application/mrb-publish+xml Media Type ..................130
+      13.3. application/mrb-consumer+xml Media Type .................131
+      13.4. URN Sub-Namespace Registration for mrb-publish ..........132
+      13.5. URN Sub-Namespace Registration for mrb-consumer .........132
+      13.6. XML Schema Registration for mrb-publish .................132
+      13.7. XML Schema Registration for mrb-consumer ................133
+   14. Acknowledgements .............................................133
+   15. References ...................................................133
+      15.1. Normative References ....................................133
+      15.2. Informative References ..................................135
+
+1.  Introduction
+
+   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 working 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 one introduces a flexible level of
+   deployment scenarios, as specified in RFC 5167 [RFC5167] and RFC 5567
+   [RFC5567].  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, to provide what can be effectively described as
+   media resource brokering.
+
+   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 than 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
+
+
+
+Boulton, et al.              Standards Track                    [Page 3]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   that each Media Server possesses a different media capability set.
+   Media Servers may offer different media services as specified in the
+   MediaCtrl architecture document [RFC5567].  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,
+   possibly supporting dissimilar applications, controlling a single
+   Media Server.  Typically, such architectures are associated with
+   application logic that requires low-demand media services.
+
+   +---+-----+---+
+   | Application |
+   |   Server    |<-----+
+   +-------------+      |
+                        |
+   +---+-----+---+      |                  +---+-----+---+
+   | Application |      |                  |    Media    |
+   |   Server    |<-----+-----MS Control-->|    Server   |
+   +-------------+      |                  +-------------+
+                        |
+   +---+-----+---+      |
+   | Application |      |
+   |   Server    |<-----+
+   +-------------+
+
+                  Figure 3: Multiple Application Servers
+
+
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 4]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The final deployment view is the most complex (Figure 4).  In this
+   model (M:N), there exist any number of Application Servers and any
+   number of Media Servers.  It is again possible in this model that
+   Media Servers might not be homogeneous, and they might have different
+   capability sets and capacities.
+
+   +---+-----+---+                         +---+-----+---+
+   | Application |                         |    Media    |
+   |   Server    |<-----+            +---->|    Server   |
+   +-------------+      |            |     +-------------+
+                        |            |
+   +---+-----+---+      |            |     +---+-----+---+
+   | Application |      |            |     |    Media    |
+   |   Server    |<-----+-MS Control-+---->|    Server   |
+   +-------------+      |            |     +-------------+
+                        |            |
+   +---+-----+---+      |            |     +---+-----+---+
+   | Application |      |            +---->|    Media    |
+   |   Server    |<-----+                  |    Server   |
+   +-------------+                         +---+-----+---+
+
+                    Figure 4: Many-to-Many Architecture
+
+   The remaining sections in this specification will focus on a new
+   entity called a Media Resource Broker (MRB), which can be utilized in
+   the deployment architectures described previously in this section.
+   The MRB entity provides the ability to obtain media resource
+   information and appropriately allocate (broker) on behalf of client
+   applications.
+
+   The high-level deployment options discussed in this section rely on
+   network architecture and policy to prohibit inappropriate use.  Such
+   policies are out of scope for this document.
+
+   This document will take a look at the specific problem areas related
+   to such deployment architectures.  It is recognized that the
+   solutions proposed in this document should be equally adaptable to
+   all of the previously described deployment models.  It is also
+   recognized that the solution is far more relevant to some of the
+   previously discussed deployment models and can almost be viewed as
+   redundant on others.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 5]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+2.  Conventions and Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   This document inherits terminology proposed in RFC 5567 [RFC5567] and
+   in "Media Control Channel Framework" [RFC6230].  In addition, the
+   following terms are defined for use in this document and for use in
+   the context of the MediaCtrl working 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 selecting appropriate Media Server resources on
+      behalf of consuming entities.
+
+   Query MRB:  An instantiation of an MRB (see previous definition) that
+      provides an interface for an Application Server to retrieve the
+      address of an appropriate Media Server.  The result returned to
+      the Application Server can be influenced by information contained
+      in the query request.
+
+   In-line MRB:  An instantiation of an MRB (see previous definition)
+      that directly receives requests on the signaling path.  There is
+      no separate query.
+
+   CFW:  Media Control Channel Framework, as specified in [RFC6230].
+
+   Within the context of In-line MRBs, additional terms are defined:
+
+   In-line Aware MRB Mode (IAMM):  Defined in Section 5.2.2.1.
+
+   In-line Unaware MRB Mode (IUMM):  Defined in Section 5.3.
+
+   The document will often specify when a specific identifier in a
+   protocol message needs to be unique.  Unless stated otherwise, such
+   uniqueness will always be within the scope of the Media Servers
+   controlled by the same MRB.  The interaction between different MRB
+   instances, e.g., the partitioning of a logical MRB, is out of scope
+   for this document.
+
+3.  Problem Discussion
+
+   As discussed in Section 1, a goal of the MediaCtrl working group is
+   to produce a solution that will service a wide variety of deployment
+   architectures.  Such architectures range from the simplest 1:1
+   relationship between Media Servers and Application Servers to
+   potentially linearly scaling 1:M, M:1, and M:N deployments.
+
+
+
+Boulton, et al.              Standards Track                    [Page 6]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Managing such deployments is itself non-trivial for the proposed
+   solution until an additional number of factors that increase
+   complexity are included in the equation.  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 toolkit 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
+   availability can be handled using the appropriate underlying
+   signaling, 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
+   functions specified 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
+   or capacity after a request has taken place should be handled by the
+   underlying protocol.
+
+   It should be noted that there may be additional information that is
+   desirable for the MRB to have for purposes of selecting a Media
+   Server resource, such as resource allocation rules across different
+   applications, planned or unplanned downtime of Media Server
+   resources, the planned addition of future Media Server resources, or
+   Media Server resource capacity models.  How the MRB acquires such
+   information is outside the scope of this document.  The specific
+   techniques used for selecting an appropriate media resource by an MRB
+   is also outside the scope of this document.
+
+4.  Deployment Scenario Options
+
+   Research into media resource brokering concluded that a couple of
+   high-level models provided an appropriate level of flexibility.  The
+   general principles of "in-line" and "query" MRB concepts are
+   discussed in the rest of this section.  It should be noted that while
+   the interfaces are different, they both use common underlying
+   mechanisms defined in this specification.
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 7]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+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
+   Publish interface, as discussed in Section 5.1, to convey capability
+   sets as well as resource information.  This is depicted by (1) in
+   Figure 5.  It is then the MRB's responsibility to accumulate all
+   appropriate information relating to media services in the logical
+   deployment cluster.  The Application Server (or other media services
+   client) is then able to query the MRB for an appropriate resource (as
+   identified by (2) in Figure 5).  Such a query would carry specific
+   information related to the media service required and enable the MRB
+   to provide increased accuracy in its response.  This particular
+   interface is discussed in "Media Service Resource Consumer Interface"
+   (Section 5.2).  The Application Server is then able to direct control
+   commands (for example, create a conference) and media dialogs to the
+   appropriate Media Server, as shown by (3) in Figure 5.  Additionally,
+   with Query mode, the MRB is not directly in the signaling path
+   between the Application Server and the selected Media Server
+   resource.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 8]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+4.1.1.  Hybrid Query MRB
+
+   As mentioned previously, it is the intention that a toolkit 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 - Application Server 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
+   Publish interface is still being used to accumulate resource
+   information at the MRB, but as it is co-hosted on the Application
+   Server, the Media Server Consumer interface has collapsed.  It might
+   still exist within the Application Server/MRB interaction, but this
+   is an implementation issue.  This type of deployment suits a single
+   Application Server environment, but it should be noted that a Media
+   Server Consumer interface could then be offered from the hybrid if
+   required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                    [Page 9]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   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
+
+   In this example, 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.  The
+   Media Server Publish interface has collapsed onto the Media Server.
+   It might still exist within the Media Server/MRB interaction, but
+   this is an implementation issue.  This type of deployment suits a
+   single Media Server environment, but it should be noted that a Media
+   Server Publish interface could then be offered from the hybrid if
+   required.  A typical use case scenario for such a topology would be a
+   single Media Server representing a pool of MSs in a cluster.  In this
+   case, the MRB would actually be handling a cluster of Media Servers,
+   rather than one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 10]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+4.2.  In-Line MRB
+
+   The "In-line" MRB is architecturally different from the "Query" model
+   discussed in the previous section.  The concept of a separate query
+   disappears.  The client of the MRB simply uses the media resource
+   control and media dialog signaling to involve the MRB.  This type of
+   deployment is illustrated in Figure 8.
+
+                               +-------<----------+----<-------+---+
+                               |                  | (1)        |   |
+                               |                  |            |   |
+                               |             +---+--+--+---+   |   |
+                               |             |    Media    |   |   |
+                               |     +------>|    Server   |   |   |
+                               |     |(3)    +-------------+   |   |
+                               |     |                      (1)|   |
+   +---+--+--+---+             |     |       +---+-----+---+   |   |
+   | Application |  (2) +---+--V--+---+  (3) |    Media    |   |   |
+   |   Server    |----->|     MRB     |----->|    Server   |->-+   |
+   +-------------+      +---+-----+---+      +-------------+       |
+                                     |                             |
+                                     |   (3) +---+-----+---+    (1)|
+                                     +------>|    Media    |       |
+                                             |    Server   |--->---+
+                                             +---+-----+---+
+
+                           Figure 8: In-Line MRB
+
+   The Media Servers still use the Media Server Publish interface to
+   convey capabilities and resources to the MRB, as illustrated by (1).
+   The Media Server Control Channels (and media dialogs as well, if
+   required) are sent to the MRB (2), which then selects an appropriate
+   Media Server (3) and remains in the signaling path between the
+   Application Server and the Media Server resources.
+
+   The In-line MRB can be split into two distinct logical roles that can
+   be applied on a per-request basis.  They are:
+
+   In-line Unaware MRB Mode (IUMM):  Allows an MRB to act on behalf of
+      clients requiring media services who are not aware of an MRB or
+      its operation.  In this case, the Application Server does not
+      provide explicit information on the kind of Media Server resource
+      it needs (as in Section 5.2), and the MRB is left to deduce it by
+      potentially inspecting other information in the request from the
+      Application Server (for example, Session Description Protocol
+      (SDP) content, or address of the requesting Application Server, or
+      additional Request-URI parameters as per RFC 4240 [RFC4240]).
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 11]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   In-line Aware MRB Mode (IAMM):  Allows an MRB to act on behalf of
+      clients requiring media services who are aware of an MRB and its
+      operation.  In particular, it allows the Application Server to
+      explicitly convey matching characteristics to those provided by
+      Media Servers, as does the Query MRB mode (as in Section 5.2).
+
+   In either of the previously described roles, signaling as specified
+   by the Media Control Channel Framework ([RFC6230]) would be involved,
+   and the MRB would deduce that the selected Media Server resources are
+   no longer needed when the Application Server or Media Server
+   terminates the corresponding SIP dialog.  The two modes are discussed
+   in more detail in Section 5.3.
+
+5.  MRB Interface Definitions
+
+   The intention of this specification is to provide a toolkit for a
+   variety of deployment architectures where media resource brokering
+   can take place.  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 Publish and Media Server Resource Consumer interfaces.
+
+   It is beyond the scope of this document to define exactly how to
+   construct an MRB using the interfaces described.  It is, however,
+   important that the two interfaces are complimentary so that
+   development of appropriate MRB functionality is supported.
+
+5.1.  Media Server Resource Publish Interface
+
+   The Media Server Resource Publish interface is responsible for
+   providing an MRB with appropriate Media Server resource information.
+   As such, this interface is assumed to provide 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
+   this interface requirement.  It provides an establishment and
+   monitoring mechanism to enable a Media Server to report appropriate
+   statistics to an MRB.  The Publish interface is used with both the
+   Query mode and In-line mode of MRB operation.
+
+   As already discussed in Section 1, the MRB view of Media Server
+   resource availability will in reality be approximate -- i.e., partial
+   and imperfect.  The MRB Publish interface does not provide an
+   exhaustive view of current Media Server resource consumption; the
+   Media Server may in some cases provide a best-effort computed view of
+   resource consumption parameters conveyed in the Publish interface
+   (e.g., Digital Signal Processors (DSPs) with a fixed number of
+
+
+
+Boulton, et al.              Standards Track                   [Page 12]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   streams versus Graphics Processing Units (GPUs) with CPU
+   availability).  Media resource information may only be reported
+   periodically over the Publish interface to an MRB.
+
+   It is also worth noting that while the scope of the MRB is in
+   providing interested Application Servers with the available
+   resources, the MRB also allows for the retrieval of information about
+   consumed resources.  While this is of course a relevant piece of
+   information (e.g., for monitoring purposes), such functionality
+   inevitably raises security considerations, and implementations should
+   take this into account.  See Section 12 for more details.
+
+   The MRB Publish interface uses the Media Control Channel Framework
+   ([RFC6230]) 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 that 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 the requirement for information that must be
+   specified during the definition of a Control Framework package, as
+   detailed in Section 8 of [RFC6230].
+
+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 Publish interface allows a Media Server to convey available
+   capabilities and resources to an MRB entity.
+
+   This package defines XML elements in Section 5.1.2 and provides an
+   XML schema in Section 10.
+
+   The XML elements in this package are split into requests, responses,
+   and event notifications.  Requests are carried in CONTROL message
+   bodies; the <mrbrequest> element is defined as a package request.
+   This request can be used for creating new subscriptions and updating/
+   removing existing subscriptions.  Event notifications are also
+   carried in CONTROL message bodies; the <mrbnotification> element is
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 13]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   defined for package event notifications.  Responses are carried
+   either in REPORT message or Control Framework 200 response bodies;
+   the <mrbresponse> element is defined as a package-level response.
+
+   Note that package responses are different from framework response
+   codes.  Framework error response codes (see Section 7 of [RFC6230])
+   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.4.
+
+5.1.1.3.  Common XML Support
+
+   The Media Control Channel Framework [RFC6230] requires a Control
+   Package definition to specify if the attributes for media dialog or
+   conference references are required.
+
+   The Publish interface defined in Section 10 does import and make use
+   of the common XML schema defined in the Media Control Channel
+   Framework.
+
+   The Consumer interface defined in Section 11 does import and make use
+   of the common XML schema defined in the Media Control Channel
+   Framework.
+
+5.1.1.4.  CONTROL Message Body
+
+   A valid CONTROL message body MUST conform to the schema defined in
+   Section 10 and described in Section 5.1.2.  XML messages appearing in
+   CONTROL messages MUST contain either an <mrbrequest> or
+   <mrbnotification> element.
+
+5.1.1.5.  REPORT Message Body
+
+   A valid REPORT message body MUST conform to the schema defined in
+   Section 10 and described in Section 5.1.2.  XML messages appearing in
+   REPORT messages MUST contain an <mrbresponse> element.
+
+5.1.1.6.  Audit
+
+   The 'mrb-publish/1.0' Media Control Channel Framework package does
+   not require any additional auditing capability.
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 14]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.2.  Element Definitions
+
+   This section defines the XML elements for the Publish interface Media
+   Control Channel package defined in Section 5.1.  The formal XML
+   schema definition for the Publish interface can be found in
+   Section 10.
+
+   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.5.
+   The MRB Publish interface response element is detailed in
+   Section 5.1.4.
+
+   The <mrbpublish> element has the following attributes:
+
+   version:  a token specifying the mrb-publish package version.  The
+      value is fixed as '1.0' for this version of the package.  The
+      attribute MUST be present.
+
+   The <mrbpublish> element has the following child elements, and there
+   MUST NOT be more than one such child element in any <mrbpublish>
+   message:
+
+      <mrbrequest> for sending an MRB request.  See Section 5.1.3.
+
+      <mrbresponse> for sending an MRB response.  See Section 5.1.4.
+
+      <mrbnotification> for sending an MRB notification.  See
+      Section 5.1.5.
+
+5.1.3.  <mrbrequest>
+
+   This section defines the <mrbrequest> element used to initiate
+   requests from an MRB to a Media Server.  The element describes
+   information relevant for the interrogation of a Media Server.
+
+   The <mrbrequest> element has no defined attributes.
+
+   The <mrbrequest> element has the following child element:
+
+      <subscription> for initiating a subscription to a Media Server
+      from an MRB.  See Section 5.1.3.1.
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 15]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.3.1.  <subscription>
+
+   The <subscription> element is included in a request from an MRB to a
+   Media Server to provide the details relating to the configuration of
+   updates (known as a subscription session).  This element can be used
+   either to request a new subscription or to update an existing one
+   (e.g., to change the frequency of the updates), and to remove ongoing
+   subscriptions as well (e.g., to stop an indefinite update).  The MRB
+   will inform the Media Server regarding how long it wishes to receive
+   updates and the frequency that updates should be sent.  Updates
+   related to the subscription are sent using the <mrbnotification>
+   element.
+
+   The <subscription> element has the following attributes:
+
+   id:  Indicates a unique token representing the subscription session
+      between the MRB and the Media Server.  The attribute MUST be
+      present.
+
+   seqnumber:  Indicates a sequence number to be used in conjunction
+      with the subscription session ID to identify a specific
+      subscription command.  The first subscription MUST contain a
+      non-zero number 'seqnumber', and subsequent subscriptions MUST
+      contain a higher number than the previous 'seqnumber' value.  If a
+      subsequent 'seqnumber' is not higher, a 405 response code is
+      generated as per Section 5.1.4.  The attribute MUST be present.
+
+   action:  Provides the operation that should be carried out on the
+      subscription:
+
+      *  The value of 'create' instructs the Media Server to attempt to
+         set up a new subscription.
+
+      *  The value of 'update' instructs the Media Server to attempt to
+         update an existing subscription.
+
+      *  The value of 'remove' instructs the Media Server to attempt to
+         remove an existing subscription and consequently stop any
+         ongoing related notification.
+
+      The attribute MUST be present.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 16]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <subscription> element has zero or more of the following child
+   elements:
+
+   <expires>:  Provides the amount of time in seconds that a
+      subscription should be installed for notifications at the Media
+      Server.  Once the amount of time has passed, the subscription
+      expires, and the MRB has to subscribe again if it is still
+      interested in receiving notifications from the Media Server.  The
+      element MAY be present.
+
+   <minfrequency>:  Provides the minimum frequency in seconds that the
+      MRB wishes to receive notifications from the Media Server.  The
+      element MAY be present.
+
+   <maxfrequency>:  Provides the maximum frequency in seconds that the
+      MRB wishes to receive notifications from the Media Server.  The
+      element MAY be present.
+
+   Please note that these three optional pieces of information provided
+   by the MRB only act as a suggestion: the Media Server MAY change the
+   proposed values if it considers the suggestions unacceptable (e.g.,
+   if the MRB has requested a notification frequency that is too high).
+   In such a case, the request would not fail, but the updated,
+   acceptable values would be reported in the <mrbresponse> accordingly.
+
+5.1.4.  <mrbresponse>
+
+   Responses to requests are indicated by an <mrbresponse> element.
+
+   The <mrbresponse> element has the following attributes:
+
+   status:  numeric code indicating the response status.  The attribute
+      MUST be present.
+
+   reason:  string specifying a reason for the response status.  The
+      attribute MAY be present.
+
+   The <mrbresponse> element has a single child element:
+
+      <subscription> for providing details related to a subscription
+      requested by a Media Server (see below in this section).
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 17]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The following status codes are defined for 'status':
+
+   +-----------+-------------------------------------------------------+
+   | code      | description                                           |
+   +-----------+-------------------------------------------------------+
+   | 200       | OK                                                    |
+   |           |                                                       |
+   | 400       | Syntax error                                          |
+   |           |                                                       |
+   | 401       | Unable to create Subscription                         |
+   |           |                                                       |
+   | 402       | Unable to update Subscription                         |
+   |           |                                                       |
+   | 403       | Unable to remove Subscription                         |
+   |           |                                                       |
+   | 404       | Subscription does not exist                           |
+   |           |                                                       |
+   | 405       | Wrong sequence number                                 |
+   |           |                                                       |
+   | 406       | Subscription already exists                           |
+   |           |                                                       |
+   | 420       | Unsupported attribute or element                      |
+   +-----------+-------------------------------------------------------+
+
+                    Table 1: <mrbresponse> Status Codes
+
+   If a new subscription request made by an MRB (action='create') has
+   been accepted, the Media Server MUST reply with an <mrbresponse> with
+   status code 200.  The same rule applies whenever a request to update
+   (action='update') or remove (action='remove') an existing transaction
+   can be fulfilled by the Media Server.
+
+   A subscription request, nevertheless, may fail for several reasons.
+   In such a case, the status codes defined in Table 1 must be used
+   instead.  Specifically, if the Media Server fails to handle a request
+   due to a syntax error in the request itself (e.g., incorrect XML,
+   violation of the schema constraints, or invalid values in any of the
+   attributes/elements), the Media Server MUST reply with an
+   <mrbresponse> with status code 400.  If a syntactically correct
+   request fails because the request also includes any attribute/element
+   the Media Server doesn't understand, the Media Server MUST reply with
+   an <mrbresponse> with status code 420.  If a syntactically correct
+   request fails because the MRB wants to create a new subscription, but
+   the provided unique 'id' for the subscription already exists, the
+   Media Server MUST reply with an <mrbresponse> with status code 406.
+   If a syntactically correct request fails because the MRB wants to
+   update/remove a subscription that doesn't exist, the Media Server
+   MUST reply with an <mrbresponse> with status code 404.  If the Media
+
+
+
+Boulton, et al.              Standards Track                   [Page 18]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Server is unable to accept a request for any other reason (e.g., the
+   MRB has no more resources to fulfill the request), the Media Server
+   MUST reply with an <mrbresponse> with status code 401/402/403,
+   depending on the action the MRB provided in its request:
+
+   o  action='create' --> 401;
+
+   o  action='update' --> 402;
+
+   o  action='remove' --> 403;
+
+   A response to a subscription request that has a status code of 200
+   indicates that the request is successful.  The response MAY also
+   contain a <subscription> child that describes the subscription.  The
+   <subscription> child MAY contain 'expires', 'minfrequency', and
+   'maxfrequency' values even if they were not contained in the request.
+
+   The Media Server can choose to change the suggested 'expires',
+   'minfrequency', and 'maxfrequency' values provided by the MRB in its
+   <mrbrequest> if it considers them unacceptable (e.g., the requested
+   frequency range is too high).  In such a case, the response MUST
+   contain a <subscription> element describing the subscription as the
+   Media Server accepted it, and the Media Server MUST include in the
+   <subscription> element all of those values that it modified relative
+   to the request, to inform the MRB about the change.
+
+5.1.5.  <mrbnotification>
+
+   The <mrbnotification> element is included in a request from a Media
+   Server to an MRB to provide the details relating to current status.
+   The Media Server will inform the MRB of its current status as defined
+   by the information in the <subscription> element.  Updates are sent
+   using the <mrbnotification> element.
+
+   The <mrbnotification> element has the following attributes:
+
+   id:  indicates a unique token representing the session between the
+      MRB and the Media Server and is the same as the one appearing in
+      the <subscription> element.  The attribute MUST be present.
+
+   seqnumber:  indicates a sequence number to be used in conjunction
+      with the subscription session ID to identify a specific
+      notification update.  The first notification update MUST contain a
+      non-zero number 'seqnumber', and subsequent notification updates
+      MUST contain a higher number than the previous 'seqnumber' value.
+      If a subsequent 'seqnumber' is not higher, the situation should be
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 19]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      considered an error by the entity receiving the notification
+      update.  How the receiving entity deals with this situation is
+      implementation specific.  The attribute MUST be present.
+
+   It's important to point out that the 'seqnumber' that appears in an
+   <mrbnotification> is not related to the 'seqnumber' appearing in a
+   <subscription>.  In fact, the latter is associated with subscriptions
+   and would increase at every command issued by the MRB, while the
+   former is associated with the asynchronous notifications the Media
+   Server would trigger according to the subscription and as such would
+   increase at every notification message to enable the MRB to keep
+   track of them.
+
+   The following sub-sections provide details of the child elements that
+   make up the contents of the <mrbnotification> element.
+
+5.1.5.1.  <media-server-id>
+
+   The <media-server-id> element provides a unique system-wide
+   identifier for a Media Server instance.  The element MUST be present
+   and MUST be chosen such that it is extremely unlikely that two
+   different Media Servers would present the same id to a given MRB.
+
+5.1.5.2.  <supported-packages>
+
+   The <supported-packages> element provides the list of Media Control
+   Channel packages supported by the Media Server.  The element MAY be
+   present.
+
+   The <supported-packages> element has no attributes.
+
+   The <supported-packages> element has a single child element:
+
+   <package>:  Gives the name of a package supported by the Media
+      Server.  The <package> element has a single attribute, 'name',
+      which provides the name of the supported Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230].
+
+5.1.5.3.  <active-rtp-sessions>
+
+   The <active-rtp-sessions> element provides information detailing the
+   current active Real-time Transport Protocol (RTP) sessions.  The
+   element MAY be present.
+
+   The <active-rtp-sessions> element has no attributes.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 20]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <active-rtp-sessions> element has a single child element:
+
+   <rtp-codec>:  Describes a supported codec and the number of active
+      sessions using that codec.  The <rtp-codec> element has one
+      attribute.  The value of the attribute, 'name', is a media type
+      (which can include parameters per [RFC6381]).  The <rtp-codec>
+      element has two child elements.  The child element <decoding> has
+      as content the decimal number of RTP sessions being decoded using
+      the specified codec, and the child element <encoding> has as
+      content the decimal number of RTP sessions being encoded using the
+      specified codec.
+
+5.1.5.4.  <active-mixer-sessions>
+
+   The <active-mixer-sessions> element provides information detailing
+   the current active mixed RTP sessions.  The element MAY be present.
+
+   The <active-mixer-sessions> element has no attributes.
+
+   The <active-mixer-sessions> element has a single child element:
+
+   <active-mix>:  Describes a mixed active RTP session.  The
+      <active-mix> element has one attribute.  The value of the
+      attribute, 'conferenceid', is the name of the mix.  The
+      <active-mix> element has one child element.  The child element,
+      <rtp-codec>, contains the same information relating to RTP
+      sessions as that defined in Section 5.1.5.3.  The element MAY be
+      present.
+
+5.1.5.5.  <non-active-rtp-sessions>
+
+   The <non-active-rtp-sessions> element provides information detailing
+   the currently available inactive RTP sessions, that is, how many more
+   RTP streams this Media Server can support.  The element MAY be
+   present.
+
+   The <non-active-rtp-sessions> element has no attributes.
+
+   The <non-active-rtp-sessions> element has a single child element:
+
+   <rtp-codec>:  Describes a supported codec and the number of
+      non-active sessions for that codec.  The <rtp-codec> element has
+      one attribute.  The value of the attribute, 'name', is a media
+      type (which can include parameters per [RFC6381]).  The
+      <rtp-codec> element has two child elements.  The child element
+      <decoding> has as content the decimal number of RTP sessions
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 21]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      available for decoding using the specified codec, and the child
+      element <encoding> has as content the decimal number of RTP
+      sessions available for encoding using the specified codec.
+
+5.1.5.6.  <non-active-mixer-sessions>
+
+   The <non-active-mixer-sessions> element provides information
+   detailing the current inactive mixed RTP sessions, that is, how many
+   more mixing sessions this Media Server can support.  The element MAY
+   be present.
+
+   The <non-active-mixer-sessions> element has no attributes.
+
+   The <non-active-mixer-sessions> element has a single child element:
+
+   <non-active-mix>:  Describes available mixed RTP sessions.  The
+      <non-active-mix> element has one attribute.  The value of the
+      attribute, 'available', is the number of mixes that could be used
+      using that profile.  The <non-active-mix> element has one child
+      element.  The child element, <rtp-codec>, contains the same
+      information relating to RTP sessions as that defined in
+      Section 5.1.5.5.  The element MAY be present.
+
+5.1.5.7.  <media-server-status>
+
+   The <media-server-status> element provides information detailing the
+   current status of the Media Server.  The element MUST be present.  It
+   can return one of the following values:
+
+   active:  Indicates that the Media Server is available for service.
+
+   deactivated:  Indicates that the Media Server has been withdrawn from
+      service, and as such requests should not be sent to it before it
+      becomes 'active' again.
+
+   unavailable:  Indicates that the Media Server continues to process
+      past requests but cannot accept new requests, and as such should
+      not be contacted before it becomes 'active' again.
+
+   The <media-server-status> element has no attributes.
+
+   The <media-server-status> element has no child elements.
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 22]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.5.8.  <supported-codecs>
+
+   The <supported-codecs> element provides information detailing the
+   current codecs supported by a Media Server and associated actions.
+   The element MAY be present.
+
+   The <supported-codecs> element has no attributes.
+
+   The <supported-codecs> element has a single child element:
+
+   <supported-codec>:  Has a single attribute, 'name', which provides
+      the name of the codec about which this element provides
+      information.  A valid value is a media type that, depending on its
+      definition, can include additional parameters (e.g., [RFC6381]).
+      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, compliant with
+      Section 13.1.1 of [RFC6230], for which the codec support applies.
+      The <supported-codec-package> element has zero or more
+      <supported-action> children, each one of which describes an action
+      that a Media Server can apply to this codec:
+
+      *  'decoding', meaning a decoder for this codec is available;
+
+      *  'encoding', meaning an encoder for this codec is available;
+
+      *  'passthrough', meaning the Media Server is able to pass a
+         stream encoded using that codec through, without re-encoding.
+
+5.1.5.9.  <application-data>
+
+   The <application-data> element provides an arbitrary string of
+   characters as application-level data.  This data is meant to only
+   have meaning at the application-level logic and as such is not
+   otherwise restricted by this specification.  The set of allowed
+   characters is the same as those in XML (viz., tab, carriage return,
+   line feed, and the legal characters of Unicode and ISO/IEC 10646
+   [ISO.10646.2012] (see also Section 2.2 of
+   <http://www.w3.org/TR/xml/>)).  The element MAY be present.
+
+   The <application-data> element has no attributes.
+
+   The <application-data> element has no child elements.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 23]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.5.10.  <file-formats>
+
+   The <file-formats> element provides a list of file formats supported
+   for the purpose of playing media.  The element MAY be present.
+
+   The <file-formats> element has no attributes.
+
+   The <file-formats> element has zero of more the following child
+   elements:
+
+   <supported-format>:  Has a single attribute, 'name', which provides
+      the type of file format that is supported.  A valid value is a
+      media type that, depending on its definition, can include
+      additional parameters (e.g., [RFC6381]).  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,
+      compliant with Section 13.1.1 of [RFC6230], for which the file
+      format support applies.
+
+5.1.5.11.  <max-prepared-duration>
+
+   The <max-prepared-duration> element provides the maximum amount of
+   time a media dialog will be kept in the prepared state before timing
+   out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231].  The element MAY be
+   present.
+
+   The <max-prepared-duration> element has no attributes.
+
+   The <max-prepared-duration> element has a single child element:
+
+   <max-time>:  Has a single attribute, 'max-time-seconds', which
+      provides the amount of time in seconds that a media dialog can be
+      in the prepared state.  The <max-time> element then has a further
+      child element, <max-time-package>.  The <max-time-package> element
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the time
+      period applies.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 24]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.5.12.  <dtmf-support>
+
+   The <dtmf-support> element specifies the supported methods to detect
+   Dual-Tone Multi-Frequency (DTMF) tones and to generate them.  The
+   element MAY be present.
+
+   The <dtmf-support> element has no attributes.
+
+   The <dtmf-support> element has zero of more of the following child
+   elements:
+
+   <detect>:  Indicates the support for DTMF detection.  The <detect>
+      element 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, and it can only be a case-
+      insensitive string containing either 'RFC4733' [RFC4733] or
+      'Media' (detecting tones as signals from the audio stream).  The
+      'package' attribute provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the DTMF type applies.
+
+   <generate>:  Indicates the support for DTMF generation.  The
+      <generate> element 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, and it can only be a case-
+      insensitive string containing either 'RFC4733' [RFC4733] or
+      'Media' (generating tones as signals in the audio stream).  The
+      'package' attribute provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the DTMF type applies.
+
+   <passthrough>:  Indicates the support for passing DTMF through
+      without re-encoding.  The <passthrough> element 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, and it can only be a case-insensitive string
+      containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as
+      signals through the audio stream).  The 'package' attribute
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+      type applies.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 25]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.5.13.  <mixing-modes>
+
+   The <mixing-modes> element provides information about the support for
+   audio and video mixing of a Media Server, specifically a list of
+   supported algorithms to mix audio and a list of supported video
+   presentation layouts.  The element MAY be present.
+
+   The <mixing-modes> element has no attributes.
+
+   The <mixing-modes> element has zero or more of the following child
+   elements:
+
+   <audio-mixing-modes>:  Describes the available algorithms for audio
+      mixing.  The <audio-mixing-modes> element has no attributes.  The
+      <audio-mixing-modes> element has one child element.  The child
+      element, <audio-mixing-mode>, contains a specific available
+      algorithm.  Valid values for the <audio-mixing-mode> element are
+      algorithm names, e.g., 'nbest' and 'controller' as defined in
+      [RFC6505].  The element has a single attribute, 'package'.  The
+      attribute 'package' provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the algorithm support applies.
+
+   <video-mixing-modes>:  Describes the available video presentation
+      layouts and the supported functionality related to video mixing.
+      The <video-mixing-modes> element has two attributes: 'vas' and
+      'activespeakermix'.  The 'vas' attribute is of type boolean with a
+      value of 'true' indicating that the Media Server supports
+      automatic Voice Activated Switching.  The 'activespeakermix' is of
+      type boolean with a value of 'true' indicating that the Media
+      Server is able to prepare an additional video stream for the
+      loudest speaker participant without its contribution.  The
+      <video-mixing-modes> element has one child element.  The child
+      element, <video-mixing-mode>, contains the name of a specific
+      video presentation layout.  The name may refer to one of the
+      predefined video layouts defined in the XCON conference
+      information data model [RFC6501], or to non-XCON layouts as well,
+      as long as they are properly prefixed according to the schema they
+      belong to.  The <video-mixing-mode> element has a single
+      attribute, 'package'.  The attribute 'package' provides the name
+      of the Media Control Channel Framework package, compliant with
+      Section 13.1.1 of [RFC6230], for which the algorithm support
+      applies.
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 26]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.1.5.14.  <supported-tones>
+
+   The <supported-tones> element provides information about which tones
+   a Media Server is able to play and recognize.  In particular, the
+   support is reported by referring to both support for country codes
+   (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T
+   Recommendation Q.1950 [ITU-T.Q.1950]).  The element MAY be present.
+
+   The <supported-tones> element has no attributes.
+
+   The <supported-tones> element has zero or more of the following child
+   elements:
+
+   <supported-country-codes>:  Describes the supported country codes
+      with respect to tones.  The <supported-country-codes> element has
+      no attributes.  The <supported-country-codes> element has one
+      child element.  The child element, <country-code>, reports support
+      for a specific country code, compliant with the ISO 3166-1
+      [ISO.3166-1] specification.  The <country-code> element has a
+      single attribute, 'package'.  The attribute 'package' provides the
+      name of the Media Control Channel Framework package, compliant
+      with Section 13.1.1 of [RFC6230], in which the tones from the
+      specified country code are supported.
+
+   <supported-h248-codes>:  Describes the supported H.248 codes with
+      respect to tones.  The <supported-h248-codes> element has no
+      attributes.  The <supported-h248-codes> element has one child
+      element.  The child element, <h248-code>, reports support for a
+      specific H.248 code, compliant with the ITU-T Recommendation
+      Q.1950 [ITU-T.Q.1950] specification.  The codes can be either
+      specific (e.g., cg/dt to only report the Dial Tone from the Call
+      Progress Tones package) or generic (e.g., cg/* to report all the
+      tones from the Call Progress Tones package), using wildcards.  The
+      <h248-code> element has a single attribute, 'package'.  The
+      attribute 'package' provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], in
+      which the specified codes are supported.
+
+5.1.5.15.  <file-transfer-modes>
+
+   The <file-transfer-modes> element allows the Media Server to specify
+   which scheme names are supported for transferring files to a Media
+   Server for each Media Control Channel Framework package type, for
+   example, whether the Media Server supports fetching resources via
+   HTTP, HTTPS, NFS, etc.  The element MAY be present.
+
+   The <file-transfer-modes> element has no attributes.
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 27]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <file-transfer-modes> element has a single child element:
+
+   <file-transfer-mode>:  Has two attributes: 'name' and 'package'.  The
+      'name' attribute provides the scheme name of the protocol that can
+      be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.); the
+      value of the attribute is case insensitive.  The 'package'
+      attribute provides the name of the Media Control Channel Framework
+      package, compliant with the specification in the related IANA
+      registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.
+
+   It is important to point out that this element provides no
+   information about whether or not the Media Server supports any flavor
+   of live streaming: for instance, a value of "HTTP" for the IVR
+   (Interactive Voice Response) Package would only mean the 'http'
+   scheme makes sense to the Media Server within the context of that
+   package.  Whether or not the Media Server can make use of HTTP to
+   only fetch resources, or also to attach an HTTP live stream to a
+   call, is to be considered implementation specific to the Media Server
+   and irrelevant to the Application Server and/or MRB.  Besides, the
+   Media Server supporting a scheme does not imply that it also supports
+   the related secure versions: for instance, if the Media Server
+   supports both HTTP and HTTPS, both the schemes will appear in the
+   element.  A lack of the "HTTPS" value would need to be interpreted as
+   a lack of support for the 'https' scheme.
+
+5.1.5.16.  <asr-tts-support>
+
+   The <asr-tts-support> element provides information about the support
+   for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
+   functionality in a Media Server.  The functionality is reported by
+   referring to the supported languages (using ISO 639-1 [ISO.639.2002]
+   codes) regarding both ASR and TTS.  The element MAY be present.
+
+   The <asr-tts-support> element has no attributes.
+
+   The <asr-tts-support> element has zero or more of the following child
+   elements:
+
+   <asr-support>:  Describes the available languages for ASR.  The
+      <asr-support> element has no attributes.  The <asr-support>
+      element has one child element.  The child element, <language>,
+      reports that the Media Server supports ASR for a specific
+      language.  The <language> element has a single attribute,
+      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
+      [ISO.639.2002] code of the supported language.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 28]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   <tts-support>:  Describes the available languages for TTS.  The
+      <tts-support> element has no attributes.  The <tts-support>
+      element has one child element.  The child element, <language>,
+      reports that the Media Server supports TTS for a specific
+      language.  The <language> element has a single attribute,
+      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
+      [ISO.639.2002] code of the supported language.
+
+5.1.5.17.  <vxml-support>
+
+   The <vxml-support> element specifies if the Media Server supports
+   VoiceXML (VXML) and, if it does, through which protocols the support
+   is exposed (e.g., via the control framework, RFC 4240 [RFC4240], or
+   RFC 5552 [RFC5552]).  The element MAY be present.
+
+   The <vxml-support> element has no attributes.
+
+   The <vxml-support> element has a single child element:
+
+   <vxml-mode>:  Has two attributes: 'package' and 'support'.  The
+      'package' attribute provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the VXML support applies.  The 'support' attribute provides
+      the type of VXML support provided by the Media Server (e.g.,
+      RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package
+      [RFC6231]), and valid values are case-insensitive RFC references
+      (e.g., "rfc6231" to specify that the Media Server supports
+      VoiceXML as provided by the IVR Package [RFC6231]).
+
+   The presence of at least one <vxml-mode> child element would indicate
+   that the Media Server does support VXML as specified by the child
+   element itself.  An empty <vxml> element would otherwise indicate
+   that the Media Server does not support VXML at all.
+
+5.1.5.18.  <media-server-location>
+
+   The <media-server-location> element provides information about the
+   civic location of a Media Server.  Its description makes use of the
+   Civic Address Schema standardized in RFC 5139 [RFC5139].  The element
+   MAY be present.  More precisely, this section is entirely optional,
+   and it's implementation specific to fill it with just the details
+   each implementer deems necessary for any optimization that may be
+   needed.
+
+   The <media-server-location> element has no attributes.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 29]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <media-server-location> element has a single child element:
+
+   <civicAddress>:  Describes the civic address location of the Media
+      Server, whose representation refers to Section 4 of RFC 5139
+      [RFC5139].
+
+5.1.5.19.  <label>
+
+   The <label> element allows a Media Server to declare a piece of
+   information that will be understood by the MRB.  For example, the
+   Media Server can declare if it's a blue or green one.  It's a string
+   to allow arbitrary values to be returned to allow arbitrary
+   classification.  The element MAY be present.
+
+   The <label> element has no attributes.
+
+   The <label> element has no child elements.
+
+5.1.5.20.  <media-server-address>
+
+   The <media-server-address> element allows a Media Server to provide a
+   direct SIP URI where it can be reached (e.g., the URI that the
+   Application Server would call in order to set up a Control Channel
+   and relay SIP media dialogs).  The element MAY be present.
+
+   The <media-server-address> element has no attributes.
+
+   The <media-server-address> element has no child elements.
+
+5.1.5.21.  <encryption>
+
+   The <encryption> element allows a Media Server to declare support for
+   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
+   MAY be present.  If the element is present, then the Media Server
+   supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP)
+   extension for Datagram Transport Layer Security (DTLS)) [RFC5763].
+
+   The <encryption> element has no attributes.
+
+   The <encryption> element has no child elements.
+
+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.  This interface allows a
+   client to pass detailed meta-information to the MRB to help select an
+   appropriate Media Server.  The MRB is then able to make an informed
+
+
+
+Boulton, et al.              Standards Track                   [Page 30]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   decision and provide the client with an appropriate Media Server
+   resource.  The MRB Consumer interface includes both 1) the In-line
+   Aware MRB Mode (IAMM), which uses the Session Initiation Protocol
+   (SIP) and 2) the Query mode, which uses the Hypertext Transfer
+   Protocol (HTTP) [RFC2616].  The MRB Consumer interface does not
+   include the In-line Unaware Mode (IUMM), which is further explained
+   in Section 5.3.  The following sub-sections provide guidance on
+   using the Consumer interface, which is represented by the
+   'application/mrb-consumer+xml' media type in Section 11, with HTTP
+   and SIP.
+
+5.2.1.  Query Mode/HTTP Consumer Interface Usage
+
+   An appropriate interface for such a 'query' style interface is in
+   fact an HTTP usage.  Using HTTP and XML combined reduces complexity
+   and encourages the use of common tools that are widely available in
+   the industry today.  The following information explains the primary
+   operations required to request and then receive information from an
+   MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport
+   for a query for a media resource, and the appropriate response.
+
+   The media resource query, as defined by the <mediaResourceRequest>
+   element from Section 11, MUST be carried in the body of an HTTP/HTTPS
+   POST request.  The media type contained in the HTTP/HTTPS request/
+   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
+   reflected in the appropriate HTTP headers, such as 'Content-Type' and
+   'Accept'.  The body of the HTTP/HTTPS POST request MUST only contain
+   an <mrbconsumer> root element with only one child
+   <mediaResourceRequest> element as defined in Section 11.
+
+   The media resource response to a query, as defined by the
+   <mediaResourceResponse> element from Section 11, MUST be carried in
+   the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
+   POST request.  The media type contained in the HTTP/HTTPS request/
+   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
+   reflected in the appropriate HTTP headers, such as 'Content-Type' and
+   'Accept'.  The body of the HTTP/HTTPS 200 response MUST only contain
+   an <mrbconsumer> root element with only one child
+   <mediaResourceResponse> element as defined in Section 11.
+
+   When an Application Server wants to release previously awarded media
+   resources granted through a prior request/response exchange with an
+   MRB, it will send a new request with an <action> element with value
+   'remove', as described in Section 5.2.3 ("Consumer Interface Lease
+   Mechanism").
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 31]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.2.  In-Line Aware Mode/SIP Consumer Interface Usage
+
+   This document provides a complete toolkit for MRB deployment that
+   includes the ability to interact with an MRB using SIP for the
+   Consumer interface.  The following information explains the primary
+   operations required to request and then receive information from an
+   MRB, by making use of SIP [RFC3261] as transport for a request for
+   media resources, and the appropriate response when using IAMM as the
+   mode of operation (as discussed in Section 5.2.2.1).
+
+   The use of IAMM, besides having the MRB select appropriate media
+   resources on behalf of a client application, includes setting up
+   either a Control Framework Control Channel between an Application
+   Server and one of the Media Servers (Section 5.2.2.1) or a media
+   dialog session between an Application Server and one of the Media
+   Servers (Section 5.2.2.2).  Note that in either case the SIP URIs of
+   the selected Media Servers are made known to the requesting
+   Application Server in the SIP 200 OK response by means of one or more
+   <media-server-address> child elements in the <response-session-info>
+   element (Section 5.2.6).
+
+5.2.2.1.  IAMM and Setting Up a Control Framework Control Channel
+
+   The media resource request information, as defined by the
+   <mediaResourceRequest> element from Section 11, is carried in a SIP
+   INVITE request.  The INVITE request will be constructed as it would
+   have been to connect to a Media Server, as defined by the Media
+   Control Channel Framework [RFC6230].  It should be noted that this
+   specification does not exclude the use of an offerless INVITE as
+   defined in RFC 3261 [RFC3261].  Using offerless INVITE messages to an
+   MRB can potentially cause confusion when applying resource selection
+   algorithms, and an MRB, like any other SIP device, can choose to
+   reject with a 4xx response.  For an offerless INVITE to be treated
+   appropriately, additional contextual information would need to be
+   provided with the request; this is out of scope for this document.
+   The following additional steps MUST be followed when using the
+   Consumer interface:
+
+   o  The Consumer client will include a payload in the SIP INVITE
+      request of type 'multipart/mixed' [RFC2046].  One of the parts to
+      be included in the 'multipart/mixed' payload MUST be the
+      'application/sdp' format, which is constructed as specified in the
+      Media Control Channel Framework [RFC6230].
+
+   o  Another part of the 'multipart/mixed' payload MUST be of type
+      'application/mrb-consumer+xml', as specified in this document and
+      defined in Section 11.  The body part MUST be an XML document
+      without prolog and whose root element is <mediaResourceRequest>.
+
+
+
+Boulton, et al.              Standards Track                   [Page 32]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   o  The INVITE request will then be dispatched to the MRB, as defined
+      by [RFC6230].
+
+   On receiving a SIP INVITE request containing the multipart/mixed
+   payload as specified previously, the MRB will complete a number of
+   steps to fulfill 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 (or Media Servers, if more than one is deemed to be
+      needed) should be selected to service the request.
+
+   o  Extract the 'application/sdp' part from the payload and use it as
+      the body of a new SIP INVITE request for connecting the client to
+      one of the selected Media Servers, as defined in the Media Channel
+      Control Framework [RFC6230].  The policy the MRB follows to pick a
+      specific Media Server out of the Media Servers it selects is
+      implementation specific and out of scope for this document.  It is
+      important to configure the SIP elements between the MRB and the
+      Media Server in such a way that the INVITE will not fork.  In the
+      case of a failure in reaching the chosen Media Server, the MRB
+      SHOULD proceed to the next one, if available.
+
+   If none of the available Media Servers can be reached, the MRB MUST
+   reply with a SIP 503 error message that includes a Retry-After header
+   with a non-zero value.  The Application Server MUST NOT attempt to
+   set up a new session before the time that the MRB asked it to wait
+   has passed.
+
+   If at least one Media Server is reachable, the MRB acts as a Back-to-
+   Back User Agent (B2BUA) that extracts the 'application/
+   mrb-consumer+xml' information from the SIP INVITE request and then
+   sends a corresponding SIP INVITE request to the Media Server it has
+   selected, to negotiate a Control Channel as defined in the Media
+   Channel Control Framework [RFC6230].
+
+   In the case of a failure in negotiating the Control Channel with the
+   Media Server, the MRB SHOULD proceed to the next one, if available,
+   as explained above.  If none of the available Media Servers can be
+   reached, or the negotiations of the Control Channel with all of them
+   fail, the MRB MUST reply with a SIP 503 error message that includes a
+   Retry-After header with a non-zero value.  The Application Server
+   MUST NOT attempt to set up a new session before the time that the MRB
+   asked it to wait has expired.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 33]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Once the MRB receives the SIP response from the selected media
+   resource (i.e., Media Server), it will in turn respond to the
+   requesting client (i.e., Application Server).
+
+   The media resource response generated by an MRB to a request, as
+   defined by the <mediaResourceResponse> element from Section 11, MUST
+   be carried in the payload of a SIP 200 OK response to the original
+   SIP INVITE request.  The SIP 200 OK response will be constructed as
+   it would have been to connect from a Media Server, as defined by the
+   Media Control Channel Framework [RFC6230].  The following additional
+   steps MUST be followed when using the Consumer interface:
+
+   o  Include a payload in the SIP 200 response of type 'multipart/
+      mixed' as per RFC 2046 [RFC2046].  One of the parts to be included
+      in the 'multipart/mixed' payload MUST be the 'application/sdp'
+      format, which is constructed as specified in the Media Control
+      Channel Framework [RFC6230] and based on the incoming response
+      from the selected media resource.
+
+   o  Another part of the 'multipart/mixed' payload MUST be of type
+      'application/mrb-consumer+xml', as specified in this document and
+      defined in Section 11.  Only the <mediaResourceResponse> and its
+      child elements can be included in the payload.
+
+   o  The SIP 200 response will then be dispatched from the MRB.
+
+   o  A SIP ACK to the 200 response will then be sent back to the MRB.
+
+   Considering that the use of SIP as a transport for Consumer
+   transactions may result in failure, the IAMM relies on a successful
+   INVITE transaction to address the previously discussed sequence
+   (using the 'seq' XML element) increment mechanism.  This means that
+   if the INVITE is unsuccessful for any reason, the Application Server
+   MUST use the same 'seq' value as previously used for the next
+   Consumer request that it may want to send to the MRB for the same
+   session.
+
+   An MRB implementation may be programmed to conclude that the
+   requested resources are no longer needed when it receives a SIP BYE
+   from the Application Server or Media Server that concludes the SIP
+   dialog that initiated the request, or when the lease (Section 5.2.3)
+   interval expires.
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 34]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.2.2.  IAMM and Setting Up a Media Dialog
+
+   This scenario is identical to the description in the previous section
+   for setting up a Control Framework Control Channel, with the
+   exception that the application/sdp payload conveys content
+   appropriate for setting up the media dialog to the media resource, as
+   per RFC 3261 [RFC3261], instead of setting up a Control Channel.
+
+5.2.3.  Consumer Interface Lease Mechanism
+
+   The Consumer interface defined in Sections 5.2 and 11 allows a client
+   to request an appropriate media resource based on information
+   included in the request (either an HTTP POST or SIP INVITE message).
+   In the case of success, the response that is returned to the client
+   MUST contain a <response-session-info> element in either the SIP 200
+   or HTTP 200 response.  The success response contains the description
+   of certain resources that have been reserved to a specific Consumer
+   client in a (new or revised) "resource session", which is identified
+   in the <response-session-info>.  The resource session is a "lease",
+   in that the reservation is scheduled to expire at a particular time
+   in the future, releasing the resources to be assigned for other uses.
+   The lease may be extended or terminated earlier by future Consumer
+   client requests that identify and reference a specific resource
+   session.
+
+   Before delving into the details of such a lease mechanism, it is
+   worth clarifying its role within the context of the Consumer
+   interface.  As explained in Section 5.1, the knowledge the MRB has of
+   the resources of all the Media Servers it is provisioned to manage is
+   not real-time.  How an MRB actually manages such resources is
+   implementation specific -- for example, an implementation may choose
+   to have the MRB keeping track and state of the allocated resources,
+   or simply rely on the Media Servers themselves to provide the
+   information using the Publish interface.  Further information may
+   also be inferred by the signaling, in the case where an MRB is in the
+   path of media dialogs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 35]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <mediaResourceResponse> element returned from the MRB contains a
+   <response-session-info> element if the request is successful.  The
+   <response-session-info> element has zero or more of the following
+   child elements, which provide the appropriate resource session
+   information:
+
+   o  <session-id> is a unique identifier that enables a Consumer client
+      and MRB to correlate future media resource requests related to an
+      initial media resource request.  The <session-id> MUST be included
+      in all future related requests (see the <session-id> paragraph
+      later in this section, where constructing a subsequent request is
+      discussed).
+
+   o  <seq> is a numeric value returned to the Consumer client.  On
+      issuing any future requests related to the media resource session
+      (as determined by the <session-id> element), the Consumer client
+      MUST increment the value returned in the <seq> element and include
+      it in the request (see the <seq> paragraph later in this section,
+      where constructing a subsequent request is discussed).  Its value
+      is a non-negative integer that MUST be limited within the
+      0..2^31-1 range.
+
+   o  <expires> provides a value indicating the number of seconds that
+      the request for media resources is deemed alive.  The Consumer
+      client should issue a refresh of the request, as discussed later
+      in this section, if the expiry is due to fire and the media
+      resources are still required.
+
+   o  <media-server-address> provides information representing an
+      assigned Media Server.  More instances of this element may appear
+      should the MRB assign more Media Servers to a Consumer request.
+
+   The <mediaResourceRequest> element is used in subsequent Consumer
+   interface requests if the client wishes to manipulate the session.
+   The Consumer client MUST include the <session-info> element, which
+   enables the receiving MRB to determine an existing media resource
+   allocation session.  The <session-info> element has the following
+   child elements, which provide the appropriate resource session
+   information to the MRB:
+
+   o  <session-id> is a unique identifier that allows a Consumer client
+      to indicate the appropriate existing media resource session to be
+      manipulated by the MRB for this request.  The value was provided
+      by the MRB in the initial request for media resources, as
+      discussed earlier in this section (<session-id> element included
+      as part of the <session-info> element in the initial
+      <mediaResourceResponse>).
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 36]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   o  <seq> is a numeric value returned to the Consumer client in the
+      initial request for media resources, as discussed earlier in this
+      section (<seq> element included as part of the <session-info>
+      element in the initial <mediaResourceResponse>).  On issuing any
+      future requests related to the specific media resource session (as
+      determined by the <session-id> element), the Consumer client MUST
+      increment the value returned in the <seq> element from the initial
+      response (contained in the <mediaResourceResponse>) for every new
+      request.  The value of the <seq> element in requests acts as a
+      counter and when used in conjunction with the unique <session-id>
+      allows for unique identification of a request.  As anticipated
+      before, the <seq> value is limited to the 0..2^31-1 range: in the
+      unlikely case that the counter increases to reach the highest
+      allowed value, the <seq> value MUST be set to 0.  The first
+      numeric value for the <seq> element is not meant to be '1' but
+      SHOULD be generated randomly by the MRB: this is to reduce the
+      chances of a malicious MRB disrupting the session created by this
+      MRB, as explained in Section 12.
+
+   o  <action> provides the operation to be carried out by the MRB on
+      receiving the request:
+
+      *  The value of 'update' is a request by the Consumer client to
+         update the existing session on the MRB with alternate media
+         resource requirements.  If the requested resource information
+         is identical to the existing MRB session, the MRB will attempt
+         a session refresh.  If the information has changed, the MRB
+         will attempt to update the existing session with the new
+         information.  If the operation is successful, the 200 status
+         code in the response is returned in the status attribute of the
+         <mediaResourceResponseType> element.  If the operation is not
+         successful, a 409 status code in the response is returned in
+         the status attribute of the <mediaResourceResponseType>
+         element.
+
+      *  The value of 'remove' is a request by the Consumer client to
+         remove the session on the MRB.  This provides a mechanism for
+         Consumer clients to release unwanted resources before they
+         expire.  If the operation is successful, a 200 status code in
+         the response is returned in the status attribute of the
+         <mediaResourceResponseType> element.  If the operation is not
+         successful, a 410 status code in the response is returned in
+         the status attribute of the <mediaResourceResponseType>
+         element.
+
+   Omitting the 'action' attribute means requesting a new set of
+   resources.
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 37]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   When used with HTTP, the <session-info> element MUST be included in
+   an HTTP POST message (as defined in [RFC2616]).  When used with SIP,
+   the <session-info> element MUST instead be included in either a SIP
+   INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP
+   UPDATE (as defined in [RFC3311]) request: in fact, any SIP dialog, be
+   it a new or an existing one, can be exploited to carry leasing
+   information, and as such new SIP INVITE messages can update other
+   leases as well as request a new one.
+
+   With IAMM, the Application Server or Media Server will eventually
+   send a SIP BYE to end the SIP session, whether it was for a Control
+   Channel or a media dialog.  That BYE contains no Consumer interface
+   lease information.
+
+5.2.4.  <mrbconsumer>
+
+   This section defines the XML elements for the Consumer interface.
+   The formal XML schema definition for the Consumer interface can be
+   found in Section 11.
+
+   The root element is <mrbconsumer>.  All other XML elements (requests,
+   responses) are contained within it.  The MRB Consumer interface
+   request element is detailed in Section 5.2.5.1.  The MRB Consumer
+   interface response element is detailed in Section 5.2.6.1.
+
+   The <mrbconsumer> element has the following attributes:
+
+   version:  a token specifying the mrb-consumer package version.  The
+      value is fixed as '1.0' for this version of the package.  The
+      attribute MUST be present.
+
+   The <mrbconsumer> element may have zero or more children of one of
+   the following child element types:
+
+      <mediaResourceRequest> for sending a Consumer request.  See
+      Section 5.2.5.1.
+
+      <mediaResourceResponse> for sending a Consumer response.  See
+      Section 5.2.6.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 38]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.5.  Media Service Resource Request
+
+   This section provides the element definitions for use in Consumer
+   interface requests.  The requests are carried in the
+   <mediaResourceRequest> element.
+
+5.2.5.1.  <mediaResourceRequest>
+
+   The <mediaResourceRequest> element provides information for clients
+   wishing to query an external MRB entity.  The <mediaResourceRequest>
+   element has a single mandatory attribute, 'id': this attribute
+   contains a random identifier, generated by the client, that will be
+   included in the response in order to map it to a specific request.
+   The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and
+   <mixerInfo> as child elements.  These three elements are used to
+   describe the requirements of a client requesting a Media Server and
+   are covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3,
+   respectively.
+
+5.2.5.1.1.  <generalInfo>
+
+   The <generalInfo> element provides general Consumer request
+   information that is neither IVR specific nor mixer specific.  This
+   includes session information that can be used for subsequent requests
+   as part of the leasing mechanism described in Section 5.2.3.  The
+   following sub-sections describe the <session-info> and <packages>
+   elements, as used by the <generalInfo> element.
+
+5.2.5.1.1.1.  <session-info>
+
+   The <session-info> element is included in Consumer requests when an
+   update is being made to an existing media resource session.  The
+   ability to change and remove an existing media resource session is
+   described in more detail in Section 5.2.3.  The element MAY be
+   present.
+
+   The <session-info> element has no attributes.
+
+   The <session-info> element has zero or more of the following child
+   elements:
+
+   <session-id>:  A unique identifier that explicitly references an
+      existing media resource session on the MRB.  The identifier is
+      included to update the existing session and is described in more
+      detail in Section 5.2.3.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 39]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   <seq>:  Used in association with the <session-id> element in a
+      subsequent request to update an existing media resource session on
+      an MRB.  The <seq> number is incremented from its original value
+      returned in response to the initial request for media resources.
+      Its value is a non-negative integer that MUST be limited within
+      the 0..2^31-1 range.  In the unlikely case that the counter
+      increases to reach the highest allowed value, the <seq> value MUST
+      be set to 0.  More information about its use is provided in
+      Section 5.2.3.
+
+   <action>:  Provides the operation that should be carried out on an
+      existing media resource session on an MRB:
+
+      *  The value of 'update' instructs the MRB to attempt to update
+         the existing media resource session with the information
+         contained in the <ivrInfo> and <mixerInfo> elements.
+
+      *  The value of 'remove' instructs the MRB to attempt to remove
+         the existing media resource session.  More information on its
+         use is provided in Section 5.2.3.
+
+5.2.5.1.1.2.  <packages>
+
+   The <packages> element provides a list of Media Control Channel
+   Framework compliant packages that are required by the Consumer
+   client.  The element MAY be present.
+
+   The <packages> element has no attributes.
+
+   The <packages> element has a single child element:
+
+   <package>:  Contains a string representing the Media Control Channel
+      Framework package required by the Consumer client.  The <package>
+      element can appear multiple times.  A valid value is a Control
+      Package name compliant with Section 13.1.1 of [RFC6230].
+
+5.2.5.1.2.  <ivrInfo>
+
+   The <ivrInfo> element provides information for general Consumer
+   request information that is IVR specific.  The following sub-sections
+   describe the elements of the <ivrInfo> element: <ivr-sessions>,
+   <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>,
+   <encryption>, <application-data>, <max-prepared-duration>, and
+   <file-transfer-modes>.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 40]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.5.1.2.1.  <ivr-sessions>
+
+   The <ivr-sessions> element indicates the number of IVR sessions that
+   a Consumer client requires from a media resource.  The element MAY be
+   present.
+
+   The <ivr-sessions> element has no attributes.
+
+   The <ivr-sessions> element has a single child element:
+
+   <rtp-codec>:  Describes a required codec and the number of sessions
+      using that codec.  The <rtp-codec> element has one attribute.  The
+      value of the attribute, 'name', is a media type (which can include
+      parameters per [RFC6381]).  The <rtp-codec> element has two child
+      elements.  The child element <decoding> contains the number of RTP
+      sessions required for decoding using the specified codec, and the
+      child element <encoding> contains the number of RTP sessions
+      required for encoding using the specified codec.
+
+5.2.5.1.2.2.  <file-formats>
+
+   The <file-formats> element provides a list of file formats required
+   for the purpose of playing media.  It should be noted that this
+   element describes media types and might better have been named
+   "media-formats", but due to existing implementations the name
+   "file-formats" is being used.  The element MAY be present.
+
+   The <file-formats> element has no attributes.
+
+   The <file-formats> element has a single child element:
+
+   <required-format>:  Has a single attribute, 'name', which provides
+      the type of file format that is required.  A valid value is a
+      media type that, depending on its definition, can include
+      additional parameters (e.g., [RFC6381]).  The <required-format>
+      element then has a further child element, <required-file-package>.
+      The <required-file-package> element has a single attribute,
+      'required-file-package-name', which contains the name of the Media
+      Control Channel Framework package, compliant with Section 13.1.1
+      of [RFC6230], for which the file format support applies.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 41]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.5.1.2.3.  <dtmf>
+
+   The <dtmf> element specifies the required methods to detect DTMF
+   tones and to generate them.  The element MAY be present.
+
+   The <dtmf> element has no attributes.
+
+   The <dtmf> element has zero or more of the following child elements:
+
+   <detect>:  Indicates the required support for DTMF detection.  The
+      <detect> element has no attributes.  The <detect> element has a
+      further child element, <dtmf-type>.  The <dtmf-type> element has
+      two attributes: 'name' and 'package'.  The 'name' attribute
+      provides the type of DTMF required and is a case-insensitive
+      string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
+      tones as signals from the audio stream).  The 'package' attribute
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+      type applies.
+
+   <generate>:  Indicates the required support for DTMF generation.  The
+      <generate> element has no attributes.  The <generate> element has
+      a single child element, <dtmf-type>.  The <dtmf-type> element has
+      two attributes: 'name' and 'package'.  The 'name' attribute
+      provides the type of DTMF required and is a case-insensitive
+      string containing either 'RFC4733' [RFC4733] or 'Media'
+      (generating tones as signals in the audio stream).  The 'package'
+      attribute provides the name of the Media Control Channel Framework
+      package, compliant with Section 13.1.1 of [RFC6230], for which the
+      DTMF type applies.
+
+   <passthrough>:  Indicates the required support for passing DTMF
+      through without re-encoding.  The <passthrough> element has no
+      attributes.  The <passthrough> element then has a further child
+      element, <dtmf-type>.  The <dtmf-type> element has two attributes:
+      'name' and 'package'.  The 'name' attribute provides the type of
+      DTMF required and is a case-insensitive string containing either
+      'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
+      the audio stream).  The 'package' attribute provides the name of
+      the Media Control Channel Framework package, compliant with
+      Section 13.1.1 of [RFC6230], for which the DTMF type applies.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 42]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.5.1.2.4.  <tones>
+
+   The <tones> element provides requested tones that a Media Server must
+   support for IVR.  In particular, the request refers to both support
+   for country codes (ISO 3166-1 [ISO.3166-1]) and requested
+   functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).  The
+   element MAY be present.
+
+   The <tones> element has no attributes.
+
+   The <tones> element has zero or more of the following child elements:
+
+   <country-codes>:  Describes the requested country codes in relation
+      to tones.  The <country-codes> element has no attributes.  The
+      <country-codes> element has one child element.  The child element,
+      <country-code>, requests a specific country code, compliant with
+      the ISO 3166-1 [ISO.3166-1] specification.  The <country-code>
+      element has a single attribute, 'package'.  The attribute
+      'package' provides the name of the Media Control Channel Framework
+      package, compliant with Section 13.1.1 of [RFC6230], in which the
+      tones from the specified country code are requested.
+
+   <h248-codes>:  Describes the requested H.248 codes in relation to
+      tones.  The <h248-codes> element has no attributes.  The
+      <h248-codes> element has one child element.  The child element,
+      <h248-code>, requests a specific H.248 code, compliant with the
+      ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.  The
+      codes can be either specific (e.g., cg/dt to only report the Dial
+      Tone from the Call Progress Tones package) or generic (e.g., cg/*
+      to report all the tones from the Call Progress Tones package),
+      using wildcards.  The <h248-code> element has a single attribute,
+      'package'.  The attribute 'package' provides the name of the Media
+      Control Channel Framework package, compliant with Section 13.1.1
+      of [RFC6230], in which the specified codes are requested.
+
+5.2.5.1.2.5.  <asr-tts>
+
+   The <asr-tts> element requests information about the support for
+   Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
+   functionality in a Media Server.  The functionality is requested by
+   referring to the supported languages (using ISO 639-1 [ISO.639.2002]
+   codes) in relation to both ASR and TTS.  The <asr-tts> element has no
+   attributes.  The <asr-tts> element has zero or more of the following
+   child elements:
+
+   <asr-support>:  Describes the available languages for ASR.  The
+      <asr-support> element has no attributes.  The <asr-support>
+      element has one child element.  The child element, <language>,
+
+
+
+Boulton, et al.              Standards Track                   [Page 43]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      requests that the Media Server supports ASR for a specific
+      language.  The <language> element has a single attribute,
+      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
+      [ISO.639.2002] code of the supported language.
+
+   <tts-support>:  Describes the available languages for TTS.  The
+      <tts-support> element has no attributes.  The <tts-support>
+      element has one child element.  The child element, <language>,
+      requests that the Media Server supports TTS for a specific
+      language.  The <language> element has a single attribute,
+      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
+      [ISO.639.2002] code of the supported language.
+
+5.2.5.1.2.6.  <vxml>
+
+   The <vxml> element specifies if the Consumer client requires VoiceXML
+   and, if so, which protocols are supported (e.g., via the control
+   framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]).  The element
+   MAY be present.
+
+   The <vxml> element has a single child element:
+
+   <vxml-mode>:  Has two attributes: 'package' and 'require'.  The
+      'package' attribute provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the VXML support applies.  The 'require' attribute specifies
+      the type of VXML support required by the Consumer client (e.g.,
+      RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]),
+      and valid values are case-insensitive RFC references (e.g.,
+      "rfc6231" to specify that the client requests support for VoiceXML
+      as provided by the IVR Package [RFC6231]).
+
+   The presence of at least one <vxml> child element would indicate that
+   the Consumer client requires VXML support as specified by the child
+   element itself.  An empty <vxml> element would otherwise indicate
+   that the Consumer client does not require VXML support.
+
+5.2.5.1.2.7.  <location>
+
+   The <location> element requests a civic location for an IVR Media
+   Server.  The request makes use of the Civic Address Schema
+   standardized in RFC 5139 [RFC5139].  The element MAY be present.
+   More precisely, this section is entirely optional and is
+   implementation specific in its level of population.
+
+   The <location> element has no attributes.
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 44]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <location> element has a single child element:
+
+   <civicAddress>:  Describes the civic address location of the
+      requested Media Server, whose representation refers to Section 4
+      of RFC 5139 [RFC5139].
+
+5.2.5.1.2.8.  <encryption>
+
+   The <encryption> element allows a Consumer client to request support
+   for encrypting RTP media streams using RFC 3711 [RFC3711].  The
+   element MAY be present.  If the element is present, then the Media
+   Server supports DTLS-SRTP [RFC5763].
+
+   The <encryption> element has no attributes.
+
+   The <encryption> element has no child elements.
+
+5.2.5.1.2.9.  <application-data>
+
+   The <application-data> element provides an arbitrary string of
+   characters as IVR application-level data.  This data is meant to only
+   have meaning at the application-level logic and as such is not
+   otherwise restricted by this specification.  The set of allowed
+   characters is the same as those in XML (viz., tab, carriage return,
+   line feed, and the legal characters of Unicode and ISO/IEC 10646
+   [ISO.10646.2012] (see also Section 2.2 of
+   <http://www.w3.org/TR/xml/>)).  The element MAY be present.
+
+   The <application-data> element has no attributes.
+
+   The <application-data> element has no child elements.
+
+5.2.5.1.2.10.  <max-prepared-duration>
+
+   The <max-prepared-duration> element indicates the amount of time
+   required by the Consumer client representing media dialog preparation
+   in the system before it is executed.  The element MAY be present.
+
+   The <max-prepared-duration> element has no attributes.
+
+   The <max-prepared-duration> element has a single child element:
+
+   <max-time>:  Has a single attribute, 'max-time-seconds', which
+      provides the amount of time in seconds that a media dialog can be
+      in the prepared state.  The <max-time> element then has a further
+      child element, <max-time-package>.  The <max-time-package> element
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 45]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the time
+      period applies.
+
+5.2.5.1.2.11.  <file-transfer-modes>
+
+   The <file-transfer-modes> element allows the Consumer client to
+   specify which scheme names are required for file transfer to a Media
+   Server for each Media Control Channel Framework package type.  For
+   example, does the Media Server support fetching media resources via
+   HTTP, HTTPS, NFS, etc.?  The element MAY be present.
+
+   The <file-transfer-modes> element has no attributes.
+
+   The <file-transfer-modes> element has a single child element:
+
+   <file-transfer-mode>:  Has two attributes: 'name' and 'package'.  The
+      'name' attribute provides the scheme name of the protocol required
+      for fetching resources: valid values are case-insensitive scheme
+      names (e.g., HTTP, HTTPS, NFS, etc.).  The 'package' attribute
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the scheme
+      name applies.
+
+   The same considerations relating to file transfer and live streaming
+   are explained further in Section 5.1.5.15 and apply here as well.
+
+5.2.5.1.3.  <mixerInfo>
+
+   The <mixerInfo> element provides information for general Consumer
+   request information that is mixer specific.  The following
+   sub-sections describe the elements of the <mixerInfo> element:
+   <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>,
+   <application-data>, <location>, and <encryption>.
+
+5.2.5.1.3.1.  <mixers>
+
+   The <mixers> element provides information detailing the required
+   mixed RTP sessions.  The element MAY be present.
+
+   The <mixers> element has no attributes.
+
+   The <mixers> element has a single child element:
+
+   <mix>:  Describes the required mixed RTP sessions.  The <mix> element
+      has one attribute.  The value of the attribute, 'users', is the
+      number of participants required in the mix.  The <mix> element has
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 46]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      one child element.  The child element, <rtp-codec>, contains the
+      same information relating to RTP sessions as that defined in
+      Section 5.1.5.3.  The element MAY be present.
+
+5.2.5.1.3.2.  <file-formats>
+
+   The <file-formats> element provides a list of file formats required
+   by the Consumer client for the purpose of playing media to a mix.
+   The element MAY be present.
+
+   The <file-formats> element has no attributes.
+
+   The <file-formats> element has a single child element:
+
+   <required-format>:  Has a single attribute, 'name', which provides
+      the type of file format supported.  A valid value is a media type
+      that, depending on its definition, can include additional
+      parameters (e.g., [RFC6381]).  The <required-format> element has a
+      child element, <required-file-package>.  The
+      <required-file-package> element contains a single attribute,
+      'required-file-package-name', which contains the name of the Media
+      Control Channel Framework package, compliant with Section 13.1.1
+      of [RFC6230], for which the file format support applies.
+
+5.2.5.1.3.3.  <dtmf>
+
+   The <dtmf> element specifies the required methods to detect DTMF
+   tones and to generate them in a mix.  The element MAY be present.
+
+   The <dtmf> element has no attributes.
+
+   The <dtmf> element has zero or more of the following child elements:
+
+   <detect>:  Indicates the required support for DTMF detection.  The
+      <detect> element 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 and is a case-insensitive
+      string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
+      tones as signals from the audio stream).  The 'package' attribute
+      provides the name of the Media Control Channel Framework package,
+      compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+      type applies.
+
+   <generate>:  Indicates the required support for DTMF generation.  The
+      <generate> element has no attributes.  The <generate> element has
+      a single child element, <dtmf-type>.  The <dtmf-type> element has
+      two attributes: 'name' and 'package'.  The 'name' attribute
+
+
+
+Boulton, et al.              Standards Track                   [Page 47]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      provides the type of DTMF being used and is a case-insensitive
+      string containing either 'RFC4733' [RFC4733] or 'Media'
+      (generating tones as signals in the audio stream).  The 'package'
+      attribute provides the name of the Media Control Channel Framework
+      package, compliant with Section 13.1.1 of [RFC6230], for which the
+      DTMF type applies.
+
+   <passthrough>:  Indicates the required support for passing DTMF
+      through without re-encoding.  The <passthrough> element has no
+      attributes.  The <passthrough> element has a single child element,
+      <dtmf-type>.  The <dtmf-type> element has two attributes: 'name'
+      and 'package'.  The 'name' attribute provides the type of DTMF
+      being used and is a case-insensitive string containing either
+      'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
+      the audio stream).  The 'package' attribute provides the name of
+      the Media Control Channel Framework package, compliant with
+      Section 13.1.1 of [RFC6230], for which the DTMF type applies.
+
+5.2.5.1.3.4.  <tones>
+
+   The <tones> element provides requested tones that a Media Server must
+   support for a mix.  In particular, the request refers to both support
+   for country codes (ISO 3166-1 [ISO.3166-1]) and requested
+   functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).  The
+   element MAY be present.
+
+   The <tones> element has no attributes.
+
+   The <tones> element has zero or more of the following child elements:
+
+   <country-codes>:  Describes the requested country codes in relation
+      to tones.  The <country-codes> element has no attributes.  The
+      <country-codes> element has a single child element.  The child
+      element, <country-code>, requests a specific country code,
+      compliant with the ISO 3166-1 [ISO.3166-1] specification.  The
+      <country-code> element has a single attribute, 'package'.  The
+      attribute 'package' provides the name of the Media Control Channel
+      Framework package, compliant with the specification in the related
+      IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
+      specified country code are requested.
+
+   <h248-codes>:  Describes the requested H.248 codes with respect to
+      tones.  The <h248-codes> element has no attributes.  The
+      <h248-codes> element has a single child element.  The child
+      element, <h248-code>, requests a specific H.248 code, compliant
+      with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
+      The codes can be either specific (e.g., cg/dt to only report the
+      Dial Tone from the Call Progress Tones package) or generic (e.g.,
+
+
+
+Boulton, et al.              Standards Track                   [Page 48]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      cg/* to report all the tones from the Call Progress Tones
+      package), using wildcards.  The <h248-code> element has a single
+      attribute, 'package'.  The attribute 'package' provides the name
+      of the Media Control Channel Framework package, compliant with
+      Section 13.1.1 of [RFC6230], in which the specified codes are
+      requested.
+
+5.2.5.1.3.5.  <mixing-modes>
+
+   The <mixing-modes> element requests information relating to support
+   for audio and video mixing, more specifically a list of supported
+   algorithms to mix audio and a list of supported video presentation
+   layouts.  The element MAY be present.
+
+   The <mixing-modes> element has no attributes.
+
+   The <mixing-modes> element has zero or more of the following child
+   elements:
+
+   <audio-mixing-modes>:  Describes the requested algorithms for audio
+      mixing.  The <audio-mixing-modes> element has no attributes.  The
+      <audio-mixing-modes> element has one child element.  The child
+      element, <audio-mixing-mode>, contains a requested mixing
+      algorithm.  Valid values for the <audio-mixing-mode> element are
+      algorithm names, e.g., 'nbest' and 'controller' as defined in
+      [RFC6505].  The element has a single attribute, 'package'.  The
+      attribute 'package' provides the name of the Media Control Channel
+      Framework package, compliant with Section 13.1.1 of [RFC6230], for
+      which the algorithm support is requested.
+
+   <video-mixing-modes>:  Describes the requested video presentation
+      layouts for video mixing.  The <video-mixing-modes> element has
+      two attributes: 'vas' and 'activespeakermix'.  The 'vas' attribute
+      is of type boolean with a value of 'true' indicating that the
+      Consumer client requires automatic Voice Activated Switching.  The
+      'activespeakermix' attribute is of type boolean with a value of
+      'true' indicating that the Consumer client requires an additional
+      video stream for the loudest speaker participant without its
+      contribution.  The <video-mixing-modes> element has one child
+      element.  The child element, <video-mixing-mode>, contains the
+      name of a specific video presentation layout.  The name may refer
+      to one of the predefined video layouts defined in the XCON
+      conference information data model, or to non-XCON layouts as well,
+      as long as they are appropriately prefixed.  The
+      <video-mixing-mode> element has a single attribute, 'package'.
+      The attribute 'package' provides the name of the Media Control
+      Channel Framework package, compliant with Section 13.1.1 of
+      [RFC6230], for which the algorithm support is requested.
+
+
+
+Boulton, et al.              Standards Track                   [Page 49]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.5.1.3.6.  <application-data>
+
+   The <application-data> element provides an arbitrary string of
+   characters as mixer application-level data.  This data is meant to
+   only have meaning at the application-level logic and as such is not
+   otherwise restricted by this specification.  The set of allowed
+   characters is the same as those in XML (viz., tab, carriage return,
+   line feed, and the legal characters of Unicode and ISO/IEC 10646
+   [ISO.10646.2012] (see also Section 2.2 of
+   <http://www.w3.org/TR/xml/>)).  The element MAY be present.
+
+   The <application-data> element has no attributes.
+
+   The <application-data> element has no child elements.
+
+5.2.5.1.3.7.  <location>
+
+   The <location> element requests a civic location for a mixer Media
+   Server.  The request makes use of the Civic Address Schema
+   standardized in RFC 5139 [RFC5139].  The element MAY be present.
+   More precisely, this section is entirely optional, and it's
+   implementation specific to fill it with just the details each
+   implementer deems necessary for any optimization that may be needed.
+
+   The <location> element has no attributes.
+
+   The <location> element has a single child element:
+
+   <civicAddress>:  Describes the civic address location of the
+      requested Media Server, whose representation refers to Section 4
+      of RFC 5139 [RFC5139].
+
+5.2.5.1.3.8.  <encryption>
+
+   The <encryption> element allows a Consumer client to request support
+   for encrypting mixed RTP media streams using RFC 3711 [RFC3711].  The
+   element MAY be present.  If the element is present, then the Media
+   Server supports DTLS-SRTP [RFC5763].
+
+   The <encryption> element has no attributes.
+
+   The <encryption> element has no child elements.
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 50]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.2.6.  Media Service Resource Response
+
+   This section provides the element definitions for use in Consumer
+   interface responses.  The responses are carried in the
+   <mediaResourceResponse> element.
+
+5.2.6.1.  <mediaResourceResponse>
+
+   The <mediaResourceResponse> element provides information for clients
+   receiving response information from an external MRB entity.
+
+   The <mediaResourceResponse> element has two mandatory attributes:
+   'id' and 'status'.  The 'id' attribute must contain the same value
+   that the client provided in the 'id' attribute in the
+   <mediaResourceRequest> to which the response is mapped.  The 'status'
+   attribute indicates the status code of the operation.  The following
+   status codes are defined for 'status':
+
+   +-----------+-------------------------------------------------------+
+   | code      | description                                           |
+   +-----------+-------------------------------------------------------+
+   | 200       | OK                                                    |
+   |           |                                                       |
+   | 400       | Syntax error                                          |
+   |           |                                                       |
+   | 405       | Wrong sequence number                                 |
+   |           |                                                       |
+   | 408       | Unable to find Resource                               |
+   |           |                                                       |
+   | 409       | Unable to update Resource                             |
+   |           |                                                       |
+   | 410       | Unable to remove Resource                             |
+   |           |                                                       |
+   | 420       | Unsupported attribute or element                      |
+   +-----------+-------------------------------------------------------+
+
+               Table 2: <mediaResourceResponse> Status Codes
+
+   If a new media resource request made by a client application has been
+   accepted, the MRB MUST reply with a <mediaResourceResponse> with
+   status code 200.  The same rule applies whenever a request to update
+   (action='update') or remove (action='remove') an existing transaction
+   can be fulfilled by the MRB.
+
+   A media resource request, nevertheless, may fail for several reasons.
+   In such a case, the status codes defined in Table 2 must be used
+   instead.  Specifically, if the MRB fails to handle a request due to a
+   syntax error in the request itself (e.g., incorrect XML, violation of
+
+
+
+Boulton, et al.              Standards Track                   [Page 51]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   the schema constraints, or invalid values in any of the attributes/
+   elements), the MRB MUST reply with a <mediaResourceResponse> with
+   status code 400.  If a syntactically correct request fails because
+   the request also includes any attribute/element the MRB doesn't
+   understand, the MRB MUST reply with a <mediaResourceResponse> with
+   status code 420.  If a syntactically correct request fails because it
+   contains a wrong sequence number, that is, a 'seq' value not
+   consistent with the increment the MRB expects according to
+   Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with
+   status code 405.  If a syntactically correct request fails because
+   the MRB couldn't find any Media Server able to fulfill the
+   requirements presented by the Application Server in its request, the
+   MRB MUST reply with a <mediaResourceResponse> with status code 408.
+   If a syntactically correct request fails because the MRB couldn't
+   update an existing request according to the new requirements
+   presented by the Application Server in its request, the MRB MUST
+   reply with a <mediaResourceResponse> with status code 409.  If a
+   syntactically correct request fails because the MRB couldn't remove
+   an existing request and release the related resources as requested by
+   the Application Server, the MRB MUST reply with a
+   <mediaResourceResponse> with status code 410.
+
+   Further details on status codes 409 and 410 are included in
+   Section 5.2.3, where the leasing mechanism, along with its related
+   scenarios, is described in more detail.
+
+   The <mediaResourceResponse> element has <response-session-info> as a
+   child element.  This element is used to describe the response of a
+   Consumer interface query and is covered in the following sub-section.
+
+5.2.6.1.1.  <response-session-info>
+
+   The <response-session-info> element is included in Consumer
+   responses.  This applies to responses to both requests for new
+   resources and requests to update an existing media resource session.
+   The ability to change and remove an existing media resource session
+   is described in more detail in Section 5.2.3.  If the request was
+   successful, the <mediaResourceResponse> MUST have one
+   <response-session-info> child, which describes the media resource
+   session addressed by the request.  If the request was not successful,
+   the <mediaResourceResponse> MUST NOT have a <response-session-info>
+   child.
+
+   The <response-session-info> element has no attributes.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 52]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The <response-session-info> element has zero or more of the following
+   child elements:
+
+   <session-id>:  A unique identifier that explicitly references an
+      existing media resource session on the MRB.  The identifier is
+      included to update the existing session and is described in more
+      detail in Section 5.2.3.
+
+   <seq>:  Used in association with the <session-id> element in a
+      subsequent request to update an existing media resource session on
+      an MRB.  The <seq> number is incremented from its original value
+      returned in response to the initial request for media resources.
+      More information on its use is provided in Section 5.2.3.
+
+   <expires>:  Includes the number of seconds that the media resources
+      are reserved as part of this interaction.  If the lease is not
+      refreshed before expiry, the MRB will reclaim the resources and
+      they will no longer be guaranteed.  It is RECOMMENDED that a
+      minimum value of 300 seconds be used for the value of the
+      'expires' attribute.  It is also RECOMMENDED that a Consumer
+      client refresh the lease at an interval that is not too close to
+      the expiry time.  A value of 80% of the timeout period could be
+      used.  For example, if the timeout period is 300 seconds, the
+      Consumer client would refresh the transaction at 240 seconds.
+      More information on its use is provided in Section 5.2.3.
+
+   <media-server-address>:  Provides information to reach the Media
+      Server handling the requested media resource.  One or more
+      instances of these elements may appear.  The
+      <media-server-address> element has a single attribute named 'uri',
+      which supplies a SIP URI that reaches the specified Media Server.
+      It also has three optional elements: <connection-id>,
+      <ivr-sessions>, and <mixers>.  The <ivr-sessions> and <mixers>
+      elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1,
+      respectively, and have the same meaning but are applied to
+      individual Media Server instances as a subset of the overall
+      resources reported in the <connection-id> element.  If multiple
+      Media Servers are assigned in an IAMM operation, exactly one
+      <media-server-address> element, more specifically the Media Server
+      that provided the media dialog or CFW response, will have a
+      <connection-id> element.  Additional information relating to the
+      use of the <connection-id> element for media dialogs is included
+      in Section 6.
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 53]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5.3.  In-Line Unaware 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 In-line Unaware MRB Mode
+   (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of
+   operation.  This section further describes IUMM.
+
+   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 the Consumer
+   interface as discussed in Sections 5.2.1 (Query mode) and 5.2.2
+   (IAMM).  An MRB entity can also act in a client-unaware mode when
+   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 that in turn will select an appropriate Media
+   Server based on knowledge of Media Server resources it currently has
+   available transparently to the client entity.  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.
+
+   With IUMM, the MRB may conclude that an assigned media resource is no
+   longer needed when it receives a SIP BYE from the Application Server
+   or Media Server that ends the SIP dialog that initiated the request.
+
+   As with IAMM, in IUMM the SIP INVITE from the Application Server
+   could convey the application/sdp payload to either set up a media
+   dialog or a Control Framework Control Channel.  In either case, in
+   order to permit the Application Server to associate a media dialog
+   with a Control Channel to the same Media Server, using the procedures
+   of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and
+   not a B2BUA).  This allows the SIP URI of the targeted Media Server
+   to be transparently passed back to the Application Server in the SIP
+   response, resulting in a direct SIP dialog between the Application
+   Server and the Media Server.
+
+   While IUMM has the least impact on legacy Application Servers, it
+   also provides the least versatility.  See Section 8.
+
+6.  MRB Acting as a B2BUA
+
+   An MRB entity can act as a SIP Back-to-Back User Agent (B2BUA) or a
+   SIP Proxy Server as defined in RFC 3261 [RFC3261].  When an MRB acts
+   as a B2BUA, issues can arise when using Media Control Channel
+   packages such as the IVR [RFC6231] and mixer [RFC6505] packages.
+   Specifically, the framework attribute 'connectionid' as provided in
+
+
+
+Boulton, et al.              Standards Track                   [Page 54]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Appendix A ("Common Package Components") of [RFC6230] uses a
+   concatenation of the SIP dialog identifiers to be used for
+   referencing SIP dialogs within the Media Control Channel.  When a
+   request traverses an MRB acting as a B2BUA, the SIP dialog
+   identifiers change, and so the 'connectionid' cannot be used as
+   intended due to this change.  For this reason, when an MRB wishes to
+   act as a SIP B2BUA when handling a request from an Application Server
+   to set up a media dialog to a Media Server, it MUST include the
+   optional <connection-id> element in a Consumer interface response
+   with a value that provides the equivalent for the 'connectionid'
+   ('Local Dialog Tag' + 'Remote Dialog Tag') for the far side of the
+   B2BUA.  If present, this value MUST be used as the value for the
+   'connectionid' in packages where the Common Package Components are
+   used.  The <connection-id> element MUST NOT be included in an HTTP
+   Consumer interface response.
+
+   It is important to point out that although more Media Server
+   instances may be returned in a Consumer response (i.e., the MRB has
+   assigned more than one Media Server to a Consumer request to fulfill
+   the Application Server requirements), in IAMM the MRB will only act
+   as a B2BUA with a single Media Server.  In this case, exactly one
+   <media-server-address> element, describing the media dialog or CFW
+   response, will have a <connection-id> element that will not be
+   included in any additional <media-server-address> elements.
+
+7.  Multimodal MRB Implementations
+
+   An MRB implementation may operate multimodally with a collection of
+   Application Server clients all sharing the same pool of media
+   resources.  That is, an MRB may be simultaneously operating in Query
+   mode, IAMM, and IUMM.  It knows in which mode to act on any
+   particular request from a client, depending on the context of the
+   request:
+
+   o  If the received request is an HTTP POST message with application/
+      mrb-consumer+xml content, then the MRB processes it in Query mode.
+
+   o  If the received request is a SIP INVITE with application/
+      mrb-consumer+xml content and application/sdp content, then the MRB
+      processes it in IAMM.
+
+   o  If the received request is a SIP INVITE without application/
+      mrb-consumer+xml content but with application/sdp content, then
+      the MRB processes it in IUMM.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 55]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+8.  Relative Merits of Query Mode, IAMM, and IUMM
+
+   At a high level, the possible Application Server MRB interactions can
+   be distinguished by the following basic types:
+
+   a.  Query mode - the client is requesting the assignment by the MRB
+       of suitable Media Server resources;
+
+   b.  IAMM/media dialog - the client is requesting the assignment by
+       the MRB of suitable Media Server resources and the establishment
+       of a media dialog to one of the Media Servers;
+
+   c.  IAMM/Control Channel - the client is requesting the assignment by
+       the MRB of suitable Media Server resources and the establishment
+       of a CFW Control Channel to one of the Media Servers;
+
+   d.  IUMM/media dialog - the client is requesting the establishment of
+       a media dialog to a Media Server resource;
+
+   e.  IUMM/Control Channel - the client is requesting the establishment
+       of a CFW Control Channel to a Media Server resource.
+
+   Each type of interaction has advantages and disadvantages, where such
+   considerations relate to the versatility of what the MRB can provide,
+   technical aspects such as efficiency in different application
+   scenarios, complexity, delay, use with legacy Application Servers, or
+   use with the Media Control Channel Framework.  Depending on the
+   characteristics of a particular setting that an MRB is intended to
+   support, some of the above interaction types may be more appropriate
+   than others.  This section provides a few observations on relative
+   merits but is not intended to be exhaustive.  Some constraints of a
+   given interaction type may be subtle.
+
+   o  Operation with other types of media control: Any of the types of
+      interactions work with the mechanisms described in RFC 4240
+      [RFC4240] and RFC 5552 [RFC5552] where initial control
+      instructions are conveyed in the SIP INVITE from the Application
+      Server for the media dialog to the Media Server and subsequent
+      instructions may be fetched using HTTP.  Query mode (a), IAMM/
+      media dialog (b), and IUMM/media dialog (d) work with the Media
+      Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the
+      Media Server Control Markup Language (MSCML) as per RFC 5022
+      [RFC5022].
+
+   o  As stated previously, IUMM has no interface impacts on an
+      Application Server.  When using IUMM, the Application Server does
+      not specify the characteristics of the type of media resource it
+      requires, as the <mediaResourceRequest> element is not passed to
+
+
+
+Boulton, et al.              Standards Track                   [Page 56]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      the MRB.  For IUMM/media dialog (d), the MRB can deduce an
+      appropriate media resource on a best-effort basis using
+      information gleaned from examining information in the SIP INVITE.
+      This includes the SDP information for the media dialog, or initial
+      control information in the SIP Request-URI as per RFC 4240
+      [RFC4240].  With IUMM/Control Channel (e), there is even less
+      information for the MRB to use.
+
+   o  If using IUMM/Control Channel (e), the subsequent sending of the
+      media dialog to the Media Server should not be done using IUMM/
+      media dialog.  That is, the SIP signaling to send the media dialog
+      to the selected Media Server must be directly between the
+      Application Server and that Media Server, and not through the MRB.
+      Unless resources can be confidentially identified, the MRB could
+      send the media dialog to a different Media Server.  Likewise, if
+      using IUMM/media dialog (d), the subsequent establishment of a
+      Control Channel should not be done with IUMM/Control Channel (e)
+      unless definitive information is available.
+
+   o  Query mode (a) and IAMM/Control Channel (c) lend themselves to
+      requesting a pool of media resources (e.g., a number of IVR or
+      conferencing ports) in advance of use and retaining use over a
+      period of time, independent of whether there are media dialogs to
+      those resources at any given moment, whereas the other types of
+      interactions do not.  This also applies to making a subsequent
+      request to increase or decrease the amount of resources previously
+      awarded.
+
+   o  While Query mode (a) and IAMM/Control Channel (c) are the most
+      versatile interaction types, the former is completely decoupled
+      from the use or non-use of a Control Channel, whereas the latter
+      requires the use of a Control Channel.
+
+   o  When Media Control Channel Framework Control Channels are to be
+      used in conjunction with the use of an MRB, Query mode (a) would
+      typically result in fewer such channels being established over
+      time, as compared to IAMM/Control Channel (c).  That is because
+      the latter would involve setting up an additional Control Channel
+      every time an Application Server has a new request for an MRB for
+      media resources.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 57]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+9.  Examples
+
+   This section provides examples of both the Publish and Consumer
+   interfaces.  Both the Query mode and In-line mode are addressed.
+
+   Note that due to RFC formatting conventions, this section often
+   splits HTTP, SIP/SDP, and CFW across lines whose content would exceed
+   72 characters.  A backslash character marks where this line folding
+   has taken place.  This backslash, and its trailing CRLF and
+   whitespace, would not appear in the actual protocol contents.  Also
+   note that the indentation of the XML content is only provided for
+   readability: actual messages will follow strict XML syntax, which
+   allows for but does not require indentation.
+
+9.1.  Publish Example
+
+   The following example assumes that a Control Channel has been
+   established and synced as described in the Media Control Channel
+   Framework ([RFC6230]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 58]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Figure 9 shows the subscription/notification mechanism the Publish
+   interface is based on, as defined in Section 5.1.  The MRB subscribes
+   for information at the Media Server (message A1.), and the Media
+   Server accepts the subscription (A2.).  Notifications are triggered
+   by the Media Server (B1.) and acknowledged by the MRB (B2.).
+
+         MRB                                            MS
+          |                                              |
+          | A1. CONTROL (MRB subscription)               |
+          |--------------------------------------------->|
+          |                                   A2. 200 OK |
+          |<---------------------------------------------|
+          |                                              |
+          .                                              .
+          .                                              .
+          |                                              |
+          |                                              |--+ collect
+          |                                              |  | up-to-date
+          |                                              |<-+ info
+          |               B1. CONTROL (MRB notification) |
+          |<---------------------------------------------|
+          | B2. 200 OK                                   |
+          |--------------------------------------------->|
+          |                                              |
+          .                                              .
+          .                                              .
+
+                Figure 9: Publish Example: Sequence Diagram
+
+   The rest of this section includes a full dump of the messages
+   associated with the previous sequence diagram, specifically:
+
+   1.  the subscription (A1.), in an <mrbrequest> (CFW CONTROL);
+
+   2.  the Media Server accepting the subscription (A2.), in an
+       <mrbresponse> (CFW 200);
+
+   3.  a notification (B1.), in an <mrbnotification> (CFW CONTROL);
+
+   4.  the ack to the notification (B2.), in a framework-level 200
+       message (CFW 200).
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 59]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+A1. MRB -> MS (CONTROL, publish request)
+----------------------------------------
+CFW lidc30BZObiC CONTROL
+Control-Package: mrb-publish/1.0
+Content-Type: application/mrb-publish+xml
+Content-Length: 337
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
+    <mrbrequest>
+        <subscription action="create" seqnumber="1" id="p0T65U">
+            <expires>600</expires>
+            <minfrequency>20</minfrequency>
+            <maxfrequency>20</maxfrequency>
+        </subscription>
+    </mrbrequest>
+</mrbpublish>
+
+
+A2. MRB <- MS (200 to CONTROL, request accepted)
+------------------------------------------------
+CFW lidc30BZObiC 200
+Timeout: 10
+Content-Type: application/mrb-publish+xml
+Content-Length: 139
+
+<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
+        <mrbresponse status="200" reason="OK: Request accepted"/>
+</mrbpublish>
+
+
+B1. MRB <- MS (CONTROL, event notification from MS)
+---------------------------------------------------
+CFW 03fff52e7b7a CONTROL
+Control-Package: mrb-publish/1.0
+Content-Type: application/mrb-publish+xml
+Content-Length: 4226
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <mrbpublish version="1.0"
+             xmlns="urn:ietf:params:xml:ns:mrb-publish">
+    <mrbnotification seqnumber="1" id="QQ6J3c">
+        <media-server-id>a1b2c3d4</media-server-id>
+        <supported-packages>
+            <package name="msc-ivr/1.0"/>
+            <package name="msc-mixer/1.0"/>
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 60]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+            <package name="mrb-publish/1.0"/>
+            <package name="msc-example-pkg/1.0"/>
+        </supported-packages>
+        <active-rtp-sessions>
+            <rtp-codec name="audio/basic">
+                <decoding>10</decoding>
+                <encoding>20</encoding>
+            </rtp-codec>
+        </active-rtp-sessions>
+        <active-mixer-sessions>
+            <active-mix conferenceid="7cfgs43">
+                <rtp-codec name="audio/basic">
+                    <decoding>3</decoding>
+                    <encoding>3</encoding>
+                </rtp-codec>
+            </active-mix>
+        </active-mixer-sessions>
+        <non-active-rtp-sessions>
+            <rtp-codec name="audio/basic">
+                <decoding>50</decoding>
+                <encoding>40</encoding>
+            </rtp-codec>
+        </non-active-rtp-sessions>
+        <non-active-mixer-sessions>
+            <non-active-mix available="15">
+                <rtp-codec name="audio/basic">
+                    <decoding>15</decoding>
+                    <encoding>15</encoding>
+                </rtp-codec>
+            </non-active-mix>
+        </non-active-mixer-sessions>
+        <media-server-status>active</media-server-status>
+        <supported-codecs>
+            <supported-codec name="audio/basic">
+                <supported-codec-package name="msc-ivr/1.0">
+                    <supported-action>encoding</supported-action>
+                    <supported-action>decoding</supported-action>
+                </supported-codec-package>
+                <supported-codec-package name="msc-mixer/1.0">
+                    <supported-action>encoding</supported-action>
+                    <supported-action>decoding</supported-action>
+                </supported-codec-package>
+            </supported-codec>
+        </supported-codecs>
+        <application-data>TestbedPrototype</application-data>
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 61]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+        <file-formats>
+            <supported-format name="audio/x-wav">
+                <supported-file-package>
+                    msc-ivr/1.0
+                </supported-file-package>
+            </supported-format>
+        </file-formats>
+        <max-prepared-duration>
+            <max-time max-time-seconds="3600">
+                <max-time-package>msc-ivr/1.0</max-time-package>
+            </max-time>
+        </max-prepared-duration>
+        <dtmf-support>
+            <detect>
+                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+            </detect>
+            <generate>
+                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+            </generate>
+            <passthrough>
+                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+            </passthrough>
+        </dtmf-support>
+        <mixing-modes>
+            <audio-mixing-modes>
+                <audio-mixing-mode package="msc-ivr/1.0">
+                     nbest
+                </audio-mixing-mode>
+            </audio-mixing-modes>
+            <video-mixing-modes activespeakermix="true" vas="true">
+                <video-mixing-mode package="msc-mixer/1.0">
+                     single-view
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     dual-view
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     dual-view-crop
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     dual-view-2x1
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     dual-view-2x1-crop
+                </video-mixing-mode>
+
+
+
+Boulton, et al.              Standards Track                   [Page 62]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+                <video-mixing-mode package="msc-mixer/1.0">
+                     quad-view
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     multiple-5x1
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     multiple-3x3
+                </video-mixing-mode>
+                <video-mixing-mode package="msc-mixer/1.0">
+                     multiple-4x4
+                </video-mixing-mode>
+            </video-mixing-modes>
+        </mixing-modes>
+        <supported-tones>
+            <supported-country-codes>
+                <country-code package="msc-ivr/1.0">GB</country-code>
+                <country-code package="msc-ivr/1.0">IT</country-code>
+                <country-code package="msc-ivr/1.0">US</country-code>
+            </supported-country-codes>
+            <supported-h248-codes>
+                <h248-code package="msc-ivr/1.0">cg/*</h248-code>
+                <h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
+                <h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
+                <h248-code package="msc-mixer/1.0">conftn/*</h248-code>
+            </supported-h248-codes>
+        </supported-tones>
+        <file-transfer-modes>
+            <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+        </file-transfer-modes>
+        <asr-tts-support>
+            <asr-support>
+                <language xml:lang="en"/>
+            </asr-support>
+            <tts-support>
+                <language xml:lang="en"/>
+            </tts-support>
+        </asr-tts-support>
+        <vxml-support>
+            <vxml-mode package="msc-ivr/1.0" support="RFC6231"/>
+        </vxml-support>
+        <media-server-location>
+            <civicAddress xml:lang="it">
+                <country>IT</country>
+                <A1>Campania</A1>
+                <A3>Napoli</A3>
+                <A6>Via Claudio</A6>
+                <HNO>21</HNO>
+
+
+
+Boulton, et al.              Standards Track                   [Page 63]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+                <LMK>University of Napoli Federico II</LMK>
+                <NAM>Dipartimento di Informatica e Sistemistica</NAM>
+                <PC>80210</PC>
+            </civicAddress>
+        </media-server-location>
+        <label>TestbedPrototype-01</label>
+     <media-server-address>sip:MS1@ms.example.net</media-server-address>
+     <encryption/>
+    </mrbnotification>
+   </mrbpublish>
+
+
+B2. MRB -> MS (200 to CONTROL)
+------------------------------
+CFW 03fff52e7b7a 200
+
+9.2.  Consumer Examples
+
+   As specified in Section 5.2, the Consumer interface can be involved
+   in two different modes: Query and In-line aware.  When in Query mode,
+   Consumer messages are transported in HTTP messages: an example of
+   such an approach is presented in Section 9.2.1.  When in In-line
+   aware mode, messages are instead transported as part of SIP
+   negotiations: considering that SIP negotiations may be related to
+   either the creation of a Control Channel or to a User Agent Client
+   (UAC) media dialog, two separate examples of such an approach are
+   presented in Section 9.2.2.
+
+9.2.1.  Query Example
+
+   The following example assumes that the interested Application Server
+   already knows the HTTP URL where an MRB is listening for Consumer
+   messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 64]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Figure 10 shows the HTTP-based transaction between the Application
+   Server (AS, as shown in the figure) and the MRB.  The Application
+   Server sends a Consumer request as payload of an HTTP POST message
+   (1.), and the MRB provides an answer in an HTTP 200 OK message (2.).
+   Specifically, as will be shown in the examples, the Application
+   Server is interested in 100 IVR ports: the MRB finds two Media
+   Servers that can satisfy the request (one providing 60 ports and the
+   other providing 40 ports) and reports them to the Application Server.
+
+     AS                                             MRB
+      |                                              |
+      | 1. HTTP POST (Consumer request)              |
+      |--------------------------------------------->|
+      |                                              |
+      |                                              |
+      |                                              |--+ Parse request
+      |                                              |  | and see if any
+      |                                              |<-+ MS applies
+      |                                              |
+      |                2. 200 OK (Consumer response) |
+      |<---------------------------------------------|
+      |                                              |
+      |--+ Parse response and                        |
+      |  | start session (SIP/COMEDIA/CFW)           |
+      |<-+ with first MS reported by MRB             |
+      |                                              |
+      .                                              .
+      .                                              .
+
+           Figure 10: Consumer Example (Query): Sequence Diagram
+
+   The rest of this section includes a full dump of the messages
+   associated with the previous sequence diagram, specifically:
+
+   1.  the Consumer request (1.), in a <mediaResourceRequest> (HTTP
+       POST, Content-Type 'application/mrb-consumer+xml');
+
+   2.  the Consumer response (2.), in a <mediaResourceResponse> (HTTP
+       200 OK, Content-Type 'application/mrb-consumer+xml').
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 65]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+1. AS -> MRB (HTTP POST, Consumer request)
+------------------------------------------
+POST /Mrb/Consumer HTTP/1.1
+Content-Length: 893
+Content-Type: application/mrb-consumer+xml
+Host: mrb.example.net:8080
+Connection: Keep-Alive
+User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
+    <mediaResourceRequest id="gh11x23v">
+        <generalInfo>
+            <packages>
+                <package>msc-ivr/1.0</package>
+                <package>msc-mixer/1.0</package>
+            </packages>
+        </generalInfo>
+        <ivrInfo>
+            <ivr-sessions>
+                <rtp-codec name="audio/basic">
+                    <decoding>100</decoding>
+                    <encoding>100</encoding>
+                </rtp-codec>
+            </ivr-sessions>
+            <file-formats>
+                <required-format name="audio/x-wav"/>
+            </file-formats>
+            <file-transfer-modes>
+                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+            </file-transfer-modes>
+        </ivrInfo>
+    </mediaResourceRequest>
+</mrbconsumer>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 66]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+2. AS <- MRB (200 to POST, Consumer response)
+---------------------------------------------
+HTTP/1.1 200 OK
+X-Powered-By: Servlet/2.5
+Server: Sun GlassFish Communications Server 1.5
+Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
+Content-Length: 1133
+Date: Mon, 12 Apr 2011 14:59:26 GMT
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
+    <mediaResourceResponse reason="Resource found" status="200"
+                           id="gh11x23v">
+        <response-session-info>
+            <session-id>5t3Y4IQ84gY1</session-id>
+            <seq>9</seq>
+            <expires>3600</expires>
+            <media-server-address
+                              uri="sip:MediaServer@ms.example.com:5080">
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+                        <decoding>60</decoding>
+                        <encoding>60</encoding>
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+            <media-server-address
+                       uri="sip:OtherMediaServer@pool.example.net:5080">
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+                        <decoding>40</decoding>
+                        <encoding>40</encoding>
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+        </response-session-info>
+    </mediaResourceResponse>
+</mrbconsumer>
+
+   As the example shows, the request and response are associated by
+   means of the 'id' attribute (id="gh11x23v").  The MRB has picked '9'
+   as the random sequence number that needs to be incremented by the
+   Application Server for the subsequent request associated with the
+   same session.
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 67]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The rest of the scenario is omitted for brevity.  After having
+   received the 'mediaResourceResponse', the Application Server has the
+   URIs of two Media Servers able to fulfill its media requirements and
+   can start a control dialog with one or both of them.
+
+9.2.2.  IAMM Examples
+
+   Two separate examples are presented for the IAMM case: in fact, IAMM
+   can take advantage of two different approaches with respect to the
+   SIP dialogs to be exploited to carry Consumer messages, i.e., i) a
+   SIP control dialog to create a Control Channel, and ii) a UAC media
+   dialog to attach to a Media Server.  To make things clearer for the
+   reader, the same Consumer request as the one presented in the Query
+   mode will be sent, in order to clarify how the behavior of the
+   involved parties may differ.
+
+9.2.2.1.  IAMM Example: CFW-Based Approach
+
+   The following example assumes that the interested Application Server
+   already knows the SIP URI of an MRB.
+
+   Figure 11 shows the first approach, i.e., SIP-based transactions
+   between the Application Server, the MRB, and one Media Server that
+   the MRB chooses from the two that are allocated to fulfill the
+   request.  The diagram is more complex than before.  This is basically
+   a scenario envisaging the MRB as a B2BUA.  The Application Server
+   sends a SIP INVITE (1.) containing both a CFW-related SDP and a
+   Consumer request (multipart body).  The MRB sends a provisional
+   response to the Application Server (2.) and starts working on the
+   request.  First of all, it makes use of the Consumer request from the
+   Application Server to determine which Media Servers should be
+   exploited.  Once the right Media Servers have been chosen (MS1 and
+   MS2 in the example), the MRB sends a new SIP INVITE (3.) to one of
+   the Media Servers (MS1 in the example) by just including the SDP part
+   of the original request.  That Media Server negotiates this INVITE as
+   specified in [RFC6230] (4., 5., 6.), providing the MRB with its own
+   CFW-related SDP.  The MRB replies to the original Application Server
+   INVITE preparing a SIP 200 OK with another multipart body (7.): this
+   multipart body includes the Consumer response used by the MRB to
+   determine the right Media Servers and the SDP returned by the Media
+   Server (MS1) in (5.).  The Application Server finally acknowledges
+   the 200 OK (8.), and can start a CFW connection towards that Media
+   Server (MS1).  Since the MRB provided the Application Server with two
+   Media Server instances to fulfill its requirements, the Application
+   Server can use the URI in the <media-server-address> element in the
+   <mediaResourceResponse> that describes the other Media Server to
+   establish a CFW channel with that Media Server (MS2) as well.
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 68]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Please note that to ease the reading of the protocol contents a
+   simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
+   payload is provided, instead of the actual boundary that would be
+   inserted in the SIP messages.
+
+  AS                     MRB                        MS1              MS2
+  |                       |                           |                |
+  | 1. INVITE             |                           |                |
+  | (multipart/mixed)     |                           |                |
+  |---------------------->|                           |                |
+  |       2. 100 (Trying) |                           |                |
+  |<----------------------|                           |                |
+  |                       |--+ Extract SDP and        |                |
+  |                       |  | MRB payloads; handle   |                |
+  |                       |<-+ Consumer request to    |                |
+  |                       |    pick MSs (MS1 and MS2) |                |
+  |                       |                           |                |
+  |                       | 3. INVITE                 |                |
+  |                       | (only copy SDP from 1.)   |                |
+  |                       |-------------------------->|                |
+  |                       |           4. 100 (Trying) |                |
+  |                       |<--------------------------|                |
+  |                       |                           |--+ Negotiate   |
+  |                       |                           |  | CFW Control |
+  |                       |                           |<-+ Channel     |
+  |                       |                 5. 200 OK |                |
+  |                       |<--------------------------|                |
+  |                       | 6. ACK                    |                |
+  |                       |-------------------------->|                |
+  |        Prepare new +--|                           |                |
+  |       payload with |  |                           |                |
+  |    SDP from MS and +->|                           |                |
+  |     Consumer reply    |                           |                |
+  |                       |                           |                |
+  |             7. 200 OK |                           |                |
+  |     (multipart/mixed) |                           |                |
+  |<----------------------|                           |                |
+  | 8. ACK                |                           |                |
+  |---------------------->|                           |                |
+  |                       |                           |                |
+  |--+ Read Cons. reply   |                           |                |
+  |  | and use SDP to     |                           |                |
+  |<-+ create CFW Chn.    |                           |                |
+  |                       |                           |                |
+  |                                                   |                |
+  |   Create TCP CFW channel towards MS1 (if needed)  |                |
+  |-------------------------------------------------->|                |
+  |                                                   |                |
+
+
+
+Boulton, et al.              Standards Track                   [Page 69]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  |<<############## TCP CONNECTION #################>>|                |
+  |                                                   |                |
+  | CFW SYNC                                          |                |
+  |++++++++++++++++++++++++++++++++++++++++++++++++++>|                |
+  |                                                   |                |
+  .                       .                           .                .
+  .                       .                           .                .
+  |                                                   |                |
+  |   Negotiate SIP control dialog with MS2                            |
+  |<------------------------------------------------------------------>|
+  |   Create TCP CFW channel towards MS2 as well (if needed)           |
+  |------------------------------------------------------------------->|
+  |                                                                    |
+  |<<######################## TCP CONNECTION ########################>>|
+  |                                                                    |
+  | CFW SYNC                                                           |
+  |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
+  |                                                                    |
+  |                       |                           |                |
+  .                       .                           .                .
+  .                       .                           .                .
+
+   Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram
+
+   The rest of this section includes an almost full trace of the
+   messages associated with the previous sequence diagram.  Only the
+   relevant SIP messages are shown (both the INVITEs and the 200 OKs),
+   and only the relevant headers are preserved for brevity (Content-Type
+   and multipart-related information).  Specifically:
+
+   1.  the original INVITE (1.) containing both a CFW-related SDP
+       (Connection-Oriented Media (COMEDIA) information to negotiate a
+       new Control Channel) and a Consumer <mediaResourceRequest>;
+
+   2.  the INVITE sent by the MRB (acting as a B2BUA) to the Media
+       Server (3.), containing only the CFW-related SDP from the
+       original INVITE;
+
+   3.  the 200 OK sent by the Media Server back to the MRB (5.) to
+       complete the CFW-related negotiation (SDP only);
+
+   4.  the 200 OK sent by the MRB back to the Application Server in
+       response to the original INVITE (7.), containing both the
+       CFW-related information sent by the Media Server and a Consumer
+       <mediaResourceRequest> documenting the MRB's decision to use that
+       Media Server.
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 70]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+1. AS -> MRB (INVITE multipart/mixed)
+-------------------------------------
+   [..]
+   Content-Type: multipart/mixed;boundary="=_Part"
+
+   =_Part
+   Content-Type: application/sdp
+
+   v=0
+   o=- 2890844526 2890842807 IN IP4 as.example.com
+   s=MediaCtrl
+   c=IN IP4 as.example.com
+   t=0 0
+   m=application 48035 TCP cfw
+   a=connection:new
+   a=setup:active
+   a=cfw-id:vF0zD4xzUAW9
+   a=ctrl-package:msc-mixer/1.0
+   a=ctrl-package:msc-ivr/1.0
+
+   =_Part
+   Content-Type: application/mrb-consumer+xml
+
+   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <mrbconsumer version="1.0"
+                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
+    <mediaResourceRequest id="pz78hnq1">
+        <generalInfo>
+            <packages>
+                <package>msc-ivr/1.0</package>
+                <package>msc-mixer/1.0</package>
+            </packages>
+        </generalInfo>
+        <ivrInfo>
+            <ivr-sessions>
+                <rtp-codec name="audio/basic">
+                    <decoding>100</decoding>
+                    <encoding>100</encoding>
+                </rtp-codec>
+            </ivr-sessions>
+            <file-formats>
+                <required-format name="audio/x-wav"/>
+            </file-formats>
+            <file-transfer-modes>
+                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+            </file-transfer-modes>
+        </ivrInfo>
+    </mediaResourceRequest>
+
+
+
+Boulton, et al.              Standards Track                   [Page 71]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </mrbconsumer>
+
+   =_Part
+
+
+3. MRB -> MS (INVITE sdp only)
+------------------------------
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=- 2890844526 2890842807 IN IP4 as.example.com
+   s=MediaCtrl
+   c=IN IP4 as.example.com
+   t=0 0
+   m=application 48035 TCP cfw
+   a=connection:new
+   a=setup:active
+   a=cfw-id:vF0zD4xzUAW9
+   a=ctrl-package:msc-mixer/1.0
+   a=ctrl-package:msc-ivr/1.0
+
+
+5. MRB <- MS (200 OK sdp)
+-------------------------
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
+   s=MediaCtrl
+   c=IN IP4 ms.example.net
+   t=0 0
+   m=application 7575 TCP cfw
+   a=connection:new
+   a=setup:passive
+   a=cfw-id:vF0zD4xzUAW9
+   a=ctrl-package:msc-mixer/1.0
+   a=ctrl-package:msc-ivr/1.0
+   a=ctrl-package:mrb-publish/1.0
+   a=ctrl-package:msc-example-pkg/1.0
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 72]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+7. AS <- MRB (200 OK multipart/mixed)
+-------------------------------------
+   [..]
+   Content-Type: multipart/mixed;boundary="=_Part"
+
+   =_Part
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
+   s=MediaCtrl
+   c=IN IP4 ms.example.net
+   t=0 0
+   m=application 7575 TCP cfw
+   a=connection:new
+   a=setup:passive
+   a=cfw-id:vF0zD4xzUAW9
+   a=ctrl-package:msc-mixer/1.0
+   a=ctrl-package:msc-ivr/1.0
+   a=ctrl-package:mrb-publish/1.0
+   a=ctrl-package:msc-example-pkg/1.0
+
+   =_Part
+   Content-Type: application/mrb-consumer+xml
+
+   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <mrbconsumer version="1.0"
+                xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
+    <mediaResourceResponse reason="Resource found" status="200"
+                           id="pz78hnq1">
+        <response-session-info>
+            <session-id>z1skKYZQ3eFu</session-id>
+            <seq>9</seq>
+            <expires>3600</expires>
+            <media-server-address
+                              uri="sip:MediaServer@ms.example.com:5080">
+                <connection-id>32pbdxZ8:KQw677BF</connection-id>
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+                        <decoding>60</decoding>
+                        <encoding>60</encoding>
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+            <media-server-address
+                       uri="sip:OtherMediaServer@pool.example.net:5080">
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+
+
+
+Boulton, et al.              Standards Track                   [Page 73]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+                        <decoding>40</decoding>
+                        <encoding>40</encoding>
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+        </response-session-info>
+    </mediaResourceResponse>
+   </mrbconsumer>
+
+   =_Part
+
+   As the previous example illustrates, the only difference in the
+   response that the MRB provides to the Application Server is in the
+   'connection-id' attribute that is added to the first allocated Media
+   Server instance: this allows the Application Server to understand
+   that the MRB has sent the CFW channel negotiation to that specific
+   Media Server and that the connection-id to be used is the one
+   provided.  This will be described in more detail in the following
+   section for the media dialog-based approach.
+
+   The continuation of the scenario (the Application Server connecting
+   to MS1 to start the Control Channel and the related SYNC message, the
+   Application Server connecting to MS2 as well later on, all the media
+   dialogs being attached to either Media Server) is omitted for
+   brevity.
+
+9.2.2.2.  IAMM Example: Media Dialog-Based Approach
+
+   The following example assumes that the interested Application Server
+   already knows the SIP URI of an MRB.
+
+   Figure 12 shows the second approach, i.e., SIP-based transactions
+   between a SIP client, the Application Server, the MRB, and the Media
+   Server that the MRB chooses.  The interaction is basically the same
+   as previous examples (e.g., contents of the multipart body), but
+   considering that a new party is involved in the communication, the
+   diagram is slightly more complex than before.  As before, the MRB
+   acts as a B2BUA.  A UAC sends a SIP INVITE to a SIP URI handled by
+   the Application Server, since it is interested to its services (1.).
+   The Application Server sends a provisional response (2.) and, since
+   it doesn't have the resources yet, sends to the MRB a new SIP INVITE
+   (3.) containing both the UAC media-related SDP and a Consumer request
+   (multipart body).  The MRB sends a provisional response to the
+   Application Server (4.) and starts working on the request.  First of
+   all, it makes use of the Consumer request from the Application Server
+   to determine which Media Servers should be chosen.  Once the Media
+   Server has been chosen, the MRB sends a new SIP INVITE to one of the
+   Media Servers by including the SDP part of the original request (5.).
+
+
+
+Boulton, et al.              Standards Track                   [Page 74]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   The Media Server negotiates this INVITE as specified in [RFC6230]
+   (6., 7., 8.) to allocate the needed media resources to handle the new
+   media dialog, eventually providing the MRB with its own media-related
+   SDP.  The MRB replies to the original Application Server INVITE
+   preparing a SIP 200 OK with a multipart body (9.): this multipart
+   body includes the Consumer response from the MRB indicating the
+   chosen Media Servers and the SDP returned by the Media Server in
+   (7.).  The Application Server finally acknowledges the 200 OK (10.)
+   and ends the scenario by eventually providing the UAC with the SDP it
+   needs to set up the RTP channels with the chosen Media Server: a
+   separate direct SIP control dialog may be initiated by the
+   Application Server to the same Media Server in order to set up a
+   Control Channel to manipulate the media dialog.
+
+   As with the IAMM/Control Channel example in the prior section, this
+   example has the MRB selecting Media Server resources across two Media
+   Server instances.  The convention could be that the MRB sent the SIP
+   INVITE to the first Media Server in the list provided to the
+   Application Server in the Consumer response information.  For the
+   sake of brevity, considerations related to connecting to the other
+   Media Servers as well are omitted, since they have already been
+   addressed in the previous section.
+
+   Please note that to ease the reading of the protocol contents, a
+   simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
+   payload is provided, instead of the actual boundary that would be
+   inserted in the SIP messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 75]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ UAC              AS                     MRB                          MS
+  |               |                       |                           |
+  | 1. INVITE     |                       |                           |
+  | (media SDP)   |                       |                           |
+  |-------------->|                       |                           |
+  | 2. 100 Trying |                       |                           |
+  |<--------------|                       |                           |
+  |               | 3. INVITE             |                           |
+  |               | (multipart/mixed)     |                           |
+  |               |---------------------->|                           |
+  |               |       4. 100 (Trying) |                           |
+  |               |<----------------------|                           |
+  |               |                       |--+ Extract SDP and        |
+  |               |                       |  | MRB payloads; handle   |
+  |               |                       |<-+ Consumer request to    |
+  |               |                       |    pick Media Servers     |
+  |               |                       |                           |
+  |               |                       | 5. INVITE                 |
+  |               |                       | (only copy SDP from 3.)   |
+  |               |                       |-------------------------->|
+  |               |                       |           6. 100 (Trying) |
+  |               |                       |<--------------------------|
+  |               |                       |                        +--|
+  |               |                       |    Handle media dialog |  |
+  |               |                       |        (connection-id) +->|
+  |               |                       |                           |
+  |               |                       |                 7. 200 OK |
+  |               |                       |<--------------------------|
+  |               |                       | 8. ACK                    |
+  |               |                       |-------------------------->|
+  |               |        Prepare new +--|                           |
+  |               |       payload with |  |                           |
+  |               |    SDP from MS and +->|                           |
+  |               |     Consumer reply    |                           |
+  |               |                       |                           |
+  |               |             9. 200 OK |                           |
+  |               |     (multipart/mixed) |                           |
+  |               |<----------------------|                           |
+  |               | 10. ACK               |                           |
+  |               |---------------------->|                           |
+  |               |                       |                           |
+  |               |--+ Read Cons. reply   |                           |
+  |               |  | and send SDP       |                           |
+  |               |<-+ back to UAC        |                           |
+  |    11. 200 OK |                       |                           |
+  |<--------------|                       |                           |
+  | 12. ACK       |                       |                           |
+  |-------------->|                       |                           |
+
+
+
+Boulton, et al.              Standards Track                   [Page 76]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  |               |                       |                           |
+  |<<*************************** RTP *******************************>>|
+  |               |                       |                           |
+  |               |--+ Negotiate          |                           |
+  |               |  | CFW channel        |                           |
+  |               |<-+ towards MS         |                           |
+  |               |    (if needed)        |                           |
+  .               .                       .                           .
+  .               .                       .                           .
+  |               |                       |                           |
+  |               |                                                   |
+  |               |    Create TCP CFW channel towards MS (if needed)  |
+  |               |-------------------------------------------------->|
+  |               |                                                   |
+  |               |<<############## TCP CONNECTION #################>>|
+  |               |                                                   |
+  |               | CFW SYNC                                          |
+  |               |++++++++++++++++++++++++++++++++++++++++++++++++++>|
+  |               |                                                   |
+  .               .                       .                           .
+  .               .                       .                           .
+
+     Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram
+
+   The rest of this section includes a trace of the messages associated
+   with the previous sequence diagram.  Only the relevant SIP messages
+   are shown (both the INVITEs and the 200 OKs), and only the relevant
+   headers are preserved for brevity (Content-Type, From/To, and
+   multipart-related information).  Specifically:
+
+   1.  the original INVITE (1.) containing the media-related SDP sent by
+       a UAC;
+
+   2.  the INVITE sent by the AS to the MRB (3.), containing both the
+       media-related SDP and a Consumer <mediaResourceRequest>;
+
+   3.  the INVITE sent by the MRB (acting as a B2BUA) to the Media
+       Server (5.), containing only the media-related SDP from the
+       original INVITE;
+
+   4.  the 200 OK sent by the Media Server back to the MRB (7.) to
+       complete the media-related negotiation (SDP only);
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 77]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   5.  the 200 OK sent by the MRB back to the Application Server in
+       response to the original INVITE (9.), containing both the
+       media-related information sent by the Media Server and a Consumer
+       <mediaResourceRequest> documenting the MRB's decision to use that
+       Media Server;
+
+   6.  the 200 OK sent by the Application Server back to the UAC to have
+       it set up the RTP channel(s) with the Media Server (11.).
+
+
+1. UAC -> AS (INVITE with media SDP)
+------------------------------------
+   [..]
+   From: <sip:lminiero@users.example.com>;tag=1153573888
+   To: <sip:mediactrlDemo@as.example.com>
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654321 IN IP4 203.0.113.2
+   s=A conversation
+   c=IN IP4 203.0.113.2
+   t=0 0
+   m=audio 7078 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000/1
+   a=rtpmap:3 GSM/8000/1
+   a=rtpmap:8 PCMA/8000/1
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-11
+   m=video 9078 RTP/AVP 98
+
+
+3. AS -> MRB (INVITE multipart/mixed)
+-------------------------------------
+   [..]
+   From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
+   To: <sip:Mrb@mrb.example.org>
+   [..]
+   Content-Type: multipart/mixed;boundary="=_Part"
+
+   =_Part
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654321 IN IP4 203.0.113.2
+   s=A conversation
+   c=IN IP4 203.0.113.2
+   t=0 0
+
+
+
+Boulton, et al.              Standards Track                   [Page 78]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   m=audio 7078 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000/1
+   a=rtpmap:3 GSM/8000/1
+   a=rtpmap:8 PCMA/8000/1
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-11
+   m=video 9078 RTP/AVP 98
+
+   =_Part
+   Content-Type: application/mrb-consumer+xml
+
+   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <mrbconsumer version="1.0"
+                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
+    <mediaResourceRequest id="ns56g1x0">
+        <generalInfo>
+            <packages>
+                <package>msc-ivr/1.0</package>
+                <package>msc-mixer/1.0</package>
+            </packages>
+        </generalInfo>
+        <ivrInfo>
+            <ivr-sessions>
+                <rtp-codec name="audio/basic">
+                    <decoding>100</decoding>
+                    <encoding>100</encoding>
+                </rtp-codec>
+            </ivr-sessions>
+            <file-formats>
+                <required-format name="audio/x-wav"/>
+            </file-formats>
+            <file-transfer-modes>
+                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+            </file-transfer-modes>
+        </ivrInfo>
+    </mediaResourceRequest>
+   </mrbconsumer>
+
+   =_Part
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 79]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+5. MRB -> MS (INVITE sdp only)
+------------------------------
+   [..]
+   From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
+   To: <sip:MediaServer@ms.example.com:5080>
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654321 IN IP4 203.0.113.2
+   s=A conversation
+   c=IN IP4 203.0.113.2
+   t=0 0
+   m=audio 7078 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000/1
+   a=rtpmap:3 GSM/8000/1
+   a=rtpmap:8 PCMA/8000/1
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-11
+   m=video 9078 RTP/AVP 98
+
+
+7. MRB <- MS (200 OK sdp)
+-------------------------
+   [..]
+   From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
+   To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654322 IN IP4 203.0.113.1
+   s=MediaCtrl
+   c=IN IP4 203.0.113.1
+   t=0 0
+   m=audio 63442 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000
+   a=rtpmap:3 GSM/8000
+   a=rtpmap:8 PCMA/8000
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-15
+   a=ptime:20
+   a=label:7eda834
+   m=video 33468 RTP/AVP 98
+   a=rtpmap:98 H263-1998/90000
+   a=fmtp:98 CIF=2
+   a=label:0132ca2
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 80]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+9. AS <- MRB (200 OK multipart/mixed)
+-------------------------------------
+   [..]
+   From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
+   To: <sip:Mrb@mrb.example.org>;tag=117652221
+   [..]
+   Content-Type: multipart/mixed;boundary="=_Part"
+
+   =_Part
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654322 IN IP4 203.0.113.1
+   s=MediaCtrl
+   c=IN IP4 203.0.113.1
+   t=0 0
+   m=audio 63442 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000
+   a=rtpmap:3 GSM/8000
+   a=rtpmap:8 PCMA/8000
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-15
+   a=ptime:20
+   a=label:7eda834
+   m=video 33468 RTP/AVP 98
+   a=rtpmap:98 H263-1998/90000
+   a=fmtp:98 CIF=2
+   a=label:0132ca2
+
+   =_Part
+   Content-Type: application/mrb-consumer+xml
+
+   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <mrbconsumer version="1.0"
+                xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
+    <mediaResourceResponse reason="Resource found" status="200"
+                           id="ns56g1x0">
+        <response-session-info>
+            <session-id>z1skKYZQ3eFu</session-id>
+            <seq>9</seq>
+            <expires>3600</expires>
+            <media-server-address
+                              uri="sip:MediaServer@ms.example.com:5080">
+                <connection-id>32pbdxZ8:KQw677BF</connection-id>
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+                        <decoding>60</decoding>
+                        <encoding>60</encoding>
+
+
+
+Boulton, et al.              Standards Track                   [Page 81]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+            <media-server-address
+                       uri="sip:OtherMediaServer@pool.example.net:5080">
+                <ivr-sessions>
+                    <rtp-codec name="audio/basic">
+                        <decoding>40</decoding>
+                        <encoding>40</encoding>
+                    </rtp-codec>
+                </ivr-sessions>
+            </media-server-address>
+        </response-session-info>
+    </mediaResourceResponse>
+   </mrbconsumer>
+
+   =_Part
+
+
+11. UAC <- AS (200 OK sdp)
+--------------------------
+   [..]
+   From: <sip:lminiero@users.example.com>;tag=1153573888
+   To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
+   [..]
+   Content-Type: application/sdp
+
+   v=0
+   o=lminiero 123456 654322 IN IP4 203.0.113.1
+   s=MediaCtrl
+   c=IN IP4 203.0.113.1
+   t=0 0
+   m=audio 63442 RTP/AVP 0 3 8 101
+   a=rtpmap:0 PCMU/8000
+   a=rtpmap:3 GSM/8000
+   a=rtpmap:8 PCMA/8000
+   a=rtpmap:101 telephone-event/8000
+   a=fmtp:101 0-15
+   a=ptime:20
+   a=label:7eda834
+   m=video 33468 RTP/AVP 98
+   a=rtpmap:98 H263-1998/90000
+   a=fmtp:98 CIF=2
+   a=label:0132ca2
+
+   As the examples illustrate, as in the IAMM/Control Channel example,
+   the MRB provides the Application Server with a <media-server-address>
+   element in the Consumer response: the 'uri' attribute identifies the
+
+
+
+Boulton, et al.              Standards Track                   [Page 82]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   specific Media Server to which the MRB has sent the SDP media
+   negotiation, and the 'connection-id' enables the Application Server
+   to identify to the Media Server the dialog between the MRB and Media
+   Server.  This attribute is needed, since according to the framework
+   specification [RFC6230] the connection-id is built out of the From/To
+   tags of the dialog between the MRB and Media Server; since the MRB
+   acts as a B2BUA in this scenario, without that attribute the
+   Application Server does not know the relevant tags, thus preventing
+   the CFW protocol from working as expected.
+
+   The continuation of the scenario (the Application Server connecting
+   to the Media Server to start the Control Channel, the SYNC message,
+   etc.) is omitted for brevity.
+
+10.  Media Service Resource Publisher Interface XML Schema
+
+   This section gives the XML Schema Definition
+   [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
+   "application/mrb-publish+xml" format.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
+ elementFormDefault="qualified" blockDefault="#all"
+ xmlns="urn:ietf:params:xml:ns:mrb-publish"
+ xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
+ xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+
+ <xsd:annotation>
+  <xsd:documentation>
+   IETF MediaCtrl MRB 1.0
+
+   This is the schema of the IETF MediaCtrl MRB package.
+
+   The schema namespace is urn:ietf:params:xml:ns:mrb-publish
+
+  </xsd:documentation>
+ </xsd:annotation>
+
+
+ <!--
+  #############################################################
+
+  SCHEMA IMPORTS
+
+  #############################################################
+ -->
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 83]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
+  schemaLocation="http://www.w3.org/2001/xml.xsd">
+  <xsd:annotation>
+   <xsd:documentation>
+    This import brings in the XML attributes for
+    xml:base, xml:lang, etc.
+   </xsd:documentation>
+  </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+  namespace="urn:ietf:params:xml:ns:control:framework-attributes"
+  schemaLocation="framework.xsd">
+  <xsd:annotation>
+   <xsd:documentation>
+    This import brings in the framework attributes for
+    conferenceid and connectionid.
+   </xsd:documentation>
+  </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+  namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+  schemaLocation="civicAddress.xsd">
+  <xsd:annotation>
+   <xsd:documentation>
+    This import brings in the civicAddress specification
+    from RFC 5139.
+   </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>
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 84]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  <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>
+
+
+
+Boulton, et al.              Standards Track                   [Page 85]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+     <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="minfrequency" type="xsd:nonNegativeInteger"
+      minOccurs="0" maxOccurs="1" />
+     <xsd:element name="maxfrequency" type="xsd:nonNegativeInteger"
+      minOccurs="0" maxOccurs="1" />
+     <xsd:any namespace="##other" minOccurs="0"
+      maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="id" type="id.datatype" use="required" />
+    <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
+      use="required" />
+    <xsd:attribute name="action" type="action.datatype"
+      use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="subscription" type="subscriptionType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 86]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--
+  #####################################################
+
+  mrbresponse TYPE
+
+  #####################################################
+ -->
+
+<!--  mrbresponse -->
+
+ <xsd:complexType name="mrbresponseType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+     <xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
+     <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="status" type="status.datatype"
+     use="required" />
+    <xsd:attribute name="reason" type="xsd:string" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+
+ <xsd:element name="mrbresponse" type="mrbresponseType" />
+
+<!--
+  #####################################################
+
+  mrbnotification TYPE
+
+  #####################################################
+ -->
+
+<!--  mrbnotification -->
+
+<xsd:complexType name="mrbnotificationType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+     <xsd:element name="media-server-id"
+        type="subscriptionid.datatype"/>
+     <xsd:element ref="supported-packages" minOccurs="0" />
+     <xsd:element ref="active-rtp-sessions" minOccurs="0" />
+     <xsd:element ref="active-mixer-sessions" minOccurs="0" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 87]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+     <xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
+     <xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
+     <xsd:element ref="media-server-status" minOccurs="0" />
+     <xsd:element ref="supported-codecs" minOccurs="0" />
+     <xsd:element ref="application-data" minOccurs="0"
+      maxOccurs="unbounded" />
+     <xsd:element ref="file-formats" minOccurs="0" />
+     <xsd:element ref="max-prepared-duration" minOccurs="0" />
+     <xsd:element ref="dtmf-support" minOccurs="0" />
+     <xsd:element ref="mixing-modes" minOccurs="0" />
+     <xsd:element ref="supported-tones" minOccurs="0" />
+     <xsd:element ref="file-transfer-modes" minOccurs="0" />
+     <xsd:element ref="asr-tts-support" minOccurs="0" />
+     <xsd:element ref="vxml-support" minOccurs="0" />
+     <xsd:element ref="media-server-location" minOccurs="0" />
+     <xsd:element ref="label" minOccurs="0" />
+     <xsd:element ref="media-server-address" minOccurs="0" />
+     <xsd:element ref="encryption" minOccurs="0" />
+     <xsd:any namespace="##other" minOccurs="0"
+      maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+     <xsd:attribute name="id" type="subscriptionid.datatype"
+      use="required" />
+     <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
+      use="required" />
+     <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mrbnotification" type="mrbnotificationType" />
+
+
+<!--  supported-packages -->
+
+ <xsd:complexType name="supported-packagesType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="package" minOccurs="0"
+        maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+
+
+Boulton, et al.              Standards Track                   [Page 88]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<xsd:element name="supported-packages" type="supported-packagesType"/>
+
+
+ <xsd:complexType name="packageType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="package" type="packageType" />
+
+
+<!--  active-rtp-sessions -->
+
+ <xsd:complexType name="active-rtp-sessionsType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="rtp-codec" minOccurs="0"
+        maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
+
+
+ <xsd:complexType name="rtp-codecType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
+      <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="xsd:string" use="required" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 89]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+    <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" />
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 90]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--  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" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 91]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="non-active-mix" type="non-active-mixType" />
+
+<!--  media-server-status -->
+
+ <xsd:element name="media-server-status" type="msstatus.datatype" />
+
+<!--  supported-codecs -->
+
+<xsd:complexType name="supported-codecsType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="supported-codec"
+         minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+         maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-codecs" type="supported-codecsType" />
+
+ <xsd:complexType name="supported-codecType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="supported-codec-package"
+         minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-codec" type="supported-codecType" />
+
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 92]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ <xsd:complexType name="supported-codec-packageType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element name="supported-action" 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"
+
+
+
+Boulton, et al.              Standards Track                   [Page 93]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+        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:element name="supported-file-package"
+  type="xsd:string" />
+
+<!--  max-prepared-duration -->
+
+<xsd:complexType name="max-prepared-durationType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="max-time" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="max-prepared-duration"
+  type="max-prepared-durationType" />
+
+
+ <xsd:complexType name="max-timeType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element name="max-time-package" type="xsd:string" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
+     use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="max-time" type="max-timeType" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 94]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--  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>
+
+
+
+Boulton, et al.              Standards Track                   [Page 95]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ <xsd:element name="generate" type="generateType" />
+
+ <xsd:complexType name="passthroughType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="dtmf-type"
+        minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="passthrough" type="passthroughType" />
+
+
+ <xsd:complexType name="dtmf-typeType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="dtmf.datatype" use="required" />
+    <xsd:attribute name="package" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="dtmf-type" type="dtmf-typeType" />
+
+
+<!--  mixing-modes -->
+
+<xsd:complexType name="mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:element ref="audio-mixing-modes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="video-mixing-modes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 96]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixing-modes" type="mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="audio-mixing-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
+
+<xsd:complexType name="video-mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="video-mixing-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:attribute name="vas" type="boolean.datatype"
+     default="false" />
+   <xsd:attribute name="activespeakermix" type="boolean.datatype"
+     default="false" />
+
+
+
+Boulton, et al.              Standards Track                   [Page 97]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
+
+<xsd:complexType name="video-mixing-modeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
+
+
+<!--  supported-tones -->
+
+<xsd:complexType name="supported-tonesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:element ref="supported-country-codes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="supported-h248-codes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-tones" type="supported-tonesType" />
+
+<xsd:complexType name="supported-country-codesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="country-code"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+
+
+
+Boulton, et al.              Standards Track                   [Page 98]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-country-codes"
+  type="supported-country-codesType" />
+
+<xsd:complexType name="country-codeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="country-code" type="country-codeType" />
+
+<xsd:complexType name="supported-h248-codesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="h248-code"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-h248-codes"
+  type="supported-h248-codesType" />
+
+<xsd:complexType name="h248-codeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="h248-code" type="h248-codeType" />
+
+
+
+
+
+Boulton, et al.              Standards Track                   [Page 99]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--  file-transfer-modes -->
+
+ <xsd:complexType name="file-transfer-modesType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="file-transfer-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="file-transfer-modes"
+              type="file-transfer-modesType" />
+
+ <xsd:complexType name="file-transfer-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="transfermode.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="file-transfer-mode" type="file-transfer-modeType" />
+
+
+<!--  asr-tts-support -->
+
+<xsd:complexType name="asr-tts-supportType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:element ref="asr-support"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="tts-support"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 100]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
+
+<xsd:complexType name="asr-supportType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="language"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-support" type="asr-supportType" />
+
+<xsd:complexType name="tts-supportType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="language"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tts-support" type="tts-supportType" />
+
+<xsd:complexType name="languageType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:attribute ref="xml:lang" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 101]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="language" type="languageType" />
+
+
+<!--  media-server-location -->
+
+<xsd:complexType name="media-server-locationType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element name="civicAddress" type="ca:civicAddress"
+                        minOccurs="1" maxOccurs="1" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="media-server-location"
+  type="media-server-locationType" />
+
+
+<!--  vxml-support -->
+
+ <xsd:complexType name="vxml-supportType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="vxml-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="vxml-support" type="vxml-supportType" />
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 102]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ <xsd:complexType name="vxml-modeType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="package" type="xsd:string" use="required" />
+    <xsd:attribute name="support" type="vxml.datatype" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="vxml-mode" type="vxml-modeType" />
+
+
+<!--  label -->
+
+ <xsd:element name="label" type="label.datatype" />
+
+
+<!-- media-server-address -->
+
+ <xsd:element name="media-server-address" type="xsd:anyURI" />
+
+<!--  encryption -->
+
+ <xsd:complexType name="encryptionType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="encryption" type="encryptionType" />
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 103]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--
+  ####################################################
+
+  DATATYPES
+
+  ####################################################
+ -->
+
+ <xsd:simpleType name="version.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="1.0" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+<xsd:simpleType name="id.datatype">
+  <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="status.datatype">
+  <xsd:restriction base="xsd:positiveInteger">
+   <xsd:pattern value="[0-9][0-9][0-9]" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="msstatus.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="active" />
+   <xsd:enumeration value="deactivated" />
+   <xsd:enumeration value="unavailable" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="action.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="create" />
+   <xsd:enumeration value="update" />
+   <xsd:enumeration value="remove" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="actions.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="encoding" />
+   <xsd:enumeration value="decoding" />
+   <xsd:enumeration value="passthrough" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 104]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+ <xsd:simpleType name="appdata.datatype">
+  <xsd:restriction base="xsd:string" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="dtmf.datatype">
+  <xsd:restriction base="xsd:NMTOKEN"/>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="transfermode.datatype">
+  <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="boolean.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="true" />
+   <xsd:enumeration value="false" />
+  </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="vxml.datatype">
+  <xsd:restriction base="xsd:NMTOKEN"/>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="label.datatype">
+  <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="subscriptionid.datatype">
+  <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+</xsd:schema>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 105]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+11.  Media Service Resource Consumer Interface XML Schema
+
+   This section gives the XML Schema Definition
+   [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
+   "application/mrb-consumer+xml" format.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
+ elementFormDefault="qualified" blockDefault="#all"
+ xmlns="urn:ietf:params:xml:ns:mrb-consumer"
+ xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+
+ <xsd:annotation>
+  <xsd:documentation>
+   IETF MediaCtrl MRB 1.0
+
+   This is the schema of the IETF MediaCtrl MRB Consumer interface.
+
+   The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
+
+  </xsd:documentation>
+ </xsd:annotation>
+
+
+ <!--
+  #############################################################
+
+  SCHEMA IMPORTS
+
+  #############################################################
+ -->
+
+ <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
+  schemaLocation="http://www.w3.org/2001/xml.xsd">
+  <xsd:annotation>
+   <xsd:documentation>
+    This import brings in the XML attributes for
+    xml:base, xml:lang, etc.
+   </xsd:documentation>
+  </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+  namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+  schemaLocation="civicAddress.xsd">
+  <xsd:annotation>
+   <xsd:documentation>
+
+
+
+Boulton, et al.              Standards Track                  [Page 106]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+    This import brings in the civicAddress specification
+    from RFC 5139.
+   </xsd:documentation>
+  </xsd:annotation>
+ </xsd:import>
+
+<!--
+  #####################################################
+
+  Extensible core type
+
+  #####################################################
+ -->
+
+ <xsd:complexType name="Tcore">
+  <xsd:annotation>
+   <xsd:documentation>
+    This type is extended by other (non-mixed) component types to
+    allow attributes from other namespaces.
+   </xsd:documentation>
+  </xsd:annotation>
+  <xsd:sequence/>
+  <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:complexType>
+
+
+<!--
+  #####################################################
+
+  TOP-LEVEL ELEMENT: mrbconsumer
+
+  #####################################################
+ -->
+
+<xsd:complexType name="mrbconsumerType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+     <xsd:choice>
+      <xsd:element ref="mediaResourceRequest" />
+      <xsd:element ref="mediaResourceResponse" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+     </xsd:choice>
+    </xsd:sequence>
+    <xsd:attribute name="version" type="version.datatype"
+      use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 107]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+ <xsd:element name="mrbconsumer" type="mrbconsumerType" />
+
+
+<!--
+  #####################################################
+
+  mediaResourceRequest TYPE
+
+  #####################################################
+ -->
+
+<!--  mediaResourceRequest -->
+
+ <xsd:complexType name="mediaResourceRequestType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="generalInfo" minOccurs="0" />
+      <xsd:element ref="ivrInfo" minOccurs="0" />
+      <xsd:element ref="mixerInfo" minOccurs="0" />
+     <xsd:any namespace="##other" minOccurs="0"
+      maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="id" type="xsd:string"
+      use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mediaResourceRequest"
+         type="mediaResourceRequestType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 108]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--
+  #####################################################
+
+  generalInfo TYPE
+
+  #####################################################
+-->
+
+<!--  generalInfo -->
+
+<xsd:complexType name="generalInfoType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="session-info" minOccurs="0" />
+      <xsd:element ref="packages" minOccurs="0" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="generalInfo" type="generalInfoType" />
+
+
+<!--  session-info -->
+
+<xsd:complexType name="session-infoType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element name="session-id" type="id.datatype"/>
+       <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
+       <xsd:element name="action" type="action.datatype"/>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="session-info" type="session-infoType" />
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 109]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--  packages -->
+
+<xsd:complexType name="packagesType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element name="package" type="xsd:string" minOccurs="0"
+        maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="packages" type="packagesType"/>
+
+
+<!--
+  #####################################################
+
+  ivrInfo TYPE
+
+  #####################################################
+-->
+
+<!--  ivrInfo -->
+
+<xsd:complexType name="ivrInfoType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="ivr-sessions" minOccurs="0" />
+      <xsd:element ref="file-formats" minOccurs="0" />
+      <xsd:element ref="dtmf-type" minOccurs="0" />
+      <xsd:element ref="tones" minOccurs="0" />
+      <xsd:element ref="asr-tts" minOccurs="0" />
+      <xsd:element ref="vxml" minOccurs="0" />
+      <xsd:element ref="location" minOccurs="0" />
+      <xsd:element ref="encryption" minOccurs="0" />
+      <xsd:element ref="application-data" minOccurs="0" />
+      <xsd:element ref="max-prepared-duration" minOccurs="0" />
+      <xsd:element ref="file-transfer-modes" minOccurs="0" />
+      <xsd:any namespace="##other" minOccurs="0"
+      maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 110]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="ivrInfo" type="ivrInfoType" />
+
+
+<!--
+  #####################################################
+
+  mixerInfo TYPE
+
+  #####################################################
+-->
+
+<!--  mixerInfo -->
+
+<xsd:complexType name="mixerInfoType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="mixers" minOccurs="0"/>
+      <xsd:element ref="file-formats" minOccurs="0"/>
+      <xsd:element ref="dtmf-type" minOccurs="0"/>
+      <xsd:element ref="tones" minOccurs="0"/>
+      <xsd:element ref="mixing-modes" minOccurs="0"/>
+      <xsd:element ref="application-data" minOccurs="0"/>
+      <xsd:element ref="location" minOccurs="0"/>
+      <xsd:element ref="encryption" minOccurs="0"/>
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="mixerInfo" type="mixerInfoType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 111]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--
+  #####################################################
+
+  mediaResourceResponse TYPE
+
+  #####################################################
+ -->
+
+<!--  mediaResourceResponse -->
+
+ <xsd:complexType name="mediaResourceResponseType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="response-session-info" minOccurs="0" />
+       <xsd:any namespace="##other" minOccurs="0"
+          maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="id" type="xsd:string"
+     use="required" />
+    <xsd:attribute name="status" type="status.datatype"
+     use="required" />
+    <xsd:attribute name="reason" type="xsd:string" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mediaResourceResponse"
+         type="mediaResourceResponseType" />
+
+
+<!--
+  ####################################################
+
+  ELEMENTS
+
+  ####################################################
+ -->
+
+<!--  response-session-info -->
+
+<xsd:complexType name="response-session-infoType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element name="session-id" type="id.datatype"/>
+       <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
+
+
+
+Boulton, et al.              Standards Track                  [Page 112]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+       <xsd:element name="expires" type="xsd:nonNegativeInteger"/>
+       <xsd:element ref="media-server-address"
+          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="response-session-info"
+   type="response-session-infoType" />
+
+<!-- media-server-address -->
+
+<xsd:complexType name="media-server-addressTYPE">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+     <xsd:element name="connection-id" type="xsd:string"
+         minOccurs="0" maxOccurs="unbounded" />
+     <xsd:element ref="ivr-sessions" minOccurs="0"/>
+     <xsd:element ref="mixers" minOccurs="0"/>
+     <xsd:any namespace="##other" minOccurs="0"
+         maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="uri" type="xsd:anyURI" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="media-server-address"
+    type="media-server-addressTYPE" />
+
+<!--  ivr-sessions -->
+
+<xsd:complexType name="ivr-sessionsType">
+ <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="rtp-codec" minOccurs="0"
+        maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 113]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
+
+<xsd:complexType name="rtp-codecType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
+      <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="rtp-codec" type="rtp-codecType" />
+
+
+<!-- file-formats -->
+
+<xsd:complexType name="file-formatsType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="required-format"
+         minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+         maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="file-formats" type="file-formatsType" />
+
+<xsd:complexType name="required-formatType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="required-file-package"
+         minOccurs="0" maxOccurs="unbounded" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 114]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="required-format" type="required-formatType" />
+
+<xsd:complexType name="required-file-packageType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element name="required-file-package-name" type="xsd:string"
+        minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="required-file-package"
+  type="required-file-packageType" />
+
+<!--  dtmf-type -->
+
+<xsd:complexType name="dtmfType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="detect" />
+       <xsd:element ref="generate" />
+       <xsd:element ref="passthrough" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="dtmf" type="dtmfType" />
+
+<xsd:complexType name="detectType">
+
+
+
+Boulton, et al.              Standards Track                  [Page 115]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  <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">
+
+
+
+Boulton, et al.              Standards Track                  [Page 116]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="name" type="dtmf.datatype" use="required" />
+    <xsd:attribute name="package" type="xsd:string" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="dtmf-type" type="dtmf-typeType" />
+
+<!--  tones -->
+
+<xsd:complexType name="required-tonesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:element ref="country-codes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="h248-codes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tones" type="required-tonesType" />
+
+<xsd:complexType name="required-country-codesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="country-code"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+
+
+Boulton, et al.              Standards Track                  [Page 117]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<xsd:element name="country-codes"
+   type="required-country-codesType" />
+
+<xsd:complexType name="country-codeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="country-code" type="country-codeType" />
+
+<xsd:complexType name="required-h248-codesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="h248-code"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="h248-codes"
+   type="required-h248-codesType" />
+
+<xsd:complexType name="h248-codeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="h248-code" type="h248-codeType" />
+
+<!--  asr-tts -->
+
+<xsd:complexType name="asr-ttsType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+
+
+
+Boulton, et al.              Standards Track                  [Page 118]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+      <xsd:element ref="asr-support"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="tts-support"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-tts" type="asr-ttsType" />
+
+<xsd:complexType name="asr-supportType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="language"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-support" type="asr-supportType" />
+
+<xsd:complexType name="tts-supportType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="language"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tts-support" type="tts-supportType" />
+
+<xsd:complexType name="languageType">
+ <xsd:complexContent>
+
+
+
+Boulton, et al.              Standards Track                  [Page 119]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:attribute ref="xml:lang" />
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="language" type="languageType" />
+
+
+<!--  vxml -->
+
+<xsd:complexType name="vxmlType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="vxml-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="vxml" type="vxmlType" />
+
+<xsd:complexType name="vxml-modeType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="package" type="xsd:string" use="required" />
+    <xsd:attribute name="require" type="vxml.datatype" use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="vxml-mode" type="vxml-modeType" />
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 120]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<!--  location -->
+
+<xsd:complexType name="locationType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:element ref="ca:civicAddress"
+                        minOccurs="1" maxOccurs="1" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="location" type="locationType" />
+
+
+<!--  encryption -->
+
+ <xsd:complexType name="encryptionType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="encryption" type="encryptionType" />
+
+<!--  application-data -->
+
+<xsd:element name="application-data" type="appdata.datatype" />
+
+<!--  max-prepared-duration -->
+
+<xsd:complexType name="max-prepared-durationType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="max-time" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al.              Standards Track                  [Page 121]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+    </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" />
+
+
+<!--  file-transfer-modes -->
+
+<xsd:complexType name="file-transfer-modesType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="file-transfer-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="file-transfer-modes"
+             type="file-transfer-modesType" />
+
+<xsd:complexType name="file-transfer-modeType">
+
+
+
+Boulton, et al.              Standards Track                  [Page 122]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+  <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="transfermode.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="file-transfer-mode" type="file-transfer-modeType" />
+
+<!--  mixers -->
+
+<xsd:complexType name="mixerssessionsType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="mix" minOccurs="0"
+        maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixers" type="mixerssessionsType" />
+
+<xsd:complexType name="mixType">
+  <xsd:complexContent>
+   <xsd:extension base="Tcore">
+    <xsd:sequence>
+      <xsd:element ref="rtp-codec" minOccurs="0"
+        maxOccurs="unbounded" />
+       <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+    </xsd:sequence>
+    <xsd:attribute name="users" type="xsd:nonNegativeInteger"
+     use="required" />
+    <xsd:anyAttribute namespace="##other" processContents="lax" />
+   </xsd:extension>
+  </xsd:complexContent>
+
+
+
+Boulton, et al.              Standards Track                  [Page 123]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+</xsd:complexType>
+
+<xsd:element name="mix" type="mixType" />
+
+<!--  mixing-modes -->
+
+<xsd:complexType name="mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+      <xsd:element ref="audio-mixing-modes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:element ref="video-mixing-modes"
+        minOccurs="0" maxOccurs="1" />
+      <xsd:any namespace="##other" minOccurs="0"
+        maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixing-modes" type="mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="audio-mixing-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+
+
+Boulton, et al.              Standards Track                  [Page 124]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
+
+<xsd:complexType name="video-mixing-modesType">
+ <xsd:complexContent>
+  <xsd:extension base="Tcore">
+   <xsd:sequence>
+     <xsd:element ref="video-mixing-mode"
+        minOccurs="0" maxOccurs="unbounded" />
+      <xsd:any namespace="##other" minOccurs="0"
+       maxOccurs="unbounded" processContents="lax" />
+   </xsd:sequence>
+   <xsd:attribute name="vas" type="boolean.datatype"
+     default="false" />
+   <xsd:attribute name="activespeakermix" type="boolean.datatype"
+     default="false" />
+   <xsd:anyAttribute namespace="##other" processContents="lax" />
+  </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
+
+<xsd:complexType name="video-mixing-modeType" mixed="true">
+ <xsd:sequence>
+    <xsd:any namespace="##other" minOccurs="0"
+     maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
+
+
+<!--
+  ####################################################
+
+  DATATYPES
+
+  ####################################################
+ -->
+
+<xsd:simpleType name="version.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="1.0" />
+  </xsd:restriction>
+</xsd:simpleType>
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 125]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+<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="transfermode.datatype">
+  <xsd:restriction base="xsd:NMTOKEN"/>
+</xsd:simpleType>
+
+<xsd:simpleType name="action.datatype">
+  <xsd:restriction base="xsd:NMTOKEN">
+   <xsd:enumeration value="remove" />
+   <xsd:enumeration value="update" />
+  </xsd:restriction>
+</xsd:simpleType>
+
+<xsd:simpleType name="dtmf.datatype">
+  <xsd:restriction base="xsd:NMTOKEN"/>
+</xsd: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:simpleType>
+
+<xsd:simpleType name="appdata.datatype">
+  <xsd:restriction base="xsd:string" />
+ </xsd:simpleType>
+
+</xsd:schema>
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 126]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+12.  Security Considerations
+
+   The MRB network entity has two primary interfaces -- Publish and
+   Consumer -- that carry sensitive information and must therefore be
+   appropriately protected and secured.
+
+   The Publish interface, as defined in and described in Section 5.1,
+   uses the Media Control Channel Framework [RFC6230] as a mechanism to
+   connect an MRB to a Media Server.  It is very important that the
+   communication between the MRB and the Media Server is secured: a
+   malicious entity may change or even delete subscriptions to a Media
+   Server, thus affecting the view the MRB has of the resources actually
+   available on a Media Server, leading it to incorrect selection when
+   media resources are being requested by an Application Server.  A
+   malicious entity may even manipulate available resources on a Media
+   Server, for example, to make the MRB think no resources are available
+   at all.  Considering that the Publish interface is a CFW Control
+   Package, the same security considerations included in the Media
+   Control Channel Framework specification apply here to protect
+   interactions between an MRB and a Media Server.
+
+   The Publish interface also allows a Media Server, as explained in
+   Section 5.1.5.18, to provide more or less accurate information about
+   its geographic location, should Application Servers be interested in
+   such details when looking for services at an MRB.  While the usage of
+   this information is entirely optional and the level of detail to be
+   provided is implementation specific, it is important to draw
+   attention to the potential security issues that the disclosure of
+   such addresses may introduce.  As such, it is important to make sure
+   MRB implementations don't disclose this information as is to
+   interested Application Servers but only exploit those addresses as
+   part of computation algorithms to pick the most adequate resources
+   Application Servers may be looking for.
+
+   The Consumer interface, as defined in and described in Section 5.2,
+   conceives transactions based on a session ID.  These transactions may
+   be transported either by means of HTTP messages or SIP dialogs.  This
+   means that malicious users could be able to disrupt or manipulate an
+   MRB session should they have access to the above-mentioned session ID
+   or replicate it somehow: for instance, a malicious entity could
+   modify an existing session between an Application Server and the MRB,
+   e.g., requesting less resources than originally requested to cause
+   media dialogs to be rejected by the Application Server, or requesting
+   many more resources instead to try and lock as many of (if not all)
+   the resources an MRB can provide, thus making them unavailable to
+   other legitimate Application Servers in subsequent requests.  In
+   order to prevent this, it is strongly advised that MRB
+   implementations generate session identifiers that are very hard to
+
+
+
+Boulton, et al.              Standards Track                  [Page 127]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   replicate, in order to minimize the chances that malicious users
+   could gain access to valid identifiers by just guessing or by means
+   of brute-force attacks.  It is very important, of course, to also
+   secure the way that these identifiers are transported by the involved
+   parties, in both requests and responses, in order to prevent network
+   attackers from intercepting Consumer messages and having access to
+   session IDs.  The Consumer interface uses either the Hypertext
+   Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) as
+   the mechanism for clients to connect to an MRB to request media
+   resources.  In the case where HTTP is used, any binding using the
+   Consumer interface MUST be capable of being transacted over Transport
+   Layer Security (TLS), as described in RFC 2818 [RFC2818].  In the
+   case where SIP is used, the same security considerations included in
+   the Media Control Channel Framework specification apply here to
+   protect interactions between a client requesting media resources and
+   an MRB.
+
+   Should a valid session ID be compromised somehow (that is,
+   intercepted or just guessed by a malicious user), as a further means
+   to prevent disruption the Consumer interface also prescribes the use
+   of a sequence number in its transactions.  This sequence number is to
+   be increased after each successful transaction, starting from a first
+   value randomly generated by the MRB when the session is first
+   created, and it must match in every request/response.  While this
+   adds complexity to the protocol (implementations must pay attention
+   to those sequence numbers, since wrong values will cause "Wrong
+   sequence number" errors and the failure of the related requests), it
+   is an important added value for security.  In fact, considering that
+   different transactions related to the same session could be
+   transported in different, unrelated HTTP messages (or SIP INVITEs in
+   cases where the In-line mode is being used), this sequence number
+   protection prevents the chances of session replication or disruption,
+   especially in cases where the session ID has been compromised: that
+   is, it should make it harder for malicious users to manipulate or
+   remove a session for which they have obtained the session ID.  It is
+   strongly advised that the MRB doesn't choose 1 as the first sequence
+   number for a new session but rather picks a random value to start
+   from.  The reaction to transactions that are out of sequence is left
+   to MRB implementations: a related error code is available, but
+   implementations may decide to enforce further limitations or actions
+   upon the receipt of too many failed attempts in a row or of what
+   looks like blatant attempts to guess what the current, valid sequence
+   number is.
+
+   It is also worth noting that in In-line mode (both IAMM and IUMM) the
+   MRB may act as a Back-to-Back User Agent (B2BUA).  This means that
+   when acting as a B2BUA the MRB may modify SIP bodies: it is the case,
+   for instance, for the IAMM handling multipart/mixed payloads.  This
+
+
+
+Boulton, et al.              Standards Track                  [Page 128]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   impacts the ability to use any SIP security feature that protects the
+   body (e.g., RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as
+   a mediator for the security association.  This should be taken into
+   account when implementing an MRB compliant with this specification.
+
+   Both the Publishing interface and Consumer interface may address the
+   location of a Media Server: the Publishing interface may be used to
+   inform the MRB where a Media Server is located (approximately or
+   precisely), and the Consumer interface may be used to ask for a Media
+   Server located somewhere in a particular region (e.g., a conference
+   bridge close to San Francisco).  Both Media Server and MRB
+   implementers need to take this into account when deciding whether or
+   not to make this location information available, and if so how many
+   bits of information really need to be made available for brokering
+   purposes.
+
+   It is worthwhile to cover authorization issues related to this
+   specification.  Neither the Publishing interface nor the Consumer
+   interface provides an explicit means for implementing authentication,
+   i.e., they do not contain specific protocol interactions to ensure
+   that authorized Application Servers can make use of the services
+   provided by an MRB instance.  Considering that both interfaces are
+   transported using well-established protocols (HTTP, SIP, CFW),
+   support for such functionality can be expressed by means of the
+   authentication mechanisms provided by the protocols themselves.
+   Therefore, any MRB-aware entity (Application Servers, Media Servers,
+   MRBs themselves) MUST support HTTP and SIP Digest access
+   authentication.  The usage of such Digest access authentications is
+   recommended and not mandatory, which means MRB-aware entities MAY
+   exploit it in deployment.
+
+   An MRB may want to enforce further constraints on the interactions
+   between an Application Server/Media Server and an MRB.  For example,
+   it may choose to only accept requests associated with a specific
+   session ID from the IP address that originated the first request or
+   may just make use of pre-shared certificates to assess the identity
+   of legitimate Application Servers and/or Media Servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 129]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+13.  IANA Considerations
+
+   There are several IANA considerations associated with this
+   specification.
+
+13.1.  Media Control Channel Framework Package Registration
+
+   This section registers a new Media Control Channel Framework package,
+   per the instructions in Section 13.1 of [RFC6230].
+
+   Package Name:  mrb-publish/1.0
+
+   Published Specification(s):  RFC 6917
+
+   Person and email address to contact for further information:  IETF
+      MediaCtrl working group (mediactrl@ietf.org), Chris Boulton
+      (chris@ns-technologies.com).
+
+13.2.  application/mrb-publish+xml Media Type
+
+   To:  application
+
+   Subject:  Registration of media type application/mrb-publish+xml
+
+   Type name:  application
+
+   Subtype name:  mrb-publish+xml
+
+   Required parameters:  none
+
+   Optional parameters:  Same as charset parameter of application/xml as
+      specified in RFC 3023 [RFC3023].
+
+   Encoding considerations:  Same as encoding considerations of
+      application/xml as specified in RFC 3023 [RFC3023].
+
+   Security considerations:  See Section 10 of RFC 3023 [RFC3023] and
+      Section 12 of RFC 6917.
+
+   Interoperability considerations:  none.
+
+   Published specification:  Section 10 of RFC 6917.
+
+   Applications that use this media type:  This media type is used to
+      support a Media Resource Broker (MRB) entity.
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 130]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Additional Information:
+
+      Magic Number:  None
+
+      File Extension:  .xdf
+
+      Macintosh file type code:  "TEXT"
+
+   Person and email address to contact for further information:  Chris
+      Boulton (chris@ns-technologies.com).
+
+   Intended usage: COMMON
+
+   Author/Change controller:  The IETF.
+
+13.3.  application/mrb-consumer+xml Media Type
+
+   To:  application
+
+   Subject:  Registration of media type application/mrb-consumer+xml
+
+   Type name:  application
+
+   Subtype name:  mrb-consumer+xml
+
+   Mandatory parameters:  none
+
+   Optional parameters:  Same as charset parameter of application/xml as
+      specified in RFC 3023 [RFC3023].
+
+   Encoding considerations:  Same as encoding considerations of
+      application/xml as specified in RFC 3023 [RFC3023].
+
+   Security considerations:  See Section 10 of RFC 3023 [RFC3023] and
+      Section 12 of RFC 6917.
+
+   Interoperability considerations:  none.
+
+   Published specification:  Section 11 of RFC 6917.
+
+   Applications that use this media type:  This media type is used to
+      support a Media Resource Broker (MRB) entity.
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 131]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   Additional Information:
+
+      Magic Number:  None
+
+      File Extension:  .xdf
+
+      Macintosh file type code:  "TEXT"
+
+   Person and email address to contact for further information:  Chris
+      Boulton (chris@ns-technologies.com).
+
+   Intended usage: COMMON
+
+   Author/Change controller:  The IETF.
+
+13.4.  URN Sub-Namespace Registration for mrb-publish
+
+   IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish",
+   with the ID of "mrb-publish".  The schema of the XML namespace named
+   urn:ietf:params:xml:ns:mrb-publish is in Section 10.
+
+13.5.  URN Sub-Namespace Registration for mrb-consumer
+
+   IANA has registered the URN "urn:ietf:params:xml:ns:mrb-consumer",
+   with the ID of "mrb-consumer".  The schema of the XML namespace named
+   urn:ietf:params:xml:ns:mrb-consumer is in Section 11.
+
+13.6.  XML Schema Registration for mrb-publish
+
+   IANA has registered the schema for mrb-publish:
+
+   URI:  urn:ietf:params:xml:schema:mrb-publish
+
+   ID:  mrb-publish
+
+   Filename:  mrb-publish
+
+   Registrant Contact:  IETF MediaCtrl working group
+      (mediactrl@ietf.org)
+
+   Schema:  The XML for the schema is in Section 10 of this document.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 132]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+13.7.  XML Schema Registration for mrb-consumer
+
+   Please register the schema for mrb-consumer:
+
+   URI:  urn:ietf:params:xml:schema:mrb-consumer
+
+   ID:  mrb-consumer
+
+   Filename:  mrb-consumer
+
+   Registrant Contact:  IETF MediaCtrl working group
+      (mediactrl@ietf.org)
+
+   Schema:  The XML for the schema is in Section 11 of this document.
+
+14.  Acknowledgements
+
+   The authors would like to thank the members of the Publish Interface
+   design team, who provided valuable input into this document.  The
+   design team consisted of Adnan Saleem, Michael Trank, Victor
+   Paulsamy, Martin Dolly, and Scott McGlashan.  The authors would also
+   like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
+   Christian Groves, and Jonathan Lennox for input into this
+   specification.
+
+   Ben Campbell carried out the RAI expert review on an early version of
+   this specification and provided a great deal of invaluable input.
+
+15.  References
+
+15.1.  Normative References
+
+   [ISO.10646.2012]
+              International Organization for Standardization,
+              "Information technology -- Universal Coded Character Set
+              (UCS)", ISO Standard 10646, 2012.
+
+   [ISO.3166-1]
+              International Organization for Standardization, "Codes for
+              the representation of names of countries and their
+              subdivisions - Part 1: Country codes", ISO Standard
+              3166-1:2006, 2006.
+
+   [ISO.639.2002]
+              International Organization for Standardization, "Codes for
+              the representation of names of languages -- Part 1:
+              Alpha-2 code", ISO Standard 639, 2002.
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 133]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   [ITU-T.Q.1950]
+              International Telecommunication Union, "Bearer independent
+              call bearer control protocol", ITU-T Recommendation
+              Q.1950, December 2002.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+              Types", RFC 3023, January 2001.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
+              UPDATE Method", RFC 3311, October 2002.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
+              Format for Presence Information Data Format Location
+              Object (PIDF-LO)", RFC 5139, February 2008.
+
+   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
+              for Establishing a Secure Real-time Transport Protocol
+              (SRTP) Security Context Using Datagram Transport Layer
+              Security (DTLS)", RFC 5763, May 2010.
+
+   [W3C.REC-xmlschema-1-20041028]
+              Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
+              "XML Schema Part 1: Structures Second Edition", World Wide
+              Web Consortium Recommendation REC-xmlschema-1-20041028,
+              October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 134]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   [W3C.REC-xmlschema-2-20041028]
+              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
+              Second Edition", World Wide Web Consortium
+              Recommendation REC-xmlschema-2-20041028, October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+15.2.  Informative References
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
+              Media Services with SIP", RFC 4240, December 2005.
+
+   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
+              Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+              December 2006.
+
+   [RFC5022]  Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
+              Control Markup Language (MSCML) and Protocol", RFC 5022,
+              September 2007.
+
+   [RFC5167]  Dolly, M. and R. Even, "Media Server Control Protocol
+              Requirements", RFC 5167, March 2008.
+
+   [RFC5552]  Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
+              Services", RFC 5552, May 2009.
+
+   [RFC5567]  Melanchuk, T., "An Architectural Framework for Media
+              Server Control", RFC 5567, June 2009.
+
+   [RFC5707]  Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
+              Language (MSML)", RFC 5707, February 2010.
+
+   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
+              Control Channel Framework", RFC 6230, May 2011.
+
+   [RFC6231]  McGlashan, S., Melanchuk, T., and C. Boulton, "An
+              Interactive Voice Response (IVR) Control Package for the
+              Media Control Channel Framework", RFC 6231, May 2011.
+
+   [RFC6381]  Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and
+              'Profiles' Parameters for "Bucket" Media Types", RFC 6381,
+              August 2011.
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 135]
+
+RFC 6917                Media Resource Brokering              April 2013
+
+
+   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+              "Conference Information Data Model for Centralized
+              Conferencing (XCON)", RFC 6501, March 2012.
+
+   [RFC6505]  McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
+              Control Package for the Media Control Channel Framework",
+              RFC 6505, March 2012.
+
+Authors' Addresses
+
+   Chris Boulton
+   NS-Technologies
+
+   EMail: chris@ns-technologies.com
+
+
+   Lorenzo Miniero
+   Meetecho
+   Via Carlo Poerio 89
+   Napoli  80100
+   Italy
+
+   EMail: lorenzo@meetecho.com
+
+
+   Gary Munson
+   AT&T
+   200 Laurel Avenue South
+   Middletown, New Jersey  07748
+   USA
+
+   EMail: gamunson@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al.              Standards Track                  [Page 136]
+