One document matched: draft-ietf-mediactrl-mrb-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" docName="draft-ietf-mediactrl-mrb-07" ipr="trust200902">
<front>
<title abbrev="Media Resource Brokering">Media Resource
Brokering</title>
<author fullname="Chris Boulton" initials="C." surname="Boulton">
<organization>NS-Technologies</organization>
<address>
<email>chris@ns-technologies.com</email>
</address>
</author>
<author initials="L." surname="Miniero" fullname="Lorenzo Miniero">
<organization>Meetecho</organization>
<address>
<postal>
<street>Via Carlo Poerio 89</street>
<code>80100</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>lorenzo@meetecho.com</email>
</address>
</author>
<date year="2010"/>
<workgroup/>
<abstract>
<t>The MediaCtrl work group in the IETF has proposed an architecture
for controlling media services. The Session Initiation Protocol (SIP) is used as
the signalling protocol which provides many inherent capabilities for
message routing. In addition to such signalling properties, a need
exists for intelligent, application level media service selection based
on non-static signalling properties. This is especially true when considered in
conjunction with deployment architectures that include 1:M and M:N combinations
of Application Servers and Media Servers. This document introduces a Media
Resource Broker (MRB) entity which manages the availability of Media Servers and the
media resource demands of Application Servers. The document includes potential deployment
options for an MRB and appropriate interfaces to Application Servers and Media Servers.
</t>
</abstract>
<!-- Abstract -->
</front>
<middle>
<section anchor="sec:Introduction" title="Introduction">
<t>The topic of Media Resource management has been in discussion for a number of years with
varying proprietary solutions being used today. It is clear that, as we move towards
a consistent architecture and protocol for Media Server Control, a standard mechanism
is required for accurate media resource selection.</t>
<t>As IP based multimedia infrastructures mature, the complexity and demands from
deployments increase. Such complexity will result in a wide variety of capabilities
from a range of vendors that should all be interoperable using the architecture
and protocols produced by the MediaCtrl work group. It should be possible
for a controlling entity to be assisted in Media Server selection so that
the most appropriate resource is selected for a particular operation. The
importance increases when you introduce a flexible level of deployment scenarios,
as specified in the <xref target="RFC5167">RFC 5167</xref> and <xref target="RFC5567">RFC 5567</xref> documents.
These documents make statements like
"it should be possible to have a many-to-many relationship between Application
Servers and Media Servers that use this protocol". This leads to the following
deployment architectures being possible when considering media resources.
</t>
<t>The simplest deployment view is illustrated in <xref target="fig:arch1"/>.
</t>
<figure anchor="fig:arch1" title="Basic Architecture">
<artwork><![CDATA[
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-------MS Control------>| Server |
+-------------+ +-------------+
]]></artwork>
</figure>
<t>This simply involves a single Application Server and Media Server. Expanding
on this view, it is also possible for an Application Server to control
multiple (greater that 1) Media Server instances at any one time. This deployment view is illustrated in
<xref target="fig:arch2"/>. Typically, such architectures are associated with
application logic that requires high demand media services. It is more than possible
that each media server possesses a different media capability set. Media servers
may offer different media services as specified in the Mediactrl architecture document.
A Media server may have similar media functionality but may have different capacity
or media codec support.</t>
<figure anchor="fig:arch2" title="Multiple Media Servers">
<artwork><![CDATA[
+---+-----+---+
| Media |
+----->| Server |
| +-------------+
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+
|
| +---+-----+---+
+----->| Media |
| Server |
+-------------+
]]></artwork>
</figure>
<t><xref target="fig:arch3"/> conveys the opposite view to that in <xref target="fig:arch2"/>.
In this model there are a number of (greater than 1) application servers, possibly supporting
dissimilar applications, controlling a single media server. Typically, such architectures are
associated with application logic that requires low demand media services.
</t>
<figure anchor="fig:arch3" title="Multiple Application Servers">
<artwork><![CDATA[
+---+-----+---+
| Application |
| Server |<-----+
+-------------+ |
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+
|
+---+-----+---+ |
| Application | |
| Server |<-----+
+-------------+
]]></artwork>
</figure>
<t>The final deployment view is the most complex. In this model (M:N) there
exists any number of Application Servers and any number of Media Servers. It is
again possible in this model that media servers might not be homogenous and have
different capability sets and capacity.</t>
<figure anchor="fig:arch4" title="Basic Architecture">
<artwork><![CDATA[
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-----+ +---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media |
| Server |<-----+ | Server |
+-------------+ +---+-----+---+
]]></artwork>
</figure>
<t>This document will take a look at the specific problem areas related
to such deployment architectures. It is recognised that the solutions
proposed in this document should be equally adaptable to all of the
previously described deployment models. It is also recognised that
the solution is far more relevant to some of the previously discussed
deployment models and can almost be viewed as redundant
on others.</t>
</section>
<!-- Introduction -->
<section anchor="Terminology" title="Conventions and Terminology">
<t>In this document, <xref target="RFC2119">BCP 14/RFC 2119</xref>
defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL".</t>
<t>This document inherits terminology proposed in
<xref target="RFC5567">RFC 5567</xref> and
<xref target="I-D.ietf-mediactrl-sip-control-framework">Media Control Channel Framework</xref> documents.
In addition, the following terms are defined for use in this document and for
use in the context of the MediaCtrl Work group in the IETF:
<list style="hanging">
<t hangText="Media Resource Broker (MRB): ">A logical entity that is responsible for
both collection of appropriate published Media Server (MS)
information and selecting appropriate MS resources on behalf of
consuming entities.</t>
<t hangText="Query MRB: ">An instantiation of an MRB (See previous definition) that provides
an interface for an Application Server to retrieve the address of an appropriate Media Server. The result
returned to the Application Server can be influenced by information contained in the query
request.</t>
<t hangText="In-line MRB: ">An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. There is no
separate query.</t>
</list>
Within the context of In-line MRBs, additional terms are defined:
<list style="hanging">
<t hangText="In-line Aware MRB Mode (IAMM): ">Defined in <xref target="sec:IAMM"/>.</t>
<t hangText="In-line Unaware MRB Mode (IUMM): ">Defined in <xref target="sec:IUMM"/>.</t>
</list>
The document will often specify when a specific identifier in a protocol message
needs to be unique. Unless differently stated, such uniqueness will always need to
be intended within the scope of the Media Servers controlled by the same Media
Resource Broker. The interaction among different Media Resource Brokers, as the
partitioning of a logical Media Resource Broker, is out of scope to this document.
</t>
</section>
<!-- Terminology -->
<section anchor="sec:Problem" title="Problem Discussion">
<t>As anticipated in <xref target="sec:Introduction"/>, the main aim of the MediaCtrl group
is to produce a solution that must service a wide variety of deployment architectures.
These range from the simplest 1:1 relationship between Media Servers and Application
Servers to potentially linearly scaling 1:M, M:1 and M:N deployments.</t>
<t>This still does not seem like a major issue for the proposed solution until
you add a number of additional factors into the equation that increase
complexity. As Media Servers evolve it must be taken into consideration that,
where many can exist in a deployment, they may not have been produced by the same
vendor and may not have the same capability set. It should be possible for an
Application Server that exists in a deployment to select a Media Service based
on a common, appropriate capability set. In conjunction with capabilities, it is
also important to take available resources into consideration. The ability
to select an appropriate Media Service function is an extremely useful
feature but becomes even more powerful when considered with
available resources for servicing a request.</t>
<t>In conclusion, the intention is to create a tool set that allows MediaCtrl
deployments to effectively utilize the available media resources. It should
be noted that in the simplest deployments where only a single media server exists,
an MRB function is probably not required. Only a single capability set exists
and resource unavailability can be handled using the appropriate underlying
signalling, e.g., SIP response. This document does not prohibit such uses of
an MRB, it simply provides the tools for various entities to interact
where appropriate. It is also worth noting that the tools provided
in this document aim to provide a 'best effort' view of media resources
at the time of request for initial Media Server routing decisions. Any
dramatic change in media capabilities after a request has taken place
should be handled by the underlying protocol.</t>
<t>Please note that there may be additional information that it is
desirable for the MRB to have for purposes of selecting an MS resource, such as
resource allocation rules across different applications, planned or unplanned
downtime of Media Server resources, the planned addition of future Media Server
resources, or MS resource capacity models. How the MRB acquires such information
is outside the scope of this document. The techniques used for selecting an
appropriate Media Resource by an MRB is outside the scope of this document.</t>
</section>
<!-- Problem -->
<section anchor="sec:Deployment" title="Deployment Scenario Options ">
<t>On researching Media Resource Brokering it became clear that a couple of high level
models exist. The general principles of "in-line" and "query"
MRB concepts are discussed in the rest of this section.
</t>
<section anchor="sec:Query" title="Query MRB">
<t>The "Query" model for MRB interactions provides the ability for
a client of media services (for example an Application Server) to
"ask" an MRB for an appropriate Media Server, as illustrated
in <xref target="fig:arch5"/>.
</t>
<figure anchor="fig:arch5" title="Query MRB">
<artwork><![CDATA[
+---+-----+---+
+------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | |
| | | |
|(2) +---+--+--+---+ | |
| | Media | | |
| +---->| Server | | |
| | +-------------+ | |
| | (1)| |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ |
| |
| +---+-----+---+ (1)|
+---->| Media | |
| Server |--->---+
+---+-----+---+
]]></artwork>
</figure>
<t>In this deployment, the Media Servers use the "Media Server Resource
Publish Interface", as discussed in <xref target="sec:MS_Pub"/>, to
convey capability sets as well as resource information. This is depicted
by (1) in <xref target="fig:arch5"/>. It is then the MRB's responsibility to
accumulate all appropriate information relating to media services in the
logical deployment cluster. The Application Server (or other media
services client) is then able to query the MRB for an appropriate resource (as
identified by (2) in <xref target="fig:arch5"/>). Such a query would carry
specific information related to the Media Service required and enable the MRB
to provide an increased accuracy in its response. This particular interface
is discussed in "Media Resource Consumer Interface" in
<xref target="sec:Res_Cons"/>. The Application Server is then able
to direct control commands (for example create conference) and Media Dialogs
to the appropriate Media Server, as shown by (3) in <xref target="fig:arch5"/>.
Additionally, with Query MRB, the MRB is not in the signaling path
between the AS and the selected MS resource.</t>
<section anchor="sec:Query_hybrid" title="Hybrid Query MRB">
<t>As mentioned previously, it is the intention that a tool kit is provided
for MRB functionality within a MediaCtrl architecture. It is expected that in
specific deployment scenarios the role of the MRB might be co-hosted as a hybrid
logical entity with an Application Server, as shown in <xref target="fig:arch6"/>.
</t>
<figure anchor="fig:arch6" title="Hybrid Query MRB - AS Hosted">
<artwork><![CDATA[
+------------<----------------<---------+----<-----+---+
| (1) | | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
V +---->| Server | | |
+------+------+ | +-------------+ | |
| MRB | | | |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ |
| |
| +---+-----+---+ |
+---->| Media | |
| Server |--->---+
+---+-----+---+
]]></artwork>
</figure>
<t>This diagram is identical to that in <xref target="fig:arch5"/> with the exception
that the MRB is now hosted on the Application Server. The "Media Server
Publish Interface" is still being used to accumulate resource information
at the MRB but as it is co-hosted on the Application Server, the "Media
Server Consumer Interface" has collapsed. It might still exist within the
Application Server/MRB interaction but this is an implementation issue. This
type of deployment suits a single Application Server environment but it should be noted
that a "Media Server Consumer Interface" could then be offered from the
hybrid if required.
</t>
<t>In a similar manner, the Media Server could also act as a hybrid for the deployment
cluster, as illustrated in <xref target="fig:arch7"/>.
</t>
<figure anchor="fig:arch7" title="Hybrid Query MRB - MS Hosted">
<artwork><![CDATA[
(1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+
| | |
| | +---+--+--+---+ |
| +---<---| Application | |
| | Server |<--+-MS Control-+--+
| +-------------+ |
| |
| +---+--+--+---+ |
+---<-------| Application | |
| Server |<--+-MS Control-+--+
+-------------+
]]></artwork>
</figure>
<t>This time the MRB has collapsed and is co-hosted by the Media Server. The
"Media Server Consumer Interface" is still available to the Application
Servers (1) to query Media Server resources. This time the "Media
Server Publish Interface" has collapsed onto the Media Server. It might
still exist within the Media Server/MRB interaction but this is an implementation
issue. This type of deployment suits a single Media Server environment but
it should be noted that a "Media Server Publish Interface" could then
be offered from the hybrid if required. A typical use case scenario for such a
topology would be a single MS representing a pool of MSs in a cluster. In that case,
the MRB would actually be handling a cluster of MSs, rather than one.
</t>
</section>
<!-- Hybrid Query MRB -->
</section>
<!-- Query MRB -->
<section anchor="sec:Inline" title="In-Line MRB">
<t>The "In-line" MRB is architecturally different from the "Query" model
that was discussed in the previous section. The concept of a separate
query disappears. The client of the MRB simply uses the media resource
control and media dialog signalling to involve the MRB. This type of deployment is illustrated
in <xref target="fig:arch8"/>.</t>
<figure anchor="fig:arch8" title="In-line MRB">
<artwork><![CDATA[
+-------<----------+----<-------+---+
| | (1) | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
| +------>| Server | | |
| |(3) +-------------+ | |
| | (1)| |
+---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ |
| |
| (3) +---+-----+---+ (1)|
+------>| Media | |
| Server |--->---+
+---+-----+---+
]]></artwork>
</figure>
<t>The Media Servers still use the 'Media Server Publish Interface' to convey
capabilities and resources to the MRB - as illustrated by (1). The media server
Control (and Media dialogs as well, if required) is sent to the MRB (2) which then selects an
appropriate Media Server (3) and would stay in the signaling path between the AS
and the MS resource for the handled dialogs.</t>
<t>In-line MRB can be split into two distinct logical roles which can be applied on a per
request basis. They are:
<list style="hanging">
<t hangText="In-line Unaware MRB Mode (IUMM):">Allows an MRB to act on behalf of clients requiring
media services who are not aware of an MRB or its operation. In this case the AS does not
provide explicit information on the kind of MS resource it needs
(as in <xref target="sec:Res_Cons"/>) and the
MRB is left to deduce it by potentially inspecting other information in the request from
the AS; for example, SDP content, or address of the requesting AS, or additional Request-URI
parameters as per <xref target="RFC4240">RFC 4240</xref>.</t>
<t hangText="In-line Aware MRB Mode (IAMM):">Allows an MRB to act on behalf of clients requiring
media services who are aware of an MRB and its operation. In particular it allows the AS
to explicitly the convey the same kinds of MS characteristics desired as does the Query MRB
mode (as in <xref target="sec:Res_Cons"/>).
</t>
</list>
In either role, the MRB would deduce that the selected MS resources are no longer needed when the AS
terminates the corresponding dialog. The two modes are discussed in more detail
in <xref target="sec:In_Line"/>.</t>
</section>
<!-- In-Line -->
</section>
<!-- Deployment -->
<section anchor="sec:Interfaces" title="MRB Interface Definitions">
<t>As discussed in previous sections in this document, the intention is to
provide a toolkit for a variety of deployment architectures where media resource
brokering can take place. As a result, two main interfaces are required to
support the differing requirements. The two interfaces are described in the
remainder of this section and have been named the 'Media Server Resource
Publish' and 'Media Server Resource Consumer' interfaces. These two
interfaces have extremely differing responsibilities and usages which is
reflected in the choice of solutions.
</t>
<t>It is beyond the scope of this document to define exactly how to
construct an MRB. This includes interpreting the data for the Media Service
Consumer interface supplied by the Media Server Publish interface. It
is, however, important that the two interfaces are complimentary so that
development of appropriate MRB functionality is supported.</t>
<section anchor="sec:MS_Pub" title="Media Server Resource Publish Interface">
<t>The Media Server Resource Publish interface is responsible for
providing an MRB with appropriate Media Server resource information.
As such, this interface is assumed to provide both general
and specific details related to Media Server resources. This
information needs to be conveyed using an industry standard mechanism
to provide increased levels of adoption and interoperability. A
Control Package for the Media Control Channel Framework will be specified to fulfil this interface
requirement. It provides an establishment and monitoring
mechanism to enable a Media Server to report appropriate statistics
to an MRB. The Publish interface is used with both Query and In-line modes of
MRB operation.
</t>
<t>As already anticipated in the introduction, the MRB view
of MS resource availability will in practice be approximate - i.e.,
partial and imperfect. The MRB Publish interface does not provide an exhaustive
view of current MS resource consumption, the MS may in some cases
provide a best-effort computed view of resource consumption
parameters conveyed in the Publish interface (e.g., DSP's with a
fixed number of streams versus GPU's with CPU availability), there may be
licensing constraints not factored in (e.g., even if lots of CPU and memory
are available, licensing or other configuration elements may restrict
the number of stream types), and MS resource information may only be
reported periodically over the Publish interface to MRB. Nevertheless,
despite such limitations it is assumed that the provided information
is enough to allow MRB implementors to realize its functionality.</t>
<t>It is also worth noting that, while the scope of the MRB is definitely on providing interested Application Servers with
the available resources, the MRB also allows for the retrieval of information about the currently
occupied resources. While this is of course a relevant piece of information (e.g., for monitoring
purposes), such a functionality inevitably raises security considerations, and implementations
should take this into account. See <xref target="sec:security"/> for more details.</t>
<t>The MRB Publish interface uses the Media Control Channel
Framework (<xref target="I-D.ietf-mediactrl-sip-control-framework"/>) as the basis for interaction
between a Media Server and an MRB. The Media Control Channel Framework uses an extension mechanism
to allow specific usages which are known as control packages. <xref target="sec:Control_Package_Definition"/>
defines the control package that MUST be implemented by any Media Server wanting to interact
with an MRB entity.</t>
<t>Please note that it is out of scope how an MRB knows what MSs should be queried
for publishing information.</t>
<section anchor="sec:Control_Package_Definition" title="Control Package Definition">
<t>This section fulfills the mandatory requirement for information that
must be specified during the definition of a Control Framework Package,
as detailed in Section 8 of <xref target="I-D.ietf-mediactrl-sip-control-framework"/>.</t>
<section anchor="sec:Control_Package_Name" title="Control Package Name">
<t>The Media Channel Control Framework requires a Control Package definition to
specify and register a unique name and version.</t>
<t>The name and version of this Control Package is "mrb-publish/1.0". </t>
</section>
<!-- Control Package Name -->
<section anchor="sec:Message_Usage" title="Framework Message Usage">
<t>The MRB publish interface allows a media server to convey available capabilities
and resources to an MRB entity.</t>
<t>This package defines XML elements in <xref target="definitions"/> and provides an XML
Schema in <xref target="sec:publisher_xml"/>. </t>
<t>The XML elements in this package are split into requests, responses
and event notifications.
Requests are carried in CONTROL message bodies; <mrbrequest> element is defined as a package request.
This request can be used for creating new subscriptions and updating/removing existing subscriptions.
Event notifications are also carried in CONTROL message bodies; the
<mrbnotification> element is defined for package event notifications.
Responses are carried either in REPORT message or Control Framework
200 response bodies; the <mrbresponse> element is defined as a
package level response.
</t>
<t>Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>) are
used when the request or event notification is
invalid; for example, a request has invalid XML (400), or is not
understood (500). Package level responses are carried in framework 200 response or
REPORT message bodies. This package's response codes are defined
in <xref target="sec:responses"/>. </t>
</section>
<!--Framework Message Usage -->
<section anchor="sec:Common_XML" title="Common XML Support">
<t>The Media Control Channel Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>
requires a Control Package definition to
specify if the attributes for media dialog or conference references are required.</t>
<t>The Publish interface defined in <xref target="sec:publisher_xml"/> does import and make use of the
common XML schema defined in the Media Control Channel Framework.</t>
<t>The Consumer interface defined in <xref target="sec:consumer_xml"/> does import and make use of the
common XML schema defined in the Media Control Channel Framework.</t>
</section>
<!-- Common XML Support -->
<section anchor="sec:Control_Body" title="CONTROL Message Body">
<t>A valid CONTROL body message MUST conform to the schema defined in <xref target="sec:publisher_xml"/> and described in
<xref target="definitions"/>. XML messages appearing in CONTROL messages
MUST contain either a <mrbrequest> or <mrbnotification> element. </t>
</section>
<!-- CONTROL Message Body -->
<section anchor="sec:REPORT_Body" title="REPORT Message Body">
<t>A valid REPORT body MUST conform to the schema defined in <xref target="sec:publisher_xml"/>
and described in <xref target="definitions"/>. XML
messages appearing in REPORT messages MUST contain a <mrbresponse> element.
</t>
</section>
<!-- REPORT Message Body -->
<section anchor="sec:Audit" title="Audit">
<t>The 'mrb-publish/1.0' Media Control Channel Framework package does not require any
additional auditing capability.</t>
</section>
<!-- Audit -->
</section>
<!-- Package Definition -->
<section anchor="definitions" title="Element Definitions">
<t>This section defines the XML elements for the Publish interface Media Control Channel package
defined in <xref target="sec:MS_Pub"/>. The formal XML schema definition for the Publish
interface can be found in <xref target="sec:publisher_xml"/>.</t>
<t>The root element is <mrbpublish>. All other XML elements (requests, responses, notifications) are
contained within it. The MRB Publish interface request element is detailed in <xref target="sec:requests"/>.
The MRB Publish interface notification element is detailed in <xref target="sec:notifications"/>.
MRB Publish interface response element is contained in <xref target="sec:responses"/>.</t>
<t>The <mrbpublish> element has the following attributes:
<list style="hanging">
<t hangText="version:">a token specifying the mrb-publish package version. The value
is fixed as '1.0' for this version of the package. The attribute MUST be present.</t>
</list>
</t>
<t>The <mrbpublish> element has the following child element, only one of which is allowed
to occur in a request.
<list style="hanging">
<t><mrbrequest> for sending an MRB request. See <xref target="sec:requests"/>.</t>
<t><mrbresponse> for sending an MRB response. See <xref target="sec:responses"/>.</t>
<t><mrbnotification> for sending an MRB notification. See <xref target="sec:notifications"/>.</t>
</list>
</t>
</section>
<!-- Element Definitions -->
<section anchor="sec:requests" title="<mrbrequest>">
<t>This section defines the <mrbrequest> element used to initiate requests from an
MRB to a Media Server. The element is a container for information relevant for the interrogation
of a media server.</t>
<t>The <mrbrequest> element has no defined attributes.</t>
<t>The <mrbrequest> element has the following sub-elements which are defined in the
remainder of this section:
<list style="hanging">
<t><subscription> for initiating a subscription to a Media Server from an MRB. See <xref target="sec:subscription"/>.</t>
</list>
</t>
<section anchor="sec:subscription" title="<subscription>">
<t>The <subscription> element is included in a request from an MRB to a Media Server to provide the
details relating to the configuration of updates. This element can be used either to request a new subscription
or to update an existing one (e.g., to change the frequency of the updates), and to remove ongoing subscriptions as
well (e.g., to stop an indefinite update). The MRB will inform the Media Server how long
it wishes to receive updates for and the frequency that updates should be sent. Updates related
to the subscription are sent using the <mrbnotification> element.</t>
<t>The <subscription> element has the following attributes:
<list style="hanging">
<t hangText="id:"> indicates a unique token representing the subscription session between the MRB
and the Media Server. The attribute MUST be present.</t>
<t hangText="seqnumber:"> indicates a sequence number to be used in conjunction
with the subscrition session id to identify a specific subscription command.
The first subscription
MUST have 1 as 'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value.
The attribute MUST be present.</t>
<t hangText="action:"> provides the operation that should be carried out on the subscription:
<list style="symbols">
<t>The value of 'create' instructs the MS to attempt to setup a new subscription.</t>
<t>The value of 'update' instructs the MS to attempt to update an existing subscription.</t>
<t>The value of 'remove' instructs the MS to attempt to remove an existing subscription
and consequently stop any ongoing related notification.</t>
</list>
The attribute MUST be present.</t>
</list>
</t>
<t>The <subscription> element has the following child elements:
<list style="hanging">
<t hangText="expires: ">Provides the amount of time in seconds that a subscription should be installed for notifications
at the Media Server. Once the amount of time has passed, the subscription expires and the MRB has to subscribe
again in case it is still interested in receiving notifications from the MS. The element MAY be present.</t>
<t hangText="frequency: ">Provides the frequency in seconds that the MRB wishes to receive notifications
from the MS. The element MAY be present.</t>
</list>
</t>
<t>
Please note that these two optional pieces of
information provided by the MRB only act as a suggestion: the MS MAY change the proposed values if it considers
the suggestions unacceptable (e.g., if the MRB has requested a too high notification frequency). In such case,
the request would not fail, but the updated, acceptable values would be reported in the <mrbresponse> accordingly.
</t>
</section>
<!--subscription -->
</section>
<!-- mrbrequest -->
<section anchor="sec:notifications" title="<mrbnotification>">
<t>The <mrbnotification> element is included in a request from a Media Server to an MRB to provide the
details relating current status. The Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent
using the <mrbnotification> element contained in an <mrbrequest> element.</t>
<t>The <mrbnotification> element has the following attributes:
<list style="hanging">
<t hangText="id:"> indicates a unique token representing the session between the MRB
and the Media Server and is the same as the one appearing in the <subscription> element.
The attribute MUST be present.</t>
<t hangText="seqnumber:"> indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific notification update.
The first notification
MUST have 1 as 'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value.
The attribute MUST be present.</t>
</list>
</t>
<t>The following subsections provide details on the child elements that are contained within an
<mrbnotification> element.</t>
<section anchor="sec:media-server-id" title="<media-server-id>">
<t>The <media-server-id> element provides a unique system wide identifier for a Media Server
instance. The element MUST be present.</t>
</section>
<!--media-server-id -->
<section anchor="sec:supported-pacakges" title="<supported-packages>">
<t>The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element MAY be present.</t>
<t>The <supported-packages> element has no attributes.</t>
<t>The <supported-packages> element has the following child element:
<list style="hanging">
<t hangText="package: "> The <package> element represents the name of a package
supported by the media server. The <package> element has a single attribute,
'name', which represents the name of the supported Media Control Channel Framework
package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0").</t>
</list>
</t>
</section>
<!--supported-packages -->
<section anchor="sec:active-rtp-sessions" title="<active-rtp-sessions>">
<t>The <active-rtp-sessions> element provides information detailing the current active
Real-time Transport Protocol(RTP) sessions. The element MAY be present.</t>
<t>The <active-rtp-sessions> element has no attributes.</t>
<t>The <active-rtp-sessions> element has the following child element:
<list style="hanging">
<t hangText="rtp-codec: "> Is a container which represents a supported codec and the associated active sessions.
The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec
being represented. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <rtp-codec> element has two child elements. The child element,
<decoding>, represents the number of RTP sessions for the specified codec being decoded. The
child element, <encoding>, represents the number of RTP sessions for the specified codec being
encoded.</t>
</list>
</t>
</section>
<!--active-rtp-sessions -->
<section anchor="sec:active-mixer-sessions" title="<active-mixer-sessions>">
<t>The <active-mixer-sessions> element provides information detailing the current active
mixed RTP sessions. The element MAY be present.</t>
<t>The <active-mixer-sessions> element has no attributes.</t>
<t>The <active-mixer-sessions> element has the following child element:
<list style="hanging">
<t hangText="active-mix: "> Is a container which represents a mixed active RTP session.
The <active-mix> element has one attribute. The attribute 'conferenceid' represents the name of the mix
being represented. The <active-mix> element has one child element. The child element,
<rtp-codec>, contains the same information relating to RTP sessions as defined in
<xref target="sec:active-rtp-sessions"/>. The element MAY be present.</t>
</list>
</t>
</section>
<!--active-mixer-sessions -->
<section anchor="sec:non-active-rtp-sessions" title="<non-active-rtp-sessions>">
<t>The <non-active-rtp-sessions> element provides information detailing the currently available inactive
RTP sessions. The element MAY be present.</t>
<t>The <non-active-rtp-sessions> element has no attributes.</t>
<t>The <non-active-rtp-sessions> element has the following child element:
<list style="hanging">
<t hangText="rtp-codec: "> Is a container which represents a supported codec and the inactive sessions.
The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec
being represented. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <rtp-codec> element has two child elements. The first child element,
<decoding>, represents the number of available incoming (decoding) RTP session for the specified codec. The second
child element, <encoding>, represents the number of available outgoing (encoding) RTP sessions
for the specified codec. The element MAY be present.</t>
</list>
</t>
</section>
<!--non-active-rtp-sessions -->
<section anchor="sec:non-active-mixer-sessions" title="<non-active-mixer-sessions>">
<t>The <non-active-mixer-sessions> element provides information detailing the current inactive
mixed RTP sessions. The element MAY be present.</t>
<t>The <non-active-rtp-sessions> element has no attributes.</t>
<t>The <non-active-mixer-sessions> element has the following child element:
<list style="hanging">
<t hangText="non-active-mix: "> Is a container which representing an available mixed RTP session.
The <non-active-mix> element has one attribute. The attribute 'available' represents the number
of mixes that could be used using that profile. The <non-active-mix> element has one child element.
The child element, <rtp-codec>, contains the same information relating to RTP sessions as defined in
<xref target="sec:non-active-rtp-sessions"/>. The element MAY be present.</t>
</list>
</t>
</section>
<!--non-active-mixer-sessions -->
<section anchor="sec:media-server-status" title="<media-server-status>">
<t>The <media-server-status> element provides information detailing the current status of the media
server. The element MUST be present. It can return one of the following values:
<list style="hanging">
<t hangText="active: "> Indicating that the Media Server is available for service.</t>
<t hangText="deactivated: "> Indicating that the Media Server has been withdrawn from service,
and as such should not be contacted before it becomes 'active' again.</t>
<t hangText="unavailable: "> Indicating that the Media Server continues to process past requests but
cannot accept new requests, and as such should not be contacted before it becomes 'active' again.</t>
</list>
</t>
<t>The <media-server-status> element has no attributes.</t>
<t>The <media-server-status> element has no child elements.</t>
</section>
<!--media-server-status -->
<section anchor="sec:supported-codecs" title="<supported-codecs>">
<t>The <supported-codecs> element provides information detailing the current codecs
supported by a media server and associated actions. The element MAY be present.</t>
<t>The <supported-codecs> element has no attributes.</t>
<t>The <supported-codecs> element has the following child element:
<list style="hanging">
<t hangText="supported-codec: "> has a single attribute, 'name', which provides the
name of the codec providing information. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <supported-codec> element then has
a further child element, <supported-codec-package>. The <supported-codec-package>
element has a single attribute, 'name', which provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the codec support applies. The <supported-codec-package>
element has one further child element, <supported-actions>, which provide the actions
that a Media Server can apply to this codec:
<list style="symbols">
<t>'decode', meaning a decoder for this codec is available;</t>
<t>'encode', meaning an encoder for this codec is available;</t>
<t>'passthrough', meaning the MS is able to pass a stream encoded using that codec through without re-encoding.</t>
</list></t>
</list>
</t>
</section>
<!--supported-codecs -->
<section anchor="sec:application-data" title="<application-data>">
<t>The <application-data> element provides arbitrary application level data. This data is
meant to only have meaning at the application level logic and as such is arbitrary. The element MAY be present.</t>
<t>The <application-data> element has no attributes.</t>
<t>The <application-data> element has no child elements.</t>
</section>
<!--application-data -->
<section anchor="sec:file-formats" title="<file-formats>">
<t>The <file-formats> element provides a list of file formats supported for the
purpose of playing media. The element MAY be present.</t>
<t>The <file-formats> element has no attributes.</t>
<t>The <file-formats> element has the following child element:
<list style="hanging">
<t hangText="supported-format: "> has a single attribute, 'name', which provides the
type of file format that is supported. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <supported-format> element then has
a further child element, <supported-file-package>. The <supported-file-package>
element provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.</t>
</list>
</t>
</section>
<!--file-formats -->
<section anchor="sec:max-prepared-duration" title="<max-prepared-duration>">
<t>The <max-prepared-duration> element provides the amount of time a media dialog
can be prepared in the system before it is executed. The element MAY be present.</t>
<t>The <max-prepared-duration> element has no attributes.</t>
<t>The <max-prepared-duration> element has the following child element:
<list style="hanging">
<t hangText="max-time: "> has a single attribute, 'max-time-seconds', which provides the
amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has
a further child element, <max-time-package>. The <max-time-package>
element provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.</t>
</list>
</t>
</section>
<!--max-prepared-duration -->
<section anchor="sec:dtmf-support" title="<dtmf-support>">
<t>The <dtmf-support> element supplies the supported methods to detect DTMF tones and to generate them.
The element MAY be present.</t>
<t>The <dtmf-support> element has no attributes.</t>
<t>The <dtmf-support> element has the following child elements:
<list style="hanging">
<t hangText="detect: ">Indicates the support for DTMF detection.
The <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="generate: ">Indicates the support for DTMF generation.
The <generate> element has no attributes. The <generate> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="passthrough: ">Indicates the support for passing DTMF through without re-encoding.
The <passthrough> element has no attributes. The <passthrough> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
</list>
</t>
</section>
<!--dtmf-support -->
<section anchor="sec:mixing-modes" title="<mixing-modes>">
<t>The <mixing-modes> element provides information about the support for audio
and video mixing of a Media Server, specifically a list of supported algorithms
to mix audio and a list of supported video presentation layouts. The element MAY be present.</t>
<t>The <mixing-modes> element has no attributes.</t>
<t>The <mixing-modes> element has the following child elements:
<list style="hanging">
<t hangText="audio-mixing-modes: "> Is a container representing the available algorithms for
audio mixing. The <audio-mixing-modes> element has no attributes. The
<audio-mixing-modes> element has one child element. The child element,
<audio-mixing-mode>, contains a specific available algorithm. It has a single
attribute, 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm support applies.</t>
<t hangText="video-mixing-modes: "> Is a container representing the available video
presentation layouts and the supported functionality for what concerns video mixing.
The <video-mixing-modes> element has two attributes, 'vas' and 'activespeakermix'.
The 'vas' attribute is of type boolean with a value of 'true' indicating the Media Server
supports automatic Voice Activated Switching. The 'activespeakermix' is of type boolean
with a value of 'true' indicating that the Media Server is able to prepare an
additional video stream for the loudest speaker participant without its contribution.
The <video-mixing-modes> element has one child element.
The child element, <video-mixing-mode>, contains the name of a specific video presentation
layout. The name may refer to one of predefined video layouts defined in the XCON
conference information data model, or to non-XCON layouts as well, as long as they are properly prefixed.
The <video-mixing-mode> element has a single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package, compliant with
the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support applies.</t>
</list>
</t>
</section>
<!--mixing-modes -->
<section anchor="sec:supported-tones" title="<supported-tones>">
<t>The <supported-tones> element provides information about which
tones a media server supports. In particular, the support is reported
referring to both country codes support (ISO 3166-1 <xref target="ISO.3166-1"/>) and supported
functionality (ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>). The element MAY be present.</t>
<t>The <supported-tones> element has no attributes.</t>
<t>The <supported-tones> element has the following child elements:
<list style="hanging">
<t hangText="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 <xref target="ISO.3166-1"/>
specification. The <country-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are supported.</t>
<t hangText="supported-h248-codes: "> Is a container representing the supported
H.248 codes with respect to tones. The <supported-h248-codes>
element has no attributes. The <supported-h248-codes> has one
child element. The child element, <h248-code>, reports support
for a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>
specification. The codes can be either specific (e.g., cg/dt to
only report the Dial Tone from the Call Progress Tones package)
or generic (e.g., cg/* to report all the tones from the Call Progress
Tones package) using wildcards. The <h248-code> element has a
single attribute, 'package'. The attribute 'package' provides
the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which
the specified codes are supported.</t>
</list>
</t>
</section>
<!--supported-tones -->
<section anchor="sec:streaming-modes" title="<streaming-modes>">
<t>The <streaming-modes> element allows the Media Server to specify which protocols are supported
for streaming to a Media Server for each Media Control Channel Framework package type. For example, whether the Media Server
supports audio streaming via RTSP, HTTP, NFS, etc protocols. The element MAY be present.</t>
<t>The <streaming-modes> element has no attributes.</t>
<t>The <streaming-modes> element has the following child element:
<list style="hanging">
<t hangText="stream-mode: ">has two attributes, 'name' and 'package'. The 'name' attribute provides the
type of protocol that can be used for streaming (e.g., "HTTP", "RTSP", etc.).
The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the streaming protocol applies.</t>
</list>
</t>
</section>
<!--streaming-modes -->
<section anchor="sec:asr-tts-support" title="<asr-tts-support>">
<t>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 <xref target="ISO.639.1988">ISO-639-1</xref> 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:
<list style="hanging">
<t hangText="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 <xref target="ISO.639.1988">ISO-639-1</xref> code of the supported language.</t>
<t hangText="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 <xref target="ISO.639.1988">ISO-639-1</xref> code of the supported language.</t>
</list>
</t>
</section>
<!--asr-tts-support -->
<section anchor="sec:vxml-support" title="<vxml-support>">
<t>The <vxml-support> element specifies if the Media Server supports VoiceXML and if it does which
protocols the support is exposed through (e.g., via the control framework, RFC4240 <xref target="RFC4240"/>, or RFC5552 <xref target="RFC5552"/>).
The element MAY be present.</t>
<t>The <vxml-support> element has a single attribute 'support'. The 'support' attribute is of
type boolean with a value of 'true' indicating that the media server does support VXML, and a
value of 'false' indicating it does not support VXML. The default value is 'false'.</t>
<t>The <vxml-support> element has the following child element:
<list style="hanging">
<t hangText="vxml-mode: ">has two attributes, 'package' and 'support'. The 'package' attribute
provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'support' attribute provides the type of VXML support provided by the
Media Server (RFC5552 <xref target="RFC5552"/>, RFC4240 <xref target="RFC4240"/> or IVR-Package <xref target="I-D.ietf-mediactrl-ivr-control-package"/>).</t>
</list>
</t>
</section>
<!--vxml-support -->
<section anchor="sec:media-server-location" title="<media-server-location>">
<t>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 <xref target="RFC5139">RFC 5139</xref>. The element MAY be present.</t>
<t>The <media-server-location> element has no attributes.</t>
<t>The <media-server-location> element one child element:
<list style="hanging">
<t hangText="civicAddress: "> Is a container representing the civic
address location of the media server, whose representation refers to the
Section 4 of <xref target="RFC5139">RFC 5139</xref>.</t>
</list>
</t>
</section>
<!--media-server-location -->
<section anchor="sec:label" title="<label>">
<t>The <label> element allows a Media Server to declare a piece of information that will be understood by the MRB.
For example, the Media Server can declare if it's a blue or green one. It's a string to allow arbitrary values to be returned
to allow arbitrary classification, and as such is not meant to provide any explicit information associated
with the features of a MS. The element MAY be present.</t>
<t>The <label> element has no attributes.</t>
<t>The <label> element has no child elements.</t>
</section>
<!--label -->
<section anchor="sec:media-server-address" title="<media-server-address>">
<t>The <media-server-address> element allows a Media Server to provide
a direct SIP URI address where it can be reached (e.g., the URI AS would
call to in order to setup a Control Channel and relay call legs).
The element MAY be present.</t>
<t>The <media-server-address> element has no attributes.</t>
<t>The <media-server-address> element has no child elements.</t>
</section>
<!--media-server-address -->
<section anchor="sec:encryption" title="<encryption>">
<t>The <encyption> element allows a Media Server to declare support for encrypting RTP media streams
using <xref target="RFC3711">RFC 3711</xref>. A value of 'true' indicates that a Media Server does support
<xref target="RFC3711">RFC 3711</xref> for RTP. A value of 'false' indicates that a Media Server does not
support <xref target="RFC3711">RFC 3711</xref> for RTP. The element MAY be present.</t>
<t>The <encryption> element has no attributes.</t>
<t>The <encryption> element has no child elements.</t>
</section>
<!--encryption -->
</section>
<!-- mrbnotification -->
<section anchor="sec:responses" title="<mrbresponse>">
<t>Responses to requests are indicated by a <response> element from <xref target="sec:publisher_xml"/>. </t>
<t>The <response> element has following attributes:
<list style="hanging">
<t hangText="status:">numeric code indicating the response status. The
attribute MUST be present.</t>
<t hangText="reason:">string specifying a reason for the response status. The
attribute MAY be present.</t>
</list>
</t>
<t>The following status codes are defined for 'status': </t>
<texttable anchor="defn.response.statuscodes"
title="<response> status codes" >
<ttcol align="left" width="15%">code</ttcol>
<ttcol align="left" width="85%">description</ttcol>
<c>200</c>
<c>OK</c>
<c>400</c>
<c>Syntax error</c>
<c>401</c>
<c>Unable to create Subscription</c>
<c>402</c>
<c>Unable to update Subscription</c>
<c>403</c>
<c>Unable to remove Subscription</c>
<c>404</c>
<c>Subscription does not exist</c>
<c>405</c>
<c>Subscription already exists</c>
<c>420</c>
<c>Unsupported attribute or element</c>
</texttable>
<t>
In case a new subscription request made by an MRB (action='create') has been accepted,
the MS MUST reply with a <mrbresponse> with status code 200. The same rule applies
whenever a request to update (action='update') or remove (action='remove') an
existing transaction can be fulfilled by the MS.
</t>
<t>
A subscription request, nevertheless, may fail for several reasons. In such
a case, the status codes defined in <xref target="defn.response.statuscodes"/>
must be used instead. Specifically, if the MS fails to handle a request
due to a syntax error in the request itself (e.g., incorrext XML,
violation of the schema constraints or invalid values in any of the
attributes/elements) the MS MUST reply with a <mrbresponse> with status code 400.
If a syntactically correct request fails because the request also includes any
attribute/element the MS doesn't understand, the MS MUST reply with a <mrbresponse> with status code 420.
If a syntactically correct request fails because the MRB wants to create a new subscription,
but the provided intended id for the subscription already exists, the MS MUST reply
with a <mrbresponse> with status code 405. If a syntactically correct request
failes because the MRB wants to update/remove a subscription that doesn't exist,
the MS MUST reply with a <mrbresponse> with status code 404.
If the MS is unable to accept a request for any other
reason (e.g., the MRB has no more resources to fulfil the request),
the MS MUST reply with a <mrbresponse> with status code 401/402/403,
depending on the action the MRB provided in its request:
<list style="symbols">
<t>action='create' --> 401;</t>
<t>action='update' --> 402;</t>
<t>action='remove' --> 403;</t>
</list>
</t>
<t>
As explained in <xref target="sec:subscription"/>, even in case of
an accepted subscription request the MS might change the
suggested 'expires' and 'frequency' values provided by the MRB in its
<mrbrequest>, if it considers them unacceptable (e.g., the requested
frequency is too high). In such a case, the MS MUST add an additional
<subscription> element to the response, including the updated values,
to inform the MRB about the change. The MS MAY include such element
if the values have been accepted or were omitted in the request.
</t>
</section>
<!-- Responses -->
</section>
<!-- Media Server Publish Interface -->
<section anchor="sec:Res_Cons" title="Media Service Resource Consumer Interface">
<t>The Media Server Consumer interface provides the ability for clients of an MRB,
such as Application Servers, to request an appropriate Media Server to satisfy
specific criteria. The interface allows a client to pass detailed meta-information
to the MRB to help select an appropriate Media Server. The MRB is then able to make
an informed decision and provide the client with an appropriate media server
resource. The MRB Consumer interface can be used in association with both
the Session Initiation Protocol (SIP) and the Hypertext Transfer Protocol (HTTP)
<xref target="RFC2616"/>. The following subsections provide guidance on
using the Consumer interface, as defined by the 'application/mrb-consumer+xml MIME
type in <xref target="sec:consumer_xml"/>, with HTTP and SIP.</t>
<section anchor="sec:http_Consumer" title="HTTP Consumer Interface Usage">
<t>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 <xref target="RFC2616"/> and HTTPS <xref target="RFC2818"/> as
transport for a query for media resource and the appropriate response.</t>
<t>The media resource query, as defined by the <mediaResourceRequest> element from
<xref target="sec:consumer_xml"/>, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS
request/response MUST be 'application/mrb-consumer+xml'. This value MUST
be reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain the
'mediaResourceRequest' element as defined
in <xref target="sec:consumer_xml"/>. The 'mediaResourceRequest' element
is the primary container of information related to a media resource
request.</t>
<t>The media resource response to a query, as defined by the <mediaResourceResponse> element from
<xref target="sec:consumer_xml"/>, 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 <xref target="sec:consumer_xml"/>. The 'mediaResourceResponse' element
is the primary container of information related to a media resource
response.</t>
</section>
<!-- HTTP Consumer Interface Usage -->
<section anchor="sec:sip_Consumer" title="SIP Consumer Interface Usage">
<t>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 <xref target="RFC3261"/> as transport for a query for media resource and the appropriate
response when used with IAMM of operation (as discussed in <xref target="sec:IAMM"/>).</t>
<t>The media resource query, as defined by the <mediaResourceRequest> element from
<xref target="sec:consumer_xml"/>, 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 <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. The following
additional steps MUST be followed when using the Consumer interface:
<list style="symbols">
<t>Include a payload in the SIP INVITE request of type
'multipart/mixed'<xref target="RFC2046"/>. One of the parts to be included
in the 'multipart/mixed' payload MUST be the 'application/sdp' format which is constructed as
specified in the Media Control Channel
Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. </t>
<t> Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and defined in
<xref target="sec:consumer_xml"/>. Only the <mediaResourceRequest> and its child
elements can be included in the payload.</t>
<t> The INVITE request will then be dispatched to the MRB, as defined
by <xref target="I-D.ietf-mediactrl-sip-control-framework"/>.</t>
</list>
</t>
<t>The media resource response to a query, as defined by the <mediaResourceResponse> element from
<xref target="sec:consumer_xml"/>, 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 <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. The following
additional steps MUST be followed when using the Consumer interface:
<list style="symbols">
<t>Include a payload in the SIP 2xx class response of type
'multipart/mixed'<xref target="RFC2046">RFC 2046</xref>. One of the parts to be included
in the 'multipart/mixed' payload MUST be the 'application/sdp' format which is constructed as
specified in the Media Control Channel
Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>.</t>
<t> Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and defined in
<xref target="sec:consumer_xml"/>. Only the <mediaResourceResponse> and its child
elements can be included in the payload.</t>
<t> The SIP 2xx class response will then be dispatched from the MRB.</t>
<t>A SIP ACK to the 2xx class response will then be sent back to the MRB.</t>
</list>
</t>
</section>
<!-- SIP Consumer Interface Usage -->
<section anchor="sec:lease" title="Consumer Interface Lease Mechanism">
<t>The Consumer interface defined in <xref target="sec:Res_Cons"/>
and <xref target="sec:consumer_xml"/> allows a client to request an appropriate
media resource based on information included in the request (either a HTTP POST
or SIP INVITE message). In case of success, the response that is returned to the client MUST contain
a <session-info> element in either the SIP 2xx class or HTTP 200 response. The
information contained in the <response-session-info>
element allows a Consumer client to monitor the life time of the resources it has
successfully requested, as well as amending them.</t>
<t>Before delving into the details of such lease mechanism, though, it's worthwhile
to first clarify its role within the context of the Consumer interface. As
explained in <xref target="sec:MS_Pub"/>, the knowledge the MRB has of the resources
of all the MS it handles is imperfect. As such, how an MRB actually manages such
resources depends on how it is implemented: one may choose to have the MRB keeping
track and state of the allocated resources, or simply depend on the MS themselves
to provide the information by means of the publishing interface notifications.
Further information may be inferred by the signalling, in case the MRB is in
the path of call legs. This means that the MRB may or may not be able to enforce
the leasing mechanism it provides: such functionality is demanded, if necessary,
to the actual deployment of a compliant entity, with the help of the information
herein provided.
</t>
<t>That said, the <mediaResourceResponse> element returned from the MRB contains a <response-session-info>
element if the request is successful. The <response-session-info> element has the following child
elements which provide the appropriate resource session information:
<list style="symbols">
<t><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).</t>
<t><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).</t>
<t><expires> provides a value which represents the number of seconds the
request for media resources is deemed alive. The Consumer client should issue a refresh
of the request, as discussed later in this section, if the expires timer is due to fire
and the media resources are still required.</t>
<t><media-server-address> provides a value which represents the SIP URI where the
assigned MS can be contacted to make use of the required media resources.</t>
</list>
</t>
<t>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:
<list style="symbols">
<t><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>).</t>
<t><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.</t>
<t><action> element provides the operation to be carried out by the MRB on receiving the request:
<list style="symbols">
<t>The value of 'update' is a request by the Consumer client to update the existing session at the MRB
with alternate requirements which are contained in the remainder of the request. If the requested
resource information is identical to the existing MRB session, the MRB will attempt a session refresh.
If the information has changed, the MRB
will attempt to update the existing session with the new information. If the operation is successful, the
200 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element.
If the operation is not successful, a 409 status code in the response is
returned in the status attribute of the <mediaResourceResponseType> element.</t>
<t>The value of 'remove' is a request by the Consumer client to remove
the session at the MRB. This provides a mechanism for Consumer clients to release unwanted
resources before they expire. If the operation is successful, a
200 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element.
If the operation is not successful, a 410 status code in the response is returned in the status attribute of
the <mediaResourceResponseType> element.</t>
</list>
</t>
</list>
</t>
<t>Omitting the 'action' attribute means requesting a new set of resources.</t>
<t>When used with SIP the <session-info> element MUST be included in either a SIP re-INVITE
(as defined in <xref target="RFC3261"/>) or a SIP UPDATE (as defined in<xref target="RFC3311"/>) request.
When used with HTTP the <session-info> element MUST be included in a HTTP POST
message (as defined in <xref target="RFC2616"/>).</t>
</section>
<!-- Consumer Interface Lease Mechanism -->
<section anchor="sec:Media_Request" title="Media Service Resource Request">
<t>This section defines the XML elements for the Consumer interface. The formal XML schema definition
for the Consumer interface can be found in <xref target="sec:consumer_xml"/>.</t>
<t>The root element is <mrbconsumer>. All other XML elements (requests, responses) are
contained within it. The MRB Consumer interface request element is detailed in <xref target="sec:mediaResourceRequest"/>.
MRB Consumer interface response element is contained in <xref target="sec:mediaResourceResponse"/>.</t>
<t>The <mrbconsumer> element has the following attributes:
<list style="hanging">
<t hangText="version: "> a token specifying the mrb-consumer package version. The value
is fixed as '1.0' for this version of the package. The attribute
MUST be present.</t>
</list>
</t>
<t>The <mrbconsumer> element has the following child elements, only one of which is allowed
to occur.
<list style="hanging">
<t><mediaResourceRequest> for sending a Consumer request. See <xref target="sec:mediaResourceRequest"/>.</t>
<t><mediaResourceResponse> for sending a Consumer response. See <xref target="sec:mediaResourceResponse"/>.</t>
</list>
</t>
<section anchor="sec:mediaResourceRequest" title="<mediaResourceRequest> element">
<t>The <mediaResourceRequest> element provides a container for clients
wishing to query an external MRB entity. The <mediaResourceRequest> element has
<generalInfo>, <ivrInfo> and <mixerInfo> as
child elements. These three elements are used to describe the requirements of a
client requesting a Media Server and are covered in the following sub-sections.</t>
<section anchor="sec:requestGeneral" title="<generalInfo> element">
<t>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 <xref target="sec:lease"/>.
The following sub-sections describe the elements of the <generalInfo> element,
<session-info> and <packages>.</t>
<section anchor="sec:session-info" title="<session-info> element">
<t>The <session-info> element is included in Consumer requests when an update is being made
to an existing media resource session. The ability to change and remove an existing media resource
session is described in more detail in <xref target="sec:lease"/>. The element MAY be present.</t>
<t>The <session-info> element has no attributes.</t>
<t>The <session-info> element has the following child elements:
<list style="hanging">
<t hangText="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 <xref target="sec:lease"/>.</t>
<t hangText="seq: "> is used in association with the <session-id> element in a subsequent
request to update an existing media resource session on an MRB. The <seq> number is incremented
from its original value returned in response to the initial request for media resources. More information
about its use is provided in <xref target="sec:lease"/>.</t>
<t hangText="action: "> provides the operation that should be carried out on an existing media
resource session on an MRB:
<list style="symbols">
<t>The value of 'update' instructs the MRB to attempt to update the
existing media resource session with the information contained in the <ivrInfo> and <mixerInfo>
elements.</t>
<t>The value of 'remove' instructs the MRB to attempt to remove the existing
media resource session. More information on its use is provided in <xref target="sec:lease"/>.</t>
</list></t>
</list>
</t>
</section>
<section anchor="sec:packages" title="<packages> element">
<t>The <packages> element provides a list of Media Control Channel Framework compliant
packages that are required by the Consumer client. The element MAY be present.</t>
<t>The <packages> element has no attributes.</t>
<t>The <packages> element has the following child element:
<list style="hanging">
<t hangText="package: "> child element contains a string representing the Media Control
Channel Framework package required by the Consumer client. The <package> element
can appear multiple times. A valid value is a Control Package name as specified
in the related IANA registry (e.g., "msc-ivr/1.0")</t>
</list>
</t>
</section>
</section>
<!-- generalInfo -->
<section anchor="sec:requestivrInfo" title="<ivrInfo> element">
<t>The <ivrInfo> element provides a container for general Consumer request information
that is IVR specific. The following sub-sections describe the elements of the <ivrInfo>
element, <ivr-sessions>, <file-formats>,
<dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <encryption>,
<application-data>, <max-prepared-duration> and <stream-mode>.</t>
<section anchor="sec:ivr-sessions" title="<ivr-sessions> element">
<t>The <ivr-sessions> element indicates the number of IVR sessions a Consumer
client requires from a media resource. The element MAY be present.</t>
<t>The <ivr-sessions> element has no attributes.</t>
<t>The <ivr-sessions> element has the following child element:
<list style="hanging">
<t hangText="rtp-codec: "> child element contains has a single attribute, 'name'. The 'name'
attribute provides the name of the codec required for an IVR session and is an appropriately
registered token. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <rtp-codec> element has two child elements. The child element,
<decoding>, represents the number of RTP sessions for which decoding using the specified codec is requested. The
child element, <encoding>, represents the number of RTP sessions for which encoding using the specified codec is
requested. </t>
</list>
</t>
</section>
<!--ivr-sessions -->
<section anchor="sec:file-formats_consumer" title="<file-formats> element">
<t>The <file-formats> element provides a list of file formats required for the
purpose of playing media. The element MAY be present.</t>
<t>The <file-formats> element has no attributes.</t>
<t>The <file-formats> element has the following child element:
<list style="hanging">
<t hangText="required-format: "> has a single attribute, 'name', which provides the
type of file format that is required. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <supported-format> element then has
a further child element, <required-file-package>. The <required-file-package>
element provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.</t>
</list>
</t>
</section>
<!--file-formats -->
<section anchor="sec:dtmf" title="<dtmf> element">
<t>The <dtmf> element supplies the required methods to detect DTMF tones and to generate them.
The element MAY be present.</t>
<t>The <dtmf> element has no attributes.</t>
<t>The <dtmf> element has the following child elements:
<list style="hanging">
<t hangText="detect: ">Indicates the required support for DTMF detection.
The <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being needed, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="generate: ">Indicates the required support for DTMF generation.
The <generate> element has no attributes. The <generate> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being needed, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="passthrough: ">Indicates the required support for passing DTMF through without re-encoding.
The <passthrough> element has no attributes. The <passthrough> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being needed, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
</list>
</t>
</section>
<!--DTMF -->
<section anchor="sec:tones" title="<tones>">
<t>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 <xref target="ISO.3166-1"/>) and requested
functionality (ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>). The element MAY be present.</t>
<t>The <tones> element has no attributes.</t>
<t>The <tones> element has the following child elements:
<list style="hanging">
<t hangText="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 <xref target="ISO.3166-1"/>
specification. The <country-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested.</t>
<t hangText="h248-codes: "> Is a container representing the requested
H.248 codes with respect to tones. The <h248-codes>
element has no attributes. The <h248-codes> has one
child element. The child element, <h248-code>, requests
a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>
specification. The codes can be either specific (e.g., cg/dt to
only report the Dial Tone from the Call Progress Tones package)
or generic (e.g., cg/* to report all the tones from the Call Progress
Tones package) using wildcards. The <h248-code> element has a
single attribute, 'package'. The attribute 'package' provides
the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which
the specified codes are requested.</t>
</list>
</t>
</section>
<!--tones -->
<section anchor="sec:asr-tts" title="<asr-tts>">
<t>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 <xref target="ISO.639.1988">ISO-639-1</xref> 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:
<list style="hanging">
<t hangText="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 <xref target="ISO.639.1988">ISO-639-1</xref> code of the supported language.</t>
<t hangText="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 <xref target="ISO.639.1988">ISO-639-1</xref> code of the supported language.</t>
</list>
</t>
</section>
<!--asr-tts -->
<section anchor="sec:vxml" title="<vxml> element">
<t>The <vxml> element specifies if the Consumer client required VoiceXML and if it does which
protocols the support is exposed through (e.g., via the control framework, RFC4240 <xref target="RFC4240"/>, or RFC5552 <xref target="RFC5552"/>).
The element MAY be present.</t>
<t>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'.</t>
<t>The <vxml> element has the following child element:
<list style="hanging">
<t hangText="vxml-mode: ">has two attributes, 'package' and 'require'. The 'package' attribute
provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'require' attribute specifies the type of VXML support required by the
Consumer client (RFC5552 <xref target="RFC5552"/>, RFC4240 <xref target="RFC4240"/> or IVR-Package <xref target="I-D.ietf-mediactrl-ivr-control-package"/>).</t>
</list>
</t>
</section>
<!--vxml -->
<section anchor="sec:location" title="<location>">
<t>The <location> element requests a civic
location for an IVR media server. The request makes use of the Civic Address
Schema standardized in <xref target="RFC5139">RFC 5139</xref>. The element MAY be present.</t>
<t>The <location> element has no attributes.</t>
<t>The <location> element one child element:
<list style="hanging">
<t hangText="civicAddress: "> Is a container representing the civic
address location of the requested media server, whose representation refers to
Section 4 of <xref target="RFC5139">RFC 5139</xref>.</t>
</list>
</t>
</section>
<!--location -->
<section anchor="sec:encryption_consumer" title="<encryption>">
<t>The <encryption> element allows a Consumer client to request support for encrypting RTP media streams
using <xref target="RFC3711">RFC 3711</xref>. A value of 'true' indicates that Consumer client requires support of
<xref target="RFC3711">RFC 3711</xref> for RTP. A value of 'false' indicates that a Consumer client does not
require support of <xref target="RFC3711">RFC 3711</xref> for RTP. The element MAY be present. The default value
is 'false'</t>
<t>The <encryption> element has no attributes.</t>
<t>The <encryption> element has no child elements.</t>
</section>
<!--encryption -->
<section anchor="sec:application-data_consumer" title="<application-data>">
<t>The <application-data> element provides IVR application level data. The element MAY be present.</t>
<t>The <application-data> element has no attributes.</t>
<t>The <application-data> element has no child elements.</t>
</section>
<!--application-data -->
<section anchor="sec:max-prepared-duration_consumer" title="<max-prepared-duration>">
<t>The <max-prepared-duration> element provides the amount of time required by the Consumer client
that a media dialog can be prepared in the system before it is executed. The element MAY be present.</t>
<t>The <max-prepared-duration> element has no attributes.</t>
<t>The <max-prepared-duration> element has the following child element:
<list style="hanging">
<t hangText="max-time: "> has a single attribute, 'max-time-seconds', which provides the
amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has
a further child element, <max-time-package>. The <max-time-package>
element provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.</t>
</list>
</t>
</section>
<!--max-prepared-duration -->
<section anchor="sec:streaming-modes_consumer" title="<streaming-modes>">
<t>The <streaming-modes> element allows the Consumer client to specify which protocols are required
for streaming to a Media Server for each Media Control Channel Framework package type. For example does the Media Server
supports audio streaming via RTSP, HTTP, NFS, etc protocols. The element MAY be present.</t>
<t>The <streaming-modes> element has no attributes.</t>
<t>The <streaming-modes> element has the following child element:
<list style="hanging">
<t hangText="stream-mode: ">has two attributes, 'name' and 'package'. The 'name' attribute provides the
type of protocol required for streaming. The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the streaming protocol applies.</t>
</list>
</t>
</section>
<!--streaming-modes -->
</section>
<!-- ivrInfo -->
<section anchor="sec:requestMixerInfo" title="<mixerInfo> element">
<t>The <mixerInfo> element provides a container for general Consumer request information
that is Mixer specific. The following sub-sections describe the elements of the <mixerInfo>
element, <mixers>, <file-formats>,
<dtmf-type>, <tones>, <mixing-mode>, <application-data>, <location> and <encryption>.</t>
<section anchor="sec:mixers" title="<mixers>">
<t>The <mixers> element provides information detailing the required
mixed RTP sessions. The element MAY be present.</t>
<t>The <mixers> element has no attributes.</t>
<t>The <mixers> element has the following child element:
<list style="hanging">
<t hangText="mix: "> Is a container which represents a required mixed RTP session.
The <mix> element has one attribute. The attribute 'users' represents the number of
participants required in the mix. The <mix> element has one child element. The child element,
<rtp-codec>, contains the same information relating to RTP sessions as defined in
<xref target="sec:active-rtp-sessions"/>. The element MAY be present.</t>
</list>
</t>
</section>
<!--active-mixer-sessions -->
<section anchor="sec:file-formats_mixer" title="<file-formats>">
<t>The <file-formats> element provides a list of file formats required by
the Consumer client for the purpose of playing media to a mix. The element MAY be present.</t>
<t>The <file-formats> element has no attributes.</t>
<t>The <file-formats> element has the following child element:
<list style="hanging">
<t hangText="required-format: "> has a single attribute, 'name', which provides the
type of file format that is supported. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., <xref target="RFC4281"/>). The <required-format> element then has
a further child element, <required-file-package>. The <required-file-package>
element provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.</t>
</list>
</t>
</section>
<!--file-formats -->
<section anchor="sec:dtmf_mixer" title="<dtmf> element">
<t>The <dtmf> element supplies the required methods to detect DTMF tones and to generate them in a mix.
The element MAY be present.</t>
<t>The <dtmf> element has no attributes.</t>
<t>The <dtmf> element has the following child elements:
<list style="hanging">
<t hangText="detect: ">Indicates the required support for DTMF detection.
The <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="generate: ">Indicates the required support for DTMF generation.
The <generate> element has no attributes. The <generate> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
<t hangText="passthrough: ">Indicates the required support for passing DTMF through without re-encoding.
The <passthrough> element has no attributes. The <passthrough> element then has
a further child element, <dtmf-type>. The <dtmf-type>
element has two attributes, 'name' and 'package. The 'name' attribute provides the
type of DTMF being used, and it can only be either 'RFC4733' <xref target="RFC4733"/> or 'Media' (tones as signals in the audio stream).
The 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.</t>
</list>
</t>
</section>
<!--DTMF -->
<section anchor="sec:tones_mixer" title="<tones>">
<t>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 <xref target="ISO.3166-1"/>) and requested
functionality (ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>). The element MAY be present.</t>
<t>The <tones> element has no attributes.</t>
<t>The <tones> element has the following child elements:
<list style="hanging">
<t hangText="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 <xref target="ISO.3166-1"/>
specification. The <country-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested.</t>
<t hangText="h248-codes: "> Is a container representing the requested
H.248 codes with respect to tones. The <h248-codes>
element has no attributes. The <h248-codes> has one
child element. The child element, <h248-code>, requests
a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 <xref target="ITU-T.Q.1950"/>
specification. The codes can be either specific (e.g., cg/dt to
only report the Dial Tone from the Call Progress Tones package)
or generic (e.g., cg/* to report all the tones from the Call Progress
Tones package) using wildcards. The <h248-code> element has a
single attribute, 'package'. The attribute 'package' provides
the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which
the specified codes are requested.</t>
</list>
</t>
</section>
<!--tones -->
<section anchor="sec:mixing-modes_mixer" title="<mixing-modes>">
<t>The <mixing-modes> element requests information about the support for audio
and video mixing of a Media Server, specifically a list of supported algorithms
to mix audio and a list of supported video presentation layouts. The element MAY be present.</t>
<t>The <mixing-modes> element has no attributes.</t>
<t>The <mixing-modes> element has the following child elements:
<list style="hanging">
<t hangText="audio-mixing-modes: "> Is a container representing the requested algorithms for
audio mixing. The <audio-mixing-modes> element has no attributes. The
<audio-mixing-modes> element has one child element. The child element,
<audio-mixing-mode>, contains a specific requested algorithm. It has a single
attribute, 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm support is requested.</t>
<t hangText="video-mixing-modes: "> Is a container representing the requested video
presentation layouts for video mixing. The <video-mixing-modes> element
has two attributes, 'vas' and 'activespeakermix'. The 'vas' attribute is of
type boolean with a value of 'true' indicating that the Consumer Client requires
automatic Voice Activated Switching. The 'activespeakermix' attribute is of
type boolean with a value of 'true' indicating that the Consumer Client requires
an additional video stream for the loudest speaker participant without its contribution.
The <video-mixing-modes> element has one child element.
The child element, <video-mixing-mode>, contains the name of a specific video presentation
layout. The name may refer to one of predefined video layouts defined in the XCON
conference information data model, or to non-XCON layouts as well, as long as they are properly prefixed.
The <video-mixing-mode> element has a single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package, compliant with the specification
in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support is requested.</t>
</list>
</t>
</section>
<!--mixing-modes -->
<section anchor="sec:application-data_mixer" title="<application-data>">
<t>The <application-data> element provides IVR application level data. The element MAY be present.</t>
<t>The <application-data> element has no attributes.</t>
<t>The <application-data> element has no child elements.</t>
</section>
<!--application-data -->
<section anchor="sec:location_mixer" title="<location>">
<t>The <location> element requests a civic
location for a mixer media server. The request makes use of the Civic Address
Schema standardized in <xref target="RFC5139">RFC 5139</xref>. The element MAY be present.</t>
<t>The <location> element has no attributes.</t>
<t>The <location> element one child element:
<list style="hanging">
<t hangText="civicAddress: "> Is a container representing the civic
address location of the requested media server, whose representation refers to
Section 4 of <xref target="RFC5139">RFC 5139</xref>.</t>
</list>
</t>
</section>
<!--location -->
<section anchor="sec:encryption_mixer" title="<encryption>">
<t>The <encryption> element allows a Consumer client to request support for encrypting mixed RTP media streams
using <xref target="RFC3711">RFC 3711</xref>. A value of 'true' indicates that Consumer client requires support of
<xref target="RFC3711">RFC 3711</xref> for RTP. A value of 'false' indicates that a Consumer client does not
require support of <xref target="RFC3711">RFC 3711</xref> for RTP. The element MAY be present. The default value
is 'false'</t>
<t>The <encryption> element has no attributes.</t>
<t>The <application-data> element has no child elements.</t>
</section>
<!--encryption -->
</section>
<!-- MixerInfo -->
</section>
<!-- MediaResourceRequest -->
</section>
<!-- Consumer -->
<section anchor="sec:Media_Response" title="Media Service Resource Response">
<t>This section provides the element definitions for use in Consumer interface
responses. The responses are carried in the <mediaResourceResponse> container
element.</t>
<section anchor="sec:mediaResourceResponse" title="<mediaResourceResponse> element">
<t>The <mediaResourceResponse> element provides a container for clients
receiving query information from an external MRB entity.</t>
<t>The <mediaResourceResponse> element has a single attribute 'status' which
indicates the status code of the operation. The following status codes are defined for 'status': </t>
<texttable anchor="defn.response.statuscodes.consumer"
title="<response> status codes" >
<ttcol align="left" width="15%">code</ttcol>
<ttcol align="left" width="85%">description</ttcol>
<c>200</c>
<c>OK</c>
<c>400</c>
<c>Syntax error</c>
<c>408</c>
<c>Unable to find Resource</c>
<c>409</c>
<c>Unable to update Resource</c>
<c>410</c>
<c>Unable to remove Resource</c>
<c>420</c>
<c>Unsupported attribute or element</c>
</texttable>
<t>
In case a new media resource request made by an AS (no action) has been accepted,
the MS MUST reply with a <mediaResourceResponse> with status code 200. The same rule applies
whenever a request to update (action='update') or remove (action='remove') an
existing transaction can be fulfilled by the MRB.
</t>
<t>
A media resource request, nevertheless, may fail for several reasons. In such
a case, the status codes defined in <xref target="defn.response.statuscodes"/>
must be used instead. Specifically, if the MRB fails to handle a request
due to a syntax error in the request itself (e.g., incorrext XML,
violation of the schema constraints or invalid values in any of the
attributes/elements) the MRB MUST reply with a <mediaResourceResponse> with status code 400.
If a syntactically correct request fails because the request also includes any
attribute/element the MRB doesn't understand, the MRB MUST reply with a <mediaResourceResponse> with status code 420.
If a syntactically correct request fails because the MRB couldn't find any MS able to
fulfil the requirements presented by the AS in its request, the MRB MUST reply
with a <mediaResourceResponse> with status code 408.
If a syntactically correct request fails because the MRB couldn't update an
existing request according to the new requirements presented by the AS in
its request, the MRB MUST reply with a <mediaResourceResponse> with status code 409.
If a syntactically correct request fails because the MRB couldn't remove an
existing request and release the related resources as requested by the AS,
the MRB MUST reply with a <mediaResourceResponse> with status code 410.
</t>
<t>
Further details on status codes 409 and 410 are presented in <xref target="sec:lease"/>,
where the leasing mechanism, together with its related scenarios, is described.
</t>
<t>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.</t>
<section anchor="sec:response-session-info" title="<response-session-info> element">
<t>The <response-session-info> element is included in Consumer responses. This applies to responses
to both requests for new resources and requests to update an existing media resource session.
The ability to change and remove an existing media resource
session is described in more detail in <xref target="sec:lease"/>.
The element MAY be present: specifically, the element MUST be included in case the request was
successful, while it would not appear otherwise (e.g., in case the request ended up
with an error).
</t>
<t>The <response-session-info> element has no attributes.</t>
<t>The <response-session-info> element has the following child elements:
<list style="hanging">
<t hangText="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 <xref target="sec:lease"/>.</t>
<t hangText="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 <xref target="sec:lease"/>.</t>
<t hangText="expires: "> includes the number of seconds that the media resources are reserved as part of this
interaction. If the lease is not refreshed before expiry, the MRB will re-claim the resources and they will
no longer be guaranteed. It is RECOMMENDED that a minimum value of 300 seconds be used for the value
of the 'expires' attribute. It is also RECOMMENDED that a Consumer client refresh the lease at an
interval that is not too close to the expiry time. A value of 80% of the timeout period could be used.
For example, if the timeout period is 300 seconds, the Server would
refresh the transaction at 240 seconds. More information on its use is provided in <xref target="sec:lease"/>.</t>
<t hangText="media-server-address: "> is the SIP URI to reach the MS handling the requested media resource.</t>
</list>
</t>
</section>
</section>
</section>
</section>
<!-- Media Server Consumer Interface -->
<section anchor="sec:In_Line" title="In-Line MRB Interface">
<t>An entity acting as an In-Line MRB can act in one of two roles for a request, as introduced
in <xref target="sec:Inline"/>. The following sub sections provide details for using In-Line Unaware
MRB Mode (IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation.</t>
<section anchor="sec:IUMM" title="In-line Unaware MRB Mode">
<t>It should be noted that the introduction of an MRB entity into the network, as specified in this document,
requires interfaces to be implemented by those requesting media server resources (for example an application
server). This applies when using both the Consumer interface as discussed in <xref target="sec:http_Consumer"/>
and IAMM <xref target="sec:sip_Consumer"/>. Nevertheless, an MRB is conceived to also
be able to act in a client unaware mode when it is deployed into the network.
This allows any SIP compliant client entity, as defined by <xref target="RFC3261">RFC 3261</xref> and its
extensions, to send requests to an MRB which in turn will select an appropriate media server based on
knowledge of media server resources it currently has available transparently to the client entity.
Mechanisms used to connect to media servers are detailed in the Media Channel Control
Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. Using an MRB in this mode allows for
easy migration of current applications and services that are unaware of the MRB concept and would simply require
a configuration change resulting in the MRB being set as a SIP outbound proxy for clients requiring media services.
Any client of media services wishing to take advantage of the advanced techniques detailed in this document
when using In-line mode would implement IAMM which is covered in <xref target="sec:IAMM"/>.
</t>
</section>
<!-- IUMM -->
<section anchor="sec:IAMM" title="In-line Aware MRB Mode">
<t>An In-Line Aware Mode MRB (IAMM) is one that complies to the extended functionality provided in this section.
A client entity, such as an application server, wishing to use advanced MRB functionality can provide additional
contextual information to an MRB. This information is identical to that used in the Consumer interface in
<xref target="sec:Res_Cons"/> with the only difference being the underlying transport mechanism of the
contextual information, as specified by the 'application/mrb-consumer+xml' payload in
<xref target="sec:consumer_xml"/>. A client of an IAMM, as anticipated in <xref target="sec:sip_Consumer"/>, uses
SIP signalling to convey the 'application/mrb-consumer+xml' payload to the IAMM, unlike the Consumer interface
presented in <xref target="sec:http_Consumer"/>, which instead uses HTTP as a transport.
A client of an IAMM requiring media services, as well as creating a standard SIP complaint request, MUST use
the following steps (also presented in <xref target="sec:sip_Consumer"/>) to ensure that the request is dealt with appropriately:
<list style="symbols">
<t>The client of the IAMM constructs a SIP INVITE request to connect to a Media
Server as detailed in the Media Channel Control
Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/> with one exception.</t>
<t>The client of the IAMM includes a MIME content type of multipart/mixed as defined in
<xref target="RFC2046">RFC 2046</xref>. As part of this mixed payload, the client MUST
at least include a content-type of
type 'application/sdp' and a content type of type 'application/mrb-consumer+xml'. The part of
type application/sdp represents the media server connection details and MUST adhere to the
Media Channel Control Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. The
part of type 'application/mrb-consumer+xml' represents the IAMM contextual information and MUST
adhere to the schema defined in <xref target="sec:consumer_xml"/>.</t>
<t>Once the SIP INVITE request is constructed, it is sent to the recipient as
per <xref target="RFC3261">RFC 3261</xref>.</t>
</list>
</t>
<t>On receiving a SIP INVITE request containing the multipart mixed payload as specified previously, the IAMM will
complete a number of steps to fulfil the request. It will:
<list style="symbols">
<t>Extract the multipart MIME payload from the SIP INVITE request. It will then use the contextual
information provided by the client in the 'application/mrb-consumer+xml' part to determine which media
server should be selected to service the request.</t>
<t>Extract the 'application/sdp' part from the payload and use it to populate a new SIP INVITE
request for connecting the client to the selected media server, as defined in the
Media Channel Control Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>. The
IAMM acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/mrb-consumer+xml' information
from the SIP INVITE request and then forwards to the selected Media Server.</t>
</list>
</t>
</section>
<!-- IAMM -->
</section>
</section>
<!-- MRB Interface Definitions -->
<section anchor="sec:Examples" title="Examples">
<t>This section provides examples of both the Publish and Consumer interfaces. For what concerns the
Consumer interface, both Query and Inline modes are addressed.</t>
<t>
Note that due to RFC formatting conventions, this section often splits
HTTP, SIP/SDP and CFW across lines whose content would exceed 72 characters.
A backslash character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in the actual
protocol contents. Besides, also note that the indentation of the XML
content is only provided for readability: actual messages will follow strict
XML syntax, which allows for, but does not require, indentation.
</t>
<section anchor="sec:ExPub" title="Publish Example">
<t>
The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework
(<xref target="I-D.ietf-mediactrl-sip-control-framework"/>).
</t>
<t>
<xref target="fig-expub"/> shows the subscription/notification mechanism
the Publish interface is based on, as defined in <xref target="sec:MS_Pub"/>.
The MRB subscribes for information at the MS (message A1.), and the MS accepts the subscription (A2).
Notifications are triggered by the MS (A3.) and acknowledged by the MRB (A4.).
</t>
<t>
<figure anchor="fig-expub" title="Publish Example: Sequence Diagram">
<artwork>
<![CDATA[
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<t>
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
</t>
<t>
<list style="numbers">
<t>the subscription (A1), in an <mrbrequest> (CFW CONTROL);</t>
<t>the MS accepting the subscription (A2), in an <mrbresponse> (CFW 200);</t>
<t>a notification (A3), in a <mrbnotification> (CFW CONTROL event);</t>
<t>the ack to the notification (A4), in a framework level 200 message (CFW 200);</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>600</expires>
<frequency>20</frequency>
</subscription>
</mrbrequest>
</mrbpublish>
A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4242
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish" \
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id>
<supported-packages>
<package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/>
</supported-packages>
<active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>10</decoding>
<encoding>20</encoding>
</rtp-codec>
</active-rtp-sessions>
<active-mixer-sessions>
<active-mix conferenceid="7cfgs43">
<rtp-codec name="audio/basic">
<decoding>3</decoding>
<encoding>3</encoding>
</rtp-codec>
</active-mix>
</active-mixer-sessions>
<non-active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>50</decoding>
<encoding>40</encoding>
</rtp-codec>
</non-active-rtp-sessions>
<non-active-mixer-sessions>
<non-active-mix available="15">
<rtp-codec name="audio/basic">
<decoding/>
<encoding/>
</rtp-codec>
</non-active-mix>
</non-active-mixer-sessions>
<media-server-status>active</media-server-status>
<supported-codecs>
<supported-codecs name="audio/basic">
<supported-codec-package name="msc-ivr/1.0">
<supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions>
</supported-codec-package>
<supported-codec-package name="msc-mixer/1.0">
<supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions>
</supported-codec-package>
</supported-codecs>
</supported-codecs>
<application-data>Testbed Prototype</application-data>
<file-formats>
<supported-format name="audio/x-wav">
<supported-file-package/>
</supported-format>
</file-formats>
<max-prepared-duration>
<max-time max-time-seconds="3600">
<max-time-package>msc-ivr</max-time-package>
</max-time>
</max-prepared-duration>
<dtmf-support>
<detect>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</detect>
<generate>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</generate>
<passthrough>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</passthrough>
</dtmf-support>
<mixing-modes>
<audio-mixing-modes>
<audio-mixing-mode package="msc-ivr/1.0">
nbest
</audio-mixing-mode>
</audio-mixing-modes>
<video-mixing-modes activespeakermix="true" vas="true">
<video-mixing-mode package="msc-mixer/1.0">
single-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
dual-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
dual-view-crop
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
dual-view-2x1
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
dual-view-2x1-crop
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
quad-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
multiple-5x1
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
multiple-3x3
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0">
multiple-4x4
</video-mixing-mode>
</video-mixing-modes>
</mixing-modes>
<supported-tones>
<supported-country-codes>
<country-code package="msc-ivr/1.0">GB</country-code>
<country-code package="msc-ivr/1.0">IT</country-code>
<country-code package="msc-ivr/1.0">US</country-code>
</supported-country-codes>
<supported-h248-codes>
<h248-code package="msc-ivr/1.0">cg/*</h248-code>
<h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
<h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
<h248-code package="msc-mixer/1.0">conftn/*</h248-code>
</supported-h248-codes>
</supported-tones>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
<asr-tts-support>
<asr-support>
<language xml:lang="en"/>
</asr-support>
<tts-support>
<language xml:lang="en"/>
</tts-support>
</asr-tts-support>
<vxml-support support="false">
<vxml-mode package="msc-ivr/1.0"/>
</vxml-support>
<media-server-location>
<ca:civicAddress xml:lang="it">
<ca:country>IT</ca:country>
<ca:A1>Campania</ca:A1>
<ca:A3>Napoli</ca:A3>
<ca:A6>Via Claudio</ca:A6>
<ca:HNO>21</ca:HNO>
<ca:LMK>University of Napoli Federico II</ca:LMK>
<ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM>
<ca:PC>80210</ca:PC>
</ca:civicAddress>
</media-server-location>
<label>TestbedPrototype-01</label>
<media-server-address>
sip:MediaServer@ms.example.com:5080
</media-server-address>
<encryption>false</encryption>
</mrbnotification>
</mrbpublish>
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
]]>
</artwork>
</figure>
</t>
</section>
<!-- Publish Example -->
<section anchor="sec:ExCons" title="Consumer Example">
<t>
As specified in <xref target="sec:Res_Cons"/>, the Consumer interface
can be involved in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of such an
approach is presented in <xref target="sec:ExConsQuery"/>. When in
Inline-aware mode, messages are transported as part of SIP negotiations:
an example of such an approach is presented in <xref target="sec:ExConsIAMM"/>.
</t>
<section anchor="sec:ExConsQuery" title="Query Example">
<t>
The following example assumes the interested AS already knows the
HTTP URL where an MRB is listening for Consumer messages.
</t>
<t>
<xref target="fig-excons"/> shows the HTTP-based transaction between the AS and
the MRB. The AS sends a consumer request as payload of an HTTP POST message (1.),
and the MRB provides an answer in an HTTP 200 OK message (2.).
</t>
<t>
<figure anchor="fig-excons" title="Consumer Example (Query): Sequence Diagram">
<artwork>
<![CDATA[
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with MS reported by MRB |
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<t>
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
</t>
<t>
<list style="numbers">
<t>the Consumer request (1), in a <mediaResourceRequest> (HTTP POST, Content-Type 'application/mrb-consumer+xml');</t>
<t>the Consumer response (2), in an <mediaResourceResponse> (HTTP 200 OK, Content-Type 'application/mrb-consumer+xml').</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------
POST /Mrb/Consumer HTTP/1.1
Content-Length: 870
Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>10</decoding>
<encoding>10</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
2. AS <- MRB (200 to POST, Consumer response)
---------------------------------------------
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 506
Date: Mon, 08 Feb 2010 16:53:34 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>0GX1jCYZ8WBa</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address>
sip:MediaServer@ms.example.com:5080
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
]]>
</artwork>
</figure>
</t>
<t>
The rest of the scenario is omitted for brevity. After having received
the 'mediaResourceResponse', the AS has the address of a MS able to
fulfil its media requirements, and can start a Control Dialog with it.
</t>
</section>
<!-- Query Example -->
<section anchor="sec:ExConsIAMM" title="IAMM Example">
<t>
The following example assumes the interested AS already knows the
SIP URI where an MRB is listening as an UAS.
</t>
<t>
<xref target="fig-excons"/> shows the SIP-based transactions involving the AS,
the MRB and the MS that will be chosen eventually. The diagram is more complex than before.
This is basically a scenario envisaging the MRB as a B2BUA. The AS sends a SIP
INVITE (1.), containing both a CFW-related SDP and a Consumer request (multipart body).
The MRB sends a provisional response to the AS (2.) and starts working on the request.
First of all, it makes use of the Consumer request from the AS to determine which MS
should be exploited. Once the right MS has been chosen, the MRB sends a new SIP INVITE
to this MS by just including the SDP part of the original request (3.). The MS
negotiates this INVITE as specified in <xref target="I-D.ietf-mediactrl-sip-control-framework"/>
(4., 5., 6.), providing the MRB with its own CFW-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body (7.): this
multipart body includes the Consumer response used by the MRB to determine the right MS
and the SDP returned by the MS in 5. The AS finally acknowledges the 200 OK (8.), and
can start a CFW connection towards the MS.
</t>
<t>
Please note that, to ease the reading of the protocol contents, a simple '=_Part' is
used whenever a boundary for a 'multipart/mixed' payload is provided, instead of
the actual boundary that would be inserted in the SIP messages.
</t>
<t>
<figure anchor="fig-exiamm" title="Consumer Example (IAMM): Sequence Diagram">
<artwork>
<![CDATA[
AS MRB MS
| | |
| 1. INVITE | |
| (multipart/mixed) | |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Extract SDP and |
| | | MRB payloads; handle |
| |<-+ Consumer request to |
| | know MS to use |
| | |
| | 3. INVITE |
| | (only copy SDP from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| Prepare new +--| |
| payload with | | |
| SDP from MS and +->| |
| Consumer reply | |
| | |
| 7. 200 OK | |
| (multipart/mixed) | |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
|--+ Read Cons. reply | |
| | and use SDP to | |
|<-+ create CFW Chn. | |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP messages
are shown (both the INVITEs and the 200 OKs), and only the relevant headers
are preserved for brevity (Content-Type and multipart-related information).
Specifically:
</t>
<t>
<list style="numbers">
<t>the original INVITE (1), containing both a CFW-related SDP (COMEDIA information
to negotiate a new Control Channel) and a Consumer <mediaResourceRequest>;</t>
<t>the INVITE sent by the MRB to the MS as a B2BUA (3.), containing only the
CFW-related SDP from the original INVITE;.</t>
<t>the 200 OK sent by the MS back to the MRB (5.), to complete the CFW-related negotiation (SDP only);</t>
<t>the 200 OK sent by the MRB back to the AS in response to the original INVITE (7.),
containing both the CFW-related information sent by the MS and a Consumer
<mediaResourceRequest> documenting the MRB's decision to use that MS.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
=_Part
Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>10</decoding>
<encoding>10</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
=_Part
3. MRB -> MS (INVITE sdp only)
------------------------------
[..]
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
5. MRB <- MS (200 OK sdp)
-------------------------
[..]
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
7. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
=_Part
Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>q79OYY0q4M6M</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
=_Part
]]>
</artwork>
</figure>
</t>
<t>
The continuation of the scenario (the AS connecting to the MS to start the Control Channel, the SYNC message, etc.)
are omitted for brevity.
</t>
</section>
<!-- IAMM Example -->
</section>
<!-- Consumer Example -->
</section>
<!-- Examples -->
<section anchor="sec:publisher_xml" title="Media Service Resource Publisher Interface XML Schema">
<t>This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/mrb-publish+xml" format.</t>
<figure anchor="fig:publisher_xml">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package.
The schema namespace is urn:ietf:params:xml:ns:mrb-publish
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the framework attributes for
conferenceid and connectionid.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP LEVEL ELEMENT: mrbpublish
#####################################################
-->
<xsd:complexType name="mrbpublishType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mrbrequest" />
<xsd:element ref="mrbresponse" />
<xsd:element ref="mrbnotification" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbpublish" type="mrbpublishType" />
<!--
#####################################################
mrbrequest TYPE
#####################################################
-->
<!-- mrbrequest -->
<xsd:complexType name="mrbrequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbrequest" type="mrbrequestType" />
<!-- subscription -->
<xsd:complexType name="subscriptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="frequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:attribute name="action" type="action.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" />
<!--
#####################################################
mrbresponse TYPE
#####################################################
-->
<!-- mrbresponse -->
<xsd:complexType name="mrbresponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbresponse" type="mrbresponseType" />
<!--
#####################################################
mrbnotification TYPE
#####################################################
-->
<!-- mrbnotification -->
<xsd:complexType name="mrbnotificationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="media-server-id"
type="subscriptionid.datatype"/>
<xsd:element ref="supported-packages" minOccurs="0" />
<xsd:element ref="active-rtp-sessions" minOccurs="0" />
<xsd:element ref="active-mixer-sessions" minOccurs="0" />
<xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
<xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
<xsd:element ref="media-server-status" minOccurs="0" />
<xsd:element ref="supported-codecs" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="dtmf-support" minOccurs="0" />
<xsd:element ref="mixing-modes" minOccurs="0" />
<xsd:element ref="supported-tones" minOccurs="0" />
<xsd:element ref="streaming-modes" minOccurs="0" />
<xsd:element ref="asr-tts-support" minOccurs="0" />
<xsd:element ref="vxml-support" minOccurs="0" />
<xsd:element ref="media-server-location" minOccurs="0" />
<xsd:element ref="label" minOccurs="0" />
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="subscriptionid.datatype"
use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbnotification" type="mrbnotificationType" />
<!-- supported-packages -->
<xsd:complexType name="supported-packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="package" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-packages" type="supported-packagesType"/>
<xsd:complexType name="packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="package" type="packageType" />
<!-- active-rtp-sessions -->
<xsd:complexType name="active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- active-mixer-sessions -->
<xsd:complexType name="active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mixer-sessions"
type="active-mixer-sessionsType" />
<xsd:complexType name="active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attributeGroup ref="fw:framework-attributes" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mix" type="active-mixType" />
<!-- non-active-rtp-sessions -->
<xsd:complexType name="non-active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-rtp-sessions"
type="non-active-rtp-sessionsType" />
<!-- non-active-mixer-sessions -->
<xsd:complexType name="non-active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="non-active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mixer-sessions"
type="non-active-mixer-sessionsType" />
<xsd:complexType name="non-active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="available" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mix" type="non-active-mixType" />
<!-- media-server-status -->
<xsd:element name="media-server-status" type="msstatus.datatype" />
<!-- supported-codecs -->
<xsd:complexType name="supported-codecsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codecs" type="supported-codecsType" />
<xsd:complexType name="supported-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec" type="supported-codecType" />
<xsd:complexType name="supported-codec-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-actions" type="actions.datatype"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec-package"
type="supported-codec-packageType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="supported-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-format" type="supported-formatType" />
<xsd:element name="supported-file-package"
type="xsd:string" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- dtmf-support -->
<xsd:complexType name="dtmf-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-support" type="dtmf-supportType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- supported-tones -->
<xsd:complexType name="supported-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="supported-h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-tones" type="supported-tonesType" />
<xsd:complexType name="supported-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-country-codes"
type="supported-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="supported-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-h248-codes"
type="supported-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- streaming-modes -->
<xsd:complexType name="streaming-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="streaming-modes" type="streaming-modesType" />
<xsd:complexType name="stream-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="streammode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream-mode" type="stream-modeType" />
<!-- asr-tts-support -->
<xsd:complexType name="asr-tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- media-server-location -->
<xsd:complexType name="media-server-locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="civicAddress" type="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-location"
type="media-server-locationType" />
<!-- vxml-support -->
<xsd:complexType name="vxml-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="support" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- label -->
<xsd:element name="label" type="label.datatype" />
<!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- encryption -->
<xsd:element name="encryption" type="boolean.datatype" />
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="msstatus.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="active" />
<xsd:enumeration value="deactivated" />
<xsd:enumeration value="unavailable" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="create" />
<xsd:enumeration value="update" />
<xsd:enumeration value="remove" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4240" />
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
]]></artwork>
</figure>
</section>
<!-- publisher_xml -->
<section anchor="sec:consumer_xml" title="Media Service Resource Consumer Interface XML Schema">
<t>This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/mrb-consumer+xml" format.</t>
<figure anchor="fig:xml_schema">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB Consumer interface.
The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP LEVEL ELEMENT: mrbconsumer
#####################################################
-->
<xsd:complexType name="mrbconsumerType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mediaResourceRequest" />
<xsd:element ref="mediaResourceResponse" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbconsumer" type="mrbconsumerType" />
<!--
#####################################################
mediaResourceRequest TYPE
#####################################################
-->
<!-- mediaResourceRequst -->
<xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="generalInfo" minOccurs="0" />
<xsd:element ref="ivrInfo" minOccurs="0" />
<xsd:element ref="mixerInfo" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceRequest"
type="mediaResourceRequestType" />
<!--
#####################################################
generalInfo TYPE
#####################################################
-->
<!-- generalInfo -->
<xsd:complexType name="generalInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generalInfo" type="generalInfoType" />
<!-- session-info -->
<xsd:complexType name="session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="session-info" type="session-infoType" />
<!-- packages -->
<xsd:complexType name="packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="package" type="xsd:string" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="packages" type="packagesType"/>
<!--
#####################################################
ivrInfo TYPE
#####################################################
-->
<!-- ivrInfo -->
<xsd:complexType name="ivrInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="ivr-sessions" />
<xsd:element ref="file-formats" />
<xsd:element ref="dtmf-type" />
<xsd:element ref="tones" />
<xsd:element ref="asr-tts" />
<xsd:element ref="vxml" />
<xsd:element ref="location" />
<xsd:element ref="encryption" />
<xsd:element ref="application-data" />
<xsd:element ref="max-prepared-duration" />
<xsd:element ref="streaming-modes" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivrInfo" type="ivrInfoType" />
<!--
#####################################################
mixerInfo TYPE
#####################################################
-->
<!-- mixerInfo -->
<xsd:complexType name="mixerInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mixers" />
<xsd:element ref="file-formats" />
<xsd:element ref="dtmf-type" />
<xsd:element ref="tones" />
<xsd:element ref="mixing-modes" />
<xsd:element ref="application-data" />
<xsd:element ref="location" />
<xsd:element ref="encryption" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixerInfo" type="mixerInfoType" />
<!--
#####################################################
mediaResourceResponse TYPE
#####################################################
-->
<!-- mediaResourceResponse -->
<xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="response-session-info" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceResponse"
type="mediaResourceResponseType" />
<!--
####################################################
ELEMENTS
####################################################
-->
<!-- session-info -->
<xsd:complexType name="response-session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="response-session-info"
type="response-session-infoType" />
<!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- file-format -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="required-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-format" type="required-formatType" />
<xsd:complexType name="required-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="required-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-file-package"
type="required-file-packageType" />
<!-- dtmf-type -->
<xsd:complexType name="dtmfType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf" type="dtmfType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- tones -->
<xsd:complexType name="required-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tones" type="required-tonesType" />
<xsd:complexType name="required-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-codes"
type="required-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="required-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-codes"
type="required-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- asr-tts -->
<xsd:complexType name="asr-ttsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts" type="asr-ttsType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- vxml -->
<xsd:complexType name="vxmlType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml" type="vxmlType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="require" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- location -->
<xsd:complexType name="locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="location" type="locationType" />
<!-- encryption -->
<xsd:element name="encryption" type="boolean.datatype" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- stream-mode -->
<xsd:complexType name="streaming-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="streaming-modes" type="streaming-modesType" />
<xsd:complexType name="stream-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="streammode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream-mode" type="stream-modeType" />
<!-- mixers -->
<xsd:complexType name="mixerssessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixers" type="mixerssessionsType" />
<xsd:complexType name="mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="users" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mix" type="mixType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="remove" />
<xsd:enumeration value="update" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4240" />
<xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
]]></artwork>
</figure>
</section>
<!-- XML Schema -->
<section anchor="sec:security" title="Security Considerations">
<t>The MRB network entity has two primary interfaces, Publish and Consumer,
that carry sensitive information and must therefore be appropriately protected
and secured.</t>
<t>The Publish interface, as defined in and described in <xref target="sec:MS_Pub"/>,
uses the Media Control Channel Framework <xref target="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.</t>
<t>The Consumer interface, as defined in and described in <xref target="sec:Res_Cons"/>,
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
<xref target="RFC2818">RFC 2818</xref>.
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.</t>
<t>It is also worth noting that in In-line mode (both IAMM and IUMM) the MRB
may act as a Back-to-Back User Agent (B2BUA). This means that, as a B2BUA, the
MRB may happen to modify SIP bodies: it is the case, for instance, of the IAMM
handling multipart/mixed payloads. This impacts the ability to use any SIP
security feature that protects the body (e.g., RFC4474, s/mime, etc.) unless
the MRB intermediates the security association. This should be taken into
account when implementing an MRB compliant with this specification.</t>
<t>Finally, it is worthwhile to also discuss authorization issues related
to the specification. Neither the Publishing nor the Consumer interface
provide an explicit means for implementing authentication, i.e., they
do not envisage protocol messages to make sure, for instance, that
only authorized Application Servers can make use of the services provided
by a MRB. Nevertheless, considering both the interfaces are transported
in well-established protocols (HTTP, SIP, CFW), support for such an
functionality can be expressed by means of the authentication mechanisms
provided by the protocol themselves. Therefore, any
MRB-aware entity (Application Servers, Media Servers, Media Resource
Brokers themselves) MUST support the HTTP and SIP Digest access
authentication. That said, the usage of such Digest access authentications
is recommended and not mandatory, which means MRB-aware entities MAY
exploit it in deployment.</t>
</section>
<!-- Security Consideration -->
<section anchor="sec:IANA_Considerations" title="IANA Considerations">
<t>There are several IANA considerations associated with this specification.</t>
<section anchor="sec:IANA_Package" title="Control Package Registration">
<t>This section registers a new Media Control Channel Framework package,
per the instructions in Section 13.1 of
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.</t>
<t>
<list style="hanging">
<t hangText="To: ">ietf-sip-control@iana.org</t>
<t hangText="Subject: ">Registration of new Channel Framework package</t>
<t hangText="Package Name: ">mrb-publish/1.0
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]</t>
<t hangText="Published Specification(s): ">RFCXXXX
Person and email address to contact for further information:
IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Chris Boulton (chris@ns-technologies.com).</t>
</list>
</t>
</section>
<section anchor="sec:IANA_Publish" title="application/mrb-publish+xml MIME Type">
<t>
<list style="hanging">
<t hangText="MIME media type name: ">application</t>
<t hangText="MIME subtype name: ">mrb-publish+xml</t>
<t hangText="Mandatory parameters: ">none</t>
<t hangText="Optional parameters: ">Same as charset parameter application/xml as
specified in RFC 3023 <xref target="RFC3023"/>.</t>
<t hangText="Encoding considerations: ">Same as encoding considerations of
application/xml as specified in RFC 3023 <xref target="RFC3023"/>.</t>
<t hangText="Security considerations: ">See Section 10 of RFC 3023 <xref target="RFC3023"/> and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].</t>
<t hangText="Interoperability considerations: ">none.</t>
<t hangText="Published specification: ">This document.</t>
<t hangText="Applications which use this media type: ">This document type has
been used to support a Media Resource Broker (MRB) entity.</t>
<t hangText="Additional Information:"></t>
<t hangText="Magic Number: ">None</t>
<t hangText="File Extension: ">.xdf</t>
<t hangText="Macintosh file type code: ">"TEXT"</t>
<t hangText="Personal and email address for further information: ">Chris
Boulton, chris@ns-technologies.com</t>
<t hangText="Intended usage: COMMON"></t>
<t hangText="Author/Change controller: ">The IETF.</t>
</list>
</t>
</section>
<!-- IANA Publish -->
<section anchor="sec:IANA_Consumer" title="application/mrb-consumer+xml MIME Type">
<t>
<list style="hanging">
<t hangText="MIME media type name: ">application</t>
<t hangText="MIME subtype name: ">mrb-consumer+xml</t>
<t hangText="Mandatory parameters: ">none</t>
<t hangText="Optional parameters: ">Same as charset parameter application/xml as
specified in RFC 3023 <xref target="RFC3023"/>.</t>
<t hangText="Encoding considerations: ">Same as encoding considerations of
application/xml as specified in RFC 3023 <xref target="RFC3023"/>.</t>
<t hangText="Security considerations: ">See Section 10 of RFC 3023 <xref target="RFC3023"/> and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].</t>
<t hangText="Interoperability considerations: ">none.</t>
<t hangText="Published specification: ">This document.</t>
<t hangText="Applications which use this media type: ">This document type has
been used to support a Media Resource Broker (MRB) entity.</t>
<t hangText="Additional Information:"></t>
<t hangText="Magic Number: ">None</t>
<t hangText="File Extension: ">.xdf</t>
<t hangText="Macintosh file type code: ">"TEXT"</t>
<t hangText="Personal and email address for further information: ">Chris
Boulton, chris@ns-technologies.com</t>
<t hangText="Intended usage: COMMON"></t>
<t hangText="Author/Change controller: ">The IETF.</t>
</list>
</t>
</section>
<!-- IANA Consumer -->
<section anchor="sec:IANA_mrbpub" title="URN Sub-Namespace Registration for mrb-publish">
<t>
Please register the URN name space "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". The template is in <xref target="sec:publisher_xml"/>.
</t>
</section>
<!-- IANA MrbPub -->
<section anchor="sec:IANA_mrbcons" title="URN Sub-Namespace Registration for mrb-consumer">
<t>
Please register the URN name space "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". The template is in <xref target="sec:consumer_xml"/>.
</t>
</section>
<!-- IANA MrbCons -->
<section anchor="sec:IANA_PubSchema" title="XML Schema Registration for mrb-publish">
<t>Please register the schema for mrb-publish:</t>
<t>
<list style="hanging">
<t hangText="URI: ">urn:ietf:params:xml:ns:mrb-publish</t>
<t hangText="ID: ">mrb-publish</t>
<t hangText="Filename: ">mbr-publish</t>
<t hangText="Registrant Contact: ">IETF, MEDIACTRL working group (mediactrl@ietf.org)</t>
<t hangText="Schema: ">The XML for the schema is in <xref target="sec:publisher_xml"/> of this document.</t>
</list>
</t>
</section>
<!-- IANA Publisher Schema -->
<section anchor="sec:IANA_ConsSchema" title="XML Schema Registration for mrb-consumer">
<t>Please register the schema for mrb-consumer:</t>
<t>
<list style="hanging">
<t hangText="URI: ">urn:ietf:params:xml:ns:mrb-consumer</t>
<t hangText="ID: ">mrb-consumer</t>
<t hangText="Filename: ">mbr-consumer</t>
<t hangText="Registrant Contact: ">IETF, MEDIACTRL working group (mediactrl@ietf.org)</t>
<t hangText="Schema: ">The XML for the schema is in <xref target="sec:consumer_xml"/> of this document.</t>
</list>
</t>
</section>
<!-- IANA Publisher Schema -->
</section>
<!-- IANA Considerations -->
<section title="Changes">
<t>Note to RFC Editor: Please remove this whole section.</t>
<section title="Changes from 06 Version">
<t>
<list style="symbols">
<t>Added the missing <encoding> and <decoding> elements to the <rtp-codec> instances, where needed.</t>
<t>Fixed a few typos in the text.</t>
</list>
</t>
</section>
<section title="Changes from 05 Version">
<t>
<list style="symbols">
<t>Clarifier that video layouts may refer to either XCON-defined layouts or others.</t>
<t>Added RFC4240 as an option for VXML support.</t>
<t>Fixed a few typos in the text and in the schemas.</t>
</list>
</t>
</section>
<section title="Changes from 04 Version">
<t>
<list style="symbols">
<t>Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions.</t>
<t>Clarified that 'response-session-info' is not only included
in reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any
error).</t>
<t>Corrected the Query example flow which included a 'session'info'
in a new request.</t>
</list>
</t>
</section>
<section title="Changes from 03 Version">
<t>
<list style="symbols">
<t>Addressed comments per the Expert RAI Review by Ben Campbell.</t>
<t>Several editorial changes (fixes, typos, nits).</t>
<t>Removed the 3xx class responses for the IAMM, per discussion in Anaheim (feature had been added in the -02 version).</t>
<t>Clarified that backslashes and XML indentation in the Examples are only provided for readability.</t>
<t>Clarified the distinction between 'deactivated' and 'unavailable'.</t>
<t>Added text to the status codes in both Publish and Consumer responses, in order to clarify when they are involved.</t>
<t>Added some text to better clarify the role of leasing in the Consumer interface.</t>
<t>Added additional IANA considerations, that were missing in the previous versions of the document.</t>
<t>Added text to the security considerations.</t>
</list>
</t>
</section>
<section title="Changes from 02 Version">
<t>
<list style="symbols">
<t>Added examples in <xref target="sec:Examples"/>.</t>
<t>Fixed some nits in the schemas (encryption and required mixed=true elements).</t>
<t>Completed review nit review comments from Gary Munson.</t>
</list>
</t>
</section>
<section title="Changes from 01 Version">
<t>
<list style="symbols">
<t>Added description of lease mechanism.</t>
<t>Added specific HTTP and SIP usage of Consumer interface.</t>
<t>Completed Publish interface schema + associated text.</t>
<t>Included Consumer interface schema + associated text.</t>
<t>Included supported-packages element.</t>
<t>Removed announce-var element from doc.</t>
<t>Expanded Abstract.</t>
<t>General scrub of text - input from Simon Romano.</t>
<t>Added IANA Considerations section.</t>
<t>Added Security Considerations section.</t>
</list>
</t>
</section>
<section title="Changes from 00 Version">
<t>
<list style="symbols">
<t>Included In-line text based on strawman proposal.</t>
<t>Included first attempt at publish interface based on design team work.</t>
</list>
</t>
</section>
</section>
<!-- Changes -->
<section title="Acknowledgments">
<t>The authors would like to thank the members of the Publish Interface design team who provided valuable
input into this document. The design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also like to thank John Dally,
Simon Romano, Henry Lum, Christian Groves and Jonathan Lennox for input into this specification.</t>
<t>Ben Campbell carried out the RAI expert review on this specification
and provided a great deal of invaluable input.</t>
</section>
<!-- Acknowledgments -->
</middle>
<!-- Middle -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.2818"?>
<?rfc include="reference.RFC.2046"?>
<?rfc include="reference.RFC.3023"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3311"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.5139"?>
<?rfc include="reference.ISO.639.1988"?>
<reference anchor="ITU-T.Q.1950">
<front>
<title>Call Bearer Control (CBC) Protocol</title>
<author>
<organization>International Telecommunication Union - Telecommunication Standardization Bureau</organization>
</author>
</front>
<seriesInfo name="ITU-T" value="Recommendation Q.1950"/>
</reference>
<reference anchor="ISO.3166-1">
<front>
<title>Codes for the representation of names of countries and their subdivisions - Part 1: Country codes</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date year="1997"/>
</front>
<seriesInfo name="ISO" value="Standard 3166-1:1997"/>
</reference>
<?rfc include="reference.W3C.CR-wsdl20-20051215"?>
<?rfc include="reference.W3C.REC-soap12-part1-20030624"?>
<?rfc include="reference.W3C.REC-soap12-part2-20030624"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4240"?>
<?rfc include="reference.RFC.4281"?>
<?rfc include="reference.RFC.4733"?>
<?rfc include="reference.RFC.5167"?>
<?rfc include="reference.RFC.5552"?>
<?rfc include="reference.RFC.5567"?>
<?rfc include="reference.I-D.ietf-mediactrl-sip-control-framework"?>
<?rfc include="reference.I-D.ietf-mediactrl-ivr-control-package"?>
</references>
</back>
<!-- Back -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:42:37 |