draft-ietf-mediactrl-mrb-01.txt   draft-ietf-mediactrl-mrb-02.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: March 29, 2010 University of Napoli Expires: June 18, 2010 University of Napoli
September 25, 2009 December 15, 2009
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-01 draft-ietf-mediactrl-mrb-02
Abstract
The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment
architectures that include 1:M and M:M combinations of Application
Servers and Media Servers. This document introduces a Media Resource
Broker (MRB) entity which manages the availability of Media Servers
and the media resource demands of Application Servers. The document
includes potential deployment options for an MRB and appropriate
interfaces to Application Servers and Media Servers.
Status of this Memo 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 49
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 March 29, 2010. This Internet-Draft will expire on June 18, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The MediaCtrl work group in the IETF is currently proposing an described in the BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 8
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 13 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publishing Interface . . . . . . . . 13 5.1. Media Server Resource Publishing Interface . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . . 14 5.1.1. Control Package Definition . . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 17 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 18
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 24 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Service Resource Consumer Interface . . . . . . . . 25 5.2. Media Service Resource Consumer Interface . . . . . . . . 28
5.2.1. Media Service Resource Request . . . . . . . . . . . . 25 5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 28
5.2.2. Media Service Resource Response . . . . . . . . . . . 26 5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . . 29
5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 27 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . . 30
5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . . 27 5.2.4. Media Service Resource Request . . . . . . . . . . . . 32
5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . . 27 5.2.5. Media Service Resource Response . . . . . . . . . . . 42
6. Media Service Resource Publisher Interface XML Schema . . . . 30 5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 44
7. Media Service Resource Consumer Interface XML Schema . . . . . 47 5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 6. Media Service Resource Publisher Interface XML Schema . . . . 47
10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7. Media Service Resource Consumer Interface XML Schema . . . . . 71
10.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 92
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.1. application/mrb-publish+xml MIME Type . . . . . . . . . . 93
12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 9.2. application/mrb-consumer+xml MIME Type . . . . . . . . . . 94
12.2. Informative References . . . . . . . . . . . . . . . . . . 54 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 10.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 95
10.2. Changes from 00 Version . . . . . . . . . . . . . . . . . 95
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12.1. Normative References . . . . . . . . . . . . . . . . . . . 97
12.2. Informative References . . . . . . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99
1. Introduction 1. Introduction
The topic of Media Resources has been in discussion for a number of The topic of Media Resource management has been in discussion for a
years with varying proprietary solutions being used today. It is number of years with varying proprietary solutions being used today.
clear that, as we move towards a consistent architecture and protocol It is clear that, as we move towards a consistent architecture and
for Media Server Control, a standard mechanism is required for protocol for Media Server Control, a standard mechanism is required
accurate media resource location. for accurate media resource location.
As IP based multimedia infrastructures mature, the complexity and As IP based multimedia infrastructures mature, the complexity and
demands from deployments increase. Such complexity will result in a demands from deployments increase. Such complexity will result in a
wide variety of capabilities from a range of vendors that should all wide variety of capabilities from a range of vendors that should all
be interoperable using the architecture and protocols produced by the be interoperable using the architecture and protocols produced by the
MediaCtrl work group. It should be possible for a controlling entity MediaCtrl work group. It should be possible for a controlling entity
to be assisted in Media Server selection so that the most appropriate to be assisted in Media Server selection so that the most appropriate
resource is selected for a particular operation. The importance resource is selected for a particular operation. The importance
increases when you introduce a flexible level of deployment increases when you introduce a flexible level of deployment
scenarios, as specified in the MediaCtrl Requirements scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567
[I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture [RFC5567] documents. These documents make statements like "it should
[I-D.ietf-mediactrl-architecture] documents. These documents make be possible to have a many-to-many relationship between Application
statements like "it should be possible to have a many-to-many Servers and Media Servers that use this protocol". This leads to the
relationship between Application Servers and Media Servers that use following deployment architectures being possible when considering
this protocol". This leads to the following deployment architectures media resources.
being possible when considering media resources.
The simplest deployment view is illustrated in Figure 1. The simplest deployment view is illustrated in Figure 1.
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Application | | Media | | Application | | Media |
| Server |<-------MS Control------>| Server | | Server |<-------MS Control------>| Server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Basic Architecture Figure 1: Basic Architecture
skipping to change at page 6, line 13 skipping to change at page 7, line 13
redundant on others. redundant on others.
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for "OPTIONAL". In addition, BCP 15 indicates requirement levels for
compliant implementations. compliant implementations.
This document inherits terminology proposed in the MediaCtrl This document inherits terminology proposed in RFC 5567 [RFC5567] and
Architecture [I-D.ietf-mediactrl-architecture] and Media Control Media Control Channel Framework
Channel Framework [I-D.ietf-mediactrl-sip-control-framework] [I-D.ietf-mediactrl-sip-control-framework] documents. In addition,
documents. In addition, the following terms are defined for use in the following terms are defined for use in this document and for use
this document and for use in the context of the MediaCtrl Work group in the context of the MediaCtrl Work group in the IETF:
in the IETF:
Media Resource Broker (MRB) A logical entity that is responsible for Media Resource Broker (MRB) A logical entity that is responsible for
both collection of appropriate published Media Server (MS) both collection of appropriate published Media Server (MS)
information and supplying of appropriate MS information to information and supplying of appropriate MS information to
consuming entities. consuming entities.
Query MRB An instantiation of an MRB (See previous definition) that Query MRB An instantiation of an MRB (See previous definition) that
provides an interface for an Application Server to retrieve the provides an interface for an Application Server to retrieve the
location of an appropriate Media Server. The result returned to location of an appropriate Media Server. The result returned to
the Application Server can be influenced by information contained the Application Server can be influenced by information contained
skipping to change at page 7, line 43 skipping to change at page 8, line 43
uses of an MRB, it simply provides the tools for various entities to uses of an MRB, it simply provides the tools for various entities to
interact where appropriate. It is also worth noting that the tools interact where appropriate. It is also worth noting that the tools
provided in this document aim to provide a 'best effort' view of provided in this document aim to provide a 'best effort' view of
media resources at the time of request for initial Media Server media resources at the time of request for initial Media Server
routing decisions. Any dramatic change in media capabilities after a routing decisions. Any dramatic change in media capabilities after a
request has taken place should be handled by the underlying protocol. request has taken place should be handled by the underlying protocol.
Please note that, while the MRB is supposed to provided ASs with as Please note that, while the MRB is supposed to provided ASs with as
much relevant information as possible, there are information pieces much relevant information as possible, there are information pieces
that ASs may be interested to which are out of scope in this that ASs may be interested to which are out of scope in this
document, as for instance reservation requests, MS resource document, as for instance MS resource allocation rules, planned or
allocation rules, planned or unplanned downtime of MS resources, the unplanned downtime of Media Server resources, the planned addition of
planned addition of future MS resources and the like. future Media Server resources.
4. Deployment Scenario Options 4. Deployment Scenario Options
On researching Media Resource Brokering it became clear that a couple On researching Media Resource Brokering it became clear that a couple
of high level models exist. The general principles of "in-line" and of high level models exist. The general principles of "in-line" and
"query" MRB concepts are discussed in the rest of this section. "query" MRB concepts are discussed in the rest of this section.
4.1. Query MRB 4.1. Query MRB
The "Query" model for MRB interactions provides the ability for a The "Query" model for MRB interactions provides the ability for a
skipping to change at page 11, line 48 skipping to change at page 12, line 48
signalling and the media server control protocol PDUs for the purpose signalling and the media server control protocol PDUs for the purpose
of Media Server selection. This includes, for example, looking for of Media Server selection. This includes, for example, looking for
explicit capabilities in the signalling and session details such as explicit capabilities in the signalling and session details such as
media types, codecs and bandwidth requirements. Ultimately the media types, codecs and bandwidth requirements. Ultimately the
decision making and policy enforcement is removed from the decision making and policy enforcement is removed from the
Application Server and shifted to the MRB logical entity. Application Server and shifted to the MRB logical entity.
In-line MRB can be split into two distinct logical roles which can be In-line MRB can be split into two distinct logical roles which can be
applied on a per request basis. They are: applied on a per request basis. They are:
In-line Unaware MRB Mode (IUMM)) Allows an MRB to act on behalf of 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 clients requiring media services who are not aware of an MRB or
its operation. its operation.
In-line Aware MRB Mode (IAMM) Allows an MRB to act on behalf of 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 clients requiring media services who are aware of an MRB and its
operation. operation.
The two modes are discussed in more detail in Section 5.3. The two modes are discussed in more detail in Section 5.3.
5. MRB Interface Definitions 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
skipping to change at page 14, line 50 skipping to change at page 15, 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; <mrbrequest> element is defined as a package request. Event bodies; <mrbrequest> element is defined as a package request. This
notifications are also carried in CONTROL message bodies; the request can be used for creating new subscriptions and update/remove
<mrbnotification> element is defined for package event notifications. existing subscriptions. Event notifications are also carried in
Responses are carried either in REPORT message or Control Framework CONTROL message bodies; the <mrbnotification> element is defined for
200 response bodies; the <mrbresponse> element is defined as a package event notifications. Responses are carried either in REPORT
package level response. message or Control Framework 200 response bodies; the <mrbresponse>
element is defined as a package level response.
Note that package responses are different from framework response 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.5. 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 Media Control Channel Framework
specify if the attributes for media dialog or conference references [I-D.ietf-mediactrl-sip-control-framework] requires a Control Package
are required. definition to specify if the attributes for media dialog or
conference references are required.
[Editors Note: *TODO*.] The Publish interface defined in Section 6 does import and make use
of the common XML schema defined in the Media Control Channel
Framework.
The Consumer interface defined in Section 7 does import and make use
of the common XML schema defined in the Media Control Channel
Framework.
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 <mrbrequest> or CONTROL messages MUST contain either a <mrbrequest> or
<mrbnotification> element. <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 <mrbresponse> element. messages MUST contain a <mrbresponse> element.
5.1.1.6. Audit 5.1.1.6. Audit
*TODO*. The 'mrb-publish/1.0' Media Control Channel Framework package does
not require any additional auditing capability.
[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]. [Editors' Note: The Authors will post and review appropriate examples
to the list that will be included in the final version.]
5.1.2. Element Definitions 5.1.2. Element Definitions
This section defines the XML elements for the Publish interface Media This section defines the XML elements for the Publish interface Media
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 6. Section 6.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The <mrbpublish> element has the following attributes: The <mrbpublish> element has the following attributes:
Version) a token specifying the mrb-publish package version. The Version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute is mandatory. attribute is mandatory.
The <mrbpublish> elements has the following child elements, only one The <mrbpublish> element has the following child element, only one of
of which is allowed to occur. which is allowed to occur in a request.
<mrbrequest> for sending an MRB request. See Section 5.1.3. <mrbrequest> for sending an MRB request. See Section 5.1.3.
<mrbresponse> for sending an MRB response. See Section 5.1.5. <mrbresponse> for sending an MRB response. See Section 5.1.5.
<mrbnotification> for sending an MRB notification. See <mrbnotification> for sending an MRB notification. See
Section 5.1.4. Section 5.1.4.
5.1.3. <mrbrequest> 5.1.3. <mrbrequest>
skipping to change at page 16, line 52 skipping to change at page 18, line 12
The <mrbrequest> element has the following sub-elements which are The <mrbrequest> element has the following sub-elements which are
defined in the remainder of this section: defined in the remainder of this section:
<subscription> for initiating a subscription to a Media Server <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1. from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of Media Server to provide the details relating to the configuration of
updates. The MRB will inform the Media Server how long it wishes to updates. This element can be used either to request a new
receive updates for and the frequency that updates should be sent. subscription or to update an existing one (e.g. to change the
Updates are sent using the <mrbnotification> element. frequency of the updates), and to remove ongoing subscriptions as
well (e.g. to stop an indefinite update). The MRB will inform the
[Editors Note: Include more detail on subscription mechanism Media Server how long it wishes to receive updates for and the
including responses/reject from MS + polling (not including expires frequency that updates should be sent. Updates are sent using the
and frequency elements constitutes a poll of the Media Server using a <mrbnotification> element.
different 'id')].
The <subscription> element has the following attributes: The <subscription> element has the following attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server. The attribute is mandatory. MRB and the Media Server. The attribute is mandatory.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the session id to identify a specific subscription command. with the session id to identify a specific subscription command.
The attribute is mandatory The attribute is mandatory.
action: provides the operation that should be carried out on the
subscription. The value of 'create' instructs the MS to attempt
to setup a new subscription. The value of 'update' instructs the
MS to attempt to update an existing subscription. The value of
'remove' instructs the MS to attempt to remove an existing
subscription and consequently stop any ongoing related
notification. The attribute is mandatory.
The <subscription> element has the following child elements: The <subscription> element has the following child elements:
expires: Provides the amount of time in seconds that a subscription expires: Provides the amount of time in seconds that a subscription
should be installed for notifications at the Media Server. The should be installed for notifications at the Media Server. The
element is optional. element is optional.
frequency: Provides the frequency in seconds that the MRB wishes to frequency: Provides the frequency in seconds that the MRB wishes to
receive notifications from the MRB. The element is optional. receive notifications from the MRB. The element is optional.
[Editors Note: Next version of the document will have exclude/include
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");].
5.1.4. <mrbnotification> 5.1.4. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The 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 Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element contained in an <mrbrequest> using the <mrbnotification> element contained in an <mrbrequest>
element. element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
skipping to change at page 18, line 18 skipping to change at page 19, line 19
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute is mandatory. the <subscription> element. The attribute is mandatory.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the session id to identify a specific notification update. with the session id to identify a specific notification update.
The attribute is mandatory The attribute is mandatory
The following subsections provide details on the child elements that The following subsections provide details on the child elements that
are contained within an <mrbnotification> element. are contained within an <mrbnotification> element.
[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> 5.1.4.1. <media-server-id>
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system wide
identifier for a Media Server instance. The element is mandatory. identifier for a Media Server instance. The element is mandatory.
[Editors Note: Need to talk more about unique property.] [Editors Note: Need to talk more about unique property.]
5.1.4.2. <active-rtp-sessions> 5.1.4.2. <supported-packages>
The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element is
optional.
The <supported-packages> element has no attributes.
The <supported-packages> element has no child elements:
package: The <package> element represents the name of a package
supported by the media server. The <package> element has a single
attribute, 'name', which represents the name of the supported
Media Control Channel Framework package.
5.1.4.3. <active-rtp-sessions>
The <active-rtp-sessions> element provides information detailing the The <active-rtp-sessions> element provides information detailing the
current active Real-time Transport Protocol(RTP) sessions. The current active Real-time Transport Protocol(RTP) sessions. The
element is optional. element is optional.
The <active-rtp-sessions> element has no attributes. The <active-rtp-sessions> element has no attributes.
The <active-rtp-sessions> element has the following child elements: The <active-rtp-sessions> element has the following child element:
rtp-codec: Is a container which representing a supported codec and rtp-codec: Is a container which represents a supported codec and
the active sessions. The <rtp-codec> element has one attribute. the associated active sessions. The <rtp-codec> element has one
The attribute 'name' represents the name of the codec being attribute. The attribute 'name' represents the name of the codec
represented. The <rtp-codec> element has two child elements. The being represented. The <rtp-codec> element has two child
child element, <decoding>, represents the number of RTP sessions elements. The child element, <decoding>, represents the number of
for the specified codec being decoded. The child element, RTP sessions for the specified codec being decoded. The child
<encoding>, represents the number of RTP sessions for the element, <encoding>, represents the number of RTP sessions for the
specified codec being encoded. specified codec being encoded.
5.1.4.3. <active-mixer-sessions> 5.1.4.4. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element is optional. the current active mixed RTP sessions. The element is optional.
The <active-rtp-sessions> element has no attributes. The <active-mixer-sessions> element has no attributes.
The <active-mixer-sessions> element has the following child elements: The <active-mixer-sessions> element has the following child element:
active-mix: Is a container which representing a mixed active RTP active-mix: Is a container which representing a mixed active RTP
session. The <active-mix> element has one attribute. The session. The <active-mix> element has one attribute. The
attribute 'conferenceid' represents the name of the mix being attribute 'conferenceid' represents the name of the mix being
represented. The <active-mix> element has one child elements. represented. The <active-mix> element has one child elements.
The child element, <rtp-codec>, contains the same information The child element, <rtp-codec>, contains the same information
relating to RTP sessions as defined in Section 5.1.4.2. The relating to RTP sessions as defined in Section 5.1.4.3. The
element is optional. element is optional.
5.1.4.4. <non-active-rtp-sessions> 5.1.4.5. <non-active-rtp-sessions>
The <non-active-rtp-sessions> element provides information detailing The <non-active-rtp-sessions> element provides information detailing
the currently available inactive RTP sessions. The element is the currently available inactive RTP sessions. The element is
optional. optional.
The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The <non-active-rtp-sessions> element has the following child The <non-active-rtp-sessions> element has the following child
elements: element:
rtp-codec: Is a container which representing a supported codec and rtp-codec: Is a container which represents a supported codec and
the inactive sessions. The <rtp-codec> element has one attribute. the inactive sessions. The <rtp-codec> element has one attribute.
The attribute 'name' represents the name of the codec being The attribute 'name' represents the name of the codec being
represented. The <rtp-codec> element has two child elements. The represented. The <rtp-codec> element has two child elements. The
first child element, <decoding>, represents the number of first child element, <decoding>, represents the number of
available RTP session for the specified codec being decoded. The available RTP session for the specified codec being decoded. The
second child element, <encoding>, represents the number of second child element, <encoding>, represents the number of
available RTP sessions for the specified codec being encoded. The available RTP sessions for the specified codec being encoded. The
element is optional. element is optional.
5.1.4.5. <non-active-mixer-sessions> 5.1.4.6. <non-active-mixer-sessions>
The <non-active-mixer-sessions> element provides information The <non-active-mixer-sessions> element provides information
detailing the current inactive mixed RTP sessions. The element is detailing the current inactive mixed RTP sessions. The element is
optional. optional.
The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The <non-active-mixer-sessions> element has the following child The <non-active-mixer-sessions> element has the following child
elements: element:
non-active-mix: Is a container which representing an available non-active-mix: Is a container which representing an available
mixed RTP session. The <non-active-mix> element has one mixed RTP session. The <non-active-mix> element has one
attribute. The attribute 'available' represents the number of attribute. The attribute 'available' represents the number of
mixes that could be used using that profile. The <non-active-mix> mixes that could be used using that profile. The <non-active-mix>
element has one child elements. The child element, <rtp-codec>, element has one child elements. The child element, <rtp-codec>,
contains the same information relating to RTP sessions as defined contains the same information relating to RTP sessions as defined
in Section 5.1.4.4. The element is optional. in Section 5.1.4.5. The element is optional.
5.1.4.6. <media-server-status> 5.1.4.7. <media-server-status>
The <media-server-status> element provides information detailing the The <media-server-status> element provides information detailing the
current status of the media server. The element is mandatory. It current status of the media server. The element is mandatory. It
can return one of the following values: can return one of the following values:
active: Indicating that the Media Server is available for service. active: Indicating that the Media Server is available for service.
deactivated: Indicating that the Media Server has been withdrawn deactivated: Indicating that the Media Server has been withdrawn
from service. from service.
unavailable: Indicating that the Media Server can not process new unavailable: Indicating that the Media Server can not process new
requests. requests.
The <media-server-status> element has no attributes. The <media-server-status> element has no attributes.
The <media-server-status> element has no child elements. The <media-server-status> element has no child elements.
[Editors Note: Need to think about status messages and meanings.] 5.1.4.8. <supported-codecs>
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 The <supported-codecs> element provides information detailing the
current codecs supported by a media server and associated actions. current codecs supported by a media server and associated actions.
The element is optional. The element is optional.
The <supported-codecs> element has no attributes. The <supported-codecs> element has no attributes.
The <supported-codecs> element has the following child elements: The <supported-codecs> element has the following child element:
supported-codec: has a single attribute, 'name', which provides the supported-codec: has a single attribute, 'name', which provides the
name of the codec providing information. The <supported-codec> name of the codec providing information. The <supported-codec>
element then has a further child element, <supported-codec- element then has a further child element, <supported-codec-
package>. The <supported-codec-package> element has a single package>. The <supported-codec-package> element has a single
attribute, 'name', which provides the name of the Media Control attribute, 'name', which provides the name of the Media Control
Channel Framework package for which the codec support applies. Channel Framework package for which the codec support applies.
The <supported-codec-package> element has one further child The <supported-codec-package> element has one further child
element, <supported-actions>, which provide the actions that an element, <supported-actions>, which provide the actions that a
Media Server can apply to this codec (decode, encode, Media Server can apply to this codec (decode, encode,
passthrough). passthrough).
5.1.4.8. <application-data> 5.1.4.9. <application-data>
The <application-data> element provides application level data. The The <application-data> element provides application level data. The
element is optional. element is optional.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.1.4.9. <file-formats> 5.1.4.10. <file-formats>
The <file-formats> element provides a list of file formats supported The <file-formats> element provides a list of file formats supported
for the purpose of making announcements. The element is optional. for the purpose of making announcements. The element is optional.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has the following child elements: The <file-formats> element has the following child element:
supported-format: has a single attribute, 'name', which provides supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format> the type of file format that is supported. The <supported-format>
element then has a further child element, <supported-file- element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package for which the codec of the Media Control Channel Framework package for which the file
support applies. format support applies.
5.1.4.10. <max-prepared-duration> 5.1.4.11. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time a The <max-prepared-duration> element provides the amount of time a
media dialog cane be prepared in the system before it is executed. media dialog cane be prepared in the system before it is executed.
The element is optional. The element is optional.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child elements: The <max-prepared-duration> element has the following child element:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be 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 in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package provides the name of the Media Control Channel Framework package
for which the time period applies. 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> 5.1.4.12. <dtmf-support>
The <dtmf-support> element supplies the supported methods to detect The <dtmf-support> element supplies the supported methods to detect
DTMF tones and to generate them. The element is optional. DTMF tones and to generate them. The element is optional.
The <dtmf-support> element has no attributes. The <dtmf-support> element has no attributes.
The <dtmf-support> element has the following child elements: The <dtmf-support> element has the following child elements:
detect: has no attributes. The <detect> element then has a further detect: has no attributes. The <detect> element then has a further
skipping to change at page 23, line 7 skipping to change at page 23, line 44
passthrough: has no attributes. The <passthrough> element then has passthrough: has no attributes. The <passthrough> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used. The 'package' attribute provides the type of DTMF being used. The 'package' attribute
provides the name of the Media Control Channel Framework package provides the name of the Media Control Channel Framework package
for which the DTMF type applies. for which the DTMF type applies.
5.1.4.13. <mixing-modes> 5.1.4.13. <mixing-modes>
[Editors Note: TODO after further group discussion]. The <mixing-modes> element provides information about the support for
audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video
presentation layouts. The element is optional.
The <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements:
audio-mixing-modes: Is a container representing the available
algorithms for audio mixing. The <audio-mixing-modes> element has
no attributes. The <audio-mixing-modes> element has one child
element. The child element, <audio-mixing-mode>, contains a
specific available algorithm. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support
applies.
video-mixing-modes: Is a container representing the available video
presentation layouts and the supported functionality for what
concerns video mixing. The <video-mixing-modes> element has two
attributes, 'vas' and 'activespeakermix'. The 'vas' attribute is
of type boolean with a value of 'true' indicating the Media Server
supports automatic Voice Activated Switching. The
'activespeakermix' is of type boolean with a value of 'true'
indicating that the Media Server is able to prepare an additional
video stream for the loudest speaker participant without its
contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains a
specific video presentation layout. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support
applies.
5.1.4.14. <supported-tones> 5.1.4.14. <supported-tones>
[Editors Note: TODO after further group discussion]. The <supported-tones> element provides information about which tones
a media server support. In particular, the support is reported
referring to both country codes support (ISO 3166-1) and supported
functionality (H.248.1v3/ITU-T Q.1950/..). The element is optional.
The <supported-tones> element has no attributes.
The <supported-tones> element has the following child elements:
supported-country-codes: Is a container representing the supported
country codes with respect to tones. The <supported-country-
codes> element has no attributes. The <supported-country-codes>
has one child element. The child element, <country-code>, reports
support for a specific country code, compliant with the ISO 3166-1
specification. The <country-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package in which the tones from the
specified country code are supported.
supported-h248-codes: Is a container representing the supported
H.248 codes with respect to tones. The <supported-h248-codes>
element has no attributes. The <supported-h248-codes> has one
child element. The child element, <h248-code>, reports support
for a specific H.248 code, compliant with the H.248.1v3/ITU-T
Q.1950/... specification. The codes can be either specific (e.g.
cg/dt to only report the Dial Tone from the Call Progress Tones
package) or generic (e.g. cg/* to report all the tones from the
Call Progress Tones package) using wildcards. The <h248-code>
element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework
package in which the specified codes are supported.
5.1.4.15. <streaming-modes> 5.1.4.15. <streaming-modes>
The <streaming-modes> element allows the Media Server to specify The <streaming-modes> element allows the Media Server to specify
which protocols are supported for streaming to a Media Server for which protocols are supported for streaming to a Media Server for
each Media Control Channel Framework package type. For example does each Media Control Channel Framework package type. For example,
the Media Server supports audio streaming via RTSP, HTTP, NFS, etc whether the Media Server supports audio streaming via RTSP, HTTP,
protocols. The element is optional. NFS, etc protocols. The element is optional.
The <streaming-modes> element has no attributes. The <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child elements: The <streaming-modes> element has the following child element:
stream-mode: has a two attributes, 'name' and 'package'. The stream-mode: has two attributes, 'name' and 'package'. The 'name'
'name' attribute provides the type of protocol that can be used attribute provides the type of protocol that can be used for
for streaming. The 'package' attribute provides the name of the streaming. The 'package' attribute provides the name of the Media
Media Control Channel Framework package for which the streaming Control Channel Framework package for which the streaming protocol
protocol applies. applies.
5.1.4.16. <asr-tts-support> 5.1.4.16. <asr-tts-support>
[Editors Note: TODO after further group discussion]. The <asr-tts-support> element provides information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The <asr-tts-support>
element has no attributes. The <asr-tts-support> element has the
following child elements:
asr-support: Is a container representing the available languages
for ASR. The <asr-support> element has no attributes. The <asr-
support> has one child element. The child element, <language>,
reports the MS supports ASR for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
tts-support: Is a container representing the available languages
for TTS. The <tts-support> element has no attributes. The <tts-
support> has one child element. The child element, <language>,
reports the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
5.1.4.17. <vxml-support> 5.1.4.17. <vxml-support>
The <vxml-support> element specifies if the Media Server supports The <vxml-support> element specifies if the Media Server supports
VoiceXML and if it does which protocols the support is exposed VoiceXML and if it does which protocols the support is exposed
through (eg via the control framework, or RFC5552). The element is through (e.g. via the control framework, or RFC5552). The element is
optional. optional.
The <vxml-support> element has a single attribute 'support'. The The <vxml-support> element has a single attribute 'support'. The
'support' attribute is of type boolean with a value of 'true' 'support' attribute is of type boolean with a value of 'true'
indicating that the media server does support VXML, and a value of indicating that the media server does support VXML, and a value of
'false' indicating it does not support VXML. The default value is 'false' indicating it does not support VXML. The default value is
'false'. 'false'.
The <vxml-support> element has the following child elements: The <vxml-support> element has the following child element:
vxml-mode: has a two attributes, 'package' and 'support'. The vxml-mode: has two attributes, 'package' and 'support'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package for which the streaming protocol applies. The Framework package for which the VXML support applies. The
'support' attribute provides the type of VXML support provided by 'support' attribute provides the type of VXML support provided by
the Media Server (RFC5552 or msc-ivr/1.0). the Media Server (RFC5552 or IVR-Package).
5.1.4.18. <media-server-location> 5.1.4.18. <media-server-location>
[Editors Note: TODO after further group discussion]. The <media-server-location> element provides information about the
civic location of a media server. Its description makes use of the
Civic Address Schema standardized in RFC5139. The element is
optional.
The <media-server-location> element has no attributes.
The <media-server-location> element one child element:
civicAddress: Is a container representing the civic address
location of the media server, whose representation refers to the
Section 4 of RFC 5139 [RFC5139].
5.1.4.19. <label> 5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the 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 Media Server can declare if it's a blue or green. It's a string to
allow arbitrary values to be returned to allow arbitrary allow arbitrary values to be returned to allow arbitrary
classification. Its arbitrary as opposed to doing it purely on classification. Its arbitrary as opposed to doing it purely on
features. The element is optional. features. The element is optional.
The <application-data> element has no attributes. The <label> element has no attributes.
The <application-data> element has no child elements. The <label> element has no child elements.
5.1.4.20. <media-server-address> 5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct URI address. direct URI address. The element is optional.
The <application-data> element has no attributes. The <media-server-address> element has no attributes.
The <application-data> element has no child elements. The <media-server-address> element has no child elements.
5.1.4.21. <encryption> 5.1.4.21. <encryption>
[Editors Note: TODO after further group discussion]. The <encyption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. A value of
'true' indicates that a Media Server does support RFC 3711 [RFC3711]
for RTP. A value of 'false' indicates that a Media Server does not
support RFC 3711 [RFC3711] for RTP. The element is optional.
The <encryption> element has no attributes.
The <application-data> element has no child elements.
5.1.5. <mrbresponse> 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:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 401 | Unable to create Subscription |
| | |
| 402 | Unable to update Subscription |
| | |
| 403 | Unable to remove Subscription |
| | |
| 404 | Subscription does not exist |
| | |
| 405 | Subscription already exists |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <response> status codes Table 1: <response> status codes
[Editors Note: more status codes to be added + an example.]
5.2. Media Service Resource Consumer Interface 5.2. Media Service Resource Consumer Interface
The Media Server Consumer interface provides the ability for clients The Media Server Consumer interface provides the ability for clients
of an MRB, such as Application Servers, to request an appropriate of an MRB, such as Application Servers, to request an appropriate
Media Server to satisfy specific criteria. The interface allows a Media Server to satisfy specific criteria. The interface allows a
client to pass detailed meta-information to the MRB to help select an 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 appropriate Media Server. The MRB is then able to make an informed
decision and provide the client with an appropriate media server decision and provide the client with an appropriate media server
resource. resource. The MRB Consumer interface can be used in association with
both the Session Initiation Protocol (SIP) and the Hypertext Transfer
It appears the most appropriate interface for such a 'query' style Protocol (HTTP) [RFC2616]. The following subsections provide
interface is in fact a HTTP usage. Using HTTP and XML combined guidance on using the Consumer interface, as defined by the
reduces complexity and encourages use of common tools that are widely 'application/mrb-consumer+xml MIME type in Section 7, with HTTP and
available in the industry today. The following subsections explain SIP.
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].
[Editors Note: Need to discuss the updating of a request and proposal 5.2.1. HTTP Consumer Interface Usage
of having the client supply updates on resources. For example,
releasing resources.]
5.2.1. Media Service Resource Request An appropriate interface for such a 'query' style interface is in
fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the
industry today. The following information explains the primary
operations required to request and then receive information from an
MRB. The following description will describe the use of HTTP
[RFC2616] and HTTPS [RFC2818] as transport for a query for media
resource and the appropriate response.
The media resource query is carried in the body of an HTTP/HTTPS POST The media resource query, as defined by the <mediaResourceRequest>
request. The MIME type contained in the HTTP/HTTPS request/response element from Section 7, MUST be carried in the body of an HTTP/HTTPS
should be 'application/mrb-consumer+xml'. This value MUST be POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the POST request MUST only contain the 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
'mediaResourceRequest' element as defined in Section 7. The the 'mediaResourceRequest' element as defined in Section 7. The
'mediaResourceRequest' element is the primary container of 'mediaResourceRequest' element is the primary container of
information related to a media resource request and has the following information related to a media resource request.
child elements which specify the request parameters:
5.2.1.1. <mediaResourceRequest> element The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 7, MUST be carried in
the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
the 'mediaResourceResponse' element as defined in Section 7. The
'mediaResourceResponse' element is the primary container of
information related to a media resource response.
5.2.2. SIP Consumer Interface Usage
This document provides a complete toolkit for MRB deployment which
includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary
operations required to request and then receive information from an
MRB. The following description will describe the use of SIP
[RFC3261] as transport for a query for media resource and the
appropriate response when used with IAMM of operation (as discussed
in Section 5.3.2).
The media resource query, as defined by the <mediaResourceRequest>
element from Section 7, MUST be carried in a SIP INVITE request. The
INVITE request will be constructed as it would have been to connect
to a media server, as defined by the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework]. The following additional
steps MUST be followed when using the Consumer interface:
o Include a payload in the SIP INVITE request of type 'multipart/
mixed'[RFC2046]. The first part to be included in the 'mixed'
payload MUST be the 'application/sdp' format which is constructed
as specified in the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework].
o The second part of the 'multipart/mixed payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and
defined in Section 7. Only the <mediaResourceRequest> and its
child elements can be included in the payload.
o The INVITE request will then be dispatched to the MRB, as defined
by [I-D.ietf-mediactrl-sip-control-framework].
The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 7, MUST be carried in
the payload of a SIP 2xx class response to the original SIP INVITE
request. The 2xx class response will be constructed as it would have
been to connect from a media server, as defined by the Media Control
Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The
following additional steps MUST be followed when using the Consumer
interface:
o Include a payload in the SIP 2xx class response of type
'multipart/mixed'RFC 2046 [RFC2046]. The first part to be
included in the 'mixed' payload MUST be the 'application/sdp'
format which is constructed as specified in the Media Control
Channel Framework [I-D.ietf-mediactrl-sip-control-framework].
o The second part of the 'multipart/mixed payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and
defined in Section 7. Only the <mediaResourceResponse> and its
child elements can be included in the payload.
o The SIP 2xx class response will then be dispatched from the MRB,
as defined by [I-D.ietf-mediactrl-sip-control-framework].
5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 7 and Section 7 allows a
client to request an appropriate media resource based on information
included in the request (either a HTTP POST or SIP INVITE message).
In case of success, the response that is returned to the client MUST
contain a <session-info> element in either the SIP 2xx class or HTTP
200 response. The information contained in the <session-info>
element allows a Consumer client to monitor the life time of the
resources it has successfully requested, as well as amending them.
The <mediaResourceResponse> element returned from the MRB contains a
<session-info> element if the request is successful. The <session-
info> element has the following child elements which provide the
appropriate resource session information:
o <session-id> is a unique identifier that enables a Consumer client
and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included
in all future related requests (see <session-id> use later in this
section when constructing a subsequent request).
o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client
MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when
constructing a subsequent request).
o <expires> provide a value which represents the number of seconds
the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later
in this section, if the expires timer is due to fire and the media
resources are still required.
The <mediaResourceRequest> element is used in subsequent Consumer
interface requests if the client wishes to manipulate the session.
The Consumer client MUST include the <session-info> element which
enables the receiving MRB to determine an existing media resource
allocation session. The <session-info> element has the following
child elements which provide the appropriate resource session
information to the MRB:
o <session-id> is a unique identifier that allows a Consumer client
to indicate the appropriate existing media resource session to be
manipulated by the MRB for this request. The value was provided
by the MRB in the initial request for media resources, as
discussed earlier in this section (<session-id> element included
as part of the <session-info> element in the initial
<mediaResourceResponse>).
o <seq> is a numeric value returned to Consumer client in the
initial request for media resources, as discussed earlier in this
section (<seq> element included as part of the <session-info>
element in the initial <mediaResourceResponse>). On issuing any
future requests related to the specific media resource session (as
determined by the <session-id> element) the consumer client MUST
increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows
for unique identification of a request.
o <action> element provides the operation to be carried out by the
MRB on receiving the request. The value of 'update' is a request
by the Consumer client to update the existing session at the MRB
with information contained in the remainder of the request. If
the information is identical as the existing request, the MRB will
attempt a session refresh. If the information has changed, the
MRB will attempt to update the existing session with the new
information. If the operation is successful, the 200 response is
returned in the status attribute of the
<mediaResourceResponseType> element. If the operation is not
successful, a 409 response is returned in the status attribute of
the <mediaResourceResponseType> element. The value of 'remove' is
a request by the Consumer client to remove the session at the MRB.
This provides a mechanism for Consumer clients to release unwanted
resources before they expire. If the operation is successful, a
200 response is returned in the status attribute of the
<mediaResourceResponseType> element. If the operation is not
successful, a 410 response is returned in the XXX element.
When used with SIP the <session-info> element MUST be included in
either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as
defined in[RFC3311]) request. When used with HTTP the <session-info>
element MUST be included in a HTTP POST message (as defined in
[RFC2616]).
5.2.4. Media Service Resource Request
This section defines the XML elements for the Consumer interface.
The formal XML schema definition for the Consumer interface can be
found in Section 7.
The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface
request element is detailed in Section 5.2.4.1. MRB Consumer
interface response element is contained in Section 5.2.5.1.
The <mrbconsumer> element has the following attributes:
Version) a token specifying the mrb-consumer package version. The
value is fixed as '1.0' for this version of the package. The
attribute is mandatory.
The <mrbconsumer> element has the following child elements, only one
of which is allowed to occur.
<mediaResourceRequest> for sending a Consumer request. See
Section 5.2.4.1.
<mediaResourceResponse> for sending a Consumer response. See
Section 5.2.5.1.
5.2.4.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides a container for clients 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 <generalInfo>, <ivrInfo> and <mixerInfo> as child
appropriate contextual information relating to the request: [Editors elements. These three elements are used to describe the requirements
Note: Convert groups input into appropriate XML schema.] of a client requesting a Media Server and are covered in the
following sub-sections.
o RTP requirements - including media/codec type, codec priority. 5.2.4.1.1. <generalInfo> element
o Conference requirements - number of users. The <generalInfo> element provides a container for general Consumer
request information that is neither IVR or Mixer specific. This
includes session information that can be used for subsequent requests
as part of the leasing mechanism described in Section 5.2.3. The
<generalInfo> element has <session-info> and <packages> as child
elements and are described in the following sub-sections.
5.2.2. Media Service Resource Response 5.2.4.1.1.1. <session-info> element
The use of HTTP/HTTPS for carrying the media service resource The <session-info> element is included in Consumer requests when an
information has no impact on the protocol. If protocol level update is being made to an existing media resource session. The
operations and errors occur then they should be signalled as ability to change and remove an existing media resource session is
specified in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119]. A described in more detail in Section 5.2.3. The element is optional.
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).
5.2.2.1. <mediaResourceResponse> element The <max-prepared-duration> element has no attributes.
The <mediaResourceResponse> element provides a container for the MRB The <max-prepared-duration> element has the following child elements:
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 session-id: is a unique identifier that explicitly references an
capabilities). existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more
detail in Section 5.2.3.
5.2.2.2. <mediaResourceError> element seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3.
The <mediaResourceError> element provides a container for the MRB to action: provides the operation that should be carried out on an
generate an error response to a previous query. The existing media resource session on an MRB. The value of 'update'
<mediaResourceError> has element the following child elements that instructs the MRB to attempt to update the existing media resource
are used to provide appropriate contextual information relating to session with the information contained in the <ivrInfo> and
the request: [Editors Note: Convert groups input into appropriate XML <mixerInfo> elements. The value of 'remove' instructs the MRB to
schema.] attempt to remove the existing media resource session. More
information on its use is provided in Section 5.2.3.
o list of appropriate error response codes. 5.2.4.1.1.2. <packages> element
The <packages> element provides a list of Media Control Channel
Framework compliant packages that are required by the Consumer
client. The element is optional.
The <packages> element has no attributes.
The <packages> element has the following child element:
package: child element contains a string representing the Media
Control Channel Framework package required by the Consumer client.
The <package> element can appear multiple times.
5.2.4.1.2. <ivrInfo> element
The <ivrInfo> element provides a container for general Consumer
request information that is IVR specific. The <ivrInfo> element has
<ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>,
<location>, <encryption>, <application-data>, <max-prepared-duration>
and <stream-mode> as child elements and are described in the
following sub-sections.
5.2.4.1.2.1. <ivr-sessions> element
The <ivr-sessions> element indicates the number of IVR sessions a
Consumer client requires from a media resource. The element is
optional.
The <ivr-sessions> element has no attributes.
The <ivr-sessions> element has the following child element:
rtp-codec: child element contains has a single attribute, 'name'.
The 'name' attribute provides the name of the codec required for
an IVR session and is an appropriately registered token. The
<rtp-codec> element has two child elements. The child element,
<decoding>, represents the number of RTP sessions for which
decoding using the specified codec is requested. The child
element, <encoding>, represents the number of RTP sessions for
which encoding using the specified codec is requested.
5.2.4.1.2.2. <file-formats> element
The <file-formats> element provides a list of file formats required
for the purpose of making announcements. The element is optional.
The <file-formats> element has no attributes.
The <file-formats> element has the following child element:
supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format>
element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package for which the file
format support applies.
5.2.4.1.2.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones
and to generate them. The element is optional.
The <dtmf> element has no attributes.
The <dtmf> 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 required. 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 required. 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 required. The 'package' attribute
provides the name of the Media Control Channel Framework package
for which the DTMF type applies.
5.2.4.1.2.4. <tones>
The <tones> element provides requested tones a media server must
support for IVR. In particular, the request refers to both country
codes support (ISO 3166-1) and requested functionality (H.248.1v3/
ITU-T Q.1950/..). The element is optional.
The <tones> element has no attributes.
The <tones> element has the following child elements:
country-codes: Is a container representing the requested country
codes with respect to tones. The <country-codes> element has no
attributes. The <country-codes> has one child element. The child
element, <country-code>, requests a specific country code,
compliant with the ISO 3166-1 specification. The <country-code>
element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework
package in which the tones from the specified country code are
requested.
h248-codes: Is a container representing the requested H.248 codes
with respect to tones. The <h248-codes> element has no
attributes. The <h248-codes> has one child element. The child
element, <h248-code>, requests a specific H.248 code, compliant
with the H.248.1v3/ITU-T Q.1950/... specification. The codes can
be either specific (e.g. cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g. cg/* to report
all the tones from the Call Progress Tones package) using
wildcards. The <h248-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package in which the specified codes are
requested.
5.2.4.1.2.5. <asr-tts>
The <asr-tts-support> element requests information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality is requested by
referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The <asr-tts-support>
element has no attributes. The <asr-tts-support> element has the
following child elements:
asr-support: Is a container representing the available languages
for ASR. The <asr-support> element has no attributes. The <asr-
support> has one child element. The child element, <language>,
requests the MS supports ASR for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
tts-support: Is a container requesting the available languages for
TTS. The <tts-support> element has no attributes. The <tts-
support> has one child element. The child element, <language>,
requests the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language.
5.2.4.1.2.6. <vxml> element
The <vxml> element specifies if the Consumer client required VoiceXML
and if it does which protocols the support is exposed through (e.g.
via the control framework, or RFC5552). The element is optional.
The <vxml> element has a single attribute 'support'. The 'support'
attribute is of type boolean with a value of 'true' indicating that
the Consumer client requires VXML support, and a value of 'false'
indicating it does not require VXML support. The default value is
'false'.
The <vxml> element has the following child element:
vxml-mode: has two attributes, 'package' and 'require'. The
'package' attribute provides the name of the Media Control Channel
Framework package for which the VXML support applies. The
'require' attribute specifies the type of VXML support required by
the Consumer client (RFC5552 or IVR-Package).
5.2.4.1.2.7. <location>
The <location> element requests a civic location for an IVR media
server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element is optional.
The <location> element has no attributes.
The <location> element one child element:
civicAddress: Is a container representing the civic address
location of the requested media server, whose representation
refers to Section 4 of RFC 5139 [RFC5139].
5.2.4.1.2.8. <encryption>
The <encryption> element allows a Consumer client to request support
for encrypting RTP media streams using RFC 3711 [RFC3711]. A value
of 'true' indicates that Consumer client requires support of RFC 3711
[RFC3711] for RTP. A value of 'false' indicates that a Consumer
client does not require support of RFC 3711 [RFC3711] for RTP. The
element is optional. The default value is 'false'
The <encryption> element has no attributes.
The <application-data> element has no child elements.
5.2.4.1.2.9. <application-data>
The <application-data> element provides IVR application level data.
The element is optional.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.2.4.1.2.10. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time
required by the Consumer client that a media dialog can be prepared
in the system before it is executed. The element is optional.
The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element:
max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package
for which the time period applies.
5.2.4.1.2.11. <streaming-modes>
The <streaming-modes> element allows the Consumer client to specify
which protocols are required for streaming to a Media Server for each
Media Control Channel Framework package type. For example does the
Media Server supports audio streaming via RTSP, HTTP, NFS, etc
protocols. The element is optional.
The <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child element:
stream-mode: has two attributes, 'name' and 'package'. The 'name'
attribute provides the type of protocol required for streaming.
The 'package' attribute provides the name of the Media Control
Channel Framework package for which the streaming protocol
applies.
5.2.4.1.3. <mixerInfo> element
The <mixerInfo> element provides a container for general Consumer
request information that is Mixer specific. The <mixerInfo> element
has <mixers>, <file-formats>, <dtmf-type>, <tones>, <mixing-mode>,
<application-data>, <location> and <encryption> are described in the
following sub-sections.
5.2.4.1.3.1. <mixers>
The <mixers> element provides information detailing the required
mixed RTP sessions. The element is optional.
The <mixers> element has no attributes.
The <mixers> element has the following child element:
mix: Is a container which representing a required mixed RTP
session. The <mix> element has one attribute. The attribute
'users' represents the number of participants required in the mix.
The <mix> element has one child elements. The child element,
<codec>, contains the same information relating to RTP sessions as
defined in Section 5.1.4.3. The element is optional.
5.2.4.1.3.2. <file-formats>
The <file-formats> element provides a list of file formats required
by the Consumer client for the purpose of making announcements to a
mix. The element is optional.
The <file-formats> element has no attributes.
The <file-formats> element has the following child element:
required-format: has a single attribute, 'name', which provides the
type of file format that is supported. The <required-format>
element then has a further child element, <required-file-package>.
The <required-file-package> element provides the name of the Media
Control Channel Framework package for which the file format
support applies.
5.2.4.1.3.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones
and to generate them in a mix. The element is optional.
The <dtmf> element has no attributes.
The <dtmf> 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 required. 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 required. 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 required. The 'package' attribute
provides the name of the Media Control Channel Framework package
for which the DTMF type applies.
5.2.4.1.3.4. <tones>
The <tones> element provides requested tones a media server must
support for a mix. In particular, the request refers to both country
codes support (ISO 3166-1) and requested functionality (H.248.1v3/
ITU-T Q.1950/..). The element is optional.
The <tones> element has no attributes.
The <tones> element has the following child elements:
country-codes: Is a container representing the requested country
codes with respect to tones. The <country-codes> element has no
attributes. The <country-codes> has one child element. The child
element, <country-code>, requests a specific country code,
compliant with the ISO 3166-1 specification. The <country-code>
element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework
package in which the tones from the specified country code are
requested.
h248-codes: Is a container representing the requested H.248 codes
with respect to tones. The <h248-codes> element has no
attributes. The <h248-codes> has one child element. The child
element, <h248-code>, requests a specific H.248 code, compliant
with the H.248.1v3/ITU-T Q.1950/... specification. The codes can
be either specific (e.g. cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g. cg/* to report
all the tones from the Call Progress Tones package) using
wildcards. The <h248-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package in which the specified codes are
requested.
5.2.4.1.3.5. <mixing-modes>
The <mixing-modes> element requests information about the support for
audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video
presentation layouts. The element is optional.
The <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements:
audio-mixing-modes: Is a container representing the requested
algorithms for audio mixing. The <audio-mixing-modes> element has
no attributes. The <audio-mixing-modes> element has one child
element. The child element, <audio-mixing-mode>, contains a
specific requested algorithm. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support
is requested.
video-mixing-modes: Is a container representing the requested video
presentation layouts for video mixing. The <video-mixing-modes>
element has two attributes, 'vas' and 'activespeakermix'. The
'vas' attribute is of type boolean with a value of 'true'
indicating that the Consumer Client requires automatic Voice
Activated Switching. The 'activespeakermix' attribute is of type
boolean with a value of 'true' indicating that the Consumer Client
requires an additional video stream for the loudest speaker
participant without its contribution. The <video-mixing-modes>
element has one child element. The child element, <video-mixing-
mode>, contains a requested video presentation layout. It has a
single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package for which the
algorithm support is requested.
5.2.4.1.3.6. <application-data>
The <application-data> element provides IVR application level data.
The element is optional.
The <application-data> element has no attributes.
The <application-data> element has no child elements.
5.2.4.1.3.7. <location>
The <location> element requests a civic location for a mixer media
server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element is optional.
The <location> element has no attributes.
The <location> element one child element:
civicAddress: Is a container representing the civic address
location of the requested media server, whose representation
refers to Section 4 of RFC 5139 [RFC5139].
5.2.4.1.3.8. <encryption>
The <encryption> element allows a Consumer client to request support
for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. A
value of 'true' indicates that Consumer client requires support of
RFC 3711 [RFC3711] for RTP. A value of 'false' indicates that a
Consumer client does not require support of RFC 3711 [RFC3711] for
RTP. The element is optional. The default value is 'false'
The <encryption> element has no attributes.
The <application-data> element has no child elements.
5.2.5. Media Service Resource Response
This section provides the element definitions for use in Consumer
interface responses. The responses are carried in the
<mediaResourceResponse> container element.
5.2.5.1. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a container for clients
receiving query information from an external MRB entity.
The <mediaResourceResponse> element has a single attribute 'status'
which indicates the status code of the operation. The following
status codes are defined:
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 408 | Unable to find Resource |
| | |
| 409 | Unable to update Resource |
| | |
| 410 | Unable to remove Resource |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 2: <response> status codes
The <mediaResourceResponse> element only has <response-session-info>
as a child element. This element is used to describe the response of
a Consumer interface query and is covered in the following sub-
section.
5.2.5.1.1. <response-session-info> element
The <response-session-info> element is included in Consumer responses
when an update has been made to an existing media resource session.
The ability to change and remove an existing media resource session
is described in more detail in Section 5.2.3. The element is
optional.
The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child elements:
session-id: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more
detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3.
expires: includes the number of seconds that the media resources
reserved as part of this interaction. If the lease is refreshed
before expiry, the MRB will re-claim the resources and they will
no longer be guaranteed. It is RECOMMENDED that a minimum value
of 300 seconds be used for the value of the 'expires' attribute.
It is also RECOMMENDED that a Consumer client refresh the lease at
an interval that is not too close to the expiry time. A value of
80% of the timeout period could be used. For example, if the
timeout period is 300 seconds, the Server would refresh the
transaction at 240 seconds. More information on its use is
provided in Section 5.2.3.
media-server-address: is the SIP URI to reach the MS handling the
requested media resource.
[Editors' Note: this response should also include a way for the
Consumer Client to contact the MS able to fulfil the request, at
least in case of the HTTP usage of the Consumer interface. Such info
wouldn't be needed in the IAMM case. At the moment this is reported
by means of the <media-server-address> element, which is also used in
the publishing interface. Is this SIP URI enough? Do we need to
provide additional details?]
5.3. In-Line MRB Interface 5.3. In-Line MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a 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 request, as introduced in Section 4.2. The following sub sections
provide details for using In-Line Unaware MRB Mode (IUAMM) of provide details for using In-Line Unaware MRB Mode (IUMM) of
operation and In-Line Aware MRB Mode (IAMM) of operation. operation and In-Line Aware MRB Mode (IAMM) of operation.
5.3.1. In-line Unaware MRB Mode 5.3.1. In-line Unaware MRB Mode
It should be noted that the introduction of an MRB entity into the It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be network, as specified in this document, requires interfaces to be
implemented by those requesting media server resources (for example implemented by those requesting media server resources (for example
an application server). This applies when using both the Consumer an application server). This applies when using both the Consumer
interface as discussed in Section 5.2 and IAMM. It is for this interface as discussed in Section 5.2.1 and IAMM Section 5.2.2.
reason that an MRB is able to act in a client unaware mode when it is Nevertheless, an MRB is conceived to also be able to act in a client
deployed into the network. This allows any SIP compliant client unaware mode when it is deployed into the network. This allows any
entity, as defined by RFC 3261 [RFC3261] and its extensions, to send SIP compliant client entity, as defined by RFC 3261 [RFC3261] and its
requests to an MRB and it will select an appropriate media server extensions, to send requests to an MRB which in turn will select an
based on knowledge of media server resources it currently has appropriate media server based on knowledge of media server resources
available. Mechanisms used to connect to media servers are detailed it currently has available transparently to the client entity.
in the Media Channel Control Mechanisms used to connect to media servers are detailed in the Media
Framework[I-D.ietf-mediactrl-sip-control-framework]. Using an MRB in Channel Control Framework [I-D.ietf-mediactrl-sip-control-framework].
this mode allows for easy migration of current applications and Using an MRB in this mode allows for easy migration of current
services that are unaware of the MRB concept and would simply require applications and services that are unaware of the MRB concept and
a configuration change resulting in the MRB being set as a SIP would simply require a configuration change resulting in the MRB
outbound proxy for clients requiring media services. Any client of being set as a SIP outbound proxy for clients requiring media
media services wishing to take advantage of the advanced techniques services. Any client of media services wishing to take advantage of
detailed in this document when using In-line mode would implement the advanced techniques detailed in this document when using In-line
IAMM which is covered in Section 5.3.2. The techniques used for mode would implement IAMM which is covered in Section 5.3.2. The
selecting an appropriate Media Server by an MRB acting in IUMM is techniques used for selecting an appropriate Media Server by an MRB
outside the scope of this document. acting in IUMM is outside the scope of this document.
5.3.2. In-line Aware MRB Mode 5.3.2. In-line Aware MRB Mode
An In-Line Aware Mode MRB (IAMM) is one that complies to the extended 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 functionality provided in this section. A client entity, such as an
application server, wishing to use advanced MRB functionality can application server, wishing to use advanced MRB functionality can
provide additional contextual information to an MRB. This provide additional contextual information to an MRB. This
information is identical to that used in the Consumer interface in information is identical to that used in the Consumer interface in
Section 5.2 with the only difference being the underlying transport Section 5.2 with the only difference being the underlying transport
mechanism of the contextual information, as specified by the mechanism of the contextual information, as specified by the
'application/mrb-consumer+xml' payload in Section 7. A client of an 'application/mrb-consumer+xml' payload in Section 7. A client of an
IAMM uses SIP signalling to convey the 'application/mrb-consumer+xml' IAMM, as anticipated in Section 5.2.2, uses SIP signalling to convey
payload to the IAMM. The Consumer interface, as specified in the 'application/mrb-consumer+xml' payload to the IAMM, unlike the
Section 5.2 , uses HTTP. A client of an IAMM requiring media Consumer interface presented in Section 5.2.1, which instead uses
services, as well as creating a standard SIP complaint request, MUST HTTP as a transport. A client of an IAMM requiring media services,
use the following steps to ensure that the request is dealt with as well as creating a standard SIP complaint request, MUST use the
appropriately: following steps (also presented in Section 5.2.2) to ensure that the
request is dealt with appropriately:
o The client of the IAMM constructs a SIP INVITE request to connect o The client of the IAMM constructs a SIP INVITE request to connect
to a Media Server as detailed in the Media Channel Control to a Media Server as detailed in the Media Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework] with one Framework [I-D.ietf-mediactrl-sip-control-framework] with one
exception. exception.
o The client of the IAMM includes a MIME content type of multipart/ 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 mixed as defined in RFC 2046 [RFC2046]. As part of this mixed
payload, the client MUST at least include a content-type of type payload, the client MUST at least include a content-type of type
'application/sdp' and a content type of type 'application/ 'application/sdp' and a content type of type 'application/
mrb-consumer+xml'. The part of type application/sdp represents mrb-consumer+xml'. The part of type application/sdp represents
the media server connection details and MUST adhere to the Media the media server connection details and MUST adhere to the Media
Channel Control Channel Control Framework
Framework[I-D.ietf-mediactrl-sip-control-framework]. The part of [I-D.ietf-mediactrl-sip-control-framework]. The part of type
type 'application/mrb-consumer+xml' represents the IAMM contextual 'application/mrb-consumer+xml' represents the IAMM contextual
information and MUST adhere to the schema defined in Section 7. information and MUST adhere to the schema defined in Section 7.
o Once the SIP INVITE request is constructed, it is sent to the o Once the SIP INVITE request is constructed, it is sent to the
recipient as per RFC 3261 [RFC3261]. recipient as per RFC 3261 [RFC3261].
[EDITORS NOTE: Include example of valid IAMM payload.]
On receiving a SIP INVITE request containing the multipart mixed On receiving a SIP INVITE request containing the multipart mixed
payload as specified previously, the IAMM will complete a number of payload as specified previously, the IAMM will complete a number of
steps to fulfil the request. It will: steps to fulfil the request. It will:
o Extract the multipart MIME payload from the SIP INVITE request. o Extract the multipart MIME payload from the SIP INVITE request.
It will then use the contextual information provided by the client It will then use the contextual information provided by the client
in the 'application/mrb-consumer+xml' part to determine which in the 'application/mrb-consumer+xml' part to determine which
media server should be selected to service the request. media server should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it to 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 populate a new SIP INVITE request for connecting the client to the
selected media server, as defined in the Media Channel Control selected media server, as defined in the Media Channel Control
Framework[I-D.ietf-mediactrl-sip-control-framework]. The IAMM Framework [I-D.ietf-mediactrl-sip-control-framework]. The IAMM
acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/ acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then mrb-consumer+xml' information from the SIP INVITE request and then
forwards to the selected Media Server. 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-publish+xml" format. mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish" xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
IETF MediaCtrl MRB 1.0 IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package. This is the schema of the IETF MediaCtrl MRB package.
The schema namespace is urn:ietf:params:xml:ns:mrb-publish The schema namespace is urn:ietf:params:xml:ns:mrb-publish
skipping to change at page 30, line 47 skipping to change at page 47, line 48
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"> schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the XML attributes for This import brings in the XML attributes for
xml:base, xml:lang, etc xml:base, xml:lang, etc
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<xsd:import <xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes" namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd"> schemaLocation="framework.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the framework attributes for This import brings in the framework attributes for
conferenceid and connectionid. conferenceid and connectionid.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!-- <!--
##################################################### #####################################################
Extensible core type Extensible core type
##################################################### #####################################################
--> -->
<xsd:complexType name="Tcore"> <xsd:complexType name="Tcore">
skipping to change at page 33, line 6 skipping to change at page 50, line 18
<xsd:element name="expires" type="xsd:nonNegativeInteger" <xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xsd:element name="frequency" type="xsd:nonNegativeInteger" <xsd:element name="frequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" /> <xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger" <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" /> use="required" />
<xsd:attribute name="action" type="action.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" /> <xsd:element name="subscription" type="subscriptionType" />
<!-- <!--
##################################################### #####################################################
skipping to change at page 34, line 4 skipping to change at page 51, line 15
<!-- <!--
##################################################### #####################################################
mrbnotification TYPE mrbnotification TYPE
##################################################### #####################################################
--> -->
<!-- mrbnotification --> <!-- mrbnotification -->
<xsd:complexType name="mrbnotificationType"> <xsd:complexType name="mrbnotificationType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence <xsd:sequence>
<xsd:element ref="media-server-id" type="subscriptionid.datatype"/> <xsd:element name="media-server-id"
type="subscriptionid.datatype"/>
<xsd:element ref="supported-packages" minOccurs="0" />
<xsd:element ref="active-rtp-sessions" minOccurs="0" /> <xsd:element ref="active-rtp-sessions" minOccurs="0" />
<xsd:element ref="active-mixer-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-rtp-sessions" minOccurs="0" />
<xsd:element ref="non-active-mixer-sessions" minOccurs="0" /> <xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
<xsd:element ref="media-server-status" minOccurs="0" /> <xsd:element ref="media-server-status" minOccurs="0" />
<xsd:element ref="supported-codecs" minOccurs="0" /> <xsd:element ref="supported-codecs" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0" <xsd:element ref="application-data" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
<xsd:element ref="file-formats" minOccurs="0" /> <xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="max-prepared-duration" 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="dtmf-support" minOccurs="0" />
<xsd:element ref="mixing-modes" minOccurs="0" /> <xsd:element ref="mixing-modes" minOccurs="0" />
<xsd:element ref="supported-tones" minOccurs="0" /> <xsd:element ref="supported-tones" minOccurs="0" />
<xsd:element ref="streaming-modes" minOccurs="0" /> <xsd:element ref="streaming-modes" minOccurs="0" />
<xsd:element ref="asr-tts-support" minOccurs="0" /> <xsd:element ref="asr-tts-support" minOccurs="0" />
<xsd:element ref="vxml-support" minOccurs="0" /> <xsd:element ref="vxml-support" minOccurs="0" />
<xsd:element ref="media-server-location" minOccurs="0" /> <xsd:element ref="media-server-location" minOccurs="0" />
<xsd:element ref="label" minOccurs="0" /> <xsd:element ref="label" minOccurs="0" />
<xsd:element ref="media-server-address" minOccurs="0" /> <xsd:element ref="media-server-address" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" /> <xsd:element ref="encryption" minOccurs="0" />
skipping to change at page 34, line 39 skipping to change at page 52, line 4
<xsd:element ref="encryption" minOccurs="0" /> <xsd:element ref="encryption" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="id" type="subscriptionid.datatype" <xsd:attribute name="id" type="subscriptionid.datatype"
use="required" /> use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger" <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" /> use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="mrbnotification" type="mrbnotificationType" /> <xsd:element name="mrbnotification" type="mrbnotificationType" />
<!-- supported-packages -->
<xsd:complexType name="supported-packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="package" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-packages" type="supported-packagesType"/>
<xsd:complexType name="packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="package" type="packageType" />
<!-- active-rtp-sessions --> <!-- active-rtp-sessions -->
<xsd:complexType name="active-rtp-sessionsType"> <xsd:complexType name="active-rtp-sessionsType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0" <xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/> <xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
skipping to change at page 36, line 5 skipping to change at page 54, line 5
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="active-mixer-sessions" <xsd:element name="active-mixer-sessions"
type="active-mixer-sessionsType" /> type="active-mixer-sessionsType" />
<xsd:complexType name="active-mixType"> <xsd:complexType name="active-mixType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0" <xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attributeGroup ref="fw:framework-attributes" /> <xsd:attributeGroup ref="fw:framework-attributes" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
skipping to change at page 37, line 31 skipping to change at page 55, line 31
use="required" /> use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="non-active-mix" type="non-active-mixType" /> <xsd:element name="non-active-mix" type="non-active-mixType" />
<!-- media-server-status --> <!-- media-server-status -->
<xsd:element name="status" type="msstatus.datatype" /> <xsd:element name="media-server-status" type="msstatus.datatype" />
<!-- supported-codecs --> <!-- supported-codecs -->
<xsd:complexType name="supported-codecsType"> <xsd:complexType name="supported-codecsType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="supported-codec" <xsd:element ref="supported-codec"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
skipping to change at page 40, line 34 skipping to change at page 58, line 34
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger" <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" /> use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="max-time" type="max-timeType" /> <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 --> <!-- dtmf-support -->
<xsd:complexType name="dtmf-supportType"> <xsd:complexType name="dtmf-supportType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="detect" /> <xsd:element ref="detect" />
<xsd:element ref="generate" /> <xsd:element ref="generate" />
<xsd:element ref="passthrough" /> <xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
skipping to change at page 43, line 4 skipping to change at page 60, line 16
<xsd:complexType name="dtmf-typeType"> <xsd:complexType name="dtmf-typeType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" /> <xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" /> <xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- mixing-modes --> <!-- mixing-modes -->
<!-- **** TODO **** --> <xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- supported-tones --> <!-- supported-tones -->
<!-- **** TODO **** --> <xsd:complexType name="supported-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="supported-h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-tones" type="supported-tonesType" />
<xsd:complexType name="supported-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-country-codes"
type="supported-country-codesType" />
<xsd:complexType name="country-codeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="supported-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-h248-codes"
type="supported-h248-codesType" />
<xsd:complexType name="h248-codeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- streaming-modes --> <!-- streaming-modes -->
<xsd:complexType name="stream-modesType"> <xsd:complexType name="streaming-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="stream-mode" <xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="stream-modes" type="stream-modesType" /> <xsd:element name="streaming-modes" type="streaming-modesType" />
<xsd:complexType name="stream-modeType"> <xsd:complexType name="stream-modeType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="streammode.datatype" <xsd:attribute name="name" type="streammode.datatype"
use="required" /> use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="stream-mode" type="stream-modeType" /> <xsd:element name="stream-mode" type="stream-modeType" />
<!-- asr-tts-support --> <!-- asr-tts-support -->
<!-- **** TODO **** --> <xsd:complexType name="asr-tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- media-server-location -->
<xsd:complexType name="media-server-locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="civicAddress" type="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-location"
type="media-server-locationType" />
<!-- vxml-support --> <!-- vxml-support -->
<xsd:complexType name="vxml-supportType"> <xsd:complexType name="vxml-supportType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="vxml-mode" <xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype" <xsd:attribute name="support" type="boolean.datatype"
default="false" use="required" /> default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" /> <xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType"> <xsd:complexType name="vxml-modeType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
skipping to change at page 44, line 46 skipping to change at page 67, line 19
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="support" type="vxml.datatype" use="required" /> <xsd:attribute name="support" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" /> <xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- media-server-location -->
<!-- **** TODO **** -->
<!-- label --> <!-- label -->
<xsd:element name="label" type="label.datatype" /> <xsd:element name="label" type="label.datatype" />
<!-- media-server-address --> <!-- media-server-address -->
<xsd:element name="ms-address" type="xsd:anyURI" /> <xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- encryption --> <!-- encryption -->
<!-- **** TODO **** --> <xsd:complexType name="encryptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="encryption-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="encryption" type="encryptionType" />
<xsd:complexType name="encryption-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="encryption-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="encryption-codec" type="encryption-codecType" />
<xsd:complexType name="encryption-codec-package">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption-codec-package"
type="supported-codec-packageType" />
<!-- <!--
#################################################### ####################################################
DATATYPES DATATYPES
#################################################### ####################################################
--> -->
<xsd:simpleType name="version.datatype"> <xsd:simpleType name="version.datatype">
skipping to change at page 45, line 46 skipping to change at page 69, line 18
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="msstatus.datatype"> <xsd:simpleType name="msstatus.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="active" /> <xsd:enumeration value="active" />
<xsd:enumeration value="deactivated" /> <xsd:enumeration value="deactivated" />
<xsd:enumeration value="unavailable" /> <xsd:enumeration value="unavailable" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="create" />
<xsd:enumeration value="update" />
<xsd:enumeration value="remove" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="actions.datatype"> <xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" /> <xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" /> <xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" /> <xsd:enumeration value="passthrough" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="dtmf.datatype"> <xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="INFO" /> <xsd:enumeration value="INFO" />
<xsd:enumeration value="RFC4733" /> <xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" /> <xsd:enumeration value="Media" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<!-- *** TODO-Look at values **** -->
<xsd:simpleType name="streammode.datatype"> <xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN" />
<xsd:enumeration value="RTSP" />
<xsd:enumeration value="HTTP" />
<xsd:enumeration value="NFS" />
</xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="boolean.datatype"> <xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" /> <xsd:enumeration value="true" />
<xsd:enumeration value="false" /> <xsd:enumeration value="false" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="vxml.datatype"> <xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC5552" /> <xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" /> <xsd:enumeration value="IVR-Package" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="label.datatype"> <xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 9 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" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:schema <xsd:annotation>
targetNamespace="urn:ietf:params:xml:ns:mediactrl:mrb" <xsd:documentation>
xmlns:xsd="http://www.w3.org/2001/XMLSchema" IETF MediaCtrl MRB 1.0
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" This is the schema of the IETF MediaCtrl MRB Consumer interface.
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:element name="mrb-message" type="mrb-message-type" />
<xsd:complexType name="mrb-message-type"> The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
<xsd:sequence>
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP LEVEL ELEMENT: mrbconsumer
#####################################################
-->
<xsd:complexType name="mrbconsumerType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice> <xsd:choice>
<xsd:element name="mediaResourceRequest" <xsd:element ref="mediaResourceRequest" />
type="mrb:mediaResourceRequestType"/> <xsd:element ref="mediaResourceResponse" />
<xsd:element name="mediaResourceResponse"
type="mrb:mediaResourceResponseType"/>
<xsd:element name="mediaResourceError"
type="mrb:mediaResourceErrorType"/>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbconsumer" type="mrbconsumerType" />
<!--
#####################################################
mediaResourceRequest TYPE
#####################################################
-->
<!-- mediaResourceRequst -->
<xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="generalInfo" minOccurs="0" />
<xsd:element ref="ivrInfo" minOccurs="0" />
<xsd:element ref="mixerInfo" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceRequest"
type="mediaResourceRequestType" />
<!--
#####################################################
generalInfo TYPE
#####################################################
-->
<!-- generalInfo -->
<xsd:complexType name="generalInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice> </xsd:choice>
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType> </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="mediaResourceRequestType"> <xsd:element name="generalInfo" type="generalInfoType" />
<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="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"> <!-- session-info -->
<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:complexType name="session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="status.datatype"> <xsd:element name="session-info" type="session-infoType" />
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[0-9][0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema> <!-- packages -->
<xsd:complexType name="packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="package" type="xsd:string" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="packages" type="packagesType"/>
<!--
#####################################################
ivrInfo TYPE
#####################################################
-->
<!-- ivrInfo -->
<xsd:complexType name="ivrInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="ivr-sessions" />
<xsd:element ref="file-formats" />
<xsd:element ref="dtmf-type" />
<xsd:element ref="tones" />
<xsd:element ref="asr-tts" />
<xsd:element ref="vxml" />
<xsd:element ref="location" />
<xsd:element ref="encryption" />
<xsd:element ref="application-data" />
<xsd:element ref="max-prepared-duration" />
<xsd:element ref="streaming-modes" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivrInfo" type="ivrInfoType" />
<!--
#####################################################
mixerInfo TYPE
#####################################################
-->
<!-- mixerInfo -->
<xsd:complexType name="mixerInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mixers" />
<xsd:element ref="file-formats" />
<xsd:element ref="dtmf-type" />
<xsd:element ref="tones" />
<xsd:element ref="mixing-modes" />
<xsd:element ref="application-data" />
<xsd:element ref="location" />
<xsd:element ref="encryption" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixerInfo" type="mixerInfoType" />
<!--
#####################################################
mediaResourceResponse TYPE
#####################################################
-->
<!-- mediaResourceResponse -->
<xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="response-session-info" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceResponse"
type="mediaResourceResponseType" />
<!--
####################################################
ELEMENTS
####################################################
-->
<!-- session-info -->
<xsd:complexType name="response-session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="response-session-info"
type="response-session-infoType" />
<!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- file-format -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="required-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-format" type="required-formatType" />
<xsd:complexType name="required-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="required-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-file-package"
type="required-file-packageType" />
<!-- dtmf-type -->
<xsd:complexType name="dtmfType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf" type="dtmfType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- tones -->
<xsd:complexType name="required-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tones" type="required-tonesType" />
<xsd:complexType name="required-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-codes"
type="required-country-codesType" />
<xsd:complexType name="country-codeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="required-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-codes"
type="required-h248-codesType" />
<xsd:complexType name="h248-codeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- asr-tts -->
<xsd:complexType name="asr-ttsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts" type="asr-ttsType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- vxml -->
<xsd:complexType name="vxmlType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml" type="vxmlType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="require" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- location -->
<xsd:complexType name="locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="location" type="locationType" />
<!-- encryption -->
<xsd:element name="encryption" type="boolean.datatype" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- stream-mode -->
<xsd:complexType name="streaming-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="streaming-modes" type="streaming-modesType" />
<xsd:complexType name="stream-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="streammode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream-mode" type="stream-modeType" />
<!-- mixers -->
<xsd:complexType name="mixerssessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixers" type="mixerssessionsType" />
<xsd:complexType name="mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="codec" type="xsd:string" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="users" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mix" type="mixType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType">
<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:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="remove" />
<xsd:enumeration value="update" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="INFO" />
<xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
Figure 10 Figure 10
8. Security Considerations 8. Security Considerations
Security Considerations to be included in later versions of this The MRB network entity has two primary interfaces, Publish and
document. Consumer, that carry sensitive information and must therefore be
appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1,
uses the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect
an MRB to a media server. The appropriate Security Considerations
included in the Media Control Channel Framework specification MUST be
used in conjunction with this specification to protect interactions
between an MRB and a media server.
The Consumer interface, as defined in and described in Section 5.2,
uses either the Hypertext Transfer Protocol (HTTP) or Session
Initiation Protocol (SIP) as the mechanism for clients to connect to
an MRB to request media resources. In the case of the HTTP use, any
binding using the Consumer interface MUST be capable of being
transacted over TLS, as described in RFC 2818 [RFC2818]. In the case
of the SIP use, the appropriate security considerations included in
the Media Control Channel Framework specification MUST be used in
conjunction with this specification to protect interactions between a
client requesting media resources and an MRB.
9. IANA Considerations 9. IANA Considerations
IANA Considerations to be included in later versions of this There are several IANA considerations associated with this
document. specification.
9.1. application/mrb-publish+xml MIME Type
MIME media type name: application
MIME subtype name: mrb-publish+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has
been used to support a Media Resource Broker (MRB) entity.
Additional Information:
Magic Number: None
File Extension: .xdf
Macintosh file type code: "TEXT"
Personal and email address for further information: Chris
Boulton, chris@ns-technologies.com
Intended usage: COMMON
Author/Change controller: The IETF.
Figure 11
9.2. application/mrb-consumer+xml MIME Type
MIME media type name: application
MIME subtype name: mrb-consumer+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has
been used to support a Media Resource Broker (MRB) entity.
Additional Information:
Magic Number: None
File Extension: .xdf
Macintosh file type code: "TEXT"
Personal and email address for further information: Chris
Boulton, chris@ns-technologies.com
Intended usage: COMMON
Author/Change controller: The IETF.
Figure 12
10. Changes 10. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
10.1. Changes from 01 Version 10.1. Changes from 01 Version
o Added description of lease mechanism.
o Added specific HTTP and SIP usage of Consumer interface.
o Completed Publish interface schema + associated text.
o Included Consumer interface schema + associated text.
o Included supported-packages element.
o Removed announce-var element from doc.
o Expanded Abstract.
o General scrub of text - input from Simon Romano.
o Added IANA Considerations section.
o Added Security Considerations section.
10.2. Changes from 00 Version
o Included In-line text based on strawman proposal. o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team o Included first attempt at publish interface based on design team
work. work.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
design team consisted of Gary Munson, Adnan Saleem, Michael Trank, design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan. Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors
would also like to thank John Dally, Simon Romano, and Christian
Groves for input into this specification.
12. References 12. References
12.1. Normative References 12.1. Normative References
[ISO.639.1988]
International Organization for Standardization, "Code for
the representation of names of languages, 1st edition",
ISO Standard 639, 1988.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. 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.
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., [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, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
"Introduction and Applicability Statements for Internet- UPDATE Method", RFC 3311, October 2002.
Standard Management Framework", RFC 3410, December 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[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]
Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H. Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-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]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Mendelsohn, N., Moreau, J., Hadley, M., Nielsen, H., and
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mediactrl-architecture] [I-D.ietf-mediactrl-call-flows]
Melanchuk, T., "An Architectural Framework for Media Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
Server Control", draft-ietf-mediactrl-architecture-04 "Media Control Channel Framework (CFW) Call Flow
(work in progress), November 2008. Examples", draft-ietf-mediactrl-call-flows-02 (work in
progress), October 2009.
[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] [I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-10 (work in draft-ietf-mediactrl-sip-control-framework-11 (work in
progress), February 2009. progress), October 2009.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Lorenzo Miniero Lorenzo Miniero
University of Napoli University of Napoli
 End of changes. 147 change blocks. 
457 lines changed or deleted 2567 lines changed or added

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