Network Working Group C. Boulton
Internet-Draft Avaya
Intended status: Standards Track October 28, 2008
Expires: May 1, 2009
Media Resource Brokering
draft-boulton-mediactrl-mrb-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2009.
Boulton Expires May 1, 2009 [Page 1]
Internet-Draft Media Resource Brokering October 2008
Abstract
The MediaCtrl work group in the IETF is currently proposing an
architecture for controlling media services. The Session Initiation
Protocol(SIP) will be used as the signalling protocol which provides
many inherent capabilities for message routing. In addition to such
signalling properties, a need exists for intelligent, application
level media service selection based on non-static signalling
properties. This is especially true when considered in conjunction
with deployment architectures that include 1:M and M:M combinations
of Application Servers and Media Servers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10
5. Interface Definition . . . . . . . . . . . . . . . . . . . . . 12
5.1. Media Server Resource Publishing Interface . . . . . . . . 12
5.2. Media Service Resource Consumer Interface . . . . . . . . 14
5.2.1. Media Service Resource Request . . . . . . . . . . . . 15
5.2.2. Media Service Resource Response . . . . . . . . . . . 15
6. Media Service Resource Consumer Interface XML Schema . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Boulton Expires May 1, 2009 [Page 2]
Internet-Draft Media Resource Brokering October 2008
1. Introduction
The topic of Media Resources has been in discussion for a number of
years with varying proprietary solutions being used today. It is
clear that as we move towards a consistent architecture and protocol
for Media Server Control, a standard mechanism is required for
accurate media resource location.
As IP based multimedia infrastructures mature, the complexity and
demands from deployments increase. Such complexity will result in a
wide variety of capabilities from a range of vendors that should all
be interoperable using the architecture and protocols produced by the
MediaCtrl work group. It should be possible for a controlling entity
to be assisted in Media Server selection so that the most appropriate
resource is selected for a particular operation. The importance
increases when you introduce a flexible level of deployment
scenarios, as specified in the MediaCtrl Requirements
[I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture
[I-D.ietf-mediactrl-architecture] documents. These documents make
statements like "it should be possible to have a many-to-many
relationship between Application Servers and Media Servers that use
this protocol". This leads to the following deployment architectures
being possible when considering media resources.
The simplest deployment view is illustrated in Figure 1.
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-------MS Control------>| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
This simply involves a single Application Server and Media Server.
Expanding on this view, it is also possible for an Application Server
to be controlling multiple (greater that 1) Media Servers. 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 Expires May 1, 2009 [Page 3]
Internet-Draft Media Resource Brokering October 2008
+---+-----+---+
| Media |
+----->| Server |
| +-------------+
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+
|
| +---+-----+---+
+----->| Media |
| Server |
+-------------+
Figure 2: Basic Architecture
Figure 3 conveys the opposite view to that in Figure 2. In this
model there are a number of (greater than 1) application servers
controlling a single media server. Typically, such architectures are
associated with application logic that requires low demand media
services.
+---+-----+---+
| Application |
| Server |<-----+
+-------------+ |
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+
|
+---+-----+---+ |
| Application | |
| Server |<-----+
+-------------+
Figure 3: Basic Architecture
The final deployment view is the most complex. In this model (M:M)
there exists any number of Application Servers and any number of
Media Servers. It is again possible in this model that media servers
might not be homogenous and have different capability sets.
Boulton Expires May 1, 2009 [Page 4]
Internet-Draft Media Resource Brokering October 2008
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-----+ +---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media |
| Server |<-----+ | Server |
+-------------+ +---+-----+---+
Figure 4: Basic Architecture
This document will take a look at the specific problem areas related
to such deployment architectures. It is recognised that the
solutions proposed in this document should be equally adaptable to
all of the previously described deployment models. It is also
recognised that the solution is far more relevant to some of the
previously discussed deployment models and can almost be viewed as
redundant on others.
Boulton Expires May 1, 2009 [Page 5]
Internet-Draft Media Resource Brokering October 2008
2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for
compliant implementations.
This document inherits terminology proposed in the MediaCtrl
Architecture [I-D.ietf-mediactrl-architecture] and MediaCtrl SIP
Control Framework [I-D.ietf-mediactrl-sip-control-framework]
documents. In addition, the following terms are defined for use in
this document and for use in the context of the MediaCtrl Work group
in the IETF:
Media Resource Broker (MRB) A logical entity that is responsible for
both collection of appropriate published Media Server (MS)
information and supplying of appropriate MS information to
consuming entities.
Query MRB An instantiation of an MRB (See previous definition) that
provides an interface for an Application Server to retrieve the
location of an appropriate Media Server. The result returned to
the Application Server can be influenced by information contained
in the query request.
In-line MRB An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. The decision
making process is totally delegated to the MRB.
Boulton Expires May 1, 2009 [Page 6]
Internet-Draft Media Resource Brokering October 2008
3. Problem Discussion
It is clear from Section 1 that the MediaCtrl group will be producing
a solution that must service a wide variety of deployment
architectures. These range from the simplest 1:1 relationship
between Media Servers and Application Servers to potentially linearly
scaling 1:M, M:1 and M:M deployments.
This still does not seem like a major issue for the proposed solution
until you add a number of additional factors into the equation that
increase complexity. As Media Servers evolve it must be taken into
consideration that where many can exist in a deployment, they may not
have been produced by the same vendor and may not have the same
capability set. It should be possible for an Application Server that
exists in a deployment to select a Media Service based on a common,
appropriate capability set. In conjunction with capabilities, it is
also important to take available resources into consideration. The
ability to select an appropriate Media Service function is an
extremely useful feature but becomes even more powerful when
considered in conjunction 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.
Boulton Expires May 1, 2009 [Page 7]
Internet-Draft Media Resource Brokering October 2008
4. Deployment Scenario Options
On researching Media Resource Brokering it became clear that a couple
of high level models exist. The general principles of "in-line" and
"query" MRB concepts are discussed in the rest of this section.
4.1. Query MRB
The "Query" model for MRB interactions provides the ability for a
client of media services (for example an Application Server) to "ask"
an MRB for an appropriate Media Server, as illustrated in Figure 5.
+---+-----+---+
+------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | |
| | | |
|(2) +---+--+--+---+ | |
| | Media | | |
| +---->| Server | | |
| | +-------------+ | |
| | (1)| |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ |
| |
| +---+-----+---+ (1)|
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 5: Query MRB
In this deployment, the Media Servers use the "Media Server Resource
Publishing Interface", as discussed in Section 5.1, to convey
capability sets as well as resource information. This is depicted by
(1) in Figure 5. It is then the MRB's responsibility to accumulate
all appropriate information relating to media services in the logical
deployment cluster. The Application Server (or other media services
client) is then able to query the MRB for an appropriate resource (as
identified by (2) in Figure 5). Such a query would carry specific
information related to the Media Service required and enable the MRB
to provide an increased accuracy in its response. This particular
interface is discussed in "Media Resource Consumer Interface" in
Section 5.2. The Application Server is then able to direct control
commands (for example create conference) and Media Dialogs to the
Boulton Expires May 1, 2009 [Page 8]
Internet-Draft Media Resource Brokering October 2008
appropriate Media Server, as shown by (3) in Figure 5.
4.1.1. Hybrid Query MRB
As mentioned previously, it is the intention that a tool kit is
provided for MRB functionality within a MediaCtrl architecture. It
is expected that in specific deployment scenarios the role of the MRB
might be co-hosted as a hybrid logical entity with an Application
Server, as shown in Figure 6.
+------------<----------------<---------+----<-----+---+
| (1) | | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
V +---->| Server | | |
+------+------+ | +-------------+ | |
| MRB | | | |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ |
| |
| +---+-----+---+ |
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 6: Hybrid Query MRB - AS Hosted
This diagram is identical to that in Figure 5 with the exception that
the MRB is now hosted on the Application Server. The "Media Server
Publishing Interface" is still being used to accumulate resource
information at the MRB but as it is co-hosted on the Application
Server, the "Media Server Consumer Interface" has collapsed. It
might still exist within the Application Server/MRB interaction but
this is an implementation issue. This type of deployment suits a
single Application Server environment but it should be noted that a
"Media Server Consumer Interface" could then be offered from the
hybrid if required.
In a similar manner, the Media Server could also act as a hybrid for
the deployment cluster, as illustrated in Figure 7.
Boulton Expires May 1, 2009 [Page 9]
Internet-Draft Media Resource Brokering October 2008
(1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+
| | |
| | +---+--+--+---+ |
| +---<---| Application | |
| | Server |<--+-MS Control-+--+
| +-------------+ |
| |
| +---+--+--+---+ |
+---<-------| Application | |
| Server |<--+-MS Control-+--+
+-------------+
Figure 7: Hybrid Query MRB - MS Hosted
This time the MRB has collapsed and is co-hosted by the Media Server.
The "Media Server Consumer Interface" is still available to the
Application Servers (1) to query Media Server resources. This time
the "Media Server Publishing Interface" has collapsed onto the Media
Server. It might still exist within the Media Server/MRB interaction
but this is an implementation issue. This type of deployment suits a
single Media Server environment but it should be noted that a "Media
Server Publishing Interface" could then be offered from the hybrid if
required.
4.2. In-Line MRB
The "In-line" MRB is architecturally different from the "Query" model
that was discussed in the previous section. The Concept of a "Media
Server Consumer Interface" disappears. The client of the MRB simply
uses the signalling to offload the decision making process - this
applies to both media server Control and Media Dialogs. This type of
deployment is illustrated in Figure 8.
Boulton Expires May 1, 2009 [Page 10]
Internet-Draft Media Resource Brokering October 2008
+-------<----------+----<-------+---+
| | (1) | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
| +------>| Server | | |
| |(3) +-------------+ | |
| | (1)| |
+---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ |
| |
| (3) +---+-----+---+ (1)|
+------>| Media | |
| Server |--->---+
+---+-----+---+
Figure 8: In-line MRB
The Media Servers still use the 'Media Server Publishing Interface'
to convey capabilities and resources to the MRB - as illustrated by
(1). The media server Control and Media dialogs are blindly sent to
the MRB (2) which then selects an appropriate Media Server (3). The
result of such an architecture is that the decision is left entirely
to the MRB and the Application Server has no input into the selection
process. This is the opposite to the "Query" model which provided
information that would help influence the Media Server decision
making process on the application server. As a by-product of this
decision shift, a lot more emphasis is placed on the intelligence of
the MRB to interpret the required capabilities of the request. It
will actually have to inspect both the SIP signalling and the media
server control protocol PDUs for the purpose of Media Server
selection. This includes, for example, looking for explicit
capabilities in the signalling and session details such as media
types, codecs and bandwidth requirements. Ultimately the decision
making and policy enforcement is removed from the Application Server
and shifted to the MRB logical entity.
Boulton Expires May 1, 2009 [Page 11]
Internet-Draft Media Resource Brokering October 2008
5. Interface Definition
As discussed in previous sections in this document, the intention is
to provide a toolkit for a variety of deployment architectures where
media resource brokering can take place. As a result, two main
interfaces are required to support the differing requirements. The
two interfaces are described in the remainder of this section and
have been named the 'Media Server Resource Publishing' and Media
Server Resource Consumer' interfaces. These two interfaces have
extremely differing responsibilities and usages which is reflected in
the choice of solutions.
It is beyond the scope of this document to define exactly how to
construct an MRB. This includes interpreting the data for the Media
Service Consumer interface supplied by the Media Serer Publishing
interface. It is, however, important that the two interfaces are
complimentary so that development of appropriate MRB functionality is
supported.
5.1. Media Server Resource Publishing Interface
The Media Server Resource Publishing interface is responsible for
providing an MRB with appropriate Media Server resource information.
It is generally accepted that this interface provides both general
and specific details related to Media Server resources. This
information needs to be conveyed using an industry standard mechanism
to provide increased levels of adoption and interoperability. A SIP
Control Package will be specified to fulfill this interface
requirement. It provides the perfect establishment and monitoring
mechanism to enable a Media Server to report appropriate statistics
to an MRB.
[EDITORS NOTE: The use of the SIP Control Framework is still up for
debate. This should be revisited and discussed appropriately. It is
fair to say that Media Servers will already support the base SIP
Control Framework and so adding this extra auditing facility provides
nice synergy and reuse.]
EDITORS NOTE: Need to map resources to a control package and define
appropriately. The following information has been taken from
feedback from the community. Please comment on existing entries and
any other that you feel should be added to the list. Note that some
of the publishing topics would naturally be included in the 'AS
Request to MRB' section that follows. At this stage it is only
included in one place for further discussion:
Boulton Expires May 1, 2009 [Page 12]
Internet-Draft Media Resource Brokering October 2008
o Active RTP sessions (including codec information). For example,
10 G711 RTP sessions, 3 H.264 sessions.
o Active Mixers. For example F4: (2 G711, 3 G729), (second mixer
and the codecs), (third mixer), ...).
o Non Active sessions - so sessions available on this MS (based on
codecs supported). For example, 80 G711 RTP session,120 G729
sessions,30 H.264 sessions.
o MS Uptime.
o Codecs/media supported (could just be bundled with above 'Non
Active Sessions'.
o In addition to the generic media processing related information,
there are definitely cases where the AS will want to specify
application-level criteria, which will be application-specific,
and difficult to enumerate in advance. So I'm thinking we need a
way to express arbitrary application specific criteria in addition
to the generic media processing criteria. For example, the AS may
need an MS which is capable of prompting and performing speech
recognition in Swahili. Or, an MS which has the capability to
invoke some application-specific functionality.
o File formats supported for announcement. E.g.: MP3, WAW etc...
May be this information is enough to determine announcement format
supported i.e. audio or video.
o Maximum duration for an announcement. Media servers can have
restrictions on memory to play the announcements for very long
durations.
o Variable announcements. Where the substitution variable can be
time, date, cost etc.
o DTMF detection and generation support.
o Types of mixing (conference supported) audio, video.
o Supported tone types in the Media Server. Different countries may
have different characteristics for the same tone. So the tone
characteristics can be configured in the media server or can be
downloaded. Capability to play the tone in both directions may be
required for conferencing applications. E.g. playing a tone when
a new participant joins in the conference. The tone needs to be
played towards the existing participants and also towards the new
participant.
Boulton Expires May 1, 2009 [Page 13]
Internet-Draft Media Resource Brokering October 2008
o Audio RTSP streaming. Audio conferencing. Audio record. Audio
transcoding.
o ASR/TTS usage. ASR grammar complexity. Language complexity.
o Speaker verification/recognition.
o Music recognition.
o Audio transformation (mask voice, raise tone, add echo, effects
etc.)
o VoiceXML dialogs and their complexity.
o Encryption of audio/video media streams.
o Video transcoding.
o Dynamic or static video frame rate, bit rate or picture size
adaptation per multimedia stream.
o Video record.
o Video RTSP streaming.
o Media insertion (audio, video, text, picture, logo, avatar or
background/ambiance) in a multimedia stream.
o Video mixing.
o Video broadcasting.
o Face/shape/image detection/removal.
5.2. Media Service Resource Consumer Interface
The Media Server Consumer interface provides the ability for clients
of an MRB, such as Application Servers, to request an appropriate
Media Server to satisfy specific criteria. The interface allows a
client to pass detailed meta-information to the MRB to help select an
appropriate Media Server. The MRB is then able to make and informed
decision and provide the client with an appropriate media server
resource.
It appears the most appropriate interface for such a 'query' style
interface is in fact a RESTful type 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
Boulton Expires May 1, 2009 [Page 14]
Internet-Draft Media Resource Brokering October 2008
subsections explain the main operations required to request and then
receive information from an MRB. The following description will
describe the use of HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818
[RFC2818] as transport for a query for media resource and the
appropriate response. Examples of the interface can be seen in
section [ref examples section].
5.2.1. Media Service Resource Request
The media resource query is carried in the body of an HTTP/HTTPS POST
request. The MIME type contained in the HTTP/HTTPS request/reponse
should be 'application/mrb+xml'. This value MUST be reflected in the
appropriate HTTP headers like 'Content-Type' and 'Accept'. The body
of the POST request MUST only contain the 'mediaResourceRequest'
element as defined in Section 6. The 'mediaResourceRequest' element
is the primary container of information related to a media resource
request and has the following child elements which specify the
request parameters:
5.2.1.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides a container for clients
wishing to query an external MRB entity. The <mediaResourceRequest>
element has the following child elements that are used to provide
appropriate contextual information relating to the request: [Editors
Note: Convert groups input into appropriate XML schema.]
o RTP requirements - including media/codec type, codec priority.
o Conference requirements - number of users.
5.2.2. Media Service Resource Response
The use of HTTP/HTTPS for carrying the media service resource
information has no impact on the protocol. If protocol level
operations and errors occur then they should be signalled as
specified in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119]. A
successful response to a HTTP POST request containing the
'mediaResourceRequest' MUST be responded to with a 200 OK HTTP/HTTPS
response message. This signifies that the request was received, was
valid and could be responded to appropriately. If the receiving MRB
wishes to generate information for the requesting entity it MUST
include a 'mediaResourceResponse' element in the 200 OK HTTP/HTTPS
response (as discussed later in this section). An MRB can
alternatively return an application level error by including a
'mediaResourceError' element in the 200 OK HTTP/HTTPS response (as
discussed later in this section).
Boulton Expires May 1, 2009 [Page 15]
Internet-Draft Media Resource Brokering October 2008
5.2.2.1. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a container for the MRB
to generate a response to a previous query. The
<mediaResourceResponse> element has the following child elements that
are used to provide appropriate contextual information relating to
the request: [Editors Note: Convert groups input into appropriate XML
schema.]
o list of appropriate media server resources (include individual
capabilities).
5.2.2.2. <mediaResourceError> element
The <mediaResourceError> element provides a container for the MRB to
generate an error response to a previous query. The
<mediaResourceError> has element the following child elements that
are used to provide appropriate contextual information relating to
the request: [Editors Note: Convert groups input into appropriate XML
schema.]
o list of appropriate error response codes.
Boulton Expires May 1, 2009 [Page 16]
Internet-Draft Media Resource Brokering October 2008
6. 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/
held+xml" format.
<?xml version="1.0"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:mediactrl:mrb"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:mrb="urn:ietf:params:xml:ns:mediactrl:mrb"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:element name="mrb-message" type="mrb-message-type" />
<xsd:complexType name="mrb-message-type">
<xsd:sequence>
<xsd:choice>
<xsd:element name="mediaResourceRequest"
type="mrb:mediaResourceRequestType"/>
<xsd:element name="mediaResourceResponse"
type="mrb:mediaResourceResponseType"/>
<xsd:element name="mediaResourceError"
type="mrb:mediaResourceErrorType"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent>
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexContent>
</xsd:complexType>
Boulton Expires May 1, 2009 [Page 17]
Internet-Draft Media Resource Brokering October 2008
<xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent>
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="mediaResourceErrorType">
<xsd:complexContent>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="status" type="status.datatype"
use="required"/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexContent>
</xsd:complexType>
<!-- DATATYPES -->
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[0-9][0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Figure 9
Boulton Expires May 1, 2009 [Page 18]
Internet-Draft Media Resource Brokering October 2008
7. Acknowledgments
The authors would like to thank
Boulton Expires May 1, 2009 [Page 19]
Internet-Draft Media Resource Brokering October 2008
8. Security Considerations
Security Considerations to be included in later versions of this
document.
Boulton Expires May 1, 2009 [Page 20]
Internet-Draft Media Resource Brokering October 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005.
[W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
Nielsen, "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]
Moreau, J., Mendelsohn, N., Hadley, M., Nielsen, H., and
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Boulton Expires May 1, 2009 [Page 21]
Internet-Draft Media Resource Brokering October 2008
9.2. Informative References
[I-D.ietf-mediactrl-architecture]
Melanchuk, T., "An Architectural Framework for Media
Server Control", draft-ietf-mediactrl-architecture-03
(work in progress), April 2008.
[I-D.ietf-mediactrl-requirements]
Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", draft-ietf-mediactrl-requirements-04 (work
in progress), February 2008.
[I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-05 (work in
progress), October 2008.
Boulton Expires May 1, 2009 [Page 22]
Internet-Draft Media Resource Brokering October 2008
Author's Address
Chris Boulton
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com
Boulton Expires May 1, 2009 [Page 23]
Internet-Draft Media Resource Brokering October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Boulton Expires May 1, 2009 [Page 24]