Media Resource Brokering
draft-ietf-mediactrl-mrb-05

Abstract

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

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on November 15, 2010.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Conventions and Terminology
3.  Problem Discussion
4.  Deployment Scenario Options
    4.1.  Query MRB
        4.1.1.  Hybrid Query MRB
    4.2.  In-Line MRB
5.  MRB Interface Definitions
    5.1.  Media Server Resource Publish Interface
        5.1.1.  Control Package Definition
        5.1.2.  Element Definitions
        5.1.3.  <mrbrequest>
        5.1.4.  <mrbnotification>
        5.1.5.  <mrbresponse>
    5.2.  Media Service Resource Consumer Interface
        5.2.1.  HTTP Consumer Interface Usage
        5.2.2.  SIP Consumer Interface Usage
        5.2.3.  Consumer Interface Lease Mechanism
        5.2.4.  Media Service Resource Request
        5.2.5.  Media Service Resource Response
    5.3.  In-Line MRB Interface
        5.3.1.  In-line Unaware MRB Mode
        5.3.2.  In-line Aware MRB Mode
6.  Examples
    6.1.  Publish Example
    6.2.  Consumer Example
        6.2.1.  Query Example
        6.2.2.  IAMM Example
7.  Media Service Resource Publisher Interface XML Schema
8.  Media Service Resource Consumer Interface XML Schema
9.  Security Considerations
10.  IANA Considerations
    10.1.  Control Package Registration
    10.2.  application/mrb-publish+xml MIME Type
    10.3.  application/mrb-consumer+xml MIME Type
    10.4.  URN Sub-Namespace Registration for mrb-publish
    10.5.  URN Sub-Namespace Registration for mrb-consumer
    10.6.  XML Schema Registration for mrb-publish
    10.7.  XML Schema Registration for mrb-consumer
11.  Changes
    11.1.  Changes from 04 Version
    11.2.  Changes from 03 Version
    11.3.  Changes from 02 Version
    11.4.  Changes from 01 Version
    11.5.  Changes from 00 Version
12.  Acknowledgments
13.  References
    13.1.  Normative References
    13.2.  Informative References
§  Authors' Addresses

1.  Introduction

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

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

The simplest deployment view is illustrated in Figure 1 (Basic Architecture).

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

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

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

Figure 3 (Multiple Application Servers) conveys the opposite view to that in Figure 2 (Multiple Media Servers). 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    |<-----+
+-------------+

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

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

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

2.  Conventions and Terminology

In this document, BCP 14/RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL".

This document inherits terminology proposed in RFC 5567 (Melanchuk, T., “An Architectural Framework for Media Server Control,” June 2009.) [RFC5567] and Media Control Channel Framework (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) [I‑D.ietf‑mediactrl‑sip‑control‑framework] documents. In addition, the following terms are defined for use in this document and for use in the context of the MediaCtrl Work group in the IETF:

Media Resource Broker (MRB):

A logical entity that is responsible for both collection of appropriate published Media Server (MS) information and selecting appropriate MS 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 definition) that directly receives requests on the signalling path. There is no separate query.

Within the context of In-line MRBs, additional terms are defined:

In-line Aware MRB Mode (IAMM):

Defined in Section 5.3.2 (In-line Aware MRB Mode).

In-line Unaware MRB Mode (IUMM):

Defined in Section 5.3.1 (In-line Unaware MRB Mode).

The document will often specify when a specific identifier in a protocol message needs to be unique. Unless differently stated, such uniqueness will always need to be intended within the scope of the Media Servers controlled by the same Media Resource Broker. The interaction among different Media Resource Brokers, as the partitioning of a logical Media Resource Broker, is out of scope to this document.

3.  Problem Discussion

As anticipated in Section 1 (Introduction), the main aim of the MediaCtrl group is to produce a solution that must service a wide variety of deployment architectures. These range from the simplest 1:1 relationship between Media Servers and Application Servers to potentially linearly scaling 1:M, M:1 and M:N deployments.

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

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

Please note that there may be additional information that it is desirable for the MRB to have for purposes of selecting an MS 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 MS resource capacity models. How the MRB acquires such information is outside the scope of this document. The techniques used for selecting an appropriate Media Resource by an MRB is outside the scope of this document.

4.  Deployment Scenario Options

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

4.1.  Query MRB

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

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

In this deployment, the Media Servers use the "Media Server Resource Publish Interface", as discussed in Section 5.1 (Media Server Resource Publish Interface), to convey capability sets as well as resource information. This is depicted by (1) in Figure 5 (Query MRB). 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 (Query MRB)). Such a query would carry specific information related to the Media Service required and enable the MRB to provide an increased accuracy in its response. This particular interface is discussed in "Media Resource Consumer Interface" in Section 5.2 (Media Service Resource Consumer Interface). The Application Server is then able to direct control commands (for example create conference) and Media Dialogs to the appropriate Media Server, as shown by (3) in Figure 5 (Query MRB). Additionally, with Query MRB, the MRB is not in the signaling path between the AS and the selected MS resource.

4.1.1.  Hybrid Query MRB

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

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

This diagram is identical to that in Figure 5 (Query MRB) 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.

In a similar manner, the Media Server could also act as a hybrid for the deployment cluster, as illustrated in Figure 7 (Hybrid Query MRB - MS Hosted).

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

This time the MRB has collapsed and is co-hosted by the Media Server. The "Media Server Consumer Interface" is still available to the Application Servers (1) to query Media Server resources. This time the "Media Server 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 MS representing a pool of MSs in a cluster. In that case, the MRB would actually be handling a cluster of MSs, rather than one.

4.2.  In-Line MRB

The "In-line" MRB is architecturally different from the "Query" model that was discussed in the previous section. The concept of a separate query disappears. The client of the MRB simply uses the media resource control and media dialog signalling to involve the MRB. This type of deployment is illustrated in Figure 8 (In-line MRB).

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

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 (and Media dialogs as well, if required) is sent to the MRB (2) which then selects an appropriate Media Server (3) and would stay in the signaling path between the AS and the MS resource for the handled dialogs.

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

In-line Unaware MRB Mode (IUMM):

Allows an MRB to act on behalf of clients requiring media services who are not aware of an MRB or its operation. In this case the AS does not provide explicit information on the kind of MS resource it needs (as in Section 5.2 (Media Service Resource Consumer Interface)) and the MRB is left to deduce it by potentially inspecting other information in the request from the AS; for example, SDP content, or address of the requesting AS, or additional Request-URI parameters as per RFC 4240 (Burger, E., Van Dyke, J., and A. Spitzer, “Basic Network Media Services with SIP,” December 2005.) [RFC4240].

In-line Aware MRB Mode (IAMM):

Allows an MRB to act on behalf of clients requiring media services who are aware of an MRB and its operation. In particular it allows the AS to explicitly the convey the same kinds of MS characteristics desired as does the Query MRB mode (as in Section 5.2 (Media Service Resource Consumer Interface)).

