Network Working Group C. Boulton
Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero
Expires: November 24, 2011 Meetecho
G. Munson
AT&T
May 23, 2011
Media Resource Brokering
draft-ietf-mediactrl-mrb-09
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 24, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Boulton, et al. Expires November 24, 2011 [Page 1]
Internet-Draft Media Resource Brokering May 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publish Interface . . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 29
5.2. Media Service Resource Consumer Interface . . . . . . . . 30
5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 31
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 34
5.2.4. Media Service Resource Request . . . . . . . . . . . 36
5.2.5. Media Service Resource Response . . . . . . . . . . . 48
5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . . 50
6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 52
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 53
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 54
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 56
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 62
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 62
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 65
10. Media Service Resource Publisher Interface XML Schema . . . . 81
11. Media Service Resource Consumer Interface XML Schema . . . . 103
12. Security Considerations . . . . . . . . . . . . . . . . . . . 124
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
Boulton, et al. Expires November 24, 2011 [Page 2]
Internet-Draft Media Resource Brokering May 2011
13.1. Control Package Registration . . . . . . . . . . . . . . 125
13.2. application/mrb-publish+xml MIME Type . . . . . . . . . . 125
13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 126
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 127
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . . 127
13.6. XML Schema Registration for mrb-publish . . . . . . . . . 127
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 127
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
14.1. Changes from 08 Version . . . . . . . . . . . . . . . . . 129
14.2. Changes from 07 Version . . . . . . . . . . . . . . . . . 129
14.3. Changes from 06 Version . . . . . . . . . . . . . . . . . 129
14.4. Changes from 05 Version . . . . . . . . . . . . . . . . . 129
14.5. Changes from 04 Version . . . . . . . . . . . . . . . . . 130
14.6. Changes from 03 Version . . . . . . . . . . . . . . . . . 130
14.7. Changes from 02 Version . . . . . . . . . . . . . . . . . 130
14.8. Changes from 01 Version . . . . . . . . . . . . . . . . . 131
14.9. Changes from 00 Version . . . . . . . . . . . . . . . . . 131
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 132
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.1. Normative References . . . . . . . . . . . . . . . . . . 133
16.2. Informative References . . . . . . . . . . . . . . . . . 134
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 136
Boulton, et al. Expires November 24, 2011 [Page 3]
Internet-Draft Media Resource Brokering May 2011
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 [RFC5167] and RFC 5567
[RFC5567] documents. These documents make statements like "it should
be possible to have a many-to-many relationship between Application
Servers and Media Servers that use this protocol". This leads to the
following deployment architectures being possible when considering
media resources.
The simplest deployment view is illustrated in Figure 1.
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-------MS Control------>| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
This simply involves a single Application Server and Media Server.
Expanding on this view, it is also possible for an Application Server
to control multiple (greater that 1) Media Server instances at any
one time. This deployment view is illustrated in Figure 2.
Typically, such architectures are associated with application logic
that requires high demand media services. It is more than possible
that each media server possesses a different media capability set.
Media servers may offer different media services as specified in the
Mediactrl architecture document. A Media server may have similar
media functionality but may have different capacity or media codec
support.
Boulton, et al. Expires November 24, 2011 [Page 4]
Internet-Draft Media Resource Brokering May 2011
+---+-----+---+
| Media |
+----->| Server |
| +-------------+
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+
|
| +---+-----+---+
+----->| Media |
| Server |
+-------------+
Figure 2: Multiple Media Servers
Figure 3 conveys the opposite view to that in Figure 2. In this
model there are a number of (greater than 1) application servers,
possibly supporting dissimilar applications, controlling a single
media server. Typically, such architectures are associated with
application logic that requires low demand media services.
+---+-----+---+
| Application |
| Server |<-----+
+-------------+ |
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+
|
+---+-----+---+ |
| Application | |
| Server |<-----+
+-------------+
Figure 3: Multiple Application Servers
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
Boulton, et al. Expires November 24, 2011 [Page 5]
Internet-Draft Media Resource Brokering May 2011
capacity.
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-----+ +---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media |
| Server |<-----+ | Server |
+-------------+ +---+-----+---+
Figure 4: Basic Architecture
The high level deployment options discussed in this section rely on
network architecture and policy to prohibit inappropriate use. Such
policies are out of the scope of this document.
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.
Boulton, et al. Expires November 24, 2011 [Page 6]
Internet-Draft Media Resource Brokering May 2011
2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL".
This document inherits terminology proposed in RFC 5567 [RFC5567] and
Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] documents. In addition,
the following terms are defined for use in this document and for use
in the context of the MediaCtrl Work group in the IETF:
Media Resource Broker (MRB): A logical entity that is responsible
for both collection of appropriate published Media Server (MS)
information and 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.2.2.1.
In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
The document will often specify when a specific identifier in a
protocol message needs to be unique. Unless 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.
Boulton, et al. Expires November 24, 2011 [Page 7]
Internet-Draft Media Resource Brokering May 2011
3. Problem Discussion
As anticipated in Section 1, 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.
Boulton, et al. Expires November 24, 2011 [Page 8]
Internet-Draft Media Resource Brokering May 2011
4. Deployment Scenario Options
On researching Media Resource Brokering it became clear that a couple
of high level models exist. The general principles of "in-line" and
"query" MRB concepts are discussed in the rest of this section.
4.1. Query MRB
The "Query" model for MRB interactions provides the ability for a
client of media services (for example an Application Server) to "ask"
an MRB for an appropriate Media Server, as illustrated in Figure 5.
+---+-----+---+
+------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | |
| | | |
|(2) +---+--+--+---+ | |
| | Media | | |
| +---->| Server | | |
| | +-------------+ | |
| | (1)| |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ |
| |
| +---+-----+---+ (1)|
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 5: Query MRB
In this deployment, the Media Servers use the "Media Server Resource
Publish Interface", as discussed in Section 5.1, to convey capability
sets as well as resource information. This is depicted by (1) in
Figure 5. It is then the MRB's responsibility to accumulate all
appropriate information relating to media services in the logical
deployment cluster. The Application Server (or other media services
client) is then able to query the MRB for an appropriate resource (as
identified by (2) in Figure 5). Such a query would carry specific
information related to the Media Service required and enable the MRB
to provide an increased accuracy in its response. This particular
interface is discussed in "Media Resource Consumer Interface" in
Section 5.2. The Application Server is then able to direct control
commands (for example create conference) and Media Dialogs to the
Boulton, et al. Expires November 24, 2011 [Page 9]
Internet-Draft Media Resource Brokering May 2011
appropriate Media Server, as shown by (3) in Figure 5. Additionally,
with Query MRB, the MRB is not in the signaling path between the AS
and the selected MS resource.
4.1.1. Hybrid Query MRB
As mentioned previously, it is the intention that a tool kit is
provided for MRB functionality within a MediaCtrl architecture. It
is expected that in specific deployment scenarios the role of the MRB
might be co-hosted as a hybrid logical entity with an Application
Server, as shown in Figure 6.
+------------<----------------<---------+----<-----+---+
| (1) | | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
V +---->| Server | | |
+------+------+ | +-------------+ | |
| MRB | | | |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ |
| |
| +---+-----+---+ |
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 6: Hybrid Query MRB - AS Hosted
This diagram is identical to that in Figure 5 with the exception that
the MRB is now hosted on the Application Server. The "Media Server
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.
Boulton, et al. Expires November 24, 2011 [Page 10]
Internet-Draft Media Resource Brokering May 2011
(1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+
| | |
| | +---+--+--+---+ |
| +---<---| Application | |
| | Server |<--+-MS Control-+--+
| +-------------+ |
| |
| +---+--+--+---+ |
+---<-------| Application | |
| Server |<--+-MS Control-+--+
+-------------+
Figure 7: Hybrid Query MRB - MS Hosted
This time the MRB has collapsed and is co-hosted by the Media Server.
The "Media Server Consumer Interface" is still available to the
Application Servers (1) to query Media Server resources. This time
the "Media Server 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.
Boulton, et al. Expires November 24, 2011 [Page 11]
Internet-Draft Media Resource Brokering May 2011
+-------<----------+----<-------+---+
| | (1) | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
| +------>| Server | | |
| |(3) +-------------+ | |
| | (1)| |
+---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ |
| |
| (3) +---+-----+---+ (1)|
+------>| Media | |
| Server |--->---+
+---+-----+---+
Figure 8: In-line MRB
The Media Servers still use the 'Media Server Publish Interface' to
convey capabilities and resources to the MRB - as illustrated by (1).
The media server Control (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) and the MRB is left to deduce it by potentially
inspecting other information in the request from the AS; for
example, SDP content, or address of the requesting AS, or
additional Request-URI parameters as per RFC 4240 [RFC4240].
In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of
clients requiring media services who are aware of an MRB and its
operation. In particular it allows the AS to explicitly the
convey the same kinds of MS characteristics desired as does the
Query MRB mode (as in Section 5.2).
In either role, the MRB would deduce that the selected MS resources
are no longer needed when the AS or MS terminates the corresponding
Boulton, et al. Expires November 24, 2011 [Page 12]
Internet-Draft Media Resource Brokering May 2011
dialog. The two modes are discussed in more detail in Section 5.3.
Boulton, et al. Expires November 24, 2011 [Page 13]
Internet-Draft Media Resource Brokering May 2011
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.
Boulton, et al. Expires November 24, 2011 [Page 14]
Internet-Draft Media Resource Brokering May 2011
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 12 for more details.
The MRB Publish interface uses the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
interaction between a Media Server and an MRB. The Media Control
Channel Framework uses an extension mechanism to allow specific
usages which are known as control packages. Section 5.1.1 defines
the control package that MUST be implemented by any Media Server
wanting to interact with an MRB entity.
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].
5.1.1.1. Control Package Name
The Media Channel Control Framework requires a Control Package
definition to specify and register a unique name and version.
The name and version of this Control Package is "mrb-publish/1.0".
5.1.1.2. Framework Message Usage
The MRB publish interface allows a media server to convey available
capabilities and resources to an MRB entity.
This package defines XML elements in Section 5.1.2 and provides an
XML Schema in Section 10.
The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message
bodies; <mrbrequest> element is defined as a package request. This
request can be used for creating new subscriptions and updating/
removing existing subscriptions. Event notifications are also
carried in CONTROL message bodies; the <mrbnotification> element is
Boulton, et al. Expires November 24, 2011 [Page 15]
Internet-Draft Media Resource Brokering May 2011
defined for package event notifications. Responses are carried
either in REPORT message or Control Framework 200 response bodies;
the <mrbresponse> element is defined as a package level response.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of
[I-D.ietf-mediactrl-sip-control-framework]) are used when the request
or event notification is invalid; for example, a request has invalid
XML (400), or is not understood (500). Package level responses are
carried in framework 200 response or REPORT message bodies. This
package's response codes are defined in Section 5.1.5.
5.1.1.3. Common XML Support
The Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] requires a Control Package
definition to specify if the attributes for media dialog or
conference references are required.
The Publish interface defined in Section 10 does import and make use
of the common XML schema defined in the Media Control Channel
Framework.
The Consumer interface defined in Section 11 does import and make use
of the common XML schema defined in the Media Control Channel
Framework.
5.1.1.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in
Section 10 and described in Section 5.1.2. XML messages appearing in
CONTROL messages MUST contain either a <mrbrequest> or
<mrbnotification> element.
5.1.1.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 10
and described in Section 5.1.2. XML messages appearing in REPORT
messages MUST contain 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.
Boulton, et al. Expires November 24, 2011 [Page 16]
Internet-Draft Media Resource Brokering May 2011
5.1.2. Element Definitions
This section defines the XML elements for the Publish interface Media
Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in
Section 10.
The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5.
The <mrbpublish> element has the following attributes:
version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The
attribute 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.
<mrbresponse> for sending an MRB response. See Section 5.1.5.
<mrbnotification> for sending an MRB notification. See
Section 5.1.4.
5.1.3. <mrbrequest>
This section defines the <mrbrequest> element used to initiate
requests from an MRB to a Media Server. The element is a container
for information relevant for the interrogation of a media server.
The <mrbrequest> element has no defined attributes.
The <mrbrequest> element has the following sub-elements which are
defined in the remainder of this section:
<subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of
updates. This element can be used either to request a new
Boulton, et al. Expires November 24, 2011 [Page 17]
Internet-Draft Media Resource Brokering May 2011
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.
minfrequency: Provides the minimum frequency in seconds that the
MRB wishes to receive notifications from the MS. The element MAY
be present.
Boulton, et al. Expires November 24, 2011 [Page 18]
Internet-Draft Media Resource Brokering May 2011
maxfrequency: Provides the maximum frequency in seconds that the
MRB wishes to receive notifications from the MS. The element MAY
be present.
Please note that these three 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.
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:
Boulton, et al. Expires November 24, 2011 [Page 19]
Internet-Draft Media Resource Brokering May 2011
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]). 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 element. The
child element, <rtp-codec>, contains the same information relating
to RTP sessions as defined in Section 5.1.4.3. The element MAY be
present.
Boulton, et al. Expires November 24, 2011 [Page 20]
Internet-Draft Media Resource Brokering May 2011
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]). 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 element. The child element, <rtp-codec>,
contains the same information relating to RTP sessions as defined
in Section 5.1.4.5. 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:
Boulton, et al. Expires November 24, 2011 [Page 21]
Internet-Draft Media Resource Brokering May 2011
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]). 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.
Boulton, et al. Expires November 24, 2011 [Page 22]
Internet-Draft Media Resource Brokering May 2011
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]). 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.
Boulton, et al. Expires November 24, 2011 [Page 23]
Internet-Draft Media Resource Brokering May 2011
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] 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] 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] 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.
Boulton, et al. Expires November 24, 2011 [Page 24]
Internet-Draft Media Resource Brokering May 2011
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 the
name of a specific video presentation layout. The name may refer
to one of predefined video layouts defined in the XCON conference
information data model, or to non-XCON layouts as well, as long as
they are properly prefixed. The <video-mixing-mode> element has a
single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package, compliant
with 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]) and
supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).
The element MAY be present.
The <supported-tones> element has no attributes.
The <supported-tones> element has the following child elements:
Boulton, et al. Expires November 24, 2011 [Page 25]
Internet-Draft Media Resource Brokering May 2011
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] 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] 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.
Boulton, et al. Expires November 24, 2011 [Page 26]
Internet-Draft Media Resource Brokering May 2011
5.1.4.16. <asr-tts-support>
The <asr-tts-support> element provides information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The element MAY be
present.
The <asr-tts-support> element has no attributes.
The <asr-tts-support> element has the following child elements:
asr-support: Is a container representing the available languages
for ASR. The <asr-support> element has no attributes. The <asr-
support> has one child element. The child element, <language>,
reports the MS supports ASR for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
tts-support: Is a container representing the available languages
for TTS. The <tts-support> element has no attributes. The <tts-
support> has one child element. The child element, <language>,
reports the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
5.1.4.17. <vxml-support>
The <vxml-support> element specifies if the Media Server supports
VoiceXML and if it does which protocols the support is exposed
through (e.g., via the control framework, RFC4240 [RFC4240], or
RFC5552 [RFC5552]). 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
Boulton, et al. Expires November 24, 2011 [Page 27]
Internet-Draft Media Resource Brokering May 2011
applies. The 'support' attribute provides the type of VXML
support provided by the Media Server (RFC5552 [RFC5552], RFC4240
[RFC4240] or IVR-Package
[I-D.ietf-mediactrl-ivr-control-package]).
5.1.4.18. <media-server-location>
The <media-server-location> element provides information about the
civic location of a media server. Its description makes use of the
Civic Address Schema standardized in RFC 5139 [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 [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 a single attribute.
The <media-server-address> element has no child elements.
Boulton, et al. Expires November 24, 2011 [Page 28]
Internet-Draft Media Resource Brokering May 2011
5.1.4.21. <encryption>
The <encyption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. A value of
'true' indicates that a Media Server does support RFC 3711 [RFC3711]
for RTP. A value of 'false' indicates that a Media Server does not
support RFC 3711 [RFC3711] for RTP. The element MAY be present.
The <encryption> element has no attributes.
The <encryption> element has no child elements.
5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from
Section 10.
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':
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 401 | Unable to create Subscription |
| | |
| 402 | Unable to update Subscription |
| | |
| 403 | Unable to remove Subscription |
| | |
| 404 | Subscription does not exist |
| | |
| 405 | Subscription already exists |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 1: <mrbresponse> status codes
Boulton, et al. Expires November 24, 2011 [Page 29]
Internet-Draft Media Resource Brokering May 2011
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 must be used
instead. Specifically, if the MS fails to handle a request due to a
syntax error in the request itself (e.g., incorrect XML, violation of
the schema constraints or invalid values in any of the attributes/
elements) the 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 fails 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:
o action='create' --> 401;
o action='update' --> 402;
o action='remove' --> 403;
As explained in Section 5.1.3.1, even in case of an accepted
subscription request the MS might change the suggested 'expires',
'minfrequency' and 'maxfrequency' values provided by the MRB in its
<mrbrequest>, if it considers them unacceptable (e.g., the requested
frequency range is too high). In such a case, the 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
Boulton, et al. Expires November 24, 2011 [Page 30]
Internet-Draft Media Resource Brokering May 2011
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 includes both 1) In-Line Aware
MRB Mode (IAMM) that uses the Session Initiation Protocol (SIP) and
2) Query mode that uses the Hypertext Transfer Protocol (HTTP)
[RFC2616]. The MRB Consumer interface does not include In-Line
Unaware Mode (IUMM) which is further explained in Section 5.3. The
following subsections provide guidance on using the Consumer
interface, as defined by the 'application/mrb-consumer+xml MIME type
in Section 11, with HTTP and SIP.
5.2.1. Query Mode / HTTP Consumer Interface Usage
An appropriate interface for such a 'query' style interface is in
fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the
industry today. The following information explains the primary
operations required to request and then receive information from an
MRB. The following description will describe the use of HTTP
[RFC2616] and HTTPS [RFC2818] as transport for a query for media
resource and the appropriate response.
The media resource query, as defined by the <mediaResourceRequest>
element from Section 11, 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 11. 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 11, 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 11. The
'mediaResourceResponse' element is the primary container of
information related to a media resource response.
When an application server wants to release previously awarded media
resources granted through a prior request/response exchange with MRB,
it will send a new request with an <action> element with value
'remove' as described in Section Section 5.2.3 about the use of the
Consumer interface lease mechanism.
Boulton, et al. Expires November 24, 2011 [Page 31]
Internet-Draft Media Resource Brokering May 2011
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage
This document provides a complete toolkit for MRB deployment which
includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary
operations required to request and then receive information from an
MRB. The following description will describe the use of SIP
[RFC3261] as transport for a request for media resources and the
appropriate response when used with IAMM of operation (as discussed
in Section 5.2.2.1).
Use of IAMM, besides having the MRB select an appropriate media
resource on behalf of a client application, includes setting up
either a Control Framework control channel between an application
server and media server (Section 5.2.2.1) or a call leg media session
between an application server and a media server (Section 5.2.2.2).
Note that in either case the SIP address of the selected media server
is made known to the requesting application server in the SIP 200 OK
response as the media-server-address element in the <response-
session-info> element (Section 5.2.5).
5.2.2.1. IAMM and Setting up a Control Framework Control Channel
The media resource request information, as defined by the
<mediaResourceRequest> element from Section 11, MUST be carried in a
SIP INVITE request. The INVITE request will be constructed as it
would have been to connect to a media server, as defined by the Media
Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework].
The following additional steps MUST be followed when using the
Consumer interface:
o Include a payload in the SIP INVITE request of type 'multipart/
mixed'[RFC2046]. 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].
o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and
defined in Section 11. Only the <mediaResourceRequest> and its
child elements can be included in the payload.
o The INVITE request will then be dispatched to the MRB, as defined
by [I-D.ietf-mediactrl-sip-control-framework].
On receiving a SIP INVITE request containing the multipart mixed
payload as specified previously, the MRB will complete a number of
steps to fulfill the request. It will:
Boulton, et al. Expires November 24, 2011 [Page 32]
Internet-Draft Media Resource Brokering May 2011
o Extract the multipart MIME payload from the SIP INVITE request.
It will then use the contextual information provided by the client
in the 'application/mrb-consumer+xml' part to determine which
media server should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it to
populate a new SIP INVITE request for connecting the client to the
selected media server, as defined in the Media Channel Control
Framework [I-D.ietf-mediactrl-sip-control-framework].
The MRB acts as a Back-to-Back-UA (B2BUA) that extracts the
'application/mrb-consumer+xml' information from the SIP INVITE
request and then sends a corresponding SIP INVITE request to the
selected Media Server.
Once the MRB receives the SIP response from the selected media
resource (i.e., media server), it will in turn respond to the
requesting client (i.e., application server).
The media resource response by MRB to a request, as defined by the
<mediaResourceResponse> element from Section 11, 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]. The
following additional steps MUST be followed when using the Consumer
interface:
o Include a payload in the SIP 2xx class response of type
'multipart/mixed' as perRFC 2046 [RFC2046]. One of the parts to
be included in the 'multipart/mixed' payload MUST be the
'application/sdp' format which is constructed as specified in the
Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework].
o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and
defined in Section 11. Only the <mediaResourceResponse> and its
child elements can be included in the payload.
o The SIP 2xx class response will then be dispatched from the MRB.
o A SIP ACK to the 2xx class response will then be sent back to the
MRB.
An MRB implementation may be programmed to conclude that the
requested resources are no longer needed when it receives a SIP BYE
from the application server or media server that concludes the SIP
Boulton, et al. Expires November 24, 2011 [Page 33]
Internet-Draft Media Resource Brokering May 2011
dialog that initiated the request, or when the lease interval
expires.
5.2.2.2. IAMM and Setting up a Call Leg
This scenario is identical to the description in the prior section
for setting up a Control Framework control channel, except for the
difference that the application/sdp payload conveys content
appropriate for setting up the call leg to the media resource, as per
RFC 3261 [RFC2046], instead of application/sdp payload for setting up
a control channel.
5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 5.2 and Section 11 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, 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.
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:
o <session-id> is a unique identifier that enables a Consumer client
and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included
in all future related requests (see <session-id> use later in this
section when constructing a subsequent request).
Boulton, et al. Expires November 24, 2011 [Page 34]
Internet-Draft Media Resource Brokering May 2011
o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client
MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when
constructing a subsequent request).
o <expires> 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.
o <media-server-address> provides information representing the
assigned MS.
The <mediaResourceRequest> element is used in subsequent Consumer
interface requests if the client wishes to manipulate the session.
The Consumer client MUST include the <session-info> element which
enables the receiving MRB to determine an existing media resource
allocation session. The <session-info> element has the following
child elements which provide the appropriate resource session
information to the MRB:
o <session-id> is a unique identifier that allows a Consumer client
to indicate the appropriate existing media resource session to be
manipulated by the MRB for this request. The value was provided
by the MRB in the initial request for media resources, as
discussed earlier in this section (<session-id> element included
as part of the <session-info> element in the initial
<mediaResourceResponse>).
o <seq> is a numeric value returned to Consumer client in the
initial request for media resources, as discussed earlier in this
section (<seq> element included as part of the <session-info>
element in the initial <mediaResourceResponse>). On issuing any
future requests related to the specific media resource session (as
determined by the <session-id> element) the consumer client MUST
increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows
for unique identification of a request.
o <action> element provides the operation to be carried out by the
MRB on receiving the request:
Boulton, et al. Expires November 24, 2011 [Page 35]
Internet-Draft Media Resource Brokering May 2011
* 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]) or a SIP UPDATE (as
defined in[RFC3311]) request. When used with HTTP the <session-info>
element MUST be included in a HTTP POST message (as defined in
[RFC2616]).
With IAMM, the application server or media server will eventually
send a SIP BYE to end the SIP session, whether it was for a control
channel or a call leg. That BYE contains no Consumer interface lease
information. An MRB can be programmed to know that receipt of such a
BYE also means to free up the media resources that had been requested
and awarded related to that session.
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 11.
The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface
Boulton, et al. Expires November 24, 2011 [Page 36]
Internet-Draft Media Resource Brokering May 2011
request element is detailed in Section 5.2.4.1. MRB Consumer
interface response element is contained in Section 5.2.5.1.
The <mrbconsumer> element has the following attributes:
version: a token specifying the mrb-consumer package version. The
value is fixed as '1.0' for this version of the package. The
attribute 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.
<mediaResourceResponse> for sending a Consumer response. See
Section 5.2.5.1.
5.2.4.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides a container for clients
wishing to query an external MRB entity. The <mediaResourceRequest>
element has <generalInfo>, <ivrInfo> and <mixerInfo> as child
elements. These three elements are used to describe the requirements
of a client requesting a Media Server and are covered in the
following sub-sections.
5.2.4.1.1. <generalInfo> element
The <generalInfo> element provides a container for general Consumer
request information that is neither IVR or Mixer specific. This
includes session information that can be used for subsequent requests
as part of the leasing mechanism described in Section 5.2.3. The
following sub-sections describe the elements of the <generalInfo>
element, <session-info> and <packages>.
5.2.4.1.1.1. <session-info> element
The <session-info> element is included in Consumer requests when an
update is being made to an existing media resource session. The
ability to change and remove an existing media resource session is
described in more detail in Section 5.2.3. The element MAY be
present.
The <session-info> element has no attributes.
The <session-info> element has the following child elements:
Boulton, et al. Expires November 24, 2011 [Page 37]
Internet-Draft Media Resource Brokering May 2011
session-id: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more
detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources.
More information about its use is provided in Section 5.2.3.
action: provides the operation that should be carried out on an
existing media resource session on an MRB:
* The value of 'update' instructs the MRB to attempt to update
the existing media resource session with the information
contained in the <ivrInfo> and <mixerInfo> elements.
* The value of 'remove' instructs the MRB to attempt to remove
the existing media resource session. More information on its
use is provided in Section 5.2.3.
5.2.4.1.1.2. <packages> element
The <packages> element provides a list of Media Control Channel
Framework compliant packages that are required by the Consumer
client. The element 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. <ivrInfo> 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>.
Boulton, et al. Expires November 24, 2011 [Page 38]
Internet-Draft Media Resource Brokering May 2011
5.2.4.1.2.1. <ivr-sessions> element
The <ivr-sessions> element indicates the number of IVR sessions a
Consumer client requires from a media resource. The element 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]). The <rtp-codec>
element has two child elements. The child element, <decoding>,
represents the number of RTP sessions for which decoding using the
specified codec is requested. The child element, <encoding>,
represents the number of RTP sessions for which encoding using the
specified codec is requested.
5.2.4.1.2.2. <file-formats> element
The <file-formats> element provides a list of file formats required
for the purpose of playing media. 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 required. A valid value is a MIME
media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-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.2.3. <dtmf> 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:
Boulton, et al. Expires November 24, 2011 [Page 39]
Internet-Draft Media Resource Brokering May 2011
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] 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] 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]
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]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present.
The <tones> element has no attributes.
The <tones> element has the following child elements:
Boulton, et al. Expires November 24, 2011 [Page 40]
Internet-Draft Media Resource Brokering May 2011
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] 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] 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 [ISO.639.1988]
codes) for what regards both ASR and TTS. The <asr-tts-support>
element has no attributes. The <asr-tts-support> element has the
following child elements:
asr-support: Is a container representing the available languages
for ASR. The <asr-support> element has no attributes. The <asr-
support> has one child element. The child element, <language>,
requests the MS supports ASR for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
tts-support: Is a container requesting the available languages for
TTS. The <tts-support> element has no attributes. The <tts-
support> has one child element. The child element, <language>,
requests the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
Boulton, et al. Expires November 24, 2011 [Page 41]
Internet-Draft Media Resource Brokering May 2011
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
5.2.4.1.2.6. <vxml> element
The <vxml> element specifies if the Consumer client required VoiceXML
and if it does which protocols the support is exposed through (e.g.,
via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]).
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],
RFC4240 [RFC4240] or IVR-Package
[I-D.ietf-mediactrl-ivr-control-package]).
5.2.4.1.2.7. <location>
The <location> element requests a civic location for an IVR media
server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element 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 [RFC5139].
5.2.4.1.2.8. <encryption>
The <encryption> element allows a Consumer client to request support
for encrypting RTP media streams using RFC 3711 [RFC3711]. A value
of 'true' indicates that Consumer client requires support of RFC 3711
[RFC3711] for RTP. A value of 'false' indicates that a Consumer
client does not require support of RFC 3711 [RFC3711] for RTP. The
Boulton, et al. Expires November 24, 2011 [Page 42]
Internet-Draft Media Resource Brokering May 2011
element MAY be present. The default value is 'false'
The <encryption> element has no attributes.
The <encryption> 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:
Boulton, et al. Expires November 24, 2011 [Page 43]
Internet-Draft Media Resource Brokering May 2011
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. <mixerInfo> 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 element. The child element, <rtp-
codec>, contains the same information relating to RTP sessions as
defined in Section 5.1.4.3. 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. A valid value is a MIME
media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). 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
Boulton, et al. Expires November 24, 2011 [Page 44]
Internet-Draft Media Resource Brokering May 2011
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. <dtmf> 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] 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] 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] 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.
Boulton, et al. Expires November 24, 2011 [Page 45]
Internet-Draft Media Resource Brokering May 2011
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]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present.
The <tones> element has no attributes.
The <tones> element has 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] 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] 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:
Boulton, et al. Expires November 24, 2011 [Page 46]
Internet-Draft Media Resource Brokering May 2011
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 the name of a specific video presentation layout.
The name may refer to one of predefined video layouts defined in
the XCON conference information data model, or to non-XCON layouts
as well, as long as they are properly prefixed. The <video-
mixing-mode> element has a single attribute, 'package'. The
attribute 'package' provides the name of the Media Control Channel
Framework package, compliant with 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 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 [RFC5139]. The element MAY be present.
The <location> element has no attributes.
The <location> element one child element:
Boulton, et al. Expires November 24, 2011 [Page 47]
Internet-Draft Media Resource Brokering May 2011
civicAddress: Is a container representing the civic address
location of the requested media server, whose representation
refers to Section 4 of RFC 5139 [RFC5139].
5.2.4.1.3.8. <encryption>
The <encryption> element allows a Consumer client to request support
for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. A
value of 'true' indicates that Consumer client requires support of
RFC 3711 [RFC3711] for RTP. A value of 'false' indicates that a
Consumer client does not require support of RFC 3711 [RFC3711] for
RTP. The element 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. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a container for clients
receiving response 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':
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 408 | Unable to find Resource |
| | |
| 409 | Unable to update Resource |
| | |
| 410 | Unable to remove Resource |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Boulton, et al. Expires November 24, 2011 [Page 48]
Internet-Draft Media Resource Brokering May 2011
Table 2: <response> status codes
In case a new media resource request made by an AS (no action) has
been accepted, the MRB MUST reply with a <mediaResourceResponse> with
status code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MRB.
A media resource request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 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, 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. <response-session-info> 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. 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).
Boulton, et al. Expires November 24, 2011 [Page 49]
Internet-Draft Media Resource Brokering May 2011
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.
seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3.
expires: includes the number of seconds that the media resources
are reserved as part of this interaction. If the lease is not
refreshed before expiry, the MRB will re-claim the resources and
they will no longer be guaranteed. It is RECOMMENDED that a
minimum value of 300 seconds be used for the value of the
'expires' attribute. It is also RECOMMENDED that a Consumer
client refresh the lease at an interval that is not too close to
the expiry time. A value of 80% of the timeout period could be
used. For example, if the timeout period is 300 seconds, the
Server would refresh the transaction at 240 seconds. More
information on its use is provided in Section 5.2.3.
media-server-address: provides information to reach the MS handling
the requested media resource. The <media-server-address> element
has a single attribute named 'uri' which supplies the direct
address to a media server. It also has three optional elements
<connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions>
and <mixers> are defined in Section 5.2.4.1.2.1 and
Section 5.2.4.1.3.1 and have the same meaning but are applied to
individual media server instances as a subset of the overall
resources reported in the <connection-id> element. For more
information on the use of the <connection-id> element see
Section 6.
5.3. In-Line Unaware MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a
request, as introduced in Section 4.2. In-Line Unaware MRB Mode
(IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation.
This section further describes IUMM.
It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be
Boulton, et al. Expires November 24, 2011 [Page 50]
Internet-Draft Media Resource Brokering May 2011
implemented by those requesting media server resources (for example
an application server). This applies when using the Consumer
interface as discussed in Section 5.2.1(Query mode) and
Section 5.2.2(IAMM). Nevertheless, an MRB is conceived to also be
able to act in a client unaware mode when it is deployed into the
network. This allows any SIP compliant client entity, as defined by
RFC 3261 [RFC3261] and its extensions, to send requests to an MRB
which in turn will select an appropriate media server based on
knowledge of media server resources it currently has available
transparently to the client entity. Using an MRB in this mode allows
for easy migration of current applications and services that are
unaware of the MRB concept and would simply require a configuration
change resulting in the MRB being set as a SIP outbound proxy for
clients requiring media services.
With IUMM, the MRB may conclude that an assigned media resource is no
longer needed when it receives a SIP BYE from the application server
or media server that ends that SIP dialog that initiated the request.
As with IAMM, in IUMM the SIP INVITE from the application server
could convey application/sdp payload to either set up a call leg or a
Control Framework control channel. In either case, if the ultimate
intent is to correlate a call leg with a control channel to the same
media server, the MRB should be acting as a SIP proxy (and not a
B2BUA) so that the SIP address of the targeted media server can be
transparently passed back to the application server in the SIP
response and so that the SIP dialog information is between the
application server and the media server.
While IUMM has the least impact on legacy application servers, it
also provides the least versatility. See Section 8.
Boulton, et al. Expires November 24, 2011 [Page 51]
Internet-Draft Media Resource Brokering May 2011
6. MRB acting as a B2BUA
An MRB entity can potentially act as a SIP Back-2-Back-User-Agent
(B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When
acting as a B2BUA issues can arise when using Media Control Channel
packages such as the IVR
Package[I-D.ietf-mediactrl-ivr-control-package] and Mixer Packages
[I-D.ietf-mediactrl-mixer-control-package]. Specifically the
Framework attribute 'connectionid' provided in the appendix titled
'Appendix: Common Package Components' of Media Control Channel
Framework[I-D.ietf-mediactrl-sip-control-framework] uses a
concatenation of the SIP dialog identifiers to be used for
referencing SIP dialogs within the media control channel. When a
request traverses an MRB acting as a B2BUA, the SIP dialog
identifiers change and so the 'connectionid' can not be used as
intended due to the SIP dialog identifiers changing. For this reason
when a MRB wishes to act as a SIP B2BUA when handling a request from
an AS to set up a call leg to a MS it MUST include the optional
<connection-id> element in a Consumer interface response with a value
that represents the equivalent for the 'connectionid' ('Local Dialog
Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If
present, this value MUST be used as the value for the 'connectionid'
in packages where the Common Package Components are used. The
<connection-id> element MUST not be included in a HTTP Consumer
interface response.
Boulton, et al. Expires November 24, 2011 [Page 52]
Internet-Draft Media Resource Brokering May 2011
7. Multi-modal MRB Implementations
An MRB implementation may operate multi-modally with a collection of
application server clients all sharing the same pool of media
resources. I.e., an MRB may be simultaneously operating in Query
mode, IAMM and IUMM. It knows in which mode to act on any particular
request from a client depending on the nature of the request:
o If the received quest is HTTP Post with application/
mrb-consumer+xml content, then MRB processes it in Query mode.
o If the received request is a SIP INVITE with application/
mrb-consumer+xml content and application/sdp content, then MRB
processes it in IAMM.
o If the received request is a SIP INVITE without application/
mrb-consumer+xml content but with application/sdp content then MRB
processes it in IUMM.
Boulton, et al. Expires November 24, 2011 [Page 53]
Internet-Draft Media Resource Brokering May 2011
8. Relative Merits of Query Mode, IAMM, and IUMM
At a high level, the possible application server MRB interactions can
be distinguished among the following basic types:
a. Query mode, in which the client is requesting the assignment by
MRB of suitable MS resources
b. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a call leg to the
MS
c. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a CFW control
channel to the MS
d. IUMM where the client is requesting the establishment of a call
leg to MS resources
e. IUMM where the client is requesting the establishment of a CFW
control channel to MS resources
Each type of interaction has advantages and disadvantages compared to
the others, where such considerations may have to do with the
versatility of what MRB can provide, technical aspects such as
efficiency in different application scenarios, complexity, delay, use
with legacy application servers, or use with the Media Control
Channel Framework. Depending on the characteristics of a particular
setting that an MRB is intended to support, some of the above
interaction types may be more appropriate than others. This section
makes a few observations on relative merits, but is not intended to
be exhaustive. Some constraints of a given interaction type may be
subtle.
o About operation with other types of media control: Any of the
types of interactions work with the use RFC 4240 [RFC4240] and RFC
5552 [RFC5552] where initial control instructions are conveyed in
the SIP INVITE from the application server for the call leg to the
media server and subsequent instructions may be fetched using
HTTP. Query mode (a), IAMM/call leg (b) and IUMM/call leg (d)
work with MSML as per RFC 5705 [RFC5705] or MSCML as per RFC 4722
[RFC4722].
o As stated previously, IUMM has no interface impacts on an
application server. On the other hand, with IUMM the application
server does not specify the characteristics of the type of media
resource it needs because the <mediaResourceRequest> element is
not passed to the MRB. For IUMM call leg (d) the best the MRB can
Boulton, et al. Expires November 24, 2011 [Page 54]
Internet-Draft Media Resource Brokering May 2011
do to deduce an appropriate media resource gleaned from examining
other information in the SIP INVITE, such as the SDP information
for the call leg, or initial control information in the SIP
Request URI as per RFC 4240 [RFC4240]. With IUMM/control channel
(e) there is even less information for the MRB to use.
o If using IUMM/control channel (e), the subsequent sending of the
call leg to the media server should not be done using IUMM/call
leg. I.e., the SIP signaling to send the call leg to the selected
media server must be directly between the application server and
that media server, and not through the MRB. Otherwise, MRB might
send the call leg to a different media server. Likewise, if using
IUMM/call leg (d), the subsequent establishment of a control
channel should not be done with IUMM/control channel (e).
o Query mode (a) and IAMM/control channel (c) lend themselves to
requesting in advance a pool of media resources (e.g., a number of
IVR or conferencing ports) in advance of use and retaining their
use over a period of time, independent of whether there are call
legs to those resources at any given moment, whereas the other
types of interactions do not. Likewise for making a subsequent
request to increase or decrease the amount of resources previously
awarded.
o While Query mode (a) and IAMM/control channel (c) are the most
versatile interaction types, the former is completely decoupled
from the use or not of a control channel, whereas the latter
requires the use of a control channel.
o When Media Control Channel Framework control channels are to be
used in conjunction with the use of MRB, Query mode (a) would
typically result in fewer such channels being established over
time as compared to IAMM/control channel (c). That is because the
latter would involve setting up an additional control channel
every time an AS has a new request for MBR for media resources.
Boulton, et al. Expires November 24, 2011 [Page 55]
Internet-Draft Media Resource Brokering May 2011
9. 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.
9.1. Publish Example
The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]).
Figure 9 shows the subscription/notification mechanism the Publish
interface is based on, as defined in Section 5.1. The MRB subscribes
for information at the MS (message A1.), and the MS accepts the
subscription (A2). Notifications are triggered by the MS (A3.) and
acknowledged by the MRB (A4.).
Boulton, et al. Expires November 24, 2011 [Page 56]
Internet-Draft Media Resource Brokering May 2011
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
Figure 9: Publish Example: Sequence Diagram
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
1. the subscription (A1), in an <mrbrequest> (CFW CONTROL);
2. the MS accepting the subscription (A2), in an <mrbresponse> (CFW
200);
3. a notification (A3), in a <mrbnotification> (CFW CONTROL event);
4. the ack to the notification (A4), in a framework level 200
message (CFW 200);
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
Boulton, et al. Expires November 24, 2011 [Page 57]
Internet-Draft Media Resource Brokering May 2011
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>600</expires>
<minfrequency>20</minfrequency>
<maxfrequency>20</maxfrequency>
</subscription>
</mrbrequest>
</mrbpublish>
A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4242
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id>
<supported-packages>
<package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/>
<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>
Boulton, et al. Expires November 24, 2011 [Page 58]
Internet-Draft Media Resource Brokering May 2011
<active-mixer-sessions>
<active-mix conferenceid="7cfgs43">
<rtp-codec name="audio/basic">
<decoding>3</decoding>
<encoding>3</encoding>
</rtp-codec>
</active-mix>
</active-mixer-sessions>
<non-active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>50</decoding>
<encoding>40</encoding>
</rtp-codec>
</non-active-rtp-sessions>
<non-active-mixer-sessions>
<non-active-mix available="15">
<rtp-codec name="audio/basic">
<decoding>15</decoding>
<encoding>15</encoding>
</rtp-codec>
</non-active-mix>
</non-active-mixer-sessions>
<media-server-status>active</media-server-status>
<supported-codecs>
<supported-codec name="audio/basic">
<supported-codec-package name="msc-ivr/1.0">
<supported-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-codec>
</supported-codecs>
<application-data>TestbedPrototype</application-data>
<file-formats>
<supported-format name="audio/x-wav">
<supported-file-package>
msc-ivr/1.0
</supported-file-package>
</supported-format>
</file-formats>
<max-prepared-duration>
<max-time max-time-seconds="3600">
<max-time-package>msc-ivr/1.0</max-time-package>
</max-time>
</max-prepared-duration>
Boulton, et al. Expires November 24, 2011 [Page 59]
Internet-Draft Media Resource Brokering May 2011
<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>
Boulton, et al. Expires November 24, 2011 [Page 60]
Internet-Draft Media Resource Brokering May 2011
</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="true">
<vxml-mode package="msc-ivr/1.0" support="IVR-Package"/>
</vxml-support>
<media-server-location>
<civicAddress xml:lang="it">
<country>IT</country>
<A1>Campania</A1>
<A3>Napoli</A3>
<A6>Via Claudio</A6>
<HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK>
<NAM>Dipartimento di Informatica e Sistemistica</NAM>
<PC>80210</PC>
</civicAddress>
</media-server-location>
<label>TestbedPrototype-01</label>
<media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
<encryption>false</encryption>
</mrbnotification>
</mrbpublish>
Boulton, et al. Expires November 24, 2011 [Page 61]
Internet-Draft Media Resource Brokering May 2011
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
9.2. Consumer Example
As specified in Section 5.2, the Consumer interface can be involved
in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of
such an approach is presented in Section 9.2.1. When in Inline-aware
mode, instead, messages are transported as part of SIP negotiations:
considering this SIP negotiations may be related to either the
creation of a control channel or to a UAC call leg, two separate
examples of such an approach are presented in Section 9.2.2.
9.2.1. Query Example
The following example assumes the interested AS already knows the
HTTP URL where an MRB is listening for Consumer messages.
Figure 10 shows the HTTP-based transaction between the AS and the
MRB. The AS sends a consumer request as payload of an HTTP POST
message (1.), and the MRB provides an answer in an HTTP 200 OK
message (2.). Specifically, as it will be shown in the dumps, the AS
is interested in 100 IVR ports: the MRB finds two MS that can satisfy
the request (one providing 60 ports, the other 40 ports) and reports
them to the AS.
Boulton, et al. Expires November 24, 2011 [Page 62]
Internet-Draft Media Resource Brokering May 2011
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with first MS reported by MRB |
| |
. .
. .
Figure 10: Consumer Example (Query): Sequence Diagram
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST,
Content-Type 'application/mrb-consumer+xml');
2. the Consumer response (2), in 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: 879
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>
Boulton, et al. Expires November 24, 2011 [Page 63]
Internet-Draft Media Resource Brokering May 2011
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<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: 1133
Date: Mon, 12 Apr 2011 14:59:26 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>5t3Y4IQ84gY1</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address \
uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
Boulton, et al. Expires November 24, 2011 [Page 64]
Internet-Draft Media Resource Brokering May 2011
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
The rest of the scenario is omitted for brevity. After having
received the 'mediaResourceResponse', the AS has the address of two
MS able to fulfil its media requirements, and can start a Control
Dialog with one or both of them.
9.2.2. IAMM Example
As anticipated, two separate examples are presented for the IAMM
case: in fact, IAMM-mode can take advantage of two different
approaches with respect to the SIP dialogs to be exploited to carry
consumer messages, i.e.: i) a SIP control dialog to create a control
channel, and, ii) a UAC call leg to attach to a MS. To make things
clearer for the reader, the same consumer request as the one
presented in the Query mode will be sent, in order to clarify how the
behaviour of the involved parties may differ.
9.2.2.1. IAMM Example: CFW-based approach
The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS.
Figure 11 shows the first approach, i.e. SIP-based transactions
involving the AS interested in setting up a control channel, 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 have
been chosen, the MRB sends a new SIP INVITE to one of the MS by just
including the SDP part of the original request (3.). The MS
negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing
the MRB with its own CFW-related SDP. The MRB replies to the
Boulton, et al. Expires November 24, 2011 [Page 65]
Internet-Draft Media Resource Brokering May 2011
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.
Boulton, et al. Expires November 24, 2011 [Page 66]
Internet-Draft Media Resource Brokering May 2011
AS MRB MS
| | |
| 1. INVITE | |
| (multipart/mixed) | |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Extract SDP and |
| | | MRB payloads; handle |
| |<-+ Consumer request to |
| | pick MS |
| | |
| | 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 |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
Boulton, et al. Expires November 24, 2011 [Page 67]
Internet-Draft Media Resource Brokering May 2011
Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP
messages are shown (both the INVITEs and the 200 OKs), and only the
relevant headers are preserved for brevity (Content-Type and
multipart-related information). Specifically:
1. the original INVITE (1), containing both a CFW-related SDP
(COMEDIA information to negotiate a new Control Channel) and a
Consumer <mediaResourceRequest>;
2. the INVITE sent by the MRB to the MS as a B2BUA (3.), containing
only the CFW-related SDP from the original INVITE;.
3. the 200 OK sent by the MS back to the MRB (5.), to complete the
CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (7.), containing both the CFW-related information
sent by the MS and a Consumer <mediaResourceRequest> documenting
the MRB's decision to use that MS.
1. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_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
Boulton, et al. Expires November 24, 2011 [Page 68]
Internet-Draft Media Resource Brokering May 2011
<?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>100</decoding>
<encoding>100</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
Boulton, et al. Expires November 24, 2011 [Page 69]
Internet-Draft Media Resource Brokering May 2011
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
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" \
Boulton, et al. Expires November 24, 2011 [Page 70]
Internet-Draft Media Resource Brokering May 2011
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address \
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
=_Part
As it can be evinced from the dumps, the only difference in the
response the MRB provides the AS with is in the 'connection-id'
attribute that is added to the first allocated MS instance: this
allows the AS to understand the MRB has sent the CFW channel
negotiation to that specific MS, and that the connection-id to be
used (should the SIP control dialog also include media-related SDP
later on) is the one provided. This will be more carefully described
in the next section, for the call leg-based approach.
The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for
brevity.
Boulton, et al. Expires November 24, 2011 [Page 71]
Internet-Draft Media Resource Brokering May 2011
9.2.2.2. IAMM Example: Call leg-based approach
The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS.
Figure 12 shows the second approach, i.e. SIP-based transactions
related to a UAC call leg the AS wants to attach to a MS, the MRB and
the MS that will be chosen eventually. The interaction is basically
the same as before (e.g. for what concerns the multipart body) but
considering a new party is involved in the communication, the diagram
is slightly more complex than before. As before, the MRB acts as a
B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the AS,
since it is interested to its services (1.). The AS sends a
provisional response (2.) and, since it doesn't have the resources
yet, sends to the MRB a new SIP INVITE (3.), containing both the UAC
media-related SDP and a Consumer request (multipart body). The MRB
sends a provisional response to the AS (4.) 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 chosen. Once the right MS have
been chosen, the MRB sends a new SIP INVITE to one of the MS by just
including the SDP part of the original request (5.). The MS
negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (6., 7., 8.) to allocate
the needed media resources to handle the new call leg, eventually
providing the MRB with its own media-related SDP. The MRB replies to
the original AS INVITE preparing a SIP 200 OK with another multipart
body (9.): this multipart body includes the Consumer response from
the MRB indicating the chosen MS and the SDP returned by the MS in 7.
The AS finally acknowledges the 200 OK (10.), and ends the scenario
by eventually providing the UAC with the SDP it needs to setup the
RTP channels with the chosen MS: a separate direct SIP control dialog
may be initiated by the AS to the same MS in order to set up a
control channel to manipulate the call leg media.
As with the IAMM - CFW example in the prior section, this example has
the MRB selecting MS resources across two MS instances. And here
again the convention can be that the MRB sent the SIP INVITE to the
first MS in the list provided to the AS in the Consumer response
information.
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.
UAC AS MRB MS
Boulton, et al. Expires November 24, 2011 [Page 72]
Internet-Draft Media Resource Brokering May 2011
| | | |
| 1. INVITE | | |
| (media SDP) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed) | |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (only copy SDP from 3.) |
| | |-------------------------->|
| | | 6. 100 (Trying) |
| | |<--------------------------|
| | | +--|
| | | Handle call leg | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | |<--------------------------|
| | | 8. ACK |
| | |-------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed) | |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Cons. reply | |
| | | and send SDP | |
| |<-+ back to UAC | |
| 11. 200 OK | | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
Boulton, et al. Expires November 24, 2011 [Page 73]
Internet-Draft Media Resource Brokering May 2011
|<<*************************** RTP *******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| |<<############## TCP CONNECTION #################>>|
| | |
| | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
Figure 12: Consumer Example (IAMM-CallLeg): Sequence Diagram
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP
messages are shown (both the INVITEs and the 200 OKs), and only the
relevant headers are preserved for brevity (Content-Type, From/To and
multipart-related information). Specifically:
1. the original INVITE (1), containing the media-related SDP sent by
a UAC;
2. the original INVITE (3), containing both the media-related SDP
and a Consumer <mediaResourceRequest>;
3. the INVITE sent by the MRB to the MS as a B2BUA (5.), containing
only the media-related SDP from the original INVITE;
4. the 200 OK sent by the MS back to the MRB (7.), to complete the
media-related negotiation (SDP only);
5. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (9.), containing both the media-related
information sent by the MS and a Consumer <mediaResourceRequest>
documenting the MRB's decision to use that MS;
6. the 200 OK sent by the AS back to the UAC to have it setup the
RTP channel(s) with the MS (11.).
Boulton, et al. Expires November 24, 2011 [Page 74]
Internet-Draft Media Resource Brokering May 2011
1. UAC -> AS (INVITE with media SDP)
------------------------------------
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
3. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
=_Part
Boulton, et al. Expires November 24, 2011 [Page 75]
Internet-Draft Media Resource Brokering May 2011
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
=_Part
5. MRB -> MS (INVITE sdp only)
------------------------------
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
Boulton, et al. Expires November 24, 2011 [Page 76]
Internet-Draft Media Resource Brokering May 2011
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
7. MRB <- MS (200 OK sdp)
-------------------------
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
9. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>;tag=117652221
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
Boulton, et al. Expires November 24, 2011 [Page 77]
Internet-Draft Media Resource Brokering May 2011
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address \
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
Boulton, et al. Expires November 24, 2011 [Page 78]
Internet-Draft Media Resource Brokering May 2011
</mediaResourceResponse>
</mrbconsumer>
=_Part
11. UAC <- AS (200 OK sdp)
--------------------------
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
As it can be evinced from the dumps, as in the IAMM-CFW example the
MRB provides the AS with a 'connection-id' attribute in the consumer
response: this connection-id allows the AS to understand the MRB has
sent the SDP media negotiation to that specific MS, and that the
connection-id to be used in CFW requests is the one provided. This
attribute is needed, since, according to the framework specification,
the AS should build this connection-id out of the From/To tags
extracted from the negotiation with the MS: since the MRB acts as a
B2BUA in this scenario, without that attribute the AS and the MS
would refer to different tags and, as a consequence, different
connection-ids, thus preventing the CFW protocol to work as expected.
The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for
Boulton, et al. Expires November 24, 2011 [Page 79]
Internet-Draft Media Resource Brokering May 2011
brevity.
Boulton, et al. Expires November 24, 2011 [Page 80]
Internet-Draft Media Resource Brokering May 2011
10. Media Service Resource Publisher Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package.
The schema namespace is urn:ietf:params:xml:ns:mrb-publish
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<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">
Boulton, et al. Expires November 24, 2011 [Page 81]
Internet-Draft Media Resource Brokering May 2011
<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
#####################################################
-->
Boulton, et al. Expires November 24, 2011 [Page 82]
Internet-Draft Media Resource Brokering May 2011
<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 -->
Boulton, et al. Expires November 24, 2011 [Page 83]
Internet-Draft Media Resource Brokering May 2011
<xsd:complexType name="subscriptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="minfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="maxfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:attribute name="action" type="action.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" />
<!--
#####################################################
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" />
Boulton, et al. Expires November 24, 2011 [Page 84]
Internet-Draft Media Resource Brokering May 2011
</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"
Boulton, et al. Expires November 24, 2011 [Page 85]
Internet-Draft Media Resource Brokering May 2011
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 -->
Boulton, et al. Expires November 24, 2011 [Page 86]
Internet-Draft Media Resource Brokering May 2011
<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>
Boulton, et al. Expires November 24, 2011 [Page 87]
Internet-Draft Media Resource Brokering May 2011
</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>
Boulton, et al. Expires November 24, 2011 [Page 88]
Internet-Draft Media Resource Brokering May 2011
<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" />
Boulton, et al. Expires November 24, 2011 [Page 89]
Internet-Draft Media Resource Brokering May 2011
</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 -->
Boulton, et al. Expires November 24, 2011 [Page 90]
Internet-Draft Media Resource Brokering May 2011
<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>
Boulton, et al. Expires November 24, 2011 [Page 91]
Internet-Draft Media Resource Brokering May 2011
</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"
Boulton, et al. Expires November 24, 2011 [Page 92]
Internet-Draft Media Resource Brokering May 2011
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>
Boulton, et al. Expires November 24, 2011 [Page 93]
Internet-Draft Media Resource Brokering May 2011
<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" />
Boulton, et al. Expires November 24, 2011 [Page 94]
Internet-Draft Media Resource Brokering May 2011
<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">
Boulton, et al. Expires November 24, 2011 [Page 95]
Internet-Draft Media Resource Brokering May 2011
<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"
Boulton, et al. Expires November 24, 2011 [Page 96]
Internet-Draft Media Resource Brokering May 2011
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" />
Boulton, et al. Expires November 24, 2011 [Page 97]
Internet-Draft Media Resource Brokering May 2011
</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">
Boulton, et al. Expires November 24, 2011 [Page 98]
Internet-Draft Media Resource Brokering May 2011
<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"
Boulton, et al. Expires November 24, 2011 [Page 99]
Internet-Draft Media Resource Brokering May 2011
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" />
Boulton, et al. Expires November 24, 2011 [Page 100]
Internet-Draft Media Resource Brokering May 2011
<!-- 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">
Boulton, et al. Expires November 24, 2011 [Page 101]
Internet-Draft Media Resource Brokering May 2011
<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="RFC4240" />
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
Figure 13
Boulton, et al. Expires November 24, 2011 [Page 102]
Internet-Draft Media Resource Brokering May 2011
11. Media Service Resource Consumer Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-consumer+xml" format.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB Consumer interface.
The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
Boulton, et al. Expires November 24, 2011 [Page 103]
Internet-Draft Media Resource Brokering May 2011
<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"
Boulton, et al. Expires November 24, 2011 [Page 104]
Internet-Draft Media Resource Brokering May 2011
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>
Boulton, et al. Expires November 24, 2011 [Page 105]
Internet-Draft Media Resource Brokering May 2011
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generalInfo" type="generalInfoType" />
<!-- session-info -->
<xsd:complexType name="session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="session-info" type="session-infoType" />
<!-- 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>
Boulton, et al. Expires November 24, 2011 [Page 106]
Internet-Draft Media Resource Brokering May 2011
</xsd:complexType>
<xsd:element name="packages" type="packagesType"/>
<!--
#####################################################
ivrInfo TYPE
#####################################################
-->
<!-- ivrInfo -->
<xsd:complexType name="ivrInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ivr-sessions" minOccurs="0" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="dtmf-type" minOccurs="0" />
<xsd:element ref="tones" minOccurs="0" />
<xsd:element ref="asr-tts" minOccurs="0" />
<xsd:element ref="vxml" minOccurs="0" />
<xsd:element ref="location" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="streaming-modes" 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="ivrInfo" type="ivrInfoType" />
<!--
#####################################################
mixerInfo TYPE
#####################################################
-->
Boulton, et al. Expires November 24, 2011 [Page 107]
Internet-Draft Media Resource Brokering May 2011
<!-- mixerInfo -->
<xsd:complexType name="mixerInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:element ref="file-formats" minOccurs="0"/>
<xsd:element ref="dtmf-type" minOccurs="0"/>
<xsd:element ref="tones" minOccurs="0"/>
<xsd:element ref="mixing-modes" minOccurs="0"/>
<xsd:element ref="application-data" minOccurs="0"/>
<xsd:element ref="location" minOccurs="0"/>
<xsd:element ref="encryption" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixerInfo" type="mixerInfoType" />
<!--
#####################################################
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>
Boulton, et al. Expires November 24, 2011 [Page 108]
Internet-Draft Media Resource Brokering May 2011
</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: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" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="response-session-info"
type="response-session-infoType" />
<!-- media-server-address -->
<xsd:complexType name="media-server-addressTYPE">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="connection-id" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="ivr-sessions" minOccurs="0"/>
<xsd:element ref="mixers" minOccurs="0"/>
Boulton, et al. Expires November 24, 2011 [Page 109]
Internet-Draft Media Resource Brokering May 2011
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="uri" type="xsd:anyURI" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-address"
type="media-server-addressTYPE" />
<!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</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" />
Boulton, et al. Expires November 24, 2011 [Page 110]
Internet-Draft Media Resource Brokering May 2011
<!-- 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>
Boulton, et al. Expires November 24, 2011 [Page 111]
Internet-Draft Media Resource Brokering May 2011
<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" />
Boulton, et al. Expires November 24, 2011 [Page 112]
Internet-Draft Media Resource Brokering May 2011
</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" />
Boulton, et al. Expires November 24, 2011 [Page 113]
Internet-Draft Media Resource Brokering May 2011
<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" />
Boulton, et al. Expires November 24, 2011 [Page 114]
Internet-Draft Media Resource Brokering May 2011
</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" />
Boulton, et al. Expires November 24, 2011 [Page 115]
Internet-Draft Media Resource Brokering May 2011
</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" />
Boulton, et al. Expires November 24, 2011 [Page 116]
Internet-Draft Media Resource Brokering May 2011
</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" />
Boulton, et al. Expires November 24, 2011 [Page 117]
Internet-Draft Media Resource Brokering May 2011
<!-- 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"
Boulton, et al. Expires November 24, 2011 [Page 118]
Internet-Draft Media Resource Brokering May 2011
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>
Boulton, et al. Expires November 24, 2011 [Page 119]
Internet-Draft Media Resource Brokering May 2011
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="users" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</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>
Boulton, et al. Expires November 24, 2011 [Page 120]
Internet-Draft Media Resource Brokering May 2011
</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" />
Boulton, et al. Expires November 24, 2011 [Page 121]
Internet-Draft Media Resource Brokering May 2011
<!--
####################################################
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>
Boulton, et al. Expires November 24, 2011 [Page 122]
Internet-Draft Media Resource Brokering May 2011
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4240" />
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
Figure 14
Boulton, et al. Expires November 24, 2011 [Page 123]
Internet-Draft Media Resource Brokering May 2011
12. Security Considerations
The MRB network entity has two primary interfaces, Publish and
Consumer, that carry sensitive information and must therefore be
appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1,
uses the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect
an MRB to a media server. The appropriate Security Considerations
included in the Media Control Channel Framework specification MUST be
used in conjunction with this specification to protect interactions
between an MRB and a media server.
The Consumer interface, as defined in and described in Section 5.2,
uses either the Hypertext Transfer Protocol (HTTP) or Session
Initiation Protocol (SIP) as the mechanism for clients to connect to
an MRB to request media resources. In the case of the HTTP use, any
binding using the Consumer interface MUST be capable of being
transacted over TLS, as described in RFC 2818 [RFC2818]. In the case
of the SIP use, the appropriate security considerations included in
the Media Control Channel Framework specification MUST be used in
conjunction with this specification to protect interactions between a
client requesting media resources and an MRB.
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.
Boulton, et al. Expires November 24, 2011 [Page 124]
Internet-Draft Media Resource Brokering May 2011
13. IANA Considerations
There are several IANA considerations associated with this
specification.
13.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].
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).
13.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].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support a Media Resource Broker (MRB) entity.
Boulton, et al. Expires November 24, 2011 [Page 125]
Internet-Draft Media Resource Brokering May 2011
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.
13.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].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support a Media Resource Broker (MRB) entity.
Additional Information:
Magic Number: None
File Extension: .xdf
Boulton, et al. Expires November 24, 2011 [Page 126]
Internet-Draft Media Resource Brokering May 2011
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.
13.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 10.
13.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 11.
13.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 10 of this document.
13.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
Boulton, et al. Expires November 24, 2011 [Page 127]
Internet-Draft Media Resource Brokering May 2011
Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document.
Boulton, et al. Expires November 24, 2011 [Page 128]
Internet-Draft Media Resource Brokering May 2011
14. Changes
Note to RFC Editor: Please remove this whole section.
14.1. Changes from 08 Version
o Fixed Nits.
o Added range for reporting period - as per mailing list.
14.2. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests;
o Fixed a few typos in the text.
o Clarified language in various places.
o Added 'Multi-modal MRB Implementations' section.
o Added 'Relative Merits of Query Mode, IAMM, and IUMM' section.
o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow
multiples.
o New B2BUA section.
o Updated Examples.
14.3. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed.
o Fixed a few typos in the text.
14.4. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined
layouts or others.
Boulton, et al. Expires November 24, 2011 [Page 129]
Internet-Draft Media Resource Brokering May 2011
o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas.
14.5. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions.
o 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).
o Corrected the Query example flow which included a 'session'info'
in a new request.
14.6. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are
only provided for readability.
o Clarified the distinction between 'deactivated' and 'unavailable'.
o Added text to the status codes in both Publish and Consumer
responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the
Consumer interface.
o Added additional IANA considerations, that were missing in the
previous versions of the document.
o Added text to the security considerations.
14.7. Changes from 02 Version
o Added examples in Section 9.
Boulton, et al. Expires November 24, 2011 [Page 130]
Internet-Draft Media Resource Brokering May 2011
o Fixed some nits in the schemas (encryption and required mixed=true
elements).
o Completed review nit review comments from Gary Munson.
14.8. Changes from 01 Version
o Added description of lease mechanism.
o Added specific HTTP and SIP usage of Consumer interface.
o Completed Publish interface schema + associated text.
o Included Consumer interface schema + associated text.
o Included supported-packages element.
o Removed announce-var element from doc.
o Expanded Abstract.
o General scrub of text - input from Simon Romano.
o Added IANA Considerations section.
o Added Security Considerations section.
14.9. Changes from 00 Version
o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team
work.
Boulton, et al. Expires November 24, 2011 [Page 131]
Internet-Draft Media Resource Brokering May 2011
15. 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 Adnan Saleem, Michael Trank, Victor
Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also
like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
Christian Groves and Jonathan Lennox for input into this
specification.
Ben Campbell carried out the RAI expert review on this specification
and provided a great deal of invaluable input.
Boulton, et al. Expires November 24, 2011 [Page 132]
Internet-Draft Media Resource Brokering May 2011
16. References
16.1. Normative References
[ISO.3166-1]
International Organization for Standardization, "Codes for
the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard 3166-
1:1997, 1997.
[ISO.639.1988]
International Organization for Standardization, "Code for
the representation of names of languages, 1st edition",
ISO Standard 639, 1988.
[ITU-T.Q.1950]
International Telecommunication Union - Telecommunication
Standardization Bureau, "Call Bearer Control (CBC)
Protocol", ITU-T Recommendation Q.1950.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Boulton, et al. Expires November 24, 2011 [Page 133]
Internet-Draft Media Resource Brokering May 2011
[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 4722,
November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005.
[W3C.REC-soap12-part1-20030624]
Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Gudgin, M., Moreau, J., Hadley, M., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
16.2. Informative References
[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",
draft-ietf-mediactrl-ivr-control-package-11 (work in
progress), January 2011.
[I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-14 (work in
progress), January 2011.
[I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Boulton, et al. Expires November 24, 2011 [Page 134]
Internet-Draft Media Resource Brokering May 2011
Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-12 (work in
progress), September 2010.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
Parameter for "Bucket" Media Types", RFC 4281,
November 2005.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
Services", RFC 5552, May 2009.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009.
Boulton, et al. Expires November 24, 2011 [Page 135]
Internet-Draft Media Resource Brokering May 2011
Authors' Addresses
Chris Boulton
NS-Technologies
Email: chris@ns-technologies.com
Lorenzo Miniero
Meetecho
Via Carlo Poerio 89
Napoli 80100
Italy
Email: lorenzo@meetecho.com
Gary Munson
AT&T
200 Laurel Avenue South
Middletown
New Jersey 07748
USA
Email: gamunson@att.com
Boulton, et al. Expires November 24, 2011 [Page 136]