draft-ietf-mediactrl-mrb-00.txt   draft-ietf-mediactrl-mrb-01.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero Intended status: Standards Track L. Miniero
Expires: November 22, 2009 University of Napoli Expires: March 29, 2010 University of Napoli
May 21, 2009 September 25, 2009
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-00 draft-ietf-mediactrl-mrb-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 22, 2009. This Internet-Draft will expire on March 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10
5. Interface Definition . . . . . . . . . . . . . . . . . . . . . 12 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 13
5.1. Media Server Resource Publishing Interface . . . . . . . . 12 5.1. Media Server Resource Publishing Interface . . . . . . . . 13
5.1.1. Control Package Definition . . . . . . . . . . . . . . 13 5.1.1. Control Package Definition . . . . . . . . . . . . . . 14
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 14 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16
5.1.3. Responses . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 16
5.2. Media Service Resource Consumer Interface . . . . . . . . 17 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 17
5.2.1. Media Service Resource Request . . . . . . . . . . . . 17 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 24
5.2.2. Media Service Resource Response . . . . . . . . . . . 18 5.2. Media Service Resource Consumer Interface . . . . . . . . 25
6. Media Service Resource Publisher Interface XML Schema . . . . 19 5.2.1. Media Service Resource Request . . . . . . . . . . . . 25
7. Media Service Resource Consumer Interface XML Schema . . . . . 20 5.2.2. Media Service Resource Response . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Media Service Resource Publisher Interface XML Schema . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7. Media Service Resource Consumer Interface XML Schema . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 51
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The topic of Media Resources has been in discussion for a number of The topic of Media Resources has been in discussion for a number of
years with varying proprietary solutions being used today. It is years with varying proprietary solutions being used today. It is
clear that, as we move towards a consistent architecture and protocol clear that, as we move towards a consistent architecture and protocol
for Media Server Control, a standard mechanism is required for for Media Server Control, a standard mechanism is required for
accurate media resource location. accurate media resource location.
As IP based multimedia infrastructures mature, the complexity and As IP based multimedia infrastructures mature, the complexity and
skipping to change at page 10, line 42 skipping to change at page 10, line 42
required. A typical use case scenario for such a topology would be a 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 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. MRB would actually be handling a cluster of MSs, rather than one.
4.2. In-Line MRB 4.2. In-Line MRB
The "In-line" MRB is architecturally different from the "Query" model The "In-line" MRB is architecturally different from the "Query" model
that was discussed in the previous section. The Concept of a "Media that was discussed in the previous section. The Concept of a "Media
Server Consumer Interface" disappears. The client of the MRB simply Server Consumer Interface" disappears. The client of the MRB simply
uses the signalling to offload the decision making process - this uses the signalling to offload the decision making process - this
applies to both media server Control and Media Dialogs. This type of applies to both media server Control and Media dialogs. This type of
deployment is illustrated in Figure 8. deployment is illustrated in Figure 8.
+-------<----------+----<-------+---+ +-------<----------+----<-------+---+
| | (1) | | | | (1) | |
| | | | | | | |
| +---+--+--+---+ | | | +---+--+--+---+ | |
| | Media | | | | | Media | | |
| +------>| Server | | | | +------>| Server | | |
| |(3) +-------------+ | | | |(3) +-------------+ | |
| | (1)| | | | (1)| |
skipping to change at page 11, line 27 skipping to change at page 11, line 27
| | | |
| (3) +---+-----+---+ (1)| | (3) +---+-----+---+ (1)|
+------>| Media | | +------>| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 8: In-line MRB Figure 8: In-line MRB
The Media Servers still use the 'Media Server Publishing Interface' The Media Servers still use the 'Media Server Publishing Interface'
to convey capabilities and resources to the MRB - as illustrated by to convey capabilities and resources to the MRB - as illustrated by
(1). The media server Control and Media dialogs are blindly sent to (1). The media server Control and Media dialogs are sent to the MRB
the MRB (2) which then selects an appropriate Media Server (3). The (2) which then selects an appropriate Media Server (3). The result
result of such an architecture is that the decision is left entirely of such an architecture is that the signalling decision is left
to the MRB and the Application Server has no input into the selection entirely to the MRB and the Application Server has no choice in the
process. This is the opposite to the "Query" model which provided final selection process. This is the opposite to the "Query" model
information that would help influence the Media Server decision which provided information that would help influence the Media Server
making process on the application server. As a by-product of this decision making process on the application server and resulted in it
decision shift, a lot more emphasis is placed on the intelligence of directly contacting an appropriate Media Server instance. As a by-
the MRB to interpret the required capabilities of the request. It product of this decision shift, a lot more emphasis is placed on the
will actually have to inspect both the SIP signalling and the media intelligence of the MRB to interpret the required capabilities of the
server control protocol PDUs for the purpose of Media Server request. The MRB will actually have to inspect both the SIP
selection. This includes, for example, looking for explicit signalling and the media server control protocol PDUs for the purpose
capabilities in the signalling and session details such as media of Media Server selection. This includes, for example, looking for
types, codecs and bandwidth requirements. Ultimately the decision explicit capabilities in the signalling and session details such as
making and policy enforcement is removed from the Application Server media types, codecs and bandwidth requirements. Ultimately the
and shifted to the MRB logical entity. decision making and policy enforcement is removed from the
Application Server and shifted to the MRB logical entity.
5. Interface Definition 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-line Aware MRB Mode (IAMM) Allows an MRB to act on behalf of
clients requiring media services who are aware of an MRB and its
operation.
The two modes are discussed in more detail in Section 5.3.
5. MRB Interface Definitions
As discussed in previous sections in this document, the intention is As discussed in previous sections in this document, the intention is
to provide a toolkit for a variety of deployment architectures where to provide a toolkit for a variety of deployment architectures where
media resource brokering can take place. As a result, two main media resource brokering can take place. As a result, two main
interfaces are required to support the differing requirements. The interfaces are required to support the differing requirements. The
two interfaces are described in the remainder of this section and two interfaces are described in the remainder of this section and
have been named the 'Media Server Resource Publishing' and 'Media have been named the 'Media Server Resource Publishing' and 'Media
Server Resource Consumer' interfaces. These two interfaces have Server Resource Consumer' interfaces. These two interfaces have
extremely differing responsibilities and usages which is reflected in extremely differing responsibilities and usages which is reflected in
the choice of solutions. the choice of solutions.
skipping to change at page 12, line 33 skipping to change at page 13, line 33
5.1. Media Server Resource Publishing Interface 5.1. Media Server Resource Publishing Interface
The Media Server Resource Publishing interface is responsible for The Media Server Resource Publishing interface is responsible for
providing an MRB with appropriate Media Server resource information. providing an MRB with appropriate Media Server resource information.
It is generally accepted that this interface provides both general It is generally accepted that this interface provides both general
and specific details related to Media Server resources. This and specific details related to Media Server resources. This
information needs to be conveyed using an industry standard mechanism information needs to be conveyed using an industry standard mechanism
to provide increased levels of adoption and interoperability. A to provide increased levels of adoption and interoperability. A
Control Package for the Media Control Channel Framework will be Control Package for the Media Control Channel Framework will be
specified to fulfill this interface requirement. It provides the specified to fulfil this interface requirement. It provides the
perfect establishment and monitoring mechanism to enable a Media perfect establishment and monitoring mechanism to enable a Media
Server to report appropriate statistics to an MRB. Server to report appropriate statistics to an MRB. The Publish
interface is used with both Query and In-line modes of MRB operation.
As already anticipated in the introduction, the information provided As already anticipated in the introduction, the information provided
by the Media Server is to be considered a best effort. This means by the Media Server is to be considered a best effort. This means
that while the information is assumed to be as exact as possible, it that while the information is assumed to be as exact as possible, it
can only be considered a good approximation rather than the exact can only be considered a good approximation rather than the exact
information. It is clear, in fact, that the accuracy of MRB resource information. It is clear, in fact, that the accuracy of MRB resource
availability will never be exact due to several reasons which include availability will never be exact due to several reasons which include
timing issues, computed as opposed to reserved resource consumption timing issues, computed as opposed to reserved resource consumption
(e.g., DSP's with a fixed number of streams versus GPU's with CPU (e.g., DSP's with a fixed number of streams versus GPU's with CPU
availability), and licensing (e.g., even if lots of CPU and memory availability), and licensing (e.g., even if lots of CPU and memory
skipping to change at page 13, line 17 skipping to change at page 14, line 18
It is also worth noting that, while the scope of the MRB is It is also worth noting that, while the scope of the MRB is
definitely on providing interested Application Servers with the definitely on providing interested Application Servers with the
available resources, the MRB also allows for the retrieval of available resources, the MRB also allows for the retrieval of
information about the currently occupied resources. While this is of information about the currently occupied resources. While this is of
course a relevant piece of information (e.g. for monitoring course a relevant piece of information (e.g. for monitoring
purposes), such a functionality inevitably raises security purposes), such a functionality inevitably raises security
considerations, and implementations should take this into account. considerations, and implementations should take this into account.
See Section 8 for more details. See Section 8 for more details.
The MRB Publish interface uses the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
interaction between a Media Server and an MRB. The Media Control
Channel Framework uses an extension mechanism to allow specific
usages which are known as control packages. Section 5.1.1 defines
the control package that MUST be implemented by any Media Server
wanting to interact with an MRB entity.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
This section fulfills the mandatory requirement for information that This section fulfils the mandatory requirement for information that
MUST be specified during the definition of a Control Framework MUST be specified during the definition of a Control Framework
Package, as detailed in Section 8 of Package, as detailed in Section 8 of
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
5.1.1.1. Control Package Name 5.1.1.1. Control Package Name
The Media Channel Control Framework requires a Control Package The Media Channel Control Framework requires a Control Package
definition to specify and register a unique name and version. definition to specify and register a unique name and version.
The name and version of this Control Package is "mrb-publish/1.0". The name and version of this Control Package is "mrb-publish/1.0".
skipping to change at page 13, line 41 skipping to change at page 14, line 50
5.1.1.2. Framework Message Usage 5.1.1.2. Framework Message Usage
The MRB publishing interface allows a media server to convey The MRB publishing interface allows a media server to convey
available capabilities and resources to an MRB entity. available capabilities and resources to an MRB entity.
This package defines XML elements in Section 5.1.2 and provides an This package defines XML elements in Section 5.1.2 and provides an
XML Schema in Section 6. XML Schema in Section 6.
The XML elements in this package are split into requests, responses The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message and event notifications. Requests are carried in CONTROL message
bodies; *TODO* elements are defined as package requests. Event bodies; <mrbrequest> element is defined as a package request. Event
notifications are also carried in CONTROL message bodies; the notifications are also carried in CONTROL message bodies; the
<notification> element is defined for package event notifications. <mrbnotification> element is defined for package event notifications.
Responses are carried either in REPORT message or Control Framework Responses are carried either in REPORT message or Control Framework
200 response bodies; the <response> element is defined as a package 200 response bodies; the <mrbresponse> element is defined as a
level response. package level response.
Note that package responses are different from framework response Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of codes. Framework error response codes (see Section 7 of
[I-D.ietf-mediactrl-sip-control-framework]) are used when the request [I-D.ietf-mediactrl-sip-control-framework]) are used when the request
or event notification is invalid; for example, a request has invalid or event notification is invalid; for example, a request has invalid
XML (400), or is not understood (500). Package level responses are XML (400), or is not understood (500). Package level responses are
carried in framework 200 response or REPORT message bodies. This carried in framework 200 response or REPORT message bodies. This
package's response codes are defined in Section 5.1.3. package's response codes are defined in Section 5.1.5.
5.1.1.3. Common XML Support 5.1.1.3. Common XML Support
The Control Framework requires a Control Package definition to The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references specify if the attributes for media dialog or conference references
are required. are required.
*TODO*. [Editors Note: *TODO*.]
5.1.1.4. CONTROL Message Body 5.1.1.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in A valid CONTROL body message MUST conform to the schema defined in
Section 6 and described in Section 5.1.2. XML messages appearing in Section 6 and described in Section 5.1.2. XML messages appearing in
CONTROL messages MUST contain either a *TODO* element. CONTROL messages MUST contain either a <mrbrequest> or
<mrbnotification> element.
5.1.1.5. REPORT Message Body 5.1.1.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 6 A valid REPORT body MUST conform to the schema defined in Section 6
and described in Section 5.1.2. XML messages appearing in REPORT and described in Section 5.1.2. XML messages appearing in REPORT
messages MUST contain a <response> (**Add ref when completed**) messages MUST contain a <mrbresponse> element.
element.
5.1.1.6. Audit 5.1.1.6. Audit
*TODO*. *TODO*.
[Editors Note: do we really need an Audit section for this package?
Auditing is not a mandatory operation in a package, but the framework
encourages its use. If we add this here, are we saying that there
are things a MRB may or may not do, and auditing tells you about it?
Or could it be used as a monitoring entity?]
5.1.1.7. Examples 5.1.1.7. Examples
[Editors Note: TODO].
5.1.2. Element Definitions 5.1.2. Element Definitions
EDITORS NOTE: Need to map resources to a control package and define This section defines the XML elements for the Publish interface Media
appropriately. The following information has been taken from Control Channel package defined in Section 5.1. The formal XML
feedback from the community. Please comment on existing entries and schema definition for the Publish interface can be found in
any other that you feel should be added to the list. Note that some Section 6.
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:
o Active RTP sessions (including codec information). For example, The root element is <mrbpublish>. All other XML elements (requests,
10 G711 RTP sessions, 3 H.264 sessions. 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.
o [MRB-04] This may not be required, since the purpose of the MRB is The <mrbpublish> element has the following attributes:
to check for available resources rather than occupied resources.
Or do you think such details might be useful for complementary
functionality as debugging and monitoring inside the MRB?
o Active Mixers. For example F4: (2 G711, 3 G729), (second mixer Version) a token specifying the mrb-publish package version. The
and the codecs), (third mixer), ...). value is fixed as '1.0' for this version of the package. The
attribute is mandatory.
o Non Active sessions - so sessions available on this MS (based on The <mrbpublish> elements has the following child elements, only one
codecs supported). For example, 80 G711 RTP session,120 G729 of which is allowed to occur.
sessions,30 H.264 sessions.
o MS Uptime. <mrbrequest> for sending an MRB request. See Section 5.1.3.
o Codecs/media supported (could just be bundled with above 'Non <mrbresponse> for sending an MRB response. See Section 5.1.5.
Active Sessions'.
o In addition to the generic media processing related information, <mrbnotification> for sending an MRB notification. See
there are definitely cases where the AS will want to specify Section 5.1.4.
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... 5.1.3. <mrbrequest>
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 This section defines the <mrbrequest> element used to initiate
restrictions on memory to play the announcements for very long requests from an MRB to a Media Server. The element is a container
durations. for information relevant for the interrogation of a media server.
o Variable announcements. Where the substitution variable can be The <mrbrequest> element has no defined attributes.
time, date, cost etc.
o DTMF detection and generation support. The <mrbrequest> element has the following sub-elements which are
defined in the remainder of this section:
o Types of mixing (conference supported) audio, video. <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1.
o Supported tone types in the Media Server. Different countries may 5.1.3.1. <subscription>
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.
o Audio RTSP streaming. Audio conferencing. Audio record. Audio The <subscription> element is included in a request from an MRB to a
transcoding. Media Server to provide the details relating to the configuration of
updates. The MRB will inform the Media Server how long it wishes to
receive updates for and the frequency that updates should be sent.
Updates are sent using the <mrbnotification> element.
o ASR/TTS usage. ASR grammar complexity. Language complexity. [Editors Note: Include more detail on subscription mechanism
including responses/reject from MS + polling (not including expires
and frequency elements constitutes a poll of the Media Server using a
different 'id')].
o Speaker verification/recognition. The <subscription> element has the following attributes:
o Music recognition. id: indicates a unique token representing the session between the
MRB and the Media Server. The attribute is mandatory.
o Audio transformation (mask voice, raise tone, add echo, effects seqnumber: indicates a sequence number to be used in conjunction
etc.) with the session id to identify a specific subscription command.
The attribute is mandatory
o VoiceXML dialogs and their complexity. The <subscription> element has the following child elements:
o Encryption of audio/video media streams. expires: Provides the amount of time in seconds that a subscription
should be installed for notifications at the Media Server. The
element is optional.
o Video transcoding. frequency: Provides the frequency in seconds that the MRB wishes to
receive notifications from the MRB. The element is optional.
o Dynamic or static video frame rate, bit rate or picture size [Editors Note: Next version of the document will have exclude/include
adaptation per multimedia stream. lists in MRB requests; the default behaviour is "subscribe me to
everything you have", and the MRB package will trigger events saying
everything it knows; we could envisage more drill-down requests like:
1) tell me everything (default) 2) tell me everything except...
(exclude list) 3) tell me only... (include list) this would only
require a change in 'subscriptionType' and optional occurrences in
'mrbnotificationType' for the reported elements; this could allow for
more lightweight notifications for entities only interested in a
subset of info, or for entities which want different transactions for
different info (e.g. "I only need to know about RTP stuff, I don't
care about the rest");].
o Video record. 5.1.4. <mrbnotification>
o Video RTSP streaming. The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The
Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent
using the <mrbnotification> element contained in an <mrbrequest>
element.
o Media insertion (audio, video, text, picture, logo, avatar or The <mrbnotification> element has the following attributes:
background/ambiance) in a multimedia stream.
o Video mixing. 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 is mandatory.
o Video broadcasting. seqnumber: indicates a sequence number to be used in conjunction
with the session id to identify a specific notification update.
The attribute is mandatory
o Face/shape/image detection/removal. The following subsections provide details on the child elements that
are contained within an <mrbnotification> element.
5.1.3. Responses [Editors Note: What is mandatory to support by Media Servers? Do we
want to specify that MS MUST support all elements in the mrbrequest
OR should we specify a minumum number of elements].
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 is mandatory.
[Editors Note: Need to talk more about unique property.]
5.1.4.2. <active-rtp-sessions>
The <active-rtp-sessions> element provides information detailing the
current active Real-time Transport Protocol(RTP) sessions. The
element is optional.
The <active-rtp-sessions> element has no attributes.
The <active-rtp-sessions> element has the following child elements:
rtp-codec: Is a container which representing a supported codec and
the active sessions. The <rtp-codec> element has one attribute.
The attribute 'name' represents the name of the codec being
represented. 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.3. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element is optional.
The <active-rtp-sessions> element has no attributes.
The <active-mixer-sessions> element has the following child elements:
active-mix: Is a container which representing a mixed active RTP
session. The <active-mix> element has one attribute. The
attribute 'conferenceid' represents the name of the mix being
represented. The <active-mix> element has one child elements.
The child element, <rtp-codec>, contains the same information
relating to RTP sessions as defined in Section 5.1.4.2. The
element is optional.
5.1.4.4. <non-active-rtp-sessions>
The <non-active-rtp-sessions> element provides information detailing
the currently available inactive RTP sessions. The element is
optional.
The <non-active-rtp-sessions> element has no attributes.
The <non-active-rtp-sessions> element has the following child
elements:
rtp-codec: Is a container which representing 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. The <rtp-codec> element has two child elements. The
first child element, <decoding>, represents the number of
available RTP session for the specified codec being decoded. The
second child element, <encoding>, represents the number of
available RTP sessions for the specified codec being encoded. The
element is optional.
5.1.4.5. <non-active-mixer-sessions>
The <non-active-mixer-sessions> element provides information
detailing the current inactive mixed RTP sessions. The element is
optional.
The <non-active-rtp-sessions> element has no attributes.
The <non-active-mixer-sessions> element has the following child
elements:
non-active-mix: Is a container which representing an available
mixed RTP session. The <non-active-mix> element has one
attribute. The attribute 'available' represents the number of
mixes that could be used using that profile. The <non-active-mix>
element has one child elements. The child element, <rtp-codec>,
contains the same information relating to RTP sessions as defined
in Section 5.1.4.4. The element is optional.
5.1.4.6. <media-server-status>
The <media-server-status> element provides information detailing the
current status of the media server. The element is mandatory. It
can return one of the following values:
active: Indicating that the Media Server is available for service.
deactivated: Indicating that the Media Server has been withdrawn
from service.
unavailable: Indicating that the Media Server can not process new
requests.
The <media-server-status> element has no attributes.
The <media-server-status> element has no child elements.
[Editors Note: Need to think about status messages and meanings.]
The <media-server-status> element has no attributes.
The <media-server-status> element has no child elements.
5.1.4.7. <supported-codecs>
The <supported-codecs> element provides information detailing the
current codecs supported by a media server and associated actions.
The element is optional.
The <supported-codecs> element has no attributes.
The <supported-codecs> element has the following child elements:
supported-codec: has a single attribute, 'name', which provides the
name of the codec providing information. The <supported-codec>
element then has a further child element, <supported-codec-
package>. The <supported-codec-package> element has a single
attribute, 'name', which provides the name of the Media Control
Channel Framework package for which the codec support applies.
The <supported-codec-package> element has one further child
element, <supported-actions>, which provide the actions that an
Media Server can apply to this codec (decode, encode,
passthrough).
5.1.4.8. <application-data>
The <application-data> element provides application level data. The
element is optional.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.1.4.9. <file-formats>
The <file-formats> element provides a list of file formats supported
for the purpose of making announcements. The element is optional.
The <file-formats> element has no attributes.
The <file-formats> element has the following child elements:
supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format>
element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package for which the codec
support applies.
5.1.4.10. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time a
media dialog cane be prepared in the system before it is executed.
The element is optional.
The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child elements:
max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package
for which the time period applies.
5.1.4.11. <announce-var>
The <announce-var> element supplies the supported substitution
variables for variable announcements, including digits, dates, costs,
etc. The element is optional.
The <announce-var> element has no attributes.
The <announce-var> element has the following child elements:
param: has a two attributes, 'name' and 'package'. The 'name'
attribute provides the name of the parameter. The 'package'
attribute provides the name of the Media Control Channel Framework
package for which the parameter applies. The <param> element then
has a further child element, <param-value>. The <param-value>
element provides the value associated with the parameter.
[Editors Note: TODO - the structure of this needs to change to
reflect top level of package and the params underneath as a child].
5.1.4.12. <dtmf-support>
The <dtmf-support> element supplies the supported methods to detect
DTMF tones and to generate them. The element is optional.
The <dtmf-support> element has no attributes.
The <dtmf-support> element has the following child elements:
detect: has no attributes. The <detect> element then has a further
child element, <dtmf-type>. The <dtmf-type> element has two
attributes, 'name' and 'package. The 'name' attribute provides
the type of DTMF being used. The 'package' attribute provides the
name of the Media Control Channel Framework package for which the
DTMF type applies.
generate: has no attributes. The <generate> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used. The 'package' attribute
provides the name of the Media Control Channel Framework package
for which the DTMF type applies.
passthrough: has no attributes. The <passthrough> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used. The 'package' attribute
provides the name of the Media Control Channel Framework package
for which the DTMF type applies.
5.1.4.13. <mixing-modes>
[Editors Note: TODO after further group discussion].
5.1.4.14. <supported-tones>
[Editors Note: TODO after further group discussion].
5.1.4.15. <streaming-modes>
The <streaming-modes> element allows the Media Server to specify
which protocols are supported for streaming to a Media Server for
each Media Control Channel Framework package type. For example does
the Media Server supports audio streaming via RTSP, HTTP, NFS, etc
protocols. The element is optional.
The <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child elements:
stream-mode: has a two attributes, 'name' and 'package'. The
'name' attribute provides the type of protocol that can be used
for streaming. The 'package' attribute provides the name of the
Media Control Channel Framework package for which the streaming
protocol applies.
5.1.4.16. <asr-tts-support>
[Editors Note: TODO after further group discussion].
5.1.4.17. <vxml-support>
The <vxml-support> element specifies if the Media Server supports
VoiceXML and if it does which protocols the support is exposed
through (eg via the control framework, or RFC5552). The element is
optional.
The <vxml-support> element has a single attribute 'support'. The
'support' attribute is of type boolean with a value of 'true'
indicating that the media server does support VXML, and a value of
'false' indicating it does not support VXML. The default value is
'false'.
The <vxml-support> element has the following child elements:
vxml-mode: has a two attributes, 'package' and 'support'. The
'package' attribute provides the name of the Media Control Channel
Framework package for which the streaming protocol applies. The
'support' attribute provides the type of VXML support provided by
the Media Server (RFC5552 or msc-ivr/1.0).
5.1.4.18. <media-server-location>
[Editors Note: TODO after further group discussion].
5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the
Media Server can declare if its a blue or green. Its a string to
allow arbitrary values to be returned to allow arbitrary
classification. Its arbitrary as opposed to doing it purely on
features. The element is optional.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a
direct URI address.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.1.4.21. <encryption>
[Editors Note: TODO after further group discussion].
5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <response> element from
Section 6. Section 6.
The <response> element has following attributes: The <response> element has following attributes:
status: numeric code indicating the response status. The attribute status: numeric code indicating the response status. The attribute
is mandatory. is mandatory.
The following status codes are defined: The following status codes are defined:
skipping to change at page 17, line 35 skipping to change at page 25, line 35
It appears the most appropriate interface for such a 'query' style It appears the most appropriate interface for such a 'query' style
interface is in fact a HTTP usage. Using HTTP and XML combined interface is in fact a HTTP usage. Using HTTP and XML combined
reduces complexity and encourages use of common tools that are widely reduces complexity and encourages use of common tools that are widely
available in the industry today. The following subsections explain available in the industry today. The following subsections explain
the main operations required to request and then receive information the main operations required to request and then receive information
from an MRB. The following description will describe the use of HTTP from an MRB. The following description will describe the use of HTTP
RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for a RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for a
query for media resource and the appropriate response. Examples of query for media resource and the appropriate response. Examples of
the interface can be seen in section [ref examples section]. the interface can be seen in section [ref examples section].
[Editors Note: Need to discuss the updating of a request and proposal
of having the client supply updates on resources. For example,
releasing resources.]
5.2.1. Media Service Resource Request 5.2.1. Media Service Resource Request
The media resource query is carried in the body of an HTTP/HTTPS POST 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 request. The MIME type contained in the HTTP/HTTPS request/response
should be 'application/mrb+xml'. This value MUST be reflected in the should be 'application/mrb-consumer+xml'. This value MUST be
appropriate HTTP headers like 'Content-Type' and 'Accept'. The body reflected in the appropriate HTTP headers like 'Content-Type' and
of the POST request MUST only contain the 'mediaResourceRequest' 'Accept'. The body of the POST request MUST only contain the
element as defined in Section 7. The 'mediaResourceRequest' element 'mediaResourceRequest' element as defined in Section 7. The
is the primary container of information related to a media resource 'mediaResourceRequest' element is the primary container of
request and has the following child elements which specify the information related to a media resource request and has the following
request parameters: child elements which specify the request parameters:
5.2.1.1. <mediaResourceRequest> element 5.2.1.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides a container for clients The <mediaResourceRequest> element provides a container for clients
wishing to query an external MRB entity. The <mediaResourceRequest> wishing to query an external MRB entity. The <mediaResourceRequest>
element has the following child elements that are used to provide element has the following child elements that are used to provide
appropriate contextual information relating to the request: [Editors appropriate contextual information relating to the request: [Editors
Note: Convert groups input into appropriate XML schema.] Note: Convert groups input into appropriate XML schema.]
o RTP requirements - including media/codec type, codec priority. o RTP requirements - including media/codec type, codec priority.
skipping to change at page 19, line 5 skipping to change at page 27, line 8
The <mediaResourceError> element provides a container for the MRB to The <mediaResourceError> element provides a container for the MRB to
generate an error response to a previous query. The generate an error response to a previous query. The
<mediaResourceError> has element the following child elements that <mediaResourceError> has element the following child elements that
are used to provide appropriate contextual information relating to are used to provide appropriate contextual information relating to
the request: [Editors Note: Convert groups input into appropriate XML the request: [Editors Note: Convert groups input into appropriate XML
schema.] schema.]
o list of appropriate error response codes. o list of appropriate error response codes.
5.3. In-Line MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a
request, as introduced in Section 4.2. The following sub sections
provide details for using In-Line Unaware MRB Mode (IUAMM) of
operation and In-Line Aware MRB Mode (IAMM) of operation.
5.3.1. In-line Unaware MRB Mode
It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be
implemented by those requesting media server resources (for example
an application server). This applies when using both the Consumer
interface as discussed in Section 5.2 and IAMM. It is for this
reason that an MRB is able to act in a client unaware mode when it is
deployed into the network. This allows any SIP compliant client
entity, as defined by RFC 3261 [RFC3261] and its extensions, to send
requests to an MRB and it will select an appropriate media server
based on knowledge of media server resources it currently has
available. Mechanisms used to connect to media servers are detailed
in the Media Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework]. Using an MRB in
this mode allows for easy migration of current applications and
services that are unaware of the MRB concept and would simply require
a configuration change resulting in the MRB being set as a SIP
outbound proxy for clients requiring media services. Any client of
media services wishing to take advantage of the advanced techniques
detailed in this document when using In-line mode would implement
IAMM which is covered in Section 5.3.2. The techniques used for
selecting an appropriate Media Server by an MRB acting in IUMM is
outside the scope of this document.
5.3.2. In-line Aware MRB Mode
An In-Line Aware Mode MRB (IAMM) is one that complies to the extended
functionality provided in this section. A client entity, such as an
application server, wishing to use advanced MRB functionality can
provide additional contextual information to an MRB. This
information is identical to that used in the Consumer interface in
Section 5.2 with the only difference being the underlying transport
mechanism of the contextual information, as specified by the
'application/mrb-consumer+xml' payload in Section 7. A client of an
IAMM uses SIP signalling to convey the 'application/mrb-consumer+xml'
payload to the IAMM. The Consumer interface, as specified in
Section 5.2 , uses HTTP. A client of an IAMM requiring media
services, as well as creating a standard SIP complaint request, MUST
use the following steps to ensure that the request is dealt with
appropriately:
o The client of the IAMM constructs a SIP INVITE request to connect
to a Media Server as detailed in the Media Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework] with one
exception.
o The client of the IAMM includes a MIME content type of multipart/
mixed as defined in RFC 2046 [RFC2046]. As part of this mixed
payload, the client MUST at least include a content-type of type
'application/sdp' and a content type of type 'application/
mrb-consumer+xml'. The part of type application/sdp represents
the media server connection details and MUST adhere to the Media
Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework]. The part of
type 'application/mrb-consumer+xml' represents the IAMM contextual
information and MUST adhere to the schema defined in Section 7.
o Once the SIP INVITE request is constructed, it is sent to the
recipient as per RFC 3261 [RFC3261].
[EDITORS NOTE: Include example of valid IAMM payload.]
On receiving a SIP INVITE request containing the multipart mixed
payload as specified previously, the IAMM will complete a number of
steps to fulfil the request. It will:
o Extract the multipart MIME payload from the SIP INVITE request.
It will then use the contextual information provided by the client
in the 'application/mrb-consumer+xml' part to determine which
media server should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it to
populate a new SIP INVITE request for connecting the client to the
selected media server, as defined in the Media Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework]. The IAMM
acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then
forwards to the selected Media Server.
[Editors Note: Consumer interface has a proposal to update a request
for media services based on HTTP. There are times when an
application server might want to override the MS view of resources.
For example, a conference where participants leave and can rejoin.
Need to decide if this use of consumer XML should also allow for
updates using SIP reINVITE and UPDATE.]
6. Media Service Resource Publisher Interface XML Schema 6. Media Service Resource Publisher Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publisher+xml" format. mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package.
The schema namespace is urn:ietf:params:xml:ns:mrb-publish
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the framework attributes for
conferenceid and connectionid.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP LEVEL ELEMENT: mrbpublish
#####################################################
-->
<xsd:complexType name="mrbpublishType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mrbrequest" />
<xsd:element ref="mrbresponse" />
<xsd:element ref="mrbnotification" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbpublish" type="mrbpublishType" />
<!--
#####################################################
mrbrequest TYPE
#####################################################
-->
<!-- mrbrequest -->
<xsd:complexType name="mrbrequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbrequest" type="mrbrequestType" />
<!-- subscription -->
<xsd:complexType name="subscriptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="frequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" />
<!--
#####################################################
mrbresponse TYPE
#####################################################
-->
<!-- mrbresponse -->
<xsd:complexType name="mrbresponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbresponse" type="mrbresponseType" />
<!--
#####################################################
mrbnotification TYPE
#####################################################
-->
<!-- mrbnotification -->
<xsd:complexType name="mrbnotificationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence
<xsd:element ref="media-server-id" type="subscriptionid.datatype"/>
<xsd:element ref="active-rtp-sessions" minOccurs="0" />
<xsd:element ref="active-mixer-sessions" minOccurs="0" />
<xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
<xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
<xsd:element ref="media-server-status" minOccurs="0" />
<xsd:element ref="supported-codecs" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="announce-var" minOccurs="0" />
<xsd:element ref="dtmf-support" minOccurs="0" />
<xsd:element ref="mixing-modes" minOccurs="0" />
<xsd:element ref="supported-tones" minOccurs="0" />
<xsd:element ref="streaming-modes" minOccurs="0" />
<xsd:element ref="asr-tts-support" minOccurs="0" />
<xsd:element ref="vxml-support" minOccurs="0" />
<xsd:element ref="media-server-location" minOccurs="0" />
<xsd:element ref="label" minOccurs="0" />
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="subscriptionid.datatype"
use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbnotification" type="mrbnotificationType" />
<!-- active-rtp-sessions -->
<xsd:complexType name="active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- active-mixer-sessions -->
<xsd:complexType name="active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mixer-sessions"
type="active-mixer-sessionsType" />
<xsd:complexType name="active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attributeGroup ref="fw:framework-attributes" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mix" type="active-mixType" />
<!-- non-active-rtp-sessions -->
<xsd:complexType name="non-active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-rtp-sessions"
type="non-active-rtp-sessionsType" />
<!-- non-active-mixer-sessions -->
<xsd:complexType name="non-active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="non-active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mixer-sessions"
type="non-active-mixer-sessionsType" />
<xsd:complexType name="non-active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="available" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mix" type="non-active-mixType" />
<!-- media-server-status -->
<xsd:element name="status" type="msstatus.datatype" />
<!-- supported-codecs -->
<xsd:complexType name="supported-codecsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codecs" type="supported-codecsType" />
<xsd:complexType name="supported-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec" type="supported-codecType" />
<xsd:complexType name="supported-codec-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-actions" type="actions.datatype"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec-package"
type="supported-codec-packageType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="supported-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-format" type="supported-formatType" />
<xsd:complexType name="supported-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-file-package"
type="supported-file-packageType" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- announce-var -->
<xsd:complexType name="announce-varType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="param" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="announce-var" type="announce-varType" />
<xsd:complexType name="paramType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="param-value" type="xsd:NMTOKEN" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="param" type="paramType" />
<!-- dtmf-support -->
<xsd:complexType name="dtmf-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-support" type="dtmf-supportType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- mixing-modes -->
<!-- **** TODO **** -->
<!-- supported-tones -->
<!-- **** TODO **** -->
<!-- streaming-modes -->
<xsd:complexType name="stream-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream-modes" type="stream-modesType" />
<xsd:complexType name="stream-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="streammode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream-mode" type="stream-modeType" />
<!-- asr-tts-support -->
<!-- **** TODO **** -->
<!-- vxml-support -->
<xsd:complexType name="vxml-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="support" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- media-server-location -->
<!-- **** TODO **** -->
<!-- label -->
<xsd:element name="label" type="label.datatype" />
<!-- media-server-address -->
<xsd:element name="ms-address" type="xsd:anyURI" />
<!-- encryption -->
<!-- **** TODO **** -->
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="msstatus.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="active" />
<xsd:enumeration value="deactivated" />
<xsd:enumeration value="unavailable" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="INFO" />
<xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" />
</xsd:restriction>
</xsd:simpleType>
<!-- *** TODO-Look at values **** -->
<xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RTSP" />
<xsd:enumeration value="HTTP" />
<xsd:enumeration value="NFS" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
Figure 9
7. Media Service Resource Consumer Interface XML Schema 7. Media Service Resource Consumer Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-consumer+xml" format. mrb-consumer+xml" format.
<?xml version="1.0"?> <?xml version="1.0"?>
<xsd:schema <xsd:schema
skipping to change at page 21, line 37 skipping to change at page 48, line 37
<xsd:simpleType name="status.datatype"> <xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[0-9][0-9][0-9]"/> <xsd:pattern value="[0-9][0-9][0-9]"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
</xsd:schema> </xsd:schema>
Figure 9 Figure 10
8. Security Considerations 8. Security Considerations
Security Considerations to be included in later versions of this Security Considerations to be included in later versions of this
document. document.
9. IANA Considerations 9. IANA Considerations
IANA Considerations to be included in later versions of this IANA Considerations to be included in later versions of this
document. document.
10. Acknowledgments 10. Changes
The authors would like to thank.... Note to RFC Editor: Please remove this whole section.
11. References 10.1. Changes from 01 Version
11.1. Normative References o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team
work.
11. Acknowledgments
The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The
design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan.
12. References
12.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
skipping to change at page 25, line 30 skipping to change at page 53, line 34
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Nielsen, H., Gudgin, M., Hadley, M., Moreau, J., and N. Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
Framework", World Wide Web Consortium FirstEdition REC- World Wide Web Consortium FirstEdition REC-soap12-part1-
soap12-part1-20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Nielsen, H., Mendelsohn, N., Hadley, M., Moreau, J., and Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H.
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
11.2. Informative References 12.2. Informative References
[I-D.ietf-mediactrl-architecture] [I-D.ietf-mediactrl-architecture]
Melanchuk, T., "An Architectural Framework for Media Melanchuk, T., "An Architectural Framework for Media
Server Control", draft-ietf-mediactrl-architecture-04 Server Control", draft-ietf-mediactrl-architecture-04
(work in progress), November 2008. (work in progress), November 2008.
[I-D.ietf-mediactrl-requirements] [I-D.ietf-mediactrl-requirements]
Dolly, M. and R. Even, "Media Server Control Protocol Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", draft-ietf-mediactrl-requirements-04 (work Requirements", draft-ietf-mediactrl-requirements-04 (work
in progress), February 2008. in progress), February 2008.
 End of changes. 63 change blocks. 
140 lines changed or deleted 1407 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/