In either role, the MRB would deduce that the selected MS resources are no longer needed when the AS terminates the corresponding dialog. The two modes are discussed in more detail in Section 5.3 (In-Line MRB Interface).

5.  MRB Interface Definitions

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

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

5.1.  Media Server Resource 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 fulfil 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 Query and In-line modes of MRB operation.

As already anticipated in the introduction, the MRB view of MS resource availability will in practice be approximate - i.e., partial and imperfect. The MRB Publish interface does not provide an exhaustive view of current MS resource consumption, the MS may in some cases provide a best-effort computed view of resource consumption parameters conveyed in the Publish interface (e.g., DSP's with a fixed number of streams versus GPU's with CPU availability), there may be licensing constraints not factored in (e.g., even if lots of CPU and memory are available, licensing or other configuration elements may restrict the number of stream types), and MS resource information may only be reported periodically over the Publish interface to MRB. Nevertheless, despite such limitations it is assumed that the provided information is enough to allow MRB implementors to realize its functionality.

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

The MRB Publish interface uses the Media Control Channel Framework ([I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.)) as the basis for interaction between a Media Server and an MRB. The Media Control Channel Framework uses an extension mechanism to allow specific usages which are known as control packages. Section 5.1.1 (Control Package Definition) defines the control package that MUST be implemented by any Media Server wanting to interact with an MRB entity.

Please note that it is out of scope how an MRB knows what MSs should be queried for publishing information.

5.1.1.  Control Package Definition

This section fulfills the mandatory requirement for information that must be specified during the definition of a Control Framework Package, as detailed in Section 8 of [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).

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 (Element Definitions) and provides an XML Schema in Section 7 (Media Service Resource Publisher Interface XML Schema).

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

Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.)) are used when the request or event notification is invalid; for example, a request has invalid XML (400), or is not understood (500). Package level responses are carried in framework 200 response or REPORT message bodies. This package's response codes are defined in Section 5.1.5 (<mrbresponse>).

5.1.1.3.  Common XML Support

The Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) requires a Control Package definition to specify if the attributes for media dialog or conference references are required.

The Publish interface defined in Section 7 (Media Service Resource Publisher Interface XML Schema) does import and make use of the common XML schema defined in the Media Control Channel Framework.

The Consumer interface defined in Section 8 (Media Service Resource Consumer Interface XML Schema) does import and make use of the common XML schema defined in the Media Control Channel Framework.

5.1.1.4.  CONTROL Message Body

A valid CONTROL body message MUST conform to the schema defined in Section 7 (Media Service Resource Publisher Interface XML Schema) and described in Section 5.1.2 (Element Definitions). XML messages appearing in CONTROL messages MUST contain either a <mrbrequest> or <mrbnotification> element.

5.1.1.5.  REPORT Message Body

A valid REPORT body MUST conform to the schema defined in Section 7 (Media Service Resource Publisher Interface XML Schema) and described in Section 5.1.2 (Element Definitions). XML messages appearing in REPORT messages MUST contain a <mrbresponse> element.

5.1.1.6.  Audit

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

5.1.2.  Element Definitions

This section defines the XML elements for the Publish interface Media Control Channel package defined in Section 5.1 (Media Server Resource Publish Interface). The formal XML schema definition for the Publish interface can be found in Section 7 (Media Service Resource Publisher Interface XML Schema).

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 (<mrbrequest>). The MRB Publish interface notification element is detailed in Section 5.1.4 (<mrbnotification>). MRB Publish interface response element is contained in Section 5.1.5 (<mrbresponse>).

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 element, only one of which is allowed to occur in a request.

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

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

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

5.1.3.  <mrbrequest>

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

The <mrbrequest> element has no defined attributes.

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

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

5.1.3.1.  <subscription>

The <subscription> element is included in a request from an MRB to a Media Server to provide the details relating to the configuration of updates. This element can be used either to request a new subscription or to update an existing one (e.g., to change the frequency of the updates), and to remove ongoing subscriptions as well (e.g., to stop an indefinite update). The MRB will inform the Media Server how long it wishes to receive updates for and the frequency that updates should be sent. Updates 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 subscrition session id to identify a specific subscription command. The first subscription MUST have 1 as 'seqnumber', and following subscriptions MUST increment by 1 the previous 'seqnumber' value. The attribute MUST be present.

action:

provides the operation that should be carried out on the subscription:

• The value of 'create' instructs the MS to attempt to setup a new subscription.
• The value of 'update' instructs the MS to attempt to update an existing subscription.
• The value of 'remove' instructs the MS to attempt to remove an existing subscription and consequently stop any ongoing related notification.

The attribute MUST be present.

The <subscription> element has the following child elements:

expires:

Provides the amount of time in seconds that a subscription should be installed for notifications at the Media Server. Once the amount of time has passed, the subscription expires and the MRB has to subscribe again in case it is still interested in receiving notifications from the MS. The element MAY be present.

frequency:

Provides the frequency in seconds that the MRB wishes to receive notifications from the MRB. The element MAY be present.

Please note that these two optional pieces of information provided by the MRB only act as a suggestion: the MS MAY change the proposed values if it considers the suggestions unacceptable (e.g., if the MRB has requested a too high notification frequency). In such case, the request would not fail, but the updated, acceptable values would be reported in the <mrbresponse> accordingly.

5.1.4.  <mrbnotification>

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

The <mrbnotification> element has the following attributes:

id:

indicates a unique token representing the session between the MRB and the Media Server and is the same as the one appearing in the <subscription> element. The attribute 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 MUST have 1 as 'seqnumber', and following notifications MUST increment by 1 the previous 'seqnumber' value. The attribute MUST be present.

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

5.1.4.1.  <media-server-id>

The <media-server-id> element provides a unique system wide identifier for a Media Server instance. The element MUST be present.

5.1.4.2.  <supported-packages>

The <supported-packages> element provides the list of Media Control Channel Packages supported by the media server. The element MAY be present.

The <supported-packages> element has no attributes.

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

package:

The <package> element represents the name of a package supported by the media server. The <package> element has a single attribute, 'name', which represents the name of the supported Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0").

5.1.4.3.  <active-rtp-sessions>

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

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

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

rtp-codec:

Is a container which represents a supported codec and the associated active sessions. The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec being represented. A valid value is a MIME media type which, depending on its definition, can include additional parameters (e.g., [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.)). The <rtp-codec> element has two child elements. The child element, <decoding>, represents the number of RTP sessions for the specified codec being decoded. The child element, <encoding>, represents the number of RTP sessions for the specified codec being encoded.

5.1.4.4.  <active-mixer-sessions>

The <active-mixer-sessions> element provides information detailing the current active mixed RTP sessions. The element MAY be present.

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

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

active-mix:

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

