draft-ietf-mediactrl-mrb-09.txt   draft-ietf-mediactrl-mrb-10.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero Intended status: Standards Track L. Miniero
Expires: November 24, 2011 Meetecho Expires: February 2, 2012 Meetecho
G. Munson G. Munson
AT&T AT&T
May 23, 2011 August 1, 2011
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-09 draft-ietf-mediactrl-mrb-10
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2011. This Internet-Draft will expire on February 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publish Interface . . . . . . . . . 14 5.1. Media Server Resource Publish Interface . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . 15 5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 29 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 29
5.2. Media Service Resource Consumer Interface . . . . . . . . 30 5.2. Media Service Resource Consumer Interface . . . . . . . 31
5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 31 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 31
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 34 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 34
5.2.4. Media Service Resource Request . . . . . . . . . . . 36 5.2.4. Media Service Resource Request . . . . . . . . . . . 37
5.2.5. Media Service Resource Response . . . . . . . . . . . 48 5.2.5. Media Service Resource Response . . . . . . . . . . . 49
5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . . 50 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 51
6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 52 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 53
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 53 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 54
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 54 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 55
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 56 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 57
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 62 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 63
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 62 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 63
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 65 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 66
10. Media Service Resource Publisher Interface XML Schema . . . . 81 10. Media Service Resource Publisher Interface XML Schema . . . . 82
11. Media Service Resource Consumer Interface XML Schema . . . . 103 11. Media Service Resource Consumer Interface XML Schema . . . . 104
12. Security Considerations . . . . . . . . . . . . . . . . . . . 124 12. Security Considerations . . . . . . . . . . . . . . . . . . . 125
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126
13.1. Control Package Registration . . . . . . . . . . . . . . 125 13.1. Control Package Registration . . . . . . . . . . . . . . 126
13.2. application/mrb-publish+xml MIME Type . . . . . . . . . . 125 13.2. application/mrb-publish+xml MIME Type . . . . . . . . . 126
13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 126 13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 127
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 127 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 128
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . . 127 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 128
13.6. XML Schema Registration for mrb-publish . . . . . . . . . 127 13.6. XML Schema Registration for mrb-publish . . . . . . . . 128
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 127 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 128
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14.1. Changes from 08 Version . . . . . . . . . . . . . . . . . 129 14.1. Changes from 09 Version . . . . . . . . . . . . . . . . 130
14.2. Changes from 07 Version . . . . . . . . . . . . . . . . . 129 14.2. Changes from 08 Version . . . . . . . . . . . . . . . . 130
14.3. Changes from 06 Version . . . . . . . . . . . . . . . . . 129 14.3. Changes from 07 Version . . . . . . . . . . . . . . . . 130
14.4. Changes from 05 Version . . . . . . . . . . . . . . . . . 129 14.4. Changes from 06 Version . . . . . . . . . . . . . . . . 130
14.5. Changes from 04 Version . . . . . . . . . . . . . . . . . 130 14.5. Changes from 05 Version . . . . . . . . . . . . . . . . 131
14.6. Changes from 03 Version . . . . . . . . . . . . . . . . . 130 14.6. Changes from 04 Version . . . . . . . . . . . . . . . . 131
14.7. Changes from 02 Version . . . . . . . . . . . . . . . . . 130 14.7. Changes from 03 Version . . . . . . . . . . . . . . . . 131
14.8. Changes from 01 Version . . . . . . . . . . . . . . . . . 131 14.8. Changes from 02 Version . . . . . . . . . . . . . . . . 132
14.9. Changes from 00 Version . . . . . . . . . . . . . . . . . 131 14.9. Changes from 01 Version . . . . . . . . . . . . . . . . 132
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 132 14.10. Changes from 00 Version . . . . . . . . . . . . . . . . 132
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 133 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 133
16.1. Normative References . . . . . . . . . . . . . . . . . . 133 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.2. Informative References . . . . . . . . . . . . . . . . . 134 16.1. Normative References . . . . . . . . . . . . . . . . . . 134
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 136 16.2. Informative References . . . . . . . . . . . . . . . . . 135
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137
1. Introduction 1. Introduction
The topic of Media Resource management has been in discussion for a The topic of Media Resource management has been in discussion for a
number of years with varying proprietary solutions being used today. number of years with varying proprietary solutions being used today.
It is clear that, as we move towards a consistent architecture and It is clear that, as we move towards a consistent architecture and
protocol for Media Server Control, a standard mechanism is required protocol for Media Server Control, a standard mechanism is required
for accurate media resource selection. for accurate media resource selection.
As IP based multimedia infrastructures mature, the complexity and As IP based multimedia infrastructures mature, the complexity and
skipping to change at page 5, line 48 skipping to change at page 5, line 48
+---+-----+---+ | +---+-----+---+ |
| Application | | | Application | |
| Server |<-----+ | Server |<-----+
+-------------+ +-------------+
Figure 3: Multiple Application Servers Figure 3: Multiple Application Servers
The final deployment view is the most complex. In this model (M:N) The final deployment view is the most complex. In this model (M:N)
there exists any number of Application Servers and any number of there exists any number of Application Servers and any number of
Media Servers. It is again possible in this model that media servers Media Servers. It is again possible in this model that media servers
might not be homogenous and have different capability sets and might not be homogeneous and have different capability sets and
capacity. capacity.
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Application | | Media | | Application | | Media |
| Server |<-----+ +---->| Server | | Server |<-----+ +---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---+-----+---+ | | +---+-----+---+ +---+-----+---+ | | +---+-----+---+
| Application | | | | Media | | Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server | | Server |<-----+-MS Control-+---->| Server |
skipping to change at page 14, line 8 skipping to change at page 14, line 8
convey the same kinds of MS characteristics desired as does the convey the same kinds of MS characteristics desired as does the
Query MRB mode (as in Section 5.2). Query MRB mode (as in Section 5.2).
In either role, the MRB would deduce that the selected MS resources In either role, the MRB would deduce that the selected MS resources
are no longer needed when the AS or MS terminates the corresponding are no longer needed when the AS or MS terminates the corresponding
dialog. The two modes are discussed in more detail in Section 5.3. dialog. The two modes are discussed in more detail in Section 5.3.
5. MRB Interface Definitions 5. MRB Interface Definitions
As discussed in previous sections in this document, the intention is As discussed in previous sections in this document, the intention is
to provide a toolkit for a variety of deployment architectures where to provide a tool-kit for a variety of deployment architectures where
media resource brokering can take place. As a result, two main media resource brokering can take place. As a result, two main
interfaces are required to support the differing requirements. The interfaces are required to support the differing requirements. The
two interfaces are described in the remainder of this section and two interfaces are described in the remainder of this section and
have been named the 'Media Server Resource Publish' and 'Media Server have been named the 'Media Server Resource Publish' and 'Media Server
Resource Consumer' interfaces. These two interfaces have extremely Resource Consumer' interfaces. These two interfaces have extremely
differing responsibilities and usages which is reflected in the differing responsibilities and usages which is reflected in the
choice of solutions. choice of solutions.
It is beyond the scope of this document to define exactly how to It is beyond the scope of this document to define exactly how to
construct an MRB. This includes interpreting the data for the Media construct an MRB. This includes interpreting the data for the Media
skipping to change at page 14, line 51 skipping to change at page 14, line 51
exhaustive view of current MS resource consumption, the MS may in exhaustive view of current MS resource consumption, the MS may in
some cases provide a best-effort computed view of resource some cases provide a best-effort computed view of resource
consumption parameters conveyed in the Publish interface (e.g., DSP's consumption parameters conveyed in the Publish interface (e.g., DSP's
with a fixed number of streams versus GPU's with CPU availability), with a fixed number of streams versus GPU's with CPU availability),
there may be licensing constraints not factored in (e.g., even if there may be licensing constraints not factored in (e.g., even if
lots of CPU and memory are available, licensing or other lots of CPU and memory are available, licensing or other
configuration elements may restrict the number of stream types), and configuration elements may restrict the number of stream types), and
MS resource information may only be reported periodically over the MS resource information may only be reported periodically over the
Publish interface to MRB. Nevertheless, despite such limitations it Publish interface to MRB. Nevertheless, despite such limitations it
is assumed that the provided information is enough to allow MRB is assumed that the provided information is enough to allow MRB
implementors to realize its functionality. implementers to realize its functionality.
It is also worth noting that, while the scope of the MRB is It is also worth noting that, while the scope of the MRB is
definitely on providing interested Application Servers with the definitely on providing interested Application Servers with the
available resources, the MRB also allows for the retrieval of available resources, the MRB also allows for the retrieval of
information about the currently occupied resources. While this is of information about the currently occupied resources. While this is of
course a relevant piece of information (e.g., for monitoring course a relevant piece of information (e.g., for monitoring
purposes), such a functionality inevitably raises security purposes), such a functionality inevitably raises security
considerations, and implementations should take this into account. considerations, and implementations should take this into account.
See Section 12 for more details. See Section 12 for more details.
skipping to change at page 15, line 27 skipping to change at page 15, line 27
Channel Framework uses an extension mechanism to allow specific Channel Framework uses an extension mechanism to allow specific
usages which are known as control packages. Section 5.1.1 defines usages which are known as control packages. Section 5.1.1 defines
the control package that MUST be implemented by any Media Server the control package that MUST be implemented by any Media Server
wanting to interact with an MRB entity. wanting to interact with an MRB entity.
Please note that it is out of scope how an MRB knows what MSs should Please note that it is out of scope how an MRB knows what MSs should
be queried for publishing information. be queried for publishing information.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
This section fulfills the mandatory requirement for information that This section fulfils the mandatory requirement for information that
must be specified during the definition of a Control Framework must be specified during the definition of a Control Framework
Package, as detailed in Section 8 of Package, as detailed in Section 8 of
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
5.1.1.1. Control Package Name 5.1.1.1. Control Package Name
The Media Channel Control Framework requires a Control Package The Media Channel Control Framework requires a Control Package
definition to specify and register a unique name and version. definition to specify and register a unique name and version.
The name and version of this Control Package is "mrb-publish/1.0". The name and version of this Control Package is "mrb-publish/1.0".
skipping to change at page 17, line 18 skipping to change at page 17, line 18
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 10. Section 10.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The <mrbpublish> element has the following attributes: The content of an <mrbpublish> element is zero or more of the
following attributes:
version: a token specifying the mrb-publish package version. The version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The <mrbpublish> element has the following child element, only one of The content of an <mrbpublish> element is the following child
which is allowed to occur in a request. elements, only one of which is allowed to occur in a request.
<mrbrequest> for sending an MRB request. See Section 5.1.3. <mrbrequest> for sending an MRB request. See Section 5.1.3.
<mrbresponse> for sending an MRB response. See Section 5.1.5. <mrbresponse> for sending an MRB response. See Section 5.1.5.
<mrbnotification> for sending an MRB notification. See <mrbnotification> for sending an MRB notification. See
Section 5.1.4. Section 5.1.4.
5.1.3. <mrbrequest> 5.1.3. <mrbrequest>
This section defines the <mrbrequest> element used to initiate This section defines the <mrbrequest> element used to initiate
requests from an MRB to a Media Server. The element is a container requests from an MRB to a Media Server. The element describes
for information relevant for the interrogation of a media server. information relevant for the interrogation of a media server.
The <mrbrequest> element has no defined attributes. The content of an <mrbrequest> element has no defined attributes.
The <mrbrequest> element has the following sub-elements which are The content of an <mrbrequest> element is zero or more of following
defined in the remainder of this section: child elements:
<subscription> for initiating a subscription to a Media Server <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1. from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of Media Server to provide the details relating to the configuration of
updates. This element can be used either to request a new updates. This element can be used either to request a new
subscription or to update an existing one (e.g., to change the subscription or to update an existing one (e.g., to change the
frequency of the updates), and to remove ongoing subscriptions as frequency of the updates), and to remove ongoing subscriptions as
well (e.g., to stop an indefinite update). The MRB will inform the 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 Media Server how long it wishes to receive updates for and the
frequency that updates should be sent. Updates related to the frequency that updates should be sent. Updates related to the
subscription are sent using the <mrbnotification> element. subscription are sent using the <mrbnotification> element.
The <subscription> element has the following attributes: The content of a <subscription> element has the following attributes:
id: indicates a unique token representing the subscription session id: indicates a unique token representing the subscription session
between the MRB and the Media Server. The attribute MUST be between the MRB and the Media Server. The attribute MUST be
present. present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscrition session id to identify a specific with the subscription session id to identify a specific
subscription command. The first subscription MUST have 1 as subscription command. The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the 'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
action: provides the operation that should be carried out on the action: provides the operation that should be carried out on the
subscription: subscription:
* The value of 'create' instructs the MS to attempt to setup a * The value of 'create' instructs the MS to attempt to set-up a
new subscription. new subscription.
* The value of 'update' instructs the MS to attempt to update an * The value of 'update' instructs the MS to attempt to update an
existing subscription. existing subscription.
* The value of 'remove' instructs the MS to attempt to remove an * The value of 'remove' instructs the MS to attempt to remove an
existing subscription and consequently stop any ongoing related existing subscription and consequently stop any ongoing related
notification. notification.
The attribute MUST be present. The attribute MUST be present.
The <subscription> element has the following child elements: The content of a <subscription> element has zero or more of the
following child elements:
expires: Provides the amount of time in seconds that a subscription expires: Provides the amount of time in seconds that a subscription
should be installed for notifications at the Media Server. Once should be installed for notifications at the Media Server. Once
the amount of time has passed, the subscription expires and the the amount of time has passed, the subscription expires and the
MRB has to subscribe again in case it is still interested in MRB has to subscribe again in case it is still interested in
receiving notifications from the MS. The element MAY be present. receiving notifications from the MS. The element MAY be present.
minfrequency: Provides the minimum frequency in seconds that the minfrequency: Provides the minimum frequency in seconds that the
MRB wishes to receive notifications from the MS. The element MAY MRB wishes to receive notifications from the MS. The element MAY
be present. be present.
skipping to change at page 19, line 24 skipping to change at page 19, line 28
reported in the <mrbresponse> accordingly. reported in the <mrbresponse> accordingly.
5.1.4. <mrbnotification> 5.1.4. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The Server to an MRB to provide the details relating current status. The
Media Server will inform the MRB of its current status as defined by Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element. using the <mrbnotification> element.
The <mrbnotification> element has the following attributes: The content of an <mrbnotification> element has the following
attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute MUST be present. the <subscription> element. The attribute MUST be present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
notification update. The first notification MUST have 1 as notification update. The first notification MUST have 1 as
'seqnumber', and following notifications MUST increment by 1 the 'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
The following subsections provide details on the child elements that The following subsections provide details of the child elements that
are contained within an <mrbnotification> element. are the content of the <mrbnotification> element.
5.1.4.1. <media-server-id> 5.1.4.1. <media-server-id>
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system wide
identifier for a Media Server instance. The element MUST be present. identifier for a Media Server instance. The element MUST be present.
5.1.4.2. <supported-packages> 5.1.4.2. <supported-packages>
The <supported-packages> element provides the list of Media Control The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element MAY be Channel Packages supported by the media server. The element MAY be
present. present.
The <supported-packages> element has no attributes. The content of a <supported-packages> element has no attributes.
The <supported-packages> element has the following child element: The content of a <supported-packages> element has zero or more of the
following child elements:
package: The <package> element represents the name of a package package: The <package> element the name of a package supported by
supported by the media server. The <package> element has a single the media server. The <package> element has a single attribute,
attribute, 'name', which represents the name of the supported 'name', which provides the name of the supported Media Control
Media Control Channel Framework package, compliant with the Channel Framework package, compliant with the specification in the
specification in the related IANA registry (e.g., "msc-ivr/1.0"). related IANA registry (e.g., "msc-ivr/1.0").
5.1.4.3. <active-rtp-sessions> 5.1.4.3. <active-rtp-sessions>
The <active-rtp-sessions> element provides information detailing the The <active-rtp-sessions> element provides information detailing the
current active Real-time Transport Protocol(RTP) sessions. The current active Real-time Transport Protocol(RTP) sessions. The
element MAY be present. element MAY be present.
The <active-rtp-sessions> element has no attributes. The content of an <active-rtp-sessions> element has no attributes.
The <active-rtp-sessions> element has the following child element: The content of an <active-rtp-sessions> element has zero or more of
the following child elements:
rtp-codec: Is a container which represents a supported codec and rtp-codec: Describes a supported codec and the number of active
the associated active sessions. The <rtp-codec> element has one sessions using that codec. The <rtp-codec> element has one
attribute. The attribute 'name' represents the name of the codec attribute. The value of the attribute 'name' is a MIME media type
being represented. A valid value is a MIME media type which, (which can include parameters per [RFC4281]). The <rtp-codec>
depending on its definition, can include additional parameters element has two child elements. The child element, <decoding>,
(e.g., [RFC4281]). The <rtp-codec> element has two child has as content the decimal number of RTP sessions being decoded
elements. The child element, <decoding>, represents the number of using the specified codec. The child element, <encoding>, has as
RTP sessions for the specified codec being decoded. The child content the decimal number of RTP sessions being encoded using the
element, <encoding>, represents the number of RTP sessions for the specified codec.
specified codec being encoded.
5.1.4.4. <active-mixer-sessions> 5.1.4.4. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element MAY be present. the current active mixed RTP sessions. The element MAY be present.
The <active-mixer-sessions> element has no attributes. The content of an <active-mixer-sessions> element has no attributes.
The <active-mixer-sessions> element has the following child element: The content of an <active-mixer-sessions> element has zero or more of
the following child elements:
active-mix: Is a container which represents a mixed active RTP active-mix: Describes a mixed active RTP session. The <active-mix>
session. The <active-mix> element has one attribute. The element has one attribute. The value of the attribute
attribute 'conferenceid' represents the name of the mix being 'conferenceid' is the name of the mix. The <active-mix> element
represented. The <active-mix> element has one child element. The has one child element. The child element, <rtp-codec>, contains
child element, <rtp-codec>, contains the same information relating the same information relating to RTP sessions as defined in
to RTP sessions as defined in Section 5.1.4.3. The element MAY be Section 5.1.4.3. The element MAY be present.
present.
5.1.4.5. <non-active-rtp-sessions> 5.1.4.5. <non-active-rtp-sessions>
The <non-active-rtp-sessions> element provides information detailing The <non-active-rtp-sessions> element provides information detailing
the currently available inactive RTP sessions. The element MAY be the currently available inactive RTP sessions. The element MAY be
present. present.
The <non-active-rtp-sessions> element has no attributes. The content of a <non-active-rtp-sessions> element has no attributes.
The <non-active-rtp-sessions> element has the following child The content of a <non-active-rtp-sessions> element has zero or more
element: of the following child elements:
rtp-codec: Is a container which represents a supported codec and rtp-codec: Describes a supported codec and the number of non-active
the inactive sessions. The <rtp-codec> element has one attribute. sessions for that codec. The <rtp-codec> element has one
The attribute 'name' represents the name of the codec being attribute. The value of the attribute 'name' is a MIME media type
represented. A valid value is a MIME media type which, depending (which can include parameters per [RFC4281]). The <rtp-codec>
on its definition, can include additional parameters (e.g., element has two child elements. The child element, <decoding>,
[RFC4281]). The <rtp-codec> element has two child elements. The has as content the decimal number of RTP sessions available for
first child element, <decoding>, represents the number of decoding using the specified codec. The child element,
available incoming (decoding) RTP session for the specified codec. <encoding>, has as content the decimal number of RTP sessions
The second child element, <encoding>, represents the number of available for encoding using the specified codec.
available outgoing (encoding) RTP sessions for the specified
codec. The element MAY be present.
5.1.4.6. <non-active-mixer-sessions> 5.1.4.6. <non-active-mixer-sessions>
The <non-active-mixer-sessions> element provides information The <non-active-mixer-sessions> element provides information
detailing the current inactive mixed RTP sessions. The element MAY detailing the current inactive mixed RTP sessions. The element MAY
be present. be present.
The <non-active-rtp-sessions> element has no attributes. The content of an <non-active-rtp-sessions> element has no
attributes.
The <non-active-mixer-sessions> element has the following child The content of an <non-active-mixer-sessions> element has zero of
element: more of the following child element:
non-active-mix: Is a container which representing an available non-active-mix: Describes available mixed RTP sessions. The <non-
mixed RTP session. The <non-active-mix> element has one active-mix> element has one attribute. The value of the attribute
attribute. The attribute 'available' represents the number of 'available' is the number of mixes that could be used using that
mixes that could be used using that profile. The <non-active-mix> profile. The <non-active-mix> element has one child element. The
element has one child element. The child element, <rtp-codec>, child element, <rtp-codec>, contains the same information relating
contains the same information relating to RTP sessions as defined to RTP sessions as defined in Section 5.1.4.5. The element MAY be
in Section 5.1.4.5. The element MAY be present. present.
5.1.4.7. <media-server-status> 5.1.4.7. <media-server-status>
The <media-server-status> element provides information detailing the The <media-server-status> element provides information detailing the
current status of the media server. The element MUST be present. It current status of the media server. The element MUST be present. It
can return one of the following values: can return one of the following values:
active: Indicating that the Media Server is available for service. active: Indicating that the Media Server is available for service.
deactivated: Indicating that the Media Server has been withdrawn deactivated: Indicating that the Media Server has been withdrawn
from service, and as such should not be contacted before it from service, and as such should not be contacted before it
becomes 'active' again. becomes 'active' again.
unavailable: Indicating that the Media Server continues to process unavailable: Indicating that the Media Server continues to process
past requests but cannot accept new requests, and as such should past requests but cannot accept new requests, and as such should
not be contacted before it becomes 'active' again. not be contacted before it becomes 'active' again.
The <media-server-status> element has no attributes. The content of a <media-server-status> element has no attributes.
The <media-server-status> element has no child elements. The content of a <media-server-status> element has no child elements.
5.1.4.8. <supported-codecs> 5.1.4.8. <supported-codecs>
The <supported-codecs> element provides information detailing the The <supported-codecs> element provides information detailing the
current codecs supported by a media server and associated actions. current codecs supported by a media server and associated actions.
The element MAY be present. The element MAY be present.
The <supported-codecs> element has no attributes. The content of a <supported-codecs> element has no attributes.
The <supported-codecs> element has the following child element: The content of a <supported-codecs> element has zero or more of the
following child element:
supported-codec: has a single attribute, 'name', which provides the supported-codec: has a single attribute, 'name', which provides the
name of the codec providing information. A valid value is a MIME name of the codec providing information. A valid value is a MIME
media type which, depending on its definition, can include media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-codec> additional parameters (e.g., [RFC4281]). The <supported-codec>
element then has a further child element, <supported-codec- element then has a further child element, <supported-codec-
package>. The <supported-codec-package> element has a single package>. The <supported-codec-package> element has a single
attribute, 'name', which provides the name of the Media Control attribute, 'name', which provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), for which the codec related IANA registry (e.g., "msc-ivr/1.0"), for which the codec
skipping to change at page 22, line 45 skipping to change at page 23, line 4
attribute, 'name', which provides the name of the Media Control attribute, 'name', which provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), for which the codec related IANA registry (e.g., "msc-ivr/1.0"), for which the codec
support applies. The <supported-codec-package> element has one support applies. The <supported-codec-package> element has one
further child element, <supported-actions>, which provide the further child element, <supported-actions>, which provide the
actions that a Media Server can apply to this codec: actions that a Media Server can apply to this codec:
* 'decode', meaning a decoder for this codec is available; * 'decode', meaning a decoder for this codec is available;
* 'encode', meaning an encoder for this codec is available; * 'encode', meaning an encoder for this codec is available;
* 'passthrough', meaning the MS is able to pass a stream encoded * 'passthrough', meaning the MS is able to pass a stream encoded
using that codec through without re-encoding. using that codec through without re-encoding.
5.1.4.9. <application-data> 5.1.4.9. <application-data>
The <application-data> element provides arbitrary application level The <application-data> element provides arbitrary application level
data. This data is meant to only have meaning at the application data. This data is meant to only have meaning at the application
level logic and as such is arbitrary. The element MAY be present. level logic and as such is arbitrary. The element MAY be present.
The <application-data> element has no attributes. The content of an <application-data> element has no attributes.
The <application-data> element has no child elements. The content of an <application-data> element has no child elements.
5.1.4.10. <file-formats> 5.1.4.10. <file-formats>
The <file-formats> element provides a list of file formats supported The <file-formats> element provides a list of file formats supported
for the purpose of playing media. The element MAY be present. for the purpose of playing media. The element MAY be present.
The <file-formats> element has no attributes. The content of a <file-formats> element has no attributes.
The <file-formats> element has the following child element: The content of a <file-formats> element has zero of more the
following child elements:
supported-format: has a single attribute, 'name', which provides supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. A valid value is a the type of file format that is supported. A valid value is a
MIME media type which, depending on its definition, can include MIME media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-format> additional parameters (e.g., [RFC4281]). The <supported-format>
element then has a further child element, <supported-file- element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package, compliant with the of the Media Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.1.4.11. <max-prepared-duration> 5.1.4.11. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time a The <max-prepared-duration> element provides the amount of time a
media dialog can be prepared in the system before it is executed. media dialog can be prepared in the system before it is executed.
The element MAY be present. The element MAY be present.
The <max-prepared-duration> element has no attributes. The content of a <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element: The content of a <max-prepared-duration> element has zero or more of
the following child elements:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the time period applies. (e.g., "msc-ivr/1.0"), for which the time period applies.
5.1.4.12. <dtmf-support> 5.1.4.12. <dtmf-support>
The <dtmf-support> element supplies the supported methods to detect The <dtmf-support> element supplies the supported methods to detect
DTMF tones and to generate them. The element MAY be present. DTMF tones and to generate them. The element MAY be present.
The <dtmf-support> element has no attributes. The content of a <dtmf-support> element has no attributes.
The <dtmf-support> element has the following child elements: The content of a <dtmf-support> element has zero of more of the
following child elements:
detect: Indicates the support for DTMF detection. The <detect> detect: Indicates the support for DTMF detection. The <detect>
element has no attributes. The <detect> element then has a element has no attributes. The <detect> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used, and it can only be either provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
skipping to change at page 25, line 5 skipping to change at page 25, line 12
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies. (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.1.4.13. <mixing-modes> 5.1.4.13. <mixing-modes>
The <mixing-modes> element provides information about the support for The <mixing-modes> element provides information about the support for
audio and video mixing of a Media Server, specifically a list of audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video supported algorithms to mix audio and a list of supported video
presentation layouts. The element MAY be present. presentation layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The content of a <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements: The content of a <mixing-modes> element has zero or more of the
following child elements:
audio-mixing-modes: Is a container representing the available audio-mixing-modes: Describes the available algorithms for audio
algorithms for audio mixing. The <audio-mixing-modes> element has mixing. The <audio-mixing-modes> element has no attributes. The
no attributes. The <audio-mixing-modes> element has one child <audio-mixing-modes> element has one child element. The child
element. The child element, <audio-mixing-mode>, contains a element, <audio-mixing-mode>, contains a specific available
specific available algorithm. It has a single attribute, algorithm. It has a single attribute, 'package'. The attribute
'package'. The attribute 'package' provides the name of the Media 'package' provides the name of the Media Control Channel Framework
Control Channel Framework package, compliant with the package, compliant with the specification in the related IANA
specification in the related IANA registry (e.g., "msc-ivr/1.0"), registry (e.g., "msc-ivr/1.0"), for which the algorithm support
for which the algorithm support applies. applies.
video-mixing-modes: Is a container representing the available video video-mixing-modes: Describes the available video presentation
presentation layouts and the supported functionality for what layouts and the supported functionality for what concerns video
concerns video mixing. The <video-mixing-modes> element has two mixing. The <video-mixing-modes> element has two attributes,
attributes, 'vas' and 'activespeakermix'. The 'vas' attribute is 'vas' and 'activespeakermix'. The 'vas' attribute is of type
of type boolean with a value of 'true' indicating the Media Server boolean with a value of 'true' indicating the Media Server
supports automatic Voice Activated Switching. The supports automatic Voice Activated Switching. The
'activespeakermix' is of type boolean with a value of 'true' 'activespeakermix' is of type boolean with a value of 'true'
indicating that the Media Server is able to prepare an additional indicating that the Media Server is able to prepare an additional
video stream for the loudest speaker participant without its video stream for the loudest speaker participant without its
contribution. The <video-mixing-modes> element has one child contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains the element. The child element, <video-mixing-mode>, contains the
name of a specific video presentation layout. The name may refer name of a specific video presentation layout. The name may refer
to one of predefined video layouts defined in the XCON conference to one of predefined video layouts defined in the XCON conference
information data model, or to non-XCON layouts as well, as long as information data model, or to non-XCON layouts as well, as long as
they are properly prefixed. The <video-mixing-mode> element has a they are properly prefixed. The <video-mixing-mode> element has a
skipping to change at page 25, line 45 skipping to change at page 26, line 4
name of the Media Control Channel Framework package, compliant name of the Media Control Channel Framework package, compliant
with the specification in the related IANA registry (e.g., "msc- with the specification in the related IANA registry (e.g., "msc-
ivr/1.0"), for which the algorithm support applies. ivr/1.0"), for which the algorithm support applies.
5.1.4.14. <supported-tones> 5.1.4.14. <supported-tones>
The <supported-tones> element provides information about which tones The <supported-tones> element provides information about which tones
a media server supports. In particular, the support is reported a media server supports. In particular, the support is reported
referring to both country codes support (ISO 3166-1 [ISO.3166-1]) and referring to both country codes support (ISO 3166-1 [ISO.3166-1]) and
supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).
The element MAY be present. The element MAY be present.
The <supported-tones> element has no attributes. The content of a <supported-tones> element has no attributes.
The <supported-tones> element has the following child elements: The content of a <supported-tones> element has zero or more of the
following child elements:
supported-country-codes: Is a container representing the supported supported-country-codes: Describes the supported country codes with
country codes with respect to tones. The <supported-country- respect to tones. The <supported-country-codes> element has no
codes> element has no attributes. The <supported-country-codes> attributes. The <supported-country-codes> has one child element.
has one child element. The child element, <country-code>, reports The child element, <country-code>, reports support for a specific
support for a specific country code, compliant with the ISO 3166-1 country code, compliant with the ISO 3166-1 [ISO.3166-1]
[ISO.3166-1] specification. The <country-code> element has a specification. The <country-code> element has a single attribute,
single attribute, 'package'. The attribute 'package' provides the 'package'. The attribute 'package' provides the name of the Media
name of the Media Control Channel Framework package, compliant Control Channel Framework package, compliant with the
with the specification in the related IANA registry (e.g., "msc- specification in the related IANA registry (e.g., "msc-ivr/1.0"),
ivr/1.0"), in which the tones from the specified country code are in which the tones from the specified country code are supported.
supported.
supported-h248-codes: Is a container representing the supported supported-h248-codes: Describes the supported H.248 codes with
H.248 codes with respect to tones. The <supported-h248-codes> respect to tones. The <supported-h248-codes> element has no
element has no attributes. The <supported-h248-codes> has one attributes. The <supported-h248-codes> has one child element.
child element. The child element, <h248-code>, reports support The child element, <h248-code>, reports support for a specific
for a specific H.248 code, compliant with the ITU-T Recommendation H.248 code, compliant with the ITU-T Recommendation Q.1950
Q.1950 [ITU-T.Q.1950] specification. The codes can be either [ITU-T.Q.1950] specification. The codes can be either specific
specific (e.g., cg/dt to only report the Dial Tone from the Call (e.g., cg/dt to only report the Dial Tone from the Call Progress
Progress Tones package) or generic (e.g., cg/* to report all the Tones package) or generic (e.g., cg/* to report all the tones from
tones from the Call Progress Tones package) using wildcards. The the Call Progress Tones package) using wild-cards. The <h248-
<h248-code> element has a single attribute, 'package'. The code> element has a single attribute, 'package'. The attribute
attribute 'package' provides the name of the Media Control Channel 'package' provides the name of the Media Control Channel Framework
Framework package, compliant with the specification in the related package, compliant with the specification in the related IANA
IANA registry (e.g., "msc-ivr/1.0"), in which the specified codes registry (e.g., "msc-ivr/1.0"), in which the specified codes are
are supported. supported.
5.1.4.15. <streaming-modes> 5.1.4.15. <streaming-modes>
The <streaming-modes> element allows the Media Server to specify The <streaming-modes> element allows the Media Server to specify
which protocols are supported for streaming to a Media Server for which protocols are supported for streaming to a Media Server for
each Media Control Channel Framework package type. For example, each Media Control Channel Framework package type. For example,
whether the Media Server supports audio streaming via RTSP, HTTP, whether the Media Server supports audio streaming via RTSP, HTTP,
NFS, etc protocols. The element MAY be present. NFS, etc protocols. The element MAY be present.
The <streaming-modes> element has no attributes. The content of a <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child element: The content of a <streaming-modes> element has zero or more of the
following child element:
stream-mode: has two attributes, 'name' and 'package'. The 'name' stream-mode: has two attributes, 'name' and 'package'. The 'name'
attribute provides the type of protocol that can be used for attribute provides the type of protocol that can be used for
streaming (e.g., "HTTP", "RTSP", etc.). The 'package' attribute streaming (e.g., "HTTP", "RTSP", etc.). The 'package' attribute
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the streaming protocol applies. (e.g., "msc-ivr/1.0"), for which the streaming protocol applies.
5.1.4.16. <asr-tts-support> 5.1.4.16. <asr-tts-support>
The <asr-tts-support> element provides information about the support The <asr-tts-support> element provides information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality are reported by functionality in a media server. The functionality are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988] referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The element MAY be codes) for what regards both ASR and TTS. The element MAY be
present. present.
The <asr-tts-support> element has no attributes. The content of an <asr-tts-support> element has no attributes.
The <asr-tts-support> element has the following child elements: The content of an <asr-tts-support> element has zero or more of the
following child elements:
asr-support: Is a container representing the available languages asr-support: Describes the available languages for ASR. The <asr-
for ASR. The <asr-support> element has no attributes. The <asr- support> element has no attributes. The <asr-support> has one
support> has one child element. The child element, <language>, child element. The child element, <language>, reports the MS
reports the MS supports ASR for a specific language. The supports ASR for a specific language. The <language> element has
<language> element has a single attribute, 'xml:lang'. The a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of the ISO-639-1 [ISO.639.1988] code of the supported language.
the supported language.
tts-support: Is a container representing the available languages tts-support: Describes the available languages for TTS. The <tts-
for TTS. The <tts-support> element has no attributes. The <tts- support> element has no attributes. The <tts-support> has one
support> has one child element. The child element, <language>, child element. The child element, <language>, reports the MS
reports the MS supports tts for a specific language. The supports tts for a specific language. The <language> element has
<language> element has a single attribute, 'xml:lang'. The a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of the ISO-639-1 [ISO.639.1988] code of the supported language.
the supported language.
5.1.4.17. <vxml-support> 5.1.4.17. <vxml-support>
The <vxml-support> element specifies if the Media Server supports The <vxml-support> element specifies if the Media Server supports
VoiceXML and if it does which protocols the support is exposed VoiceXML and if it does which protocols the support is exposed
through (e.g., via the control framework, RFC4240 [RFC4240], or through (e.g., via the control framework, RFC4240 [RFC4240], or
RFC5552 [RFC5552]). The element MAY be present. RFC5552 [RFC5552]). The element MAY be present.
The <vxml-support> element has a single attribute 'support'. The The content of a <vxml-support> element has a single attribute
'support' attribute is of type boolean with a value of 'true' 'support'. The 'support' attribute is of type boolean with a value
indicating that the media server does support VXML, and a value of of 'true' indicating that the media server does support VXML, and a
'false' indicating it does not support VXML. The default value is value of 'false' indicating it does not support VXML. The default
'false'. value is 'false'.
The <vxml-support> element has the following child element: The content of a <vxml-support> element has the following child
element:
vxml-mode: has two attributes, 'package' and 'support'. The vxml-mode: has two attributes, 'package' and 'support'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'support' attribute provides the type of VXML applies. The 'support' attribute provides the type of VXML
support provided by the Media Server (RFC5552 [RFC5552], RFC4240 support provided by the Media Server (RFC5552 [RFC5552], RFC4240
[RFC4240] or IVR-Package [RFC4240] or IVR-Package
[I-D.ietf-mediactrl-ivr-control-package]). [I-D.ietf-mediactrl-ivr-control-package]).
5.1.4.18. <media-server-location> 5.1.4.18. <media-server-location>
The <media-server-location> element provides information about the The <media-server-location> element provides information about the
civic location of a media server. Its description makes use of the civic location of a media server. Its description makes use of the
Civic Address Schema standardized in RFC 5139 [RFC5139]. The element Civic Address Schema standardized in RFC 5139 [RFC5139]. The element
MAY be present. MAY be present.
The <media-server-location> element has no attributes. The content of a <media-server-location> element has no attributes.
The <media-server-location> element one child element: The content of a <media-server-location> element has zero or more of
the following child elements:
civicAddress: Is a container representing the civic address civicAddress: Describes the civic address location of the media
location of the media server, whose representation refers to the server, whose representation refers to the Section 4 of RFC 5139
Section 4 of RFC 5139 [RFC5139]. [RFC5139].
5.1.4.19. <label> 5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the information that will be understood by the MRB. For example, the
Media Server can declare if it's a blue or green one. It's a string 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 to allow arbitrary values to be returned to allow arbitrary
classification, and as such is not meant to provide any explicit classification, and as such is not meant to provide any explicit
information associated with the features of a MS. The element MAY be information associated with the features of a MS. The element MAY be
present. present.
The <label> element has no attributes. The content of a <label> element has no attributes.
The <label> element has no child elements. The content of a <label> element has no child elements.
5.1.4.20. <media-server-address> 5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct SIP URI address where it can be reached (e.g., the URI AS 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 would call to in order to set-up a Control Channel and relay call
legs). The element MAY be present. legs). The element MAY be present.
The <media-server-address> element has a single attribute. The <media-server-address> element has a single attribute.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.4.21. <encryption> 5.1.4.21. <encryption>
The <encyption> element allows a Media Server to declare support for The <encryption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. A value of encrypting RTP media streams using RFC 3711 [RFC3711]. A value of
'true' indicates that a Media Server does support RFC 3711 [RFC3711] 'true' indicates that a Media Server does support RFC 3711 [RFC3711]
for RTP. A value of 'false' indicates that a Media Server does not for RTP. A value of 'false' indicates that a Media Server does not
support RFC 3711 [RFC3711] for RTP. The element MAY be present. support RFC 3711 [RFC3711] for RTP. The element MAY be present.
The <encryption> element has no attributes. The content of an <encryption> element has no attributes.
The <encryption> element has no child elements. The content of an <encryption> element has no child elements.
5.1.5. <mrbresponse> 5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <response> element from
Section 10. Section 10.
The <response> element has following attributes: The content of a <response> element has the following attributes:
status: numeric code indicating the response status. The attribute status: numeric code indicating the response status. The attribute
MUST be present. MUST be present.
reason: string specifying a reason for the response status. The reason: string specifying a reason for the response status. The
attribute MAY be present. attribute MAY be present.
The following status codes are defined for 'status': The following status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
skipping to change at page 31, line 32 skipping to change at page 32, line 6
MRB. The following description will describe the use of HTTP MRB. The following description will describe the use of HTTP
[RFC2616] and HTTPS [RFC2818] as transport for a query for media [RFC2616] and HTTPS [RFC2818] as transport for a query for media
resource and the appropriate response. resource and the appropriate response.
The media resource query, as defined by the <mediaResourceRequest> The media resource query, as defined by the <mediaResourceRequest>
element from Section 11, MUST be carried in the body of an HTTP/HTTPS element from Section 11, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
the 'mediaResourceRequest' element as defined in Section 11. The the 'mediaResourceRequest' element as defined in Section 11.
'mediaResourceRequest' element is the primary container of 'mediaResourceRequest' is the primary element describing information
information related to a media resource request. related to a media resource request.
The media resource response to a query, as defined by the The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 11, MUST be carried in <mediaResourceResponse> element from Section 11, MUST be carried in
the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
the 'mediaResourceResponse' element as defined in Section 11. The the 'mediaResourceResponse' element as defined in Section 11.
'mediaResourceResponse' element is the primary container of 'mediaResourceResponse' is the primary element describing information
information related to a media resource response. related to a media resource response.
When an application server wants to release previously awarded media When an application server wants to release previously awarded media
resources granted through a prior request/response exchange with MRB, resources granted through a prior request/response exchange with MRB,
it will send a new request with an <action> element with value it will send a new request with an <action> element with value
'remove' as described in Section Section 5.2.3 about the use of the 'remove' as described in Section Section 5.2.3 about the use of the
Consumer interface lease mechanism. Consumer interface lease mechanism.
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage
This document provides a complete toolkit for MRB deployment which This document provides a complete tool-kit for MRB deployment which
includes the ability to interact with an MRB using SIP for the includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary Consumer interface. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of SIP MRB. The following description will describe the use of SIP
[RFC3261] as transport for a request for media resources and the [RFC3261] as transport for a request for media resources and the
appropriate response when used with IAMM of operation (as discussed appropriate response when used with IAMM of operation (as discussed
in Section 5.2.2.1). in Section 5.2.2.1).
Use of IAMM, besides having the MRB select an appropriate media Use of IAMM, besides having the MRB select an appropriate media
resource on behalf of a client application, includes setting up resource on behalf of a client application, includes setting up
skipping to change at page 34, line 41 skipping to change at page 35, line 18
MRB has of the resources of all the MS it handles is imperfect. As 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 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 implemented: one may choose to have the MRB keeping track and state
of the allocated resources, or simply depend on the MS themselves to of the allocated resources, or simply depend on the MS themselves to
provide the information by means of the publishing interface provide the information by means of the publishing interface
notifications. Further information may be inferred by the notifications. Further information may be inferred by the
signalling, in case the MRB is in the path of call legs. signalling, in case the MRB is in the path of call legs.
That said, the <mediaResourceResponse> element returned from the MRB That said, the <mediaResourceResponse> element returned from the MRB
contains a <response-session-info> element if the request is contains a <response-session-info> element if the request is
successful. The <response-session-info> element has the following successful. The content of a <response-session-info> element has
child elements which provide the appropriate resource session zero or more of the following child elements which provide the
information: appropriate resource session information:
o <session-id> is a unique identifier that enables a Consumer client o <session-id> is a unique identifier that enables a Consumer client
and MRB to correlate future media resource requests related to an and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included initial media resource request. The <session-id> MUST be included
in all future related requests (see <session-id> use later in this in all future related requests (see <session-id> use later in this
section when constructing a subsequent request). section when constructing a subsequent request).
o <seq> is a numeric value returned to the Consumer client. On o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client (as determined by the <session-id> element) the consumer client
MUST increment the value returned in the <seq> element and include MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when in the request (see <seq> use later in this section when
constructing a subsequent request). constructing a subsequent request).
o <expires> provides a value which represents the number of seconds o <expires> provides a value which provides the number of seconds
the request for media resources is deemed alive. The Consumer the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later 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 in this section, if the expires timer is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides information representing the o <media-server-address> provides information representing the
assigned MS. assigned MS.
The <mediaResourceRequest> element is used in subsequent Consumer The <mediaResourceRequest> element is used in subsequent Consumer
interface requests if the client wishes to manipulate the session. interface requests if the client wishes to manipulate the session.
skipping to change at page 37, line 7 skipping to change at page 37, line 30
This section defines the XML elements for the Consumer interface. This section defines the XML elements for the Consumer interface.
The formal XML schema definition for the Consumer interface can be The formal XML schema definition for the Consumer interface can be
found in Section 11. found in Section 11.
The root element is <mrbconsumer>. All other XML elements (requests, The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface responses) are contained within it. The MRB Consumer interface
request element is detailed in Section 5.2.4.1. MRB Consumer request element is detailed in Section 5.2.4.1. MRB Consumer
interface response element is contained in Section 5.2.5.1. interface response element is contained in Section 5.2.5.1.
The <mrbconsumer> element has the following attributes: The content of an <mrbconsumer> element has the following attributes:
version: a token specifying the mrb-consumer package version. The version: a token specifying the mrb-consumer package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The <mrbconsumer> element has the following child elements, only one The content of an <mrbconsumer> element has zero or more of the
of which is allowed to occur. following child elements, only one of which is allowed to occur.
<mediaResourceRequest> for sending a Consumer request. See <mediaResourceRequest> for sending a Consumer request. See
Section 5.2.4.1. Section 5.2.4.1.
<mediaResourceResponse> for sending a Consumer response. See <mediaResourceResponse> for sending a Consumer response. See
Section 5.2.5.1. Section 5.2.5.1.
5.2.4.1. <mediaResourceRequest> element 5.2.4.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides a container for clients The <mediaResourceRequest> element provides information for clients
wishing to query an external MRB entity. The <mediaResourceRequest> wishing to query an external MRB entity. The <mediaResourceRequest>
element has <generalInfo>, <ivrInfo> and <mixerInfo> as child element has <generalInfo>, <ivrInfo> and <mixerInfo> as child
elements. These three elements are used to describe the requirements elements. These three elements are used to describe the requirements
of a client requesting a Media Server and are covered in the of a client requesting a Media Server and are covered in the
following sub-sections. following sub-sections.
5.2.4.1.1. <generalInfo> element 5.2.4.1.1. <generalInfo> element
The <generalInfo> element provides a container for general Consumer The <generalInfo> element provides a information for general Consumer
request information that is neither IVR or Mixer specific. This request information that is neither IVR or Mixer specific. This
includes session information that can be used for subsequent requests includes session information that can be used for subsequent requests
as part of the leasing mechanism described in Section 5.2.3. The as part of the leasing mechanism described in Section 5.2.3. The
following sub-sections describe the elements of the <generalInfo> following sub-sections describe the elements of the <generalInfo>
element, <session-info> and <packages>. element, <session-info> and <packages>.
5.2.4.1.1.1. <session-info> element 5.2.4.1.1.1. <session-info> element
The <session-info> element is included in Consumer requests when an The <session-info> element is included in Consumer requests when an
update is being made to an existing media resource session. The update is being made to an existing media resource session. The
ability to change and remove an existing media resource session is ability to change and remove an existing media resource session is
described in more detail in Section 5.2.3. The element MAY be described in more detail in Section 5.2.3. The element MAY be
present. present.
The <session-info> element has no attributes. The content of the <session-info> element has no attributes.
The <session-info> element has the following child elements: The content of the <session-info> element has zero or more of the
following child elements:
session-id: is a unique identifier that explicitly references an session-id: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
skipping to change at page 38, line 33 skipping to change at page 39, line 11
* The value of 'remove' instructs the MRB to attempt to remove * The value of 'remove' instructs the MRB to attempt to remove
the existing media resource session. More information on its the existing media resource session. More information on its
use is provided in Section 5.2.3. use is provided in Section 5.2.3.
5.2.4.1.1.2. <packages> element 5.2.4.1.1.2. <packages> element
The <packages> element provides a list of Media Control Channel The <packages> element provides a list of Media Control Channel
Framework compliant packages that are required by the Consumer Framework compliant packages that are required by the Consumer
client. The element MAY be present. client. The element MAY be present.
The <packages> element has no attributes. The content of a <packages> element has no attributes.
The <packages> element has the following child element: The content of a <packages> element has zero or more of the following
child element:
package: child element contains a string representing the Media package: child element contains a string representing the Media
Control Channel Framework package required by the Consumer client. Control Channel Framework package required by the Consumer client.
The <package> element can appear multiple times. A valid value is The <package> element can appear multiple times. A valid value is
a Control Package name as specified in the related IANA registry a Control Package name as specified in the related IANA registry
(e.g., "msc-ivr/1.0") (e.g., "msc-ivr/1.0")
5.2.4.1.2. <ivrInfo> element 5.2.4.1.2. <ivrInfo> element
The <ivrInfo> element provides a container for general Consumer The <ivrInfo> element provides information for general Consumer
request information that is IVR specific. The following sub-sections request information that is IVR specific. The following sub-sections
describe the elements of the <ivrInfo> element, <ivr-sessions>, describe the elements of the <ivrInfo> element, <ivr-sessions>,
<file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>,
<encryption>, <application-data>, <max-prepared-duration> and <encryption>, <application-data>, <max-prepared-duration> and
<stream-mode>. <stream-mode>.
5.2.4.1.2.1. <ivr-sessions> element 5.2.4.1.2.1. <ivr-sessions> element
The <ivr-sessions> element indicates the number of IVR sessions a The <ivr-sessions> element indicates the number of IVR sessions a
Consumer client requires from a media resource. The element MAY be Consumer client requires from a media resource. The element MAY be
present. present.
The <ivr-sessions> element has no attributes. The content of an <ivr-sessions> element has no attributes.
The <ivr-sessions> element has the following child element: The content of an <ivr-sessions> element has zero or more of the
following child element:
rtp-codec: child element contains has a single attribute, 'name'. rtp-codec: Describes a required codec and the number of sessions
The 'name' attribute provides the name of the codec required for using that codec. The <rtp-codec> element has one attribute. The
an IVR session and is an appropriately registered token. A valid value of the attribute 'name' is a MIME media type (which can
value is a MIME media type which, depending on its definition, can include parameters per [RFC4281]). The <rtp-codec> element has
include additional parameters (e.g., [RFC4281]). The <rtp-codec> two child elements. The child element, <decoding>, has as content
element has two child elements. The child element, <decoding>, the decimal number of RTP sessions required for decoding using the
represents the number of RTP sessions for which decoding using the specified codec. The child element, <encoding>, has as content
specified codec is requested. The child element, <encoding>, the decimal number of RTP sessions required for encoding using the
represents the number of RTP sessions for which encoding using the specified codec.
specified codec is requested.
5.2.4.1.2.2. <file-formats> element 5.2.4.1.2.2. <file-formats> element
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
for the purpose of playing media. The element MAY be present. for the purpose of playing media. The element MAY be present.
The <file-formats> element has no attributes. The content of a <file-formats> element has no attributes.
The <file-formats> element has the following child element: The content of a <file-formats> element has zero or more of the
following child element:
required-format: has a single attribute, 'name', which provides the required-format: has a single attribute, 'name', which provides the
type of file format that is required. A valid value is a MIME type of file format that is required. A valid value is a MIME
media type which, depending on its definition, can include media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-format> additional parameters (e.g., [RFC4281]). The <supported-format>
element then has a further child element, <required-file-package>. element then has a further child element, <required-file-package>.
The <required-file-package> element provides the name of the Media The <required-file-package> element provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.2.4.1.2.3. <dtmf> element 5.2.4.1.2.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones The <dtmf> element supplies the required methods to detect DTMF tones
and to generate them. The element MAY be present. and to generate them. The element MAY be present.
The <dtmf> element has no attributes. The content of a <dtmf> element has no attributes.
The <dtmf> element has the following child elements: The content of a <dtmf> element has zero or more of the following
child elements:
detect: Indicates the required support for DTMF detection. The detect: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element then has <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being needed, and it can only be either provides the type of DTMF being needed, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
skipping to change at page 40, line 46 skipping to change at page 41, line 27
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies. registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.2.4.1.2.4. <tones> 5.2.4.1.2.4. <tones>
The <tones> element provides requested tones a media server must The <tones> element provides requested tones a media server must
support for IVR. In particular, the request refers to both country support for IVR. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The <tones> element has no attributes. The content of a <tones> element has no attributes.
The <tones> element has the following child elements: The content of a <tones> element has zero or more of the following
child elements:
country-codes: Is a container representing the requested country country-codes: Describes the requested country codes with respect
codes with respect to tones. The <country-codes> element has no to tones. The <country-codes> element has no attributes. The
attributes. The <country-codes> has one child element. The child <country-codes> has one child element. The child element,
element, <country-code>, requests a specific country code, <country-code>, requests a specific country code, compliant with
compliant with the ISO 3166-1 [ISO.3166-1] specification. The the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
<country-code> element has a single attribute, 'package'. The element has a single attribute, 'package'. The attribute
attribute 'package' provides the name of the Media Control Channel 'package' provides the name of the Media Control Channel Framework
Framework package, compliant with the specification in the related package, compliant with the specification in the related IANA
IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
h248-codes: Is a container representing the requested H.248 codes h248-codes: Describes the requested H.248 codes with respect to
with respect to tones. The <h248-codes> element has no tones. The <h248-codes> element has no attributes. The <h248-
attributes. The <h248-codes> has one child element. The child codes> has one child element. The child element, <h248-code>,
element, <h248-code>, requests a specific H.248 code, compliant requests a specific H.248 code, compliant with the ITU-T
with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
The codes can be either specific (e.g., cg/dt to only report the be either specific (e.g., cg/dt to only report the Dial Tone from
Dial Tone from the Call Progress Tones package) or generic (e.g., the Call Progress Tones package) or generic (e.g., cg/* to report
cg/* to report all the tones from the Call Progress Tones package) all the tones from the Call Progress Tones package) using wild-
using wildcards. The <h248-code> element has a single attribute, cards. The <h248-code> element has a single attribute, 'package'.
'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package, compliant with the The attribute 'package' provides the name of the Media Control
specification in the related IANA registry (e.g., "msc-ivr/1.0"), Channel Framework package, compliant with the specification in the
in which the specified codes are requested. related IANA registry (e.g., "msc-ivr/1.0"), in which the
specified codes are requested.
5.2.4.1.2.5. <asr-tts> 5.2.4.1.2.5. <asr-tts>
The <asr-tts-support> element requests information about the support The <asr-tts-support> element requests information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality is requested by functionality in a media server. The functionality is requested by
referring to the supported languages (using ISO-639-1 [ISO.639.1988] referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The <asr-tts-support> codes) for what regards both ASR and TTS. The content of an <asr-
element has no attributes. The <asr-tts-support> element has the tts-support> element has no attributes. The content of an <asr-tts-
following child elements: support> element has zero or more of the following child elements:
asr-support: Is a container representing the available languages asr-support: Describes the available languages for ASR. The <asr-
for ASR. The <asr-support> element has no attributes. The <asr- support> element has no attributes. The <asr-support> has one
support> has one child element. The child element, <language>, child element. The child element, <language>, requests the MS
requests the MS supports ASR for a specific language. The supports ASR for a specific language. The <language> element has
<language> element has a single attribute, 'xml:lang'. The a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of the ISO-639-1 [ISO.639.1988] code of the supported language.
the supported language.
tts-support: Is a container requesting the available languages for tts-support: Describes the available languages for TTS. The <tts-
TTS. The <tts-support> element has no attributes. The <tts- support> element has no attributes. The <tts-support> has one
support> has one child element. The child element, <language>, child element. The child element, <language>, requests the MS
requests the MS supports tts for a specific language. The supports tts for a specific language. The <language> element has
<language> element has a single attribute, 'xml:lang'. The a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of the ISO-639-1 [ISO.639.1988] code of the supported language.
the supported language.
5.2.4.1.2.6. <vxml> element 5.2.4.1.2.6. <vxml> element
The <vxml> element specifies if the Consumer client required VoiceXML The <vxml> element specifies if the Consumer client required VoiceXML
and if it does which protocols the support is exposed through (e.g., and if it does which protocols the support is exposed through (e.g.,
via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]). via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]).
The element MAY be present. The element MAY be present.
The <vxml> element has a single attribute 'support'. The 'support' The content of a <vxml> element has a single attribute 'support'.
attribute is of type boolean with a value of 'true' indicating that The 'support' attribute is of type boolean with a value of 'true'
the Consumer client requires VXML support, and a value of 'false' indicating that the Consumer client requires VXML support, and a
indicating it does not require VXML support. The default value is value of 'false' indicating it does not require VXML support. The
'false'. default value is 'false'.
The <vxml> element has the following child element: The content of a <vxml> element has zero or more of the following
child elements:
vxml-mode: has two attributes, 'package' and 'require'. The vxml-mode: has two attributes, 'package' and 'require'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'require' attribute specifies the type of VXML applies. The 'require' attribute specifies the type of VXML
support required by the Consumer client (RFC5552 [RFC5552], support required by the Consumer client (RFC5552 [RFC5552],
RFC4240 [RFC4240] or IVR-Package RFC4240 [RFC4240] or IVR-Package
[I-D.ietf-mediactrl-ivr-control-package]). [I-D.ietf-mediactrl-ivr-control-package]).
5.2.4.1.2.7. <location> 5.2.4.1.2.7. <location>
The <location> element requests a civic location for an IVR media The <location> element requests a civic location for an IVR media
server. The request makes use of the Civic Address Schema server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element MAY be present. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The <location> element has no attributes. The content of the <location> element has no attributes.
The <location> element one child element: The content of the <location> element consists of a single child
element:
civicAddress: Is a container representing the civic address civicAddress: Describes the civic address location of the requested
location of the requested media server, whose representation media server, whose representation refers to Section 4 of RFC 5139
refers to Section 4 of RFC 5139 [RFC5139]. [RFC5139].
5.2.4.1.2.8. <encryption> 5.2.4.1.2.8. <encryption>
The <encryption> element allows a Consumer client to request support The <encryption> element allows a Consumer client to request support
for encrypting RTP media streams using RFC 3711 [RFC3711]. A value for encrypting RTP media streams using RFC 3711 [RFC3711]. A value
of 'true' indicates that Consumer client requires support of RFC 3711 of 'true' indicates that Consumer client requires support of RFC 3711
[RFC3711] for RTP. A value of 'false' indicates that a Consumer [RFC3711] for RTP. A value of 'false' indicates that a Consumer
client does not require support of RFC 3711 [RFC3711] for RTP. The client does not require support of RFC 3711 [RFC3711] for RTP. The
element MAY be present. The default value is 'false' element MAY be present. The default value is 'false'
The <encryption> element has no attributes. The content of an <encryption> element has no attributes.
The <encryption> element has no child elements. The content of an <encryption> element has no child elements.
5.2.4.1.2.9. <application-data> 5.2.4.1.2.9. <application-data>
The <application-data> element provides IVR application level data. The <application-data> element provides IVR application level data.
The element MAY be present. The element MAY be present.
The <application-data> element has no attributes. The content of an <application-data> element has no attributes.
The <application-data> element has no child elements. The content of an <application-data> element has no child elements.
5.2.4.1.2.10. <max-prepared-duration> 5.2.4.1.2.10. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time The <max-prepared-duration> element provides the amount of time
required by the Consumer client that a media dialog can be prepared required by the Consumer client that a media dialog can be prepared
in the system before it is executed. The element MAY be present. in the system before it is executed. The element MAY be present.
The <max-prepared-duration> element has no attributes. The content of a <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element: The content of a <max-prepared-duration> element has a single child
element:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the time period applies. (e.g., "msc-ivr/1.0"), for which the time period applies.
5.2.4.1.2.11. <streaming-modes> 5.2.4.1.2.11. <streaming-modes>
The <streaming-modes> element allows the Consumer client to specify The <streaming-modes> element allows the Consumer client to specify
which protocols are required for streaming to a Media Server for each which protocols are required for streaming to a Media Server for each
Media Control Channel Framework package type. For example does the Media Control Channel Framework package type. For example does the
Media Server supports audio streaming via RTSP, HTTP, NFS, etc Media Server supports audio streaming via RTSP, HTTP, NFS, etc
protocols. The element MAY be present. protocols. The element MAY be present.
The <streaming-modes> element has no attributes. The content of a <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child element: The content of a <streaming-modes> element has a single child
element:
stream-mode: has two attributes, 'name' and 'package'. The 'name' stream-mode: has two attributes, 'name' and 'package'. The 'name'
attribute provides the type of protocol required for streaming. attribute provides the type of protocol required for streaming.
The 'package' attribute provides the name of the Media Control The 'package' attribute provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), for which the related IANA registry (e.g., "msc-ivr/1.0"), for which the
streaming protocol applies. streaming protocol applies.
5.2.4.1.3. <mixerInfo> element 5.2.4.1.3. <mixerInfo> element
The <mixerInfo> element provides a container for general Consumer The <mixerInfo> element provides information for general Consumer
request information that is Mixer specific. The following sub- request information that is Mixer specific. The following sub-
sections describe the elements of the <mixerInfo> element, <mixers>, sections describe the elements of the <mixerInfo> element, <mixers>,
<file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application- <file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application-
data>, <location> and <encryption>. data>, <location> and <encryption>.
5.2.4.1.3.1. <mixers> 5.2.4.1.3.1. <mixers>
The <mixers> element provides information detailing the required The <mixers> element provides information detailing the required
mixed RTP sessions. The element MAY be present. mixed RTP sessions. The element MAY be present.
The <mixers> element has no attributes. The content of a <mixers> element has no attributes.
The <mixers> element has the following child element: The content of a <mixers> element has a single child element:
mix: Is a container which represents a required mixed RTP session. mix: Describes required mixed RTP sessions. The <mix> element has
The <mix> element has one attribute. The attribute 'users' one attribute. The value of the attribute 'users' is the number
represents the number of participants required in the mix. The of participants required in the mix. The <mix> element has one
<mix> element has one child element. The child element, <rtp- child element. The child element, <rtp-codec>, contains the same
codec>, contains the same information relating to RTP sessions as information relating to RTP sessions as defined in
defined in Section 5.1.4.3. The element MAY be present. Section 5.1.4.3. The element MAY be present.
5.2.4.1.3.2. <file-formats> 5.2.4.1.3.2. <file-formats>
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
by the Consumer client for the purpose of playing media to a mix. by the Consumer client for the purpose of playing media to a mix.
The element MAY be present. The element MAY be present.
The <file-formats> element has no attributes. The content of a <file-formats> element has no attributes.
The <file-formats> element has the following child element: The content of a <file-formats> element has a single child element:
required-format: has a single attribute, 'name', which provides the required-format: has a single attribute, 'name', which provides the
type of file format that is supported. A valid value is a MIME type of file format that is supported. A valid value is a MIME
media type which, depending on its definition, can include media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <required-format> additional parameters (e.g., [RFC4281]). The <required-format>
element then has a further child element, <required-file-package>. element then has a further child element, <required-file-package>.
The <required-file-package> element provides the name of the Media The <required-file-package> element provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.2.4.1.3.3. <dtmf> element 5.2.4.1.3.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones The <dtmf> element supplies the required methods to detect DTMF tones
and to generate them in a mix. The element MAY be present. and to generate them in a mix. The element MAY be present.
The <dtmf> element has no attributes. The content of a <dtmf> element has no attributes.
The <dtmf> element has the following child elements: The content of a <dtmf> element has zero or more of the following
child elements:
detect: Indicates the required support for DTMF detection. The detect: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element then has <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used, and it can only be either provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
skipping to change at page 46, line 13 skipping to change at page 46, line 46
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies. registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.2.4.1.3.4. <tones> 5.2.4.1.3.4. <tones>
The <tones> element provides requested tones a media server must The <tones> element provides requested tones a media server must
support for a mix. In particular, the request refers to both country support for a mix. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The <tones> element has no attributes. The content of a <tones> element has no attributes.
The <tones> element has the following child elements: The content of a <tones> element has zero or more of the following
child elements:
country-codes: Is a container representing the requested country country-codes: Describes the requested country codes with respect
codes with respect to tones. The <country-codes> element has no to tones. The <country-codes> element has no attributes. The
attributes. The <country-codes> has one child element. The child <country-codes> has one child element. The child element,
element, <country-code>, requests a specific country code, <country-code>, requests a specific country code, compliant with
compliant with the ISO 3166-1 [ISO.3166-1] specification. The the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
<country-code> element has a single attribute, 'package'. The element has a single attribute, 'package'. The attribute
attribute 'package' provides the name of the Media Control Channel 'package' provides the name of the Media Control Channel Framework
Framework package, compliant with the specification in the related package, compliant with the specification in the related IANA
IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
h248-codes: Is a container representing the requested H.248 codes h248-codes: Describes the requested H.248 codes with respect to
with respect to tones. The <h248-codes> element has no tones. The <h248-codes> element has no attributes. The <h248-
attributes. The <h248-codes> has one child element. The child codes> has one child element. The child element, <h248-code>,
element, <h248-code>, requests a specific H.248 code, compliant requests a specific H.248 code, compliant with the ITU-T
with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
The codes can be either specific (e.g., cg/dt to only report the be either specific (e.g., cg/dt to only report the Dial Tone from
Dial Tone from the Call Progress Tones package) or generic (e.g., the Call Progress Tones package) or generic (e.g., cg/* to report
cg/* to report all the tones from the Call Progress Tones package) all the tones from the Call Progress Tones package) using wild-
using wildcards. The <h248-code> element has a single attribute, cards. The <h248-code> element has a single attribute, 'package'.
'package'. The attribute 'package' provides the name of the Media The attribute 'package' provides the name of the Media Control
Control Channel Framework package, compliant with the Channel Framework package, compliant with the specification in the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), related IANA registry (e.g., "msc-ivr/1.0"), in which the
in which the specified codes are requested. specified codes are requested.
5.2.4.1.3.5. <mixing-modes> 5.2.4.1.3.5. <mixing-modes>
The <mixing-modes> element requests information about the support for The <mixing-modes> element requests information about the support for
audio and video mixing of a Media Server, specifically a list of audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video supported algorithms to mix audio and a list of supported video
presentation layouts. The element MAY be present. presentation layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The content of a <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements: The content of a <mixing-modes> element has zero or more of the
following child elements:
audio-mixing-modes: Is a container representing the requested audio-mixing-modes: Describes the requested algorithms for audio
algorithms for audio mixing. The <audio-mixing-modes> element has mixing. The <audio-mixing-modes> element has no attributes. The
no attributes. The <audio-mixing-modes> element has one child <audio-mixing-modes> element has one child element. The child
element. The child element, <audio-mixing-mode>, contains a element, <audio-mixing-mode>, contains a specific requested
specific requested algorithm. It has a single attribute, algorithm. It has a single attribute, 'package'. The attribute
'package'. The attribute 'package' provides the name of the Media 'package' provides the name of the Media Control Channel Framework
Control Channel Framework package, compliant with the package, compliant with the specification in the related IANA
specification in the related IANA registry (e.g., "msc-ivr/1.0"), registry (e.g., "msc-ivr/1.0"), for which the algorithm support is
for which the algorithm support is requested. requested.
video-mixing-modes: Is a container representing the requested video video-mixing-modes: Describes the requested video presentation
presentation layouts for video mixing. The <video-mixing-modes> layouts for video mixing. The <video-mixing-modes> element has
element has two attributes, 'vas' and 'activespeakermix'. The two attributes, 'vas' and 'activespeakermix'. The 'vas' attribute
'vas' attribute is of type boolean with a value of 'true' is of type boolean with a value of 'true' indicating that the
indicating that the Consumer Client requires automatic Voice Consumer Client requires automatic Voice Activated Switching. The
Activated Switching. The 'activespeakermix' attribute is of type 'activespeakermix' attribute is of type boolean with a value of
boolean with a value of 'true' indicating that the Consumer Client 'true' indicating that the Consumer Client requires an additional
requires an additional video stream for the loudest speaker video stream for the loudest speaker participant without its
participant without its contribution. The <video-mixing-modes> contribution. The <video-mixing-modes> element has one child
element has one child element. The child element, <video-mixing- element. The child element, <video-mixing-mode>, contains the
mode>, contains the name of a specific video presentation layout. name of a specific video presentation layout. The name may refer
The name may refer to one of predefined video layouts defined in to one of predefined video layouts defined in the XCON conference
the XCON conference information data model, or to non-XCON layouts information data model, or to non-XCON layouts as well, as long as
as well, as long as they are properly prefixed. The <video- they are properly prefixed. The <video-mixing-mode> element has a
mixing-mode> element has a single attribute, 'package'. The single attribute, 'package'. The attribute 'package' provides the
attribute 'package' provides the name of the Media Control Channel name of the Media Control Channel Framework package, compliant
Framework package, compliant with the specification in the related with the specification in the related IANA registry (e.g., "msc-
IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm ivr/1.0"), for which the algorithm support is requested.
support is requested.
5.2.4.1.3.6. <application-data> 5.2.4.1.3.6. <application-data>
The <application-data> element provides application level data. The The <application-data> element provides application level data. The
element MAY be present. element MAY be present.
The <application-data> element has no attributes. The contents of an <application-data> element has no attributes.
The <application-data> element has no child elements. The contents of an <application-data> element has no child elements.
5.2.4.1.3.7. <location> 5.2.4.1.3.7. <location>
The <location> element requests a civic location for a mixer media The <location> element requests a civic location for a mixer media
server. The request makes use of the Civic Address Schema server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element MAY be present. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The <location> element has no attributes. The contents of a <location> element has no attributes.
The <location> element one child element: The contents of a <location> element has a single child element:
civicAddress: Is a container representing the civic address civicAddress: Describes the civic address location of the requested
location of the requested media server, whose representation media server, whose representation refers to Section 4 of RFC 5139
refers to Section 4 of RFC 5139 [RFC5139]. [RFC5139].
5.2.4.1.3.8. <encryption> 5.2.4.1.3.8. <encryption>
The <encryption> element allows a Consumer client to request support The <encryption> element allows a Consumer client to request support
for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. A for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. A
value of 'true' indicates that Consumer client requires support of value of 'true' indicates that Consumer client requires support of
RFC 3711 [RFC3711] for RTP. A value of 'false' indicates that a RFC 3711 [RFC3711] for RTP. A value of 'false' indicates that a
Consumer client does not require support of RFC 3711 [RFC3711] for Consumer client does not require support of RFC 3711 [RFC3711] for
RTP. The element MAY be present. The default value is 'false' RTP. The element MAY be present. The default value is 'false'
The <encryption> element has no attributes. The contents of an <encryption> element has no attributes.
The <application-data> element has no child elements. The contents of an <application-data> element has no child elements.
5.2.5. Media Service Resource Response 5.2.5. Media Service Resource Response
This section provides the element definitions for use in Consumer This section provides the element definitions for use in Consumer
interface responses. The responses are carried in the interface responses. The responses are carried in the
<mediaResourceResponse> container element. <mediaResourceResponse> element.
5.2.5.1. <mediaResourceResponse> element 5.2.5.1. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a container for clients The <mediaResourceResponse> element provides a information for
receiving response information from an external MRB entity. clients receiving response information from an external MRB entity.
The <mediaResourceResponse> element has a single attribute 'status' The <mediaResourceResponse> element has a single attribute 'status'
which indicates the status code of the operation. The following which indicates the status code of the operation. The following
status codes are defined for 'status': status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | | | | |
skipping to change at page 49, line 15 skipping to change at page 50, line 5
In case a new media resource request made by an AS (no action) has In case a new media resource request made by an AS (no action) has
been accepted, the MRB MUST reply with a <mediaResourceResponse> with been accepted, the MRB MUST reply with a <mediaResourceResponse> with
status code 200. The same rule applies whenever a request to update status code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction (action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MRB. can be fulfilled by the MRB.
A media resource request, nevertheless, may fail for several reasons. A media resource request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used In such a case, the status codes defined in Table 1 must be used
instead. Specifically, if the MRB fails to handle a request due to a 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 syntax error in the request itself (e.g., incorrect XML, violation of
the schema constraints or invalid values in any of the attributes/ the schema constraints or invalid values in any of the attributes/
elements) the MRB MUST reply with a <mediaResourceResponse> with elements) the MRB MUST reply with a <mediaResourceResponse> with
status code 400. If a syntactically correct request fails because status code 400. If a syntactically correct request fails because
the request also includes any attribute/element the MRB doesn't the request also includes any attribute/element the MRB doesn't
understand, the MRB MUST reply with a <mediaResourceResponse> with understand, the MRB MUST reply with a <mediaResourceResponse> with
status code 420. If a syntactically correct request fails because status code 420. If a syntactically correct request fails because
the MRB couldn't find any MS able to fulfil the requirements 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 presented by the AS in its request, the MRB MUST reply with a
<mediaResourceResponse> with status code 408. If a syntactically <mediaResourceResponse> with status code 408. If a syntactically
correct request fails because the MRB couldn't update an existing correct request fails because the MRB couldn't update an existing
skipping to change at page 50, line 5 skipping to change at page 50, line 43
The <response-session-info> element is included in Consumer The <response-session-info> element is included in Consumer
responses. This applies to responses to both requests for new responses. This applies to responses to both requests for new
resources and requests to update an existing media resource session. resources and requests to update an existing media resource session.
The ability to change and remove an existing media resource session The ability to change and remove an existing media resource session
is described in more detail in Section 5.2.3. The element MAY be is described in more detail in Section 5.2.3. The element MAY be
present: specifically, the element MUST be included in case the present: specifically, the element MUST be included in case the
request was successful, while it would not appear otherwise (e.g., in request was successful, while it would not appear otherwise (e.g., in
case the request ended up with an error). case the request ended up with an error).
The <response-session-info> element has no attributes. The contents of a <response-session-info> element has no attributes.
The <response-session-info> element has the following child elements: The contents of a <response-session-info> element has zero or more of
the following child elements:
session-id: is a unique identifier that explicitly references an session-id: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3. More information its use is provided in Section 5.2.3.
expires: includes the number of seconds that the media resources expires: includes the number of seconds that the media resources
are reserved as part of this interaction. If the lease is not are reserved as part of this interaction. If the lease is not
refreshed before expiry, the MRB will re-claim the resources and refreshed before expiry, the MRB will re-claim the resources and
they will no longer be guaranteed. It is RECOMMENDED that a they will no longer be guaranteed. It is RECOMMENDED that a
minimum value of 300 seconds be used for the value of the minimum value of 300 seconds be used for the value of the
'expires' attribute. It is also RECOMMENDED that a Consumer 'expires' attribute. It is also RECOMMENDED that a Consumer
client refresh the lease at an interval that is not too close to 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 the expiry time. A value of 80% of the time-out period could be
used. For example, if the timeout period is 300 seconds, the used. For example, if the time-out period is 300 seconds, the
Server would refresh the transaction at 240 seconds. More Server would refresh the transaction at 240 seconds. More
information on its use is provided in Section 5.2.3. information on its use is provided in Section 5.2.3.
media-server-address: provides information to reach the MS handling media-server-address: provides information to reach the MS handling
the requested media resource. The <media-server-address> element the requested media resource. The <media-server-address> element
has a single attribute named 'uri' which supplies the direct has a single attribute named 'uri' which supplies the direct
address to a media server. It also has three optional elements address to a media server. It also has three optional elements
<connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions> <connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions>
and <mixers> are defined in Section 5.2.4.1.2.1 and and <mixers> are defined in Section 5.2.4.1.2.1 and
Section 5.2.4.1.3.1 and have the same meaning but are applied to Section 5.2.4.1.3.1 and have the same meaning but are applied to
skipping to change at page 52, line 24 skipping to change at page 53, line 24
'Appendix: Common Package Components' of Media Control Channel 'Appendix: Common Package Components' of Media Control Channel
Framework[I-D.ietf-mediactrl-sip-control-framework] uses a Framework[I-D.ietf-mediactrl-sip-control-framework] uses a
concatenation of the SIP dialog identifiers to be used for concatenation of the SIP dialog identifiers to be used for
referencing SIP dialogs within the media control channel. When a referencing SIP dialogs within the media control channel. When a
request traverses an MRB acting as a B2BUA, the SIP dialog request traverses an MRB acting as a B2BUA, the SIP dialog
identifiers change and so the 'connectionid' can not be used as identifiers change and so the 'connectionid' can not be used as
intended due to the SIP dialog identifiers changing. For this reason intended due to the SIP dialog identifiers changing. For this reason
when a MRB wishes to act as a SIP B2BUA when handling a request from when a MRB wishes to act as a SIP B2BUA when handling a request from
an AS to set up a call leg to a MS it MUST include the optional an AS to set up a call leg to a MS it MUST include the optional
<connection-id> element in a Consumer interface response with a value <connection-id> element in a Consumer interface response with a value
that represents the equivalent for the 'connectionid' ('Local Dialog that provides the equivalent for the 'connectionid' ('Local Dialog
Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If
present, this value MUST be used as the value for the 'connectionid' present, this value MUST be used as the value for the 'connectionid'
in packages where the Common Package Components are used. The in packages where the Common Package Components are used. The
<connection-id> element MUST not be included in a HTTP Consumer <connection-id> element MUST not be included in a HTTP Consumer
interface response. interface response.
7. Multi-modal MRB Implementations 7. Multi-modal MRB Implementations
An MRB implementation may operate multi-modally with a collection of An MRB implementation may operate multi-modally with a collection of
application server clients all sharing the same pool of media application server clients all sharing the same pool of media
skipping to change at page 72, line 34 skipping to change at page 73, line 34
been chosen, the MRB sends a new SIP INVITE to one of the MS by just been chosen, the MRB sends a new SIP INVITE to one of the MS by just
including the SDP part of the original request (5.). The MS including the SDP part of the original request (5.). The MS
negotiates this INVITE as specified in negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (6., 7., 8.) to allocate [I-D.ietf-mediactrl-sip-control-framework] (6., 7., 8.) to allocate
the needed media resources to handle the new call leg, eventually the needed media resources to handle the new call leg, eventually
providing the MRB with its own media-related SDP. The MRB replies to providing the MRB with its own media-related SDP. The MRB replies to
the original AS INVITE preparing a SIP 200 OK with another multipart the original AS INVITE preparing a SIP 200 OK with another multipart
body (9.): this multipart body includes the Consumer response from body (9.): this multipart body includes the Consumer response from
the MRB indicating the chosen MS and the SDP returned by the MS in 7. the MRB indicating the chosen MS and the SDP returned by the MS in 7.
The AS finally acknowledges the 200 OK (10.), and ends the scenario The AS finally acknowledges the 200 OK (10.), and ends the scenario
by eventually providing the UAC with the SDP it needs to setup the by eventually providing the UAC with the SDP it needs to set-up the
RTP channels with the chosen MS: a separate direct SIP control dialog RTP channels with the chosen MS: a separate direct SIP control dialog
may be initiated by the AS to the same MS in order to set up a may be initiated by the AS to the same MS in order to set up a
control channel to manipulate the call leg media. control channel to manipulate the call leg media.
As with the IAMM - CFW example in the prior section, this example has As with the IAMM - CFW example in the prior section, this example has
the MRB selecting MS resources across two MS instances. And here the MRB selecting MS resources across two MS instances. And here
again the convention can be that the MRB sent the SIP INVITE to the again the convention can be that the MRB sent the SIP INVITE to the
first MS in the list provided to the AS in the Consumer response first MS in the list provided to the AS in the Consumer response
information. information.
skipping to change at page 74, line 46 skipping to change at page 75, line 46
only the media-related SDP from the original INVITE; only the media-related SDP from the original INVITE;
4. the 200 OK sent by the MS back to the MRB (7.), to complete the 4. the 200 OK sent by the MS back to the MRB (7.), to complete the
media-related negotiation (SDP only); media-related negotiation (SDP only);
5. the 200 OK sent by the MRB back to the AS in response to the 5. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (9.), containing both the media-related original INVITE (9.), containing both the media-related
information sent by the MS and a Consumer <mediaResourceRequest> information sent by the MS and a Consumer <mediaResourceRequest>
documenting the MRB's decision to use that MS; documenting the MRB's decision to use that MS;
6. the 200 OK sent by the AS back to the UAC to have it setup the 6. the 200 OK sent by the AS back to the UAC to have it set-up the
RTP channel(s) with the MS (11.). RTP channel(s) with the MS (11.).
1. UAC -> AS (INVITE with media SDP) 1. UAC -> AS (INVITE with media SDP)
------------------------------------ ------------------------------------
[..] [..]
From: <sip:lminiero@users.example.com>;tag=1153573888 From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 129, line 9 skipping to change at page 130, line 9
Filename: mbr-consumer Filename: mbr-consumer
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document. Schema: The XML for the schema is in Section 11 of this document.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 08 Version 14.1. Changes from 09 Version
o Language changes as a result of Shepherd review.
14.2. Changes from 08 Version
o Fixed Nits. o Fixed Nits.
o Added range for reporting period - as per mailing list. o Added range for reporting period - as per mailing list.
14.2. Changes from 07 Version 14.3. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences; incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests; o Corrected examples after validation tests;
o Fixed a few typos in the text. o Fixed a few typos in the text.
o Clarified language in various places. o Clarified language in various places.
skipping to change at page 129, line 40 skipping to change at page 130, line 44
o Clarifying text related to IAMM and IUMM. o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow o Expanded media-server-address for extra information and to allow
multiples. multiples.
o New B2BUA section. o New B2BUA section.
o Updated Examples. o Updated Examples.
14.3. Changes from 06 Version 14.4. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp- o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed. codec> instances, where needed.
o Fixed a few typos in the text. o Fixed a few typos in the text.
14.4. Changes from 05 Version 14.5. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined o Clarifier that video layouts may refer to either XCON-defined
layouts or others. layouts or others.
o Added RFC4240 as an option for VXML support. o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas. o Fixed a few typos in the text and in the schemas.
14.5. Changes from 04 Version 14.6. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions. 'response-session-info' definitions.
o Clarified that 'response-session-info' is not only included in o Clarified that 'response-session-info' is not only included in
reply to updates, but also to new requests; besides, clarified reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any in successful responses (200), while not needed otherwise (any
error). error).
o Corrected the Query example flow which included a 'session'info' o Corrected the Query example flow which included a 'session'info'
in a new request. in a new request.
14.6. Changes from 03 Version 14.7. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell. o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits). o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version). Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are o Clarified that backslashes and XML indentation in the Examples are
only provided for readability. only provided for readability.
skipping to change at page 130, line 48 skipping to change at page 132, line 5
responses, in order to clarify when they are involved. responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the o Added some text to better clarify the role of leasing in the
Consumer interface. Consumer interface.
o Added additional IANA considerations, that were missing in the o Added additional IANA considerations, that were missing in the
previous versions of the document. previous versions of the document.
o Added text to the security considerations. o Added text to the security considerations.
14.7. Changes from 02 Version 14.8. Changes from 02 Version
o Added examples in Section 9. o Added examples in Section 9.
o Fixed some nits in the schemas (encryption and required mixed=true o Fixed some nits in the schemas (encryption and required mixed=true
elements). elements).
o Completed review nit review comments from Gary Munson. o Completed review nit review comments from Gary Munson.
14.8. Changes from 01 Version 14.9. Changes from 01 Version
o Added description of lease mechanism. o Added description of lease mechanism.
o Added specific HTTP and SIP usage of Consumer interface. o Added specific HTTP and SIP usage of Consumer interface.
o Completed Publish interface schema + associated text. o Completed Publish interface schema + associated text.
o Included Consumer interface schema + associated text. o Included Consumer interface schema + associated text.
o Included supported-packages element. o Included supported-packages element.
skipping to change at page 131, line 32 skipping to change at page 132, line 36
o Removed announce-var element from doc. o Removed announce-var element from doc.
o Expanded Abstract. o Expanded Abstract.
o General scrub of text - input from Simon Romano. o General scrub of text - input from Simon Romano.
o Added IANA Considerations section. o Added IANA Considerations section.
o Added Security Considerations section. o Added Security Considerations section.
14.9. Changes from 00 Version 14.10. Changes from 00 Version
o Included In-line text based on strawman proposal. o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team o Included first attempt at publish interface based on design team
work. work.
15. Acknowledgments 15. Acknowledgements
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
design team consisted of Adnan Saleem, Michael Trank, Victor design team consisted of Adnan Saleem, Michael Trank, Victor
Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also
like to thank John Dally, Bob Epley, Simon Romano, Henry Lum, like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
Christian Groves and Jonathan Lennox for input into this Christian Groves and Jonathan Lennox for input into this
specification. specification.
Ben Campbell carried out the RAI expert review on this specification Ben Campbell carried out the RAI expert review on this specification
skipping to change at page 134, line 23 skipping to change at page 135, line 23
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H.
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Gudgin, M., Moreau, J., Hadley, M., and H. Mendelsohn, N., Hadley, M., Moreau, J., Gudgin, M., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-mediactrl-ivr-control-package] [I-D.ietf-mediactrl-ivr-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "An McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the Interactive Voice Response (IVR) Control Package for the
 End of changes. 164 change blocks. 
405 lines changed or deleted 431 lines changed or added

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