5.1.4.5.  <non-active-rtp-sessions>

The <non-active-rtp-sessions> element provides information detailing the currently available inactive RTP sessions. The element MAY be present.

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

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

rtp-codec:

Is a container which represents a supported codec and the inactive sessions. The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec being represented. A valid value is a MIME media type which, depending on its definition, can include additional parameters (e.g., [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.)). The <rtp-codec> element has two child elements. The first child element, <decoding>, represents the number of available incoming (decoding) RTP session for the specified codec. The second child element, <encoding>, represents the number of available outgoing (encoding) RTP sessions for the specified codec. The element MAY be present.

5.1.4.6.  <non-active-mixer-sessions>

The <non-active-mixer-sessions> element provides information detailing the current inactive mixed RTP sessions. The element MAY be present.

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

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

non-active-mix:

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

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

Indicating that the Media Server is available for service.

deactivated:

Indicating that the Media Server has been withdrawn from service, and as such should not be contacted before it becomes 'active' again.

unavailable:

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

5.1.4.8.  <supported-codecs>

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

The <supported-codecs> element has no attributes.

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

supported-codec:

has a single attribute, 'name', which provides the name of the codec providing information. A valid value is a MIME media type which, depending on its definition, can include additional parameters (e.g., [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.)). 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the codec support applies. The <supported-codec-package> element has one further child element, <supported-actions>, which provide the actions that a Media Server can apply to this codec:

• 'decode', meaning a decoder for this codec is available;
• 'encode', meaning an encoder for this codec is available;
• 'passthrough', meaning the MS is able to pass a stream encoded using that codec through without re-encoding.

5.1.4.9.  <application-data>

The <application-data> element provides arbitrary application level data. This data is meant to only have meaning at the application level logic and as such is arbitrary. The element MAY be present.

The <application-data> element has no attributes.

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

5.1.4.10.  <file-formats>

The <file-formats> element provides a list of file formats supported for the purpose of playing media. The element MAY be present.

The <file-formats> element has no attributes.

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

supported-format:

has a single attribute, 'name', which provides the type of file format that is supported. A valid value is a MIME media type which, depending on its definition, can include additional parameters (e.g., [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.)). 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.

5.1.4.11.  <max-prepared-duration>

The <max-prepared-duration> element provides the amount of time a media dialog can be prepared 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 the following child element:

max-time:

has a single attribute, 'max-time-seconds', which provides the amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has a further child element, <max-time-package>. The <max-time-package> element provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.

5.1.4.12.  <dtmf-support>

The <dtmf-support> element supplies the supported methods to detect DTMF tones and to generate them. The element MAY be present.

The <dtmf-support> element has no attributes.

The <dtmf-support> element has 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 either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 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 either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 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 either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 DTMF type applies.

5.1.4.13.  <mixing-modes>

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

The <mixing-modes> element has no attributes.

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

audio-mixing-modes:

Is a container representing the available algorithms for audio mixing. The <audio-mixing-modes> element has no attributes. The <audio-mixing-modes> element has one child element. The child element, <audio-mixing-mode>, contains a specific available algorithm. It has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm support applies.

video-mixing-modes:

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

5.1.4.14.  <supported-tones>

The <supported-tones> element provides information about which tones a media server supports. In particular, the support is reported referring to both country codes support (ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.)) and supported functionality (ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .)). The element MAY be present.

The <supported-tones> element has no attributes.

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

supported-country-codes:

Is a container representing the supported country codes with respect to tones. The <supported-country-codes> element has no attributes. The <supported-country-codes> has one child element. The child element, <country-code>, reports support for a specific country code, compliant with the ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.) 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 supported.

supported-h248-codes:

Is a container representing the supported H.248 codes with respect to tones. The <supported-h248-codes> element has no attributes. The <supported-h248-codes> has one child element. The child element, <h248-code>, reports support for a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .) 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the specified codes are supported.

5.1.4.15.  <streaming-modes>

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

The <streaming-modes> element has no attributes.

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

stream-mode:

has two attributes, 'name' and 'package'. The 'name' attribute provides the type of protocol that can be used for streaming (e.g., "HTTP", "RTSP", etc.). 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 streaming protocol applies.

5.1.4.16.  <asr-tts-support>

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

asr-support:

Is a container representing the available languages for ASR. The <asr-support> element has no attributes. The <asr-support> has one child element. The child element, <language>, reports the MS supports ASR for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO-639-1 (International Organization for Standardization, “Code for the representation of names of languages, 1st edition,” 1988.) [ISO.639.1988] code of the supported language.

tts-support:

Is a container representing the available languages for TTS. The <tts-support> element has no attributes. The <tts-support> has one child element. The child element, <language>, reports the MS supports tts for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO-639-1 (International Organization for Standardization, “Code for the representation of names of languages, 1st edition,” 1988.) [ISO.639.1988] code of the supported language.

5.1.4.17.  <vxml-support>

The <vxml-support> element specifies if the Media Server supports VoiceXML and if it does which protocols the support is exposed through (e.g., via the control framework, or RFC5552 [RFC5552] (Burke, D. and M. Scott, “SIP Interface to VoiceXML Media Services,” May 2009.)). The element MAY be present.

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

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

vxml-mode:

has two attributes, 'package' and 'support'. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support applies. The 'support' attribute provides the type of VXML support provided by the Media Server (RFC5552 [RFC5552] (Burke, D. and M. Scott, “SIP Interface to VoiceXML Media Services,” May 2009.) or IVR-Package [I‑D.ietf‑mediactrl‑ivr‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework,” February 2010.)).

5.1.4.18.  <media-server-location>

The <media-server-location> element provides information about the civic location of a media server. Its description makes use of the Civic Address Schema standardized in RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139]. The element MAY be present.

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

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

civicAddress:

Is a container representing the civic address location of the media server, whose representation refers to the Section 4 of RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139].

5.1.4.19.  <label>

The <label> element allows a Media Server to declare a piece of information that will be understood by the MRB. For example, the Media Server can declare if it's a blue or green one. It's a string to allow arbitrary values to be returned to allow arbitrary classification, and as such is not meant to provide any explicit information associated with the features of a MS. The element MAY be present.

The <label> element has no attributes.

The <label> element has no child elements.

5.1.4.20.  <media-server-address>

The <media-server-address> element allows a Media Server to provide a direct SIP URI address where it can be reached (e.g., the URI AS would call to in order to setup a Control Channel and relay call legs). The element MAY be present.

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

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

5.1.4.21.  <encryption>

The <encyption> element allows a Media Server to declare support for encrypting RTP media streams using RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711]. A value of 'true' indicates that a Media Server does support RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. A value of 'false' indicates that a Media Server does not support RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. The element MAY be present.

The <encryption> element has no attributes.

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

5.1.5.  <mrbresponse>

Responses to requests are indicated by a <response> element from Section 7 (Media Service Resource Publisher Interface XML Schema).

The <response> element has 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 following status codes are defined for 'status':

In case a new subscription request made by an MRB (action='create') has been accepted, the MS MUST reply with a <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 MS.

A subscription request, nevertheless, may fail for several reasons. In such a case, the status codes defined in Table 1 (<response> status codes) must be used instead. Specifically, if the MS fails to handle a request due to a syntax error in the request itself (e.g., incorrext XML, violation of the schema constraints or invalid values in any of the attributes/elements) the MS MUST reply with a <mrbresponse> with status code 400. If a syntactically correct request fails because the request also includes any attribute/element the MS doesn't understand, the MS MUST reply with a <mrbresponse> with status code 420. If a syntactically correct request fails because the MRB wants to create a new subscription, but the provided intended id for the subscription already exists, the MS MUST reply with a <mrbresponse> with status code 405. If a syntactically correct request failes because the MRB wants to update/remove a subscription that doesn't exist, the MS MUST reply with a <mrbresponse> with status code 404. If the MS is unable to accept a request for any other reason (e.g., the MRB has no more resources to fulfil the request), the MS MUST reply with a <mrbresponse> with status code 401/402/403, depending on the action the MRB provided in its request:

• action='create' --> 401;
• action='update' --> 402;
• action='remove' --> 403;

As explained in Section 5.1.3.1 (<subscription>), even in case of an accepted subscription request the MS might change the suggested 'expires' and 'frequency' values provided by the MRB in its <mrbrequest>, if it considers them unacceptable (e.g., the requested frequency is too high). In such a case, the MS MUST add an additional <subscription> element to the response, including the updated values, to inform the MRB about the change. The MS MAY include such element if the values have been accepted or were omitted in the request.

5.2.  Media Service Resource Consumer Interface

The Media Server Consumer interface provides the ability for clients of an MRB, such as Application Servers, to request an appropriate Media Server to satisfy specific criteria. The interface allows a client to pass detailed meta-information to the MRB to help select an appropriate Media Server. The MRB is then able to make an informed decision and provide the client with an appropriate media server resource. The MRB Consumer interface can be used in association with both the Session Initiation Protocol (SIP) and the Hypertext Transfer Protocol (HTTP) [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.). The following subsections provide guidance on using the Consumer interface, as defined by the 'application/mrb-consumer+xml MIME type in Section 8 (Media Service Resource Consumer Interface XML Schema), with HTTP and SIP.

5.2.1.  HTTP Consumer Interface Usage

An appropriate interface for such a 'query' style interface is in fact a HTTP usage. Using HTTP and XML combined reduces complexity and encourages use of common tools that are widely available in the industry today. The following information explains the primary operations required to request and then receive information from an MRB. The following description will describe the use of HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) and HTTPS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) as transport for a query for media resource and the appropriate response.

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

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

5.2.2.  SIP Consumer Interface Usage

This document provides a complete toolkit for MRB deployment which includes the ability to interact with an MRB using SIP for the Consumer interface. The following information explains the primary operations required to request and then receive information from an MRB. The following description will describe the use of SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) as transport for a query for media resource and the appropriate response when used with IAMM of operation (as discussed in Section 5.3.2 (In-line Aware MRB Mode)).

The media resource query, as defined by the <mediaResourceRequest> element from Section 8 (Media Service Resource Consumer Interface XML Schema), MUST be carried in a SIP INVITE request. The INVITE request will be constructed as it would have been to connect to a media server, as defined by the Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.). The following additional steps MUST be followed when using the Consumer interface:

• Include a payload in the SIP INVITE request of type 'multipart/mixed'[RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.). 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 [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).
• Another part of the 'multipart/mixed' payload MUST be of type 'application/mrb-consumer+xml', as specified in this document and defined in Section 8 (Media Service Resource Consumer Interface XML Schema). Only the <mediaResourceRequest> and its child elements can be included in the payload.
• The INVITE request will then be dispatched to the MRB, as defined by [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).

The media resource response to a query, as defined by the <mediaResourceResponse> element from Section 8 (Media Service Resource Consumer Interface XML Schema), MUST be carried in the payload of a SIP 2xx class response to the original SIP INVITE request. The 2xx class response will be constructed as it would have been to connect from a media server, as defined by the Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.). The following additional steps MUST be followed when using the Consumer interface:

• Include a payload in the SIP 2xx class response of type 'multipart/mixed'RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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 [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).
• Another part of the 'multipart/mixed' payload MUST be of type 'application/mrb-consumer+xml', as specified in this document and defined in Section 8 (Media Service Resource Consumer Interface XML Schema). Only the <mediaResourceResponse> and its child elements can be included in the payload.
• The SIP 2xx class response will then be dispatched from the MRB.
• A SIP ACK to the 2xx class response will then be sent back to the MRB.

5.2.3.  Consumer Interface Lease Mechanism

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

Before delving into the details of such lease mechanism, though, it's worthwhile to first clarify its role within the context of the Consumer interface. As explained in Section 5.1 (Media Server Resource Publish Interface), the knowledge the MRB has of the resources of all the MS it handles is imperfect. As such, how an MRB actually manages such resources depends on how it is implemented: one may choose to have the MRB keeping track and state of the allocated resources, or simply depend on the MS themselves to provide the information by means of the publishing interface notifications. Further information may be inferred by the signalling, in case the MRB is in the path of call legs. This means that the MRB may or may not be able to enforce the leasing mechanism it provides: such functionality is demanded, if necessary, to the actual deployment of a compliant entity, with the help of the information herein provided.

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

• <session-id> is a unique identifier that enables a Consumer client and MRB to correlate future media resource requests related to an initial media resource request. The <session-id> MUST be included in all future related requests (see <session-id> use later in this section when constructing a subsequent request).
• <seq> is a numeric value returned to the Consumer client. On issuing any future requests related to the media resource session (as determined by the <session-id> element) the consumer client MUST increment the value returned in the <seq> element and include in the request (see <seq> use later in this section when constructing a subsequent request).
• <expires> provides a value which represents the number of seconds the request for media resources is deemed alive. The Consumer client should issue a refresh of the request, as discussed later in this section, if the expires timer is due to fire and the media resources are still required.
• <media-server-address> provides a value which represents the SIP URI where the assigned MS can be contacted to make use of the required media resources.

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:

• <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>).
• <seq> is a numeric value returned to Consumer client in the initial request for media resources, as discussed earlier in this section (<seq> element included as part of the <session-info> element in the initial <mediaResourceResponse>). On issuing any future requests related to the specific media resource session (as determined by the <session-id> element) the consumer client MUST increment the value returned in the <seq> element from the initial response (contained in the <mediaResourceResponse>) for every new request. The value of the <seq> element in requests acts as a counter to and in conjunction with the unique <session-id> allows for unique identification of a request.
• <action> element provides the operation to be carried out by the MRB on receiving the request:
  • The value of 'update' is a request by the Consumer client to update the existing session at the MRB with alternate requirements which are contained in the remainder of the request. 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 at 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.

When used with SIP the <session-info> element MUST be included in either a SIP re-INVITE (as defined in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)) or a SIP UPDATE (as defined in[RFC3311] (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.)) request. When used with HTTP the <session-info> element MUST be included in a HTTP POST message (as defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.)).

5.2.4.  Media Service Resource Request

This section defines the XML elements for the Consumer interface. The formal XML schema definition for the Consumer interface can be found in Section 8 (Media Service Resource Consumer Interface XML Schema).

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

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 has the following child elements, only one of which is allowed to occur.

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

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

5.2.4.1.  element

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

5.2.4.1.1.  element

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

5.2.4.1.1.1.  element

The <session-info> element is included in Consumer requests when an update is being made to an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3 (Consumer Interface Lease Mechanism). The element MAY be present.

The <session-info> element has no attributes.

The <session-info> element has the following child elements:

session-id:

is a unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3 (Consumer Interface Lease Mechanism).

seq:

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

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 (Consumer Interface Lease Mechanism).

5.2.4.1.1.2.  element

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 the following child element:

package:

child element contains a string representing the Media Control Channel Framework package required by the Consumer client. The <package> element can appear multiple times. A valid value is a Control Package name as specified in the related IANA registry (e.g., "msc-ivr/1.0")

5.2.4.1.2.  element

The <ivrInfo> element provides a container 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 <stream-mode>.

5.2.4.1.2.1.  element

The <ivr-sessions> element indicates the number of IVR sessions 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 the following child element:

rtp-codec:

child element contains has a single attribute, 'name'. The 'name' attribute provides the name of the codec required for an IVR session and is an appropriately registered token. A valid value is a MIME media type which, depending on its definition, can include additional parameters (e.g., [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.)). The <rtp-codec> element has two child elements. The child element, <decoding>, represents the number of RTP sessions for which decoding using the specified codec is requested. The child element, <encoding>, represents the number of RTP sessions for which encoding using the specified codec is requested.

5.2.4.1.2.2.  element

The <file-formats> element provides a list of file formats required for the purpose of playing media. The element MAY be present.

The <file-formats> element has no attributes.

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

supported-format:

has a single attribute, 'name', which provides the type of file format that is supported. The <supported-format> element then has a further child element, <supported-file-package>. The <supported-file-package> element provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.

5.2.4.1.2.3.  element

The <dtmf> element supplies 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 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 needed, and it can only be either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 DTMF type applies.

generate:

Indicates the required 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 needed, and it can only be either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 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 being needed, and it can only be either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 DTMF type applies.

5.2.4.1.2.4.  <tones>

The <tones> element provides requested tones a media server must support for IVR. In particular, the request refers to both country codes support (ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.)) and requested functionality (ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .)). The element MAY be present.

The <tones> element has no attributes.

The <tones> element has the following child elements:

country-codes:

Is a container representing the requested country codes with respect to tones. The <country-codes> element has no attributes. The <country-codes> has one child element. The child element, <country-code>, requests a specific country code, compliant with the ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.) 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:

Is a container representing the requested H.248 codes with respect to tones. The <h248-codes> element has no attributes. The <h248-codes> has one child element. The child element, <h248-code>, requests a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .) 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the specified codes are requested.

5.2.4.1.2.5.  <asr-tts>

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

asr-support:

Is a container representing the available languages for ASR. The <asr-support> element has no attributes. The <asr-support> has one child element. The child element, <language>, requests the MS supports ASR for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO-639-1 (International Organization for Standardization, “Code for the representation of names of languages, 1st edition,” 1988.) [ISO.639.1988] code of the supported language.

tts-support:

Is a container requesting the available languages for TTS. The <tts-support> element has no attributes. The <tts-support> has one child element. The child element, <language>, requests the MS supports tts for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO-639-1 (International Organization for Standardization, “Code for the representation of names of languages, 1st edition,” 1988.) [ISO.639.1988] code of the supported language.

5.2.4.1.2.6.  element

The <vxml> element specifies if the Consumer client required VoiceXML and if it does which protocols the support is exposed through (e.g., via the control framework, or RFC5552 [RFC5552] (Burke, D. and M. Scott, “SIP Interface to VoiceXML Media Services,” May 2009.)). The element MAY be present.

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

The <vxml> element has the following child element:

vxml-mode:

has two attributes, 'package' and 'require'. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support applies. The 'require' attribute specifies the type of VXML support required by the Consumer client (RFC5552 [RFC5552] (Burke, D. and M. Scott, “SIP Interface to VoiceXML Media Services,” May 2009.) or IVR-Package [I‑D.ietf‑mediactrl‑ivr‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework,” February 2010.)).

5.2.4.1.2.7.  <location>

The <location> element requests a civic location for an IVR media server. The request makes use of the Civic Address Schema standardized in RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139]. The element MAY be present.

The <location> element has no attributes.

The <location> element one child element:

civicAddress:

Is a container representing the civic address location of the requested media server, whose representation refers to Section 4 of RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139].

5.2.4.1.2.8.  <encryption>

The <encryption> element allows a Consumer client to request support for encrypting RTP media streams using RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711]. A value of 'true' indicates that Consumer client requires support of RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. A value of 'false' indicates that a Consumer client does not require support of RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. The element MAY be present. The default value is 'false'

The <encryption> element has no attributes.

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

5.2.4.1.2.9.  <application-data>

The <application-data> element provides IVR application level data. The element MAY be present.

The <application-data> element has no attributes.

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

5.2.4.1.2.10.  <max-prepared-duration>

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

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

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

max-time:

has a single attribute, 'max-time-seconds', which provides the amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has a further child element, <max-time-package>. The <max-time-package> element provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.

5.2.4.1.2.11.  <streaming-modes>

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

The <streaming-modes> element has no attributes.

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

stream-mode:

has two attributes, 'name' and 'package'. The 'name' attribute provides the type of protocol required for streaming. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the streaming protocol applies.

5.2.4.1.3.  element

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

5.2.4.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 the following child element:

mix:

Is a container which represents a required mixed RTP session. The <mix> element has one attribute. The attribute 'users' represents the number of participants required in the mix. The <mix> element has one child elements. The child element, <codec>, contains the same information relating to RTP sessions as defined in Section 5.1.4.3 (<active-rtp-sessions>). The element MAY be present.

5.2.4.1.3.2.  <file-formats>

The <file-formats> element provides a list of file formats required by the Consumer client for the purpose of playing media to a mix. The element MAY be present.

The <file-formats> element has no attributes.

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

required-format:

has a single attribute, 'name', which provides the type of file format that is supported. The <required-format> element then has a further child element, <required-file-package>. The <required-file-package> element provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.

5.2.4.1.3.3.  element

The <dtmf> element supplies 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 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 it can only be either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 DTMF type applies.

generate:

Indicates the required 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 either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 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 being used, and it can only be either 'RFC4733' [RFC4733] (Schulzrinne, H. and T. Taylor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” December 2006.) or 'Media' (tones as signals in the audio stream). 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 DTMF type applies.

5.2.4.1.3.4.  <tones>

The <tones> element provides requested tones a media server must support for a mix. In particular, the request refers to both country codes support (ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.)) and requested functionality (ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .)). The element MAY be present.

The <tones> element has no attributes.

The <tones> element has the following child elements:

country-codes:

Is a container representing the requested country codes with respect to tones. The <country-codes> element has no attributes. The <country-codes> has one child element. The child element, <country-code>, requests a specific country code, compliant with the ISO 3166-1 [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.) 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:

Is a container representing the requested H.248 codes with respect to tones. The <h248-codes> element has no attributes. The <h248-codes> has one child element. The child element, <h248-code>, requests a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 [ITU‑T.Q.1950] (International Telecommunication Union - Telecommunication Standardization Bureau, “Call Bearer Control (CBC) Protocol,” .) 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the specified codes are requested.

5.2.4.1.3.5.  <mixing-modes>

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

The <mixing-modes> element has no attributes.

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

audio-mixing-modes:

Is a container representing the requested algorithms for audio mixing. The <audio-mixing-modes> element has no attributes. The <audio-mixing-modes> element has one child element. The child element, <audio-mixing-mode>, contains a specific requested algorithm. It has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm support is requested.

video-mixing-modes:

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

5.2.4.1.3.6.  <application-data>

The <application-data> element provides IVR application level data. The element MAY be present.

The <application-data> element has no attributes.

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

5.2.4.1.3.7.  <location>

The <location> element requests a civic location for a mixer media server. The request makes use of the Civic Address Schema standardized in RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139]. The element MAY be present.

The <location> element has no attributes.

The <location> element one child element:

civicAddress:

Is a container representing the civic address location of the requested media server, whose representation refers to Section 4 of RFC 5139 (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139].

5.2.4.1.3.8.  <encryption>

The <encryption> element allows a Consumer client to request support for encrypting mixed RTP media streams using RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711]. A value of 'true' indicates that Consumer client requires support of RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. A value of 'false' indicates that a Consumer client does not require support of RFC 3711 (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] for RTP. The element MAY be present. The default value is 'false'

The <encryption> element has no attributes.

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

5.2.5.  Media Service Resource Response

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

5.2.5.1.  element

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

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

In case a new media resource request made by an AS (no action) has been accepted, the MS 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 1 (<response> status codes) must be used instead. Specifically, if the MRB fails to handle a request due to a syntax error in the request itself (e.g., incorrext XML, violation of 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 the MRB couldn't find any MS able to fulfil the requirements presented by the AS 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 AS 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 AS, the MRB MUST reply with a <mediaResourceResponse> with status code 410.

Further details on status codes 409 and 410 are presented in Section 5.2.3 (Consumer Interface Lease Mechanism), where the leasing mechanism, together with its related scenarios, is described.

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

5.2.5.1.1.  element

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 (Consumer Interface Lease Mechanism). The element MAY be present: specifically, the element MUST be included in case the request was successful, while it would not appear otherwise (e.g., in case the request ended up with an error).

The <response-session-info> element has no attributes.

The <response-session-info> element has the following child elements:

session-id:

is a unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3 (Consumer Interface Lease Mechanism).

seq:

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

expires:

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

media-server-address:

is the SIP URI to reach the MS handling the requested media resource.

5.3.  In-Line MRB Interface

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

5.3.1.  In-line Unaware MRB Mode

It should be noted that the introduction of an MRB entity into the network, as specified in this document, requires interfaces to be implemented by those requesting media server resources (for example an application server). This applies when using both the Consumer interface as discussed in Section 5.2.1 (HTTP Consumer Interface Usage) and IAMM Section 5.2.2 (SIP Consumer Interface Usage). Nevertheless, an MRB is conceived to also be able to act in a client unaware mode when it is deployed into the network. This allows any SIP compliant client entity, as defined by RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and its extensions, to send requests to an MRB which in turn will select an appropriate media server based on knowledge of media server resources it currently has available transparently to the client entity. Mechanisms used to connect to media servers are detailed in the Media Channel Control Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.). Using an MRB in this mode allows for easy migration of current applications and services that are unaware of the MRB concept and would simply require a configuration change resulting in the MRB being set as a SIP outbound proxy for clients requiring media services. Any client of media services wishing to take advantage of the advanced techniques detailed in this document when using In-line mode would implement IAMM which is covered in Section 5.3.2 (In-line Aware MRB Mode).

5.3.2.  In-line Aware MRB Mode

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

• The client of the IAMM constructs a SIP INVITE request to connect to a Media Server as detailed in the Media Channel Control Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) with one exception.
• The client of the IAMM includes a MIME content type of multipart/mixed as defined in RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2046]. As part of this mixed payload, the client MUST at least include a content-type of type 'application/sdp' and a content type of type 'application/mrb-consumer+xml'. The part of type application/sdp represents the media server connection details and MUST adhere to the Media Channel Control Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.). The part of type 'application/mrb-consumer+xml' represents the IAMM contextual information and MUST adhere to the schema defined in Section 8 (Media Service Resource Consumer Interface XML Schema).
• Once the SIP INVITE request is constructed, it is sent to the recipient as per RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].

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

• Extract the multipart MIME payload from the SIP INVITE request. It will then use the contextual information provided by the client in the 'application/mrb-consumer+xml' part to determine which media server should be selected to service the request.
• Extract the 'application/sdp' part from the payload and use it to populate a new SIP INVITE request for connecting the client to the selected media server, as defined in the Media Channel Control Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.). The IAMM acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/mrb-consumer+xml' information from the SIP INVITE request and then forwards to the selected Media Server.

6.  Examples

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

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

6.1.  Publish Example

The following example assumes a control channel has been established and synced as described in the Media Control Channel Framework ([I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.)).

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

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

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

1. the subscription (A1), in an <mrbrequest> (CFW CONTROL);
2. the MS accepting the subscription (A2), in an <mrbresponse> (CFW 200);
3. a notification (A3), in a <mrbnotification> (CFW CONTROL event);
4. the ack to the notification (A4), in a framework level 200 message (CFW 200);

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

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



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

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



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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish" \
            xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
    <mrbnotification seqnumber="1" id="QQ6J3c">
        <media-server-id>a1b2c3d4</media-server-id>
        <supported-packages>
            <package name="msc-ivr/1.0"/>
            <package name="msc-mixer/1.0"/>
            <package name="mrb-publish/1.0"/>
            <package name="msc-example-pkg/1.0"/>
        </supported-packages>
        <active-rtp-sessions>
            <rtp-codec name="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"/>
            </non-active-mix>
        </non-active-mixer-sessions>
        <media-server-status>active</media-server-status>
        <supported-codecs>
            <supported-codecs name="audio/basic">
                <supported-codec-package name="msc-ivr/1.0">
                    <supported-actions>encoding</supported-actions>
                    <supported-actions>decoding</supported-actions>
                </supported-codec-package>
                <supported-codec-package name="msc-mixer/1.0">
                    <supported-actions>encoding</supported-actions>
                    <supported-actions>decoding</supported-actions>
                </supported-codec-package>
            </supported-codecs>
        </supported-codecs>
        <application-data>Testbed Prototype</application-data>
        <file-formats>
            <supported-format name="audio/x-wav">
                <supported-file-package/>
            </supported-format>
        </file-formats>
        <max-prepared-duration>
            <max-time max-time-seconds="3600">
                <max-time-package>msc-ivr</max-time-package>
            </max-time>
        </max-prepared-duration>
        <dtmf-support>
            <detect>
                <dtmf-type package="msc-ivr/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>
                <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>
        <streaming-modes>
            <stream-mode package="msc-ivr/1.0" name="HTTP"/>
        </streaming-modes>
        <asr-tts-support>
            <asr-support>
                <language xml:lang="en"/>
            </asr-support>
            <tts-support>
                <language xml:lang="en"/>
            </tts-support>
        </asr-tts-support>
        <vxml-support support="false">
            <vxml-mode package="msc-ivr/1.0"/>
        </vxml-support>
        <media-server-location>
           <ca:civicAddress xml:lang="it">
             <ca:country>IT</ca:country>
             <ca:A1>Campania</ca:A1>
             <ca:A3>Napoli</ca:A3>
             <ca:A6>Via Claudio</ca:A6>
             <ca:HNO>21</ca:HNO>
             <ca:LMK>University of Napoli Federico II</ca:LMK>
             <ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM>
             <ca:PC>80210</ca:PC>
           </ca:civicAddress>
        </media-server-location>
        <label>TestbedPrototype-01</label>
        <media-server-address>
                 sip:MediaServer@ms.example.com:5080
        </media-server-address>
        <encryption>false</encryption>
    </mrbnotification>
</mrbpublish>



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

6.2.  Consumer Example

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

6.2.1.  Query Example

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

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

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

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

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

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

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


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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
    <mediaResourceResponse reason="Resource found" status="200">
        <response-session-info>
            <session-id>0GX1jCYZ8WBa</session-id>
            <seq>1</seq>
            <expires>3600</expires>
            <media-server-address>
                sip:MediaServer@ms.example.com:5080
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
</mrbconsumer>

The rest of the scenario is omitted for brevity. After having received the 'mediaResourceResponse', the AS has the address of a MS able to fulfil its media requirements, and can start a Control Dialog with it.

6.2.2.  IAMM Example

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

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

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

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

1. the original INVITE (1), containing both a CFW-related SDP (COMEDIA information to negotiate a new Control Channel) and a Consumer <mediaResourceRequest>;
2. the INVITE sent by the MRB to the MS as a B2BUA (3.), containing only the CFW-related SDP from the original INVITE;.
3. the 200 OK sent by the MS back to the MRB (5.), to complete the CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the original INVITE (7.), containing both the CFW-related information sent by the MS and a Consumer <mediaResourceRequest> documenting the MRB's decision to use that MS.

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

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

   <mrbconsumer version="1.0" \
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceRequest>
        <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>10</decoding>
                    <encoding>10</encoding>
                </rtp-codec>
            </ivr-sessions>
            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>
            <streaming-modes>
                <stream-mode package="msc-ivr/1.0" name="HTTP"/>
            </streaming-modes>
        </ivrInfo>
    </mediaResourceRequest>
   </mrbconsumer>

   =_Part



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

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



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

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



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

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

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

   =_Part

The continuation of the scenario (the AS connecting to the MS to start the Control Channel, the SYNC message, etc.) are omitted for brevity.

7.  Media Service Resource Publisher Interface XML Schema

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

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

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

   This is the schema of the IETF MediaCtrl MRB package.

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

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


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

  SCHEMA IMPORTS

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

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

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

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

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

  Extensible core type

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


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


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

  TOP LEVEL ELEMENT: mrbpublish

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

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

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

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

  mrbrequest TYPE

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

<!--  mrbrequest -->

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

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

<!--  subscription -->

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

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


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

  mrbresponse TYPE

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

<!--  mrbresponse -->

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

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


<!--  supported-packages -->

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

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


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

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


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

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

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


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

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


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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

<!--  supported-codecs -->

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

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

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

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

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

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


<!--  application-data -->

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

<!--  file-formats -->

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

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

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

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

 <xsd: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" />

<!--  dtmf-support -->

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

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

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

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

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

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

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

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


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

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


<!--  mixing-modes -->

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

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

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

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

<xsd:complexType name="audio-mixing-modeType" 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" />
   <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>
   <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" />


<!--  streaming-modes -->

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


<!--  vxml-support -->

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

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

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

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


<!--  label -->

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


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

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


<!--  encryption -->

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


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

  DATATYPES

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


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

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

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

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

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

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

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

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

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

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

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

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

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

</xsd:schema>

8.  Media Service Resource Consumer Interface XML Schema

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

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

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

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

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

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


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

  SCHEMA IMPORTS

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

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

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

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

  Extensible core type

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


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


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

  TOP LEVEL ELEMENT: mrbconsumer

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

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

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

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

  mediaResourceRequest TYPE

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

<!--  mediaResourceRequst -->

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

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

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

  generalInfo TYPE

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

<!--  generalInfo -->

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

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


<!--  session-info -->

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

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

<!--  packages -->

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

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


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

  ivrInfo TYPE

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

<!--  ivrInfo -->

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

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


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

  mixerInfo TYPE

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

<!--  mixerInfo -->

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

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


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

  mediaResourceResponse TYPE

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

<!--  mediaResourceResponse -->

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


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


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

  ELEMENTS

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

<!--  session-info -->

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

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


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

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


<!--  ivr-sessions -->

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

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

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

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


<!-- file-format -->

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

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

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

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

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

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

<!--  dtmf-type -->

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

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

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

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

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

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

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

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

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

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

<!--  tones -->

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

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

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

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

<xsd:complexType name="country-codeType" 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>
      <xsd:element ref="asr-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:element ref="tts-support"
        minOccurs="0" maxOccurs="1" />
      <xsd:any namespace="##other" minOccurs="0"
        maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:anyAttribute namespace="##other" processContents="lax" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

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

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

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

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

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

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


<!--  vxml -->

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

<xsd:element name="vxml" type="vxmlType" />

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

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

<!--  location -->

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

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


<!--  encryption -->

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

<!--  application-data -->

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

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

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

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


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

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


<!--  stream-mode -->

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

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

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

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

<!--  mixers -->

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

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

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

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


<!--  mixing-modes -->

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

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

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

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

<xsd:complexType name="audio-mixing-modeType" 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" />
   <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>

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

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

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

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

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

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

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

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

</xsd:schema>

9.  Security Considerations

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

The Publish interface, as defined in and described in Section 5.1 (Media Server Resource Publish Interface), uses the Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) as a mechanism to connect an MRB to a media server. The appropriate Security Considerations included in the Media Control Channel Framework specification MUST be used in conjunction with this specification to protect interactions between an MRB and a media server.

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

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, as a B2BUA, the MRB may happen to modify SIP bodies: it is the case, for instance, of the IAMM handling multipart/mixed payloads. This impacts the ability to use any SIP security feature that protects the body (e.g., RFC4474, s/mime, etc.) unless the MRB intermediates the security association. This should be taken into account when implementing an MRB compliant with this specification.

Finally, it is worthwhile to also discuss authorization issues related to the specification. Neither the Publishing nor the Consumer interface provide an explicit means for implementing authentication, i.e., they do not envisage protocol messages to make sure, for instance, that only authorized Application Servers can make use of the services provided by a MRB. Nevertheless, considering both the interfaces are transported in well-established protocols (HTTP, SIP, CFW), support for such an functionality can be expressed by means of the authentication mechanisms provided by the protocol themselves. Therefore, any MRB-aware entity (Application Servers, Media Servers, Media Resource Brokers themselves) MUST support the HTTP and SIP Digest access authentication. That said, the usage of such Digest access authentications is recommended and not mandatory, which means MRB-aware entities MAY exploit it in deployment.

10.  IANA Considerations

There are several IANA considerations associated with this specification.

10.1.  Control Package Registration

This section registers a new Media Control Channel Framework package, per the instructions in Section 13.1 of [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).

To:

ietf-sip-control@iana.org

Subject:

Registration of new Channel Framework package

Package Name:

mrb-publish/1.0 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]

Published Specification(s):

RFCXXXX Person and email address to contact for further information: IETF, MEDIACTRL working group, (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).

10.2.  application/mrb-publish+xml MIME Type

MIME media type name:

application

MIME subtype name:

mrb-publish+xml

Mandatory parameters:

none

Optional parameters:

Same as charset parameter application/xml as specified in RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

Encoding considerations:

Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

Security considerations:

See Section 10 of RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) and Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace XXXX with the RFC number of this specification.]].

Interoperability considerations:

none.

Published specification:

This document.

Applications which use this media type:

This document type has been used to support a Media Resource Broker (MRB) entity.

Additional Information:

Magic Number:

None

File Extension:

.xdf

Macintosh file type code:

"TEXT"

Personal and email address for further information:

Chris Boulton, chris@ns-technologies.com

Intended usage: COMMON

Author/Change controller:

The IETF.

10.3.  application/mrb-consumer+xml MIME Type

MIME media type name:

application

MIME subtype name:

mrb-consumer+xml

Mandatory parameters:

none

Optional parameters:

Same as charset parameter application/xml as specified in RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

Encoding considerations:

Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

Security considerations:

See Section 10 of RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) and Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace XXXX with the RFC number of this specification.]].

Interoperability considerations:

none.

Published specification:

This document.

Applications which use this media type:

This document type has been used to support a Media Resource Broker (MRB) entity.

Additional Information:

Magic Number:

None

File Extension:

.xdf

Macintosh file type code:

"TEXT"

Personal and email address for further information:

Chris Boulton, chris@ns-technologies.com

Intended usage: COMMON

Author/Change controller:

The IETF.

10.4.  URN Sub-Namespace Registration for mrb-publish

Please register the URN name space "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". The template is in Section 7 (Media Service Resource Publisher Interface XML Schema).

10.5.  URN Sub-Namespace Registration for mrb-consumer

Please register the URN name space "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". The template is in Section 8 (Media Service Resource Consumer Interface XML Schema).

10.6.  XML Schema Registration for mrb-publish

Please register the schema for mrb-publish:

URI:

urn:ietf:params:xml:ns:mrb-publish

ID:

mrb-publish

Filename:

mbr-publish

Registrant Contact:

IETF, MEDIACTRL working group (mediactrl@ietf.org)

Schema:

The XML for the schema is in Section 7 (Media Service Resource Publisher Interface XML Schema) of this document.

10.7.  XML Schema Registration for mrb-consumer

Please register the schema for mrb-consumer:

URI:

urn:ietf:params:xml:ns:mrb-consumer

ID:

mrb-consumer

Filename:

mbr-consumer

Registrant Contact:

IETF, MEDIACTRL working group (mediactrl@ietf.org)

Schema:

The XML for the schema is in Section 8 (Media Service Resource Consumer Interface XML Schema) of this document.

11.  Changes

Note to RFC Editor: Please remove this whole section.

11.1.  Changes from 04 Version

• Corrected some typos and leftovers in both 'session-info' and 'response-session-info' definitions.
• Clarified that 'response-session-info' is not only included in reply to updates, but also to new requests; besides, clarified that it is an optional element, in the sense that it is mandatory in successful responses (200), while not needed otherwise (any error).
• Corrected the Query example flow which included a 'session'info' in a new request.

11.2.  Changes from 03 Version

• Addressed comments per the Expert RAI Review by Ben Campbell.
• Several editorial changes (fixes, typos, nits).
• Removed the 3xx class responses for the IAMM, per discussion in Anaheim (feature had been added in the -02 version).
• Clarified that backslashes and XML indentation in the Examples are only provided for readability.
• Clarified the distinction between 'deactivated' and 'unavailable'.
• Added text to the status codes in both Publish and Consumer responses, in order to clarify when they are involved.
• Added some text to better clarify the role of leasing in the Consumer interface.
• Added additional IANA considerations, that were missing in the previous versions of the document.
• Added text to the security considerations.

11.3.  Changes from 02 Version

• Added examples in Section 6 (Examples).
• Fixed some nits in the schemas (encryption and required mixed=true elements).
• Completed review nit review comments from Gary Munson.

11.4.  Changes from 01 Version

• Added description of lease mechanism.
• Added specific HTTP and SIP usage of Consumer interface.
• Completed Publish interface schema + associated text.
• Included Consumer interface schema + associated text.
• Included supported-packages element.
• Removed announce-var element from doc.
• Expanded Abstract.
• General scrub of text - input from Simon Romano.
• Added IANA Considerations section.
• Added Security Considerations section.

11.5.  Changes from 00 Version

• Included In-line text based on strawman proposal.
• Included first attempt at publish interface based on design team work.

12.  Acknowledgments

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

Ben Campbell carried out the RAI expert review on this specification and provided a great deal of invaluable input.

13.  References

13.1. Normative References

13.2. Informative References

Authors' Addresses