draft-ietf-mediactrl-mrb-03.txt   draft-ietf-mediactrl-mrb-04.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: August 14, 2010 University of Napoli Expires: October 1, 2010 University of Napoli
February 10, 2010 March 30, 2010
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-03 draft-ietf-mediactrl-mrb-04
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 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2010. This Internet-Draft will expire on October 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 17 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . 16 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 18 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 27 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 28
5.2. Media Service Resource Consumer Interface . . . . . . . . 27 5.2. Media Service Resource Consumer Interface . . . . . . . . 30
5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 28 5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 30
5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . 28 5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . 31
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 30 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 32
5.2.4. Media Service Resource Request . . . . . . . . . . . 32 5.2.4. Media Service Resource Request . . . . . . . . . . . 35
5.2.5. Media Service Resource Response . . . . . . . . . . . 42 5.2.5. Media Service Resource Response . . . . . . . . . . . 46
5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 44 5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 48
5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . 44 5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . 48
5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . 44 5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . 49
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 46 6.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 51
6.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 51 6.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 51 6.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 57
6.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 54 6.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 59
7. Media Service Resource Publisher Interface XML Schema . . . . 60 7. Media Service Resource Publisher Interface XML Schema . . . . 66
8. Media Service Resource Consumer Interface XML Schema . . . . 82 8. Media Service Resource Consumer Interface XML Schema . . . . 88
9. Security Considerations . . . . . . . . . . . . . . . . . . . 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 109
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110
10.1. application/mrb-publish+xml MIME Type . . . . . . . . . . 104 10.1. Control Package Registration . . . . . . . . . . . . . . 110
10.2. application/mrb-consumer+xml MIME Type . . . . . . . . . 105 10.2. application/mrb-publish+xml MIME Type . . . . . . . . . . 110
11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 10.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 111
11.1. Changes from 02 Version . . . . . . . . . . . . . . . . . 106 10.4. URN Sub-Namespace Registration for mrb-publish . . . . . 112
11.2. Changes from 01 Version . . . . . . . . . . . . . . . . . 106 10.5. URN Sub-Namespace Registration for mrb-consumer . . . . . 112
11.3. Changes from 00 Version . . . . . . . . . . . . . . . . . 106 10.6. XML Schema Registration for mrb-publish . . . . . . . . . 112
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 10.7. XML Schema Registration for mrb-consumer . . . . . . . . 112
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
13.1. Normative References . . . . . . . . . . . . . . . . . . 108 11.1. Changes from 03 Version . . . . . . . . . . . . . . . . . 114
13.2. Informative References . . . . . . . . . . . . . . . . . 109 11.2. Changes from 02 Version . . . . . . . . . . . . . . . . . 114
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 11.3. Changes from 01 Version . . . . . . . . . . . . . . . . . 114
11.4. Changes from 00 Version . . . . . . . . . . . . . . . . . 115
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 116
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.1. Normative References . . . . . . . . . . . . . . . . . . 117
13.2. Informative References . . . . . . . . . . . . . . . . . 118
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
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 7, line 10 skipping to change at page 7, line 10
all of the previously described deployment models. It is also all of the previously described deployment models. It is also
recognised that the solution is far more relevant to some of the recognised that the solution is far more relevant to some of the
previously discussed deployment models and can almost be viewed as previously discussed deployment models and can almost be viewed as
redundant on others. redundant on others.
2. Conventions and Terminology 2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for "OPTIONAL".
compliant implementations.
This document inherits terminology proposed in RFC 5567 [RFC5567] and This document inherits terminology proposed in RFC 5567 [RFC5567] and
Media Control Channel Framework Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] documents. In addition, [I-D.ietf-mediactrl-sip-control-framework] documents. In addition,
the following terms are defined for use in this document and for use the following terms are defined for use in this document and for use
in the context of the MediaCtrl Work group in the IETF: in the context of the MediaCtrl Work group in the IETF:
Media Resource Broker (MRB) A logical entity that is responsible for Media Resource Broker (MRB): A logical entity that is responsible
both collection of appropriate published Media Server (MS) for both collection of appropriate published Media Server (MS)
information and selecting appropriate MS resources on behalf of information and selecting appropriate MS resources on behalf of
consuming entities. consuming entities.
Query MRB An instantiation of an MRB (See previous definition) that Query MRB: An instantiation of an MRB (See previous definition)
provides an interface for an Application Server to retrieve the that provides an interface for an Application Server to retrieve
address of an appropriate Media Server. The result returned to the address of an appropriate Media Server. The result returned
the Application Server can be influenced by information contained to the Application Server can be influenced by information
in the query request. contained in the query request.
In-line MRB An instantiation of an MRB (See definition) that In-line MRB: An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. There is no directly receives requests on the signalling path. There is no
separate query. separate query.
Within the context of In-line MRBs, additional terms are defined:
In-line Aware MRB Mode (IAMM): Defined in Section 5.3.2.
In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.1.
The document will often specify when a specific identifier in a
protocol message needs to be unique. Unless differently stated, such
uniqueness will always need to be intended within the scope of the
Media Servers controlled by the same Media Resource Broker. The
interaction among different Media Resource Brokers, as the
partitioning of a logical Media Resource Broker, is out of scope to
this document.
3. Problem Discussion 3. Problem Discussion
It is clear from Section 1 that the MediaCtrl group will be producing As anticipated in Section 1, the main aim of the MediaCtrl group is
a solution that must service a wide variety of deployment to produce a solution that must service a wide variety of deployment
architectures. These range from the simplest 1:1 relationship architectures. These range from the simplest 1:1 relationship
between Media Servers and Application Servers to potentially linearly between Media Servers and Application Servers to potentially linearly
scaling 1:M, M:1 and M:N deployments. scaling 1:M, M:1 and M:N deployments.
This still does not seem like a major issue for the proposed solution This still does not seem like a major issue for the proposed solution
until you add a number of additional factors into the equation that until you add a number of additional factors into the equation that
increase complexity. As Media Servers evolve it must be taken into increase complexity. As Media Servers evolve it must be taken into
consideration that, where many can exist in a deployment, they may consideration that, where many can exist in a deployment, they may
not have been produced by the same vendor and may not have the same not have been produced by the same vendor and may not have the same
capability set. It should be possible for an Application Server that capability set. It should be possible for an Application Server that
skipping to change at page 8, line 32 skipping to change at page 8, line 32
ability to select an appropriate Media Service function is an ability to select an appropriate Media Service function is an
extremely useful feature but becomes even more powerful when extremely useful feature but becomes even more powerful when
considered with available resources for servicing a request. considered with available resources for servicing a request.
In conclusion, the intention is to create a tool set that allows In conclusion, the intention is to create a tool set that allows
MediaCtrl deployments to effectively utilize the available media MediaCtrl deployments to effectively utilize the available media
resources. It should be noted that in the simplest deployments where resources. It should be noted that in the simplest deployments where
only a single media server exists, an MRB function is probably not only a single media server exists, an MRB function is probably not
required. Only a single capability set exists and resource required. Only a single capability set exists and resource
unavailability can be handled using the appropriate underlying unavailability can be handled using the appropriate underlying
signalling e.g. SIP response. This document does not prohibit such signalling, e.g., SIP response. This document does not prohibit such
uses of an MRB, it simply provides the tools for various entities to uses of an MRB, it simply provides the tools for various entities to
interact where appropriate. It is also worth noting that the tools interact where appropriate. It is also worth noting that the tools
provided in this document aim to provide a 'best effort' view of provided in this document aim to provide a 'best effort' view of
media resources at the time of request for initial Media Server media resources at the time of request for initial Media Server
routing decisions. Any dramatic change in media capabilities after a routing decisions. Any dramatic change in media capabilities after a
request has taken place should be handled by the underlying protocol. request has taken place should be handled by the underlying protocol.
Please note that there may be additional information that it is Please note that there may be additional information that it is
desirable for the MRB to have for purposes of selecting an MS desirable for the MRB to have for purposes of selecting an MS
resource, such as resource allocation rules across different resource, such as resource allocation rules across different
skipping to change at page 14, line 28 skipping to change at page 14, line 28
construct an MRB. This includes interpreting the data for the Media construct an MRB. This includes interpreting the data for the Media
Service Consumer interface supplied by the Media Server Publish Service Consumer interface supplied by the Media Server Publish
interface. It is, however, important that the two interfaces are interface. It is, however, important that the two interfaces are
complimentary so that development of appropriate MRB functionality is complimentary so that development of appropriate MRB functionality is
supported. supported.
5.1. Media Server Resource Publish Interface 5.1. Media Server Resource Publish Interface
The Media Server Resource Publish interface is responsible for The Media Server Resource Publish interface is responsible for
providing an MRB with appropriate Media Server resource information. providing an MRB with appropriate Media Server resource information.
It is generally accepted that this interface provides both general As such, this interface is assumed to provide both general and
and specific details related to Media Server resources. This specific details related to Media Server resources. This information
information needs to be conveyed using an industry standard mechanism needs to be conveyed using an industry standard mechanism to provide
to provide increased levels of adoption and interoperability. A increased levels of adoption and interoperability. A Control Package
Control Package for the Media Control Channel Framework will be for the Media Control Channel Framework will be specified to fulfil
specified to fulfil this interface requirement. It provides the this interface requirement. It provides an establishment and
perfect establishment and monitoring mechanism to enable a Media monitoring mechanism to enable a Media Server to report appropriate
Server to report appropriate statistics to an MRB. The Publish statistics to an MRB. The Publish interface is used with both Query
interface is used with both Query and In-line modes of MRB operation. and In-line modes of MRB operation.
As already anticipated in the introduction, the MRB view of MS As already anticipated in the introduction, the MRB view of MS
resource availability will in practice be approximate - i.e., partial resource availability will in practice be approximate - i.e., partial
and imperfect. The MRB Publish interface does not provide an and imperfect. The MRB Publish interface does not provide an
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 and Publish interface to MRB. Nevertheless, despite such limitations it
with the aid of good engineering the MRB can still perform its is assumed that the provided information is enough to allow MRB
function well. implementors 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 9 for more details. See Section 9 for more details.
The MRB Publish interface uses the Media Control Channel Framework The MRB Publish interface uses the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]) as the basis for ([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
interaction between a Media Server and an MRB. The Media Control interaction between a Media Server and an MRB. The Media Control
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
be queried for publishing information.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
This section fulfils the mandatory requirement for information that This section fulfills 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 13 skipping to change at page 17, line 20
Section 7. Section 7.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The <mrbpublish> element has the following attributes: The <mrbpublish> element has the following attributes:
Version: a token specifying the mrb-publish package version. The version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute is mandatory. attribute MUST be present.
The <mrbpublish> element has the following child element, only one of The <mrbpublish> element has the following child element, only one of
which is allowed to occur in a request. 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.
skipping to change at page 17, line 46 skipping to change at page 18, line 4
defined in the remainder of this section: defined in the remainder of this section:
<subscription> for initiating a subscription to a Media Server <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1. from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of Media Server to provide the details relating to the configuration of
updates. 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 are sent using the frequency that updates should be sent. Updates related to the
<mrbnotification> element. subscription are sent using the <mrbnotification> element.
The <subscription> element has the following attributes: The <subscription> element has the following attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the subscription session
MRB and the Media Server. The attribute is mandatory. between the MRB and the Media Server. 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 session id to identify a specific subscription command. with the subscrition session id to identify a specific
The attribute is mandatory. subscription command. The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present.
action: provides the operation that should be carried out on the action: provides the operation that should be carried out on the
subscription. The value of 'create' instructs the MS to attempt subscription:
to setup a new subscription. The value of 'update' instructs the
MS to attempt to update an existing subscription. The value of * The value of 'create' instructs the MS to attempt to setup a
'remove' instructs the MS to attempt to remove an existing new subscription.
subscription and consequently stop any ongoing related
notification. The attribute is mandatory. * The value of 'update' instructs the MS to attempt to update an
existing subscription.
* The value of 'remove' instructs the MS to attempt to remove an
existing subscription and consequently stop any ongoing related
notification.
The attribute MUST be present.
The <subscription> element has the following child elements: The <subscription> element has the following child elements:
expires: Provides the amount of time in seconds that a subscription expires: Provides the amount of time in seconds that a subscription
should be installed for notifications at the Media Server. The should be installed for notifications at the Media Server. Once
element is optional. the amount of time has passed, the subscription expires and the
MRB has to subscribe again in case it is still interested in
receiving notifications from the MS. The element MAY be present.
frequency: Provides the frequency in seconds that the MRB wishes to frequency: Provides the frequency in seconds that the MRB wishes to
receive notifications from the MRB. The element is optional. receive notifications from the MRB. The element MAY be present.
Please note that these two optional pieces of information provided by
the MRB only act as a suggestion: the MS MAY change the proposed
values if it considers the suggestions unacceptable (e.g., if the MRB
has requested a too high notification frequency). In such case, the
request would not fail, but the updated, acceptable values would be
reported in the <mrbresponse> accordingly.
5.1.4. <mrbnotification> 5.1.4. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The Server to an MRB to provide the details relating current status. The
Media Server will inform the MRB of its current status as defined by Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element contained in an <mrbrequest> using the <mrbnotification> element contained in an <mrbrequest>
element. element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
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 is mandatory. 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 session id to identify a specific notification update. with the subscription session id to identify a specific
The attribute is mandatory notification update. The first notification MUST have 1 as
'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present.
The following subsections provide details on the child elements that The following subsections provide details on the child elements that
are contained within an <mrbnotification> element. are contained within an <mrbnotification> element.
5.1.4.1. <media-server-id> 5.1.4.1. <media-server-id>
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system wide
identifier for a Media Server instance. The element is mandatory. identifier for a Media Server instance. The element 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 is Channel Packages supported by the media server. The element MAY be
optional. present.
The <supported-packages> element has no attributes. The <supported-packages> element has no attributes.
The <supported-packages> element has no child elements: The <supported-packages> element has the following child element:
package: The <package> element represents the name of a package package: The <package> element represents the name of a package
supported by the media server. The <package> element has a single supported by the media server. The <package> element has a single
attribute, 'name', which represents the name of the supported attribute, 'name', which represents the name of the supported
Media Control Channel Framework package. Media Control Channel Framework package, compliant with the
specification in the 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 is optional. element MAY be present.
The <active-rtp-sessions> element has no attributes. The <active-rtp-sessions> element has no attributes.
The <active-rtp-sessions> element has the following child element: The <active-rtp-sessions> element has the following child element:
rtp-codec: Is a container which represents a supported codec and rtp-codec: Is a container which represents a supported codec and
the associated active sessions. The <rtp-codec> element has one the associated active sessions. The <rtp-codec> element has one
attribute. The attribute 'name' represents the name of the codec attribute. The attribute 'name' represents the name of the codec
being represented. The <rtp-codec> element has two child being represented. A valid value is a MIME media type which,
depending on its definition, can include additional parameters
(e.g., [RFC4281]). The <rtp-codec> element has two child
elements. The child element, <decoding>, represents the number of elements. The child element, <decoding>, represents the number of
RTP sessions for the specified codec being decoded. The child RTP sessions for the specified codec being decoded. The child
element, <encoding>, represents the number of RTP sessions for the element, <encoding>, represents the number of RTP sessions for the
specified codec being encoded. specified codec being encoded.
5.1.4.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 is optional. the current active mixed RTP sessions. The element MAY be present.
The <active-mixer-sessions> element has no attributes. The <active-mixer-sessions> element has no attributes.
The <active-mixer-sessions> element has the following child element: The <active-mixer-sessions> element has the following child element:
active-mix: Is a container which represents a mixed active RTP active-mix: Is a container which represents a mixed active RTP
session. The <active-mix> element has one attribute. The session. The <active-mix> element has one attribute. The
attribute 'conferenceid' represents the name of the mix being attribute 'conferenceid' represents the name of the mix being
represented. The <active-mix> element has one child elements. represented. The <active-mix> element has one child elements.
The child element, <rtp-codec>, contains the same information The child element, <rtp-codec>, contains the same information
relating to RTP sessions as defined in Section 5.1.4.3. The relating to RTP sessions as defined in Section 5.1.4.3. The
element is optional. element MAY be 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 is the currently available inactive RTP sessions. The element MAY be
optional. present.
The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The <non-active-rtp-sessions> element has the following child The <non-active-rtp-sessions> element has the following child
element: element:
rtp-codec: Is a container which represents a supported codec and rtp-codec: Is a container which represents a supported codec and
the inactive sessions. The <rtp-codec> element has one attribute. the inactive sessions. The <rtp-codec> element has one attribute.
The attribute 'name' represents the name of the codec being The attribute 'name' represents the name of the codec being
represented. The <rtp-codec> element has two child elements. The represented. A valid value is a MIME media type which, depending
on its definition, can include additional parameters (e.g.,
[RFC4281]). The <rtp-codec> element has two child elements. The
first child element, <decoding>, represents the number of first child element, <decoding>, represents the number of
available RTP session for the specified codec being decoded. The available incoming (decoding) RTP session for the specified codec.
second child element, <encoding>, represents the number of The second child element, <encoding>, represents the number of
available RTP sessions for the specified codec being encoded. The available outgoing (encoding) RTP sessions for the specified
element is optional. 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 is detailing the current inactive mixed RTP sessions. The element MAY
optional. be present.
The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The <non-active-mixer-sessions> element has the following child The <non-active-mixer-sessions> element has the following child
element: element:
non-active-mix: Is a container which representing an available non-active-mix: Is a container which representing an available
mixed RTP session. The <non-active-mix> element has one mixed RTP session. The <non-active-mix> element has one
attribute. The attribute 'available' represents the number of attribute. The attribute 'available' represents the number of
mixes that could be used using that profile. The <non-active-mix> mixes that could be used using that profile. The <non-active-mix>
element has one child elements. The child element, <rtp-codec>, element has one child elements. The child element, <rtp-codec>,
contains the same information relating to RTP sessions as defined contains the same information relating to RTP sessions as defined
in Section 5.1.4.5. The element is optional. in Section 5.1.4.5. The element MAY be 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 is mandatory. 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. from service, and as such should not be contacted before it
becomes 'active' again.
unavailable: Indicating that the Media Server can not process new unavailable: Indicating that the Media Server continues to process
requests. past requests but cannot accept new requests, and as such should
not be contacted before it becomes 'active' again.
The <media-server-status> element has no attributes. The <media-server-status> element has no attributes.
The <media-server-status> element has no child elements. The <media-server-status> element has no child elements.
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 is optional. The element MAY be present.
The <supported-codecs> element has no attributes. The <supported-codecs> element has no attributes.
The <supported-codecs> element has the following child element: The <supported-codecs> element has the following child element:
supported-codec: has a single attribute, 'name', which provides the supported-codec: has a single attribute, 'name', which provides the
name of the codec providing information. The <supported-codec> name of the codec providing information. A valid value is a MIME
media type which, depending on its definition, can include
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 for which the codec support applies. Channel Framework package, compliant with the specification in the
The <supported-codec-package> element has one further child related IANA registry (e.g., "msc-ivr/1.0"), for which the codec
element, <supported-actions>, which provide the actions that a support applies. The <supported-codec-package> element has one
Media Server can apply to this codec (decode, encode, further child element, <supported-actions>, which provide the
passthrough). actions that a Media Server can apply to this codec:
* 'decode', meaning a decoder 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
using that codec through without re-encoding.
5.1.4.9. <application-data> 5.1.4.9. <application-data>
The <application-data> element provides application level data. The The <application-data> element provides arbitrary application level
element is optional. data. This data is meant to only have meaning at the application
level logic and as such is arbitrary. The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.1.4.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 making announcements. The element is optional. for the purpose of playing media. The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has the following child element: The <file-formats> element has the following child element:
supported-format: has a single attribute, 'name', which provides supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format> the type of file format that is supported. A valid value is a
MIME media type which, depending on its definition, can include
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 for which the file of the Media Control Channel Framework package, compliant with the
format support applies. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
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 is optional. The element MAY be present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element: The <max-prepared-duration> element has the following child element:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package provides the name of the Media Control Channel Framework package,
for which the time period applies. compliant with the specification in the related IANA registry
(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 is optional. DTMF tones and to generate them. The element MAY be present.
The <dtmf-support> element has no attributes. The <dtmf-support> element has no attributes.
The <dtmf-support> element has the following child elements: The <dtmf-support> element has the following child elements:
detect: has no attributes. The <detect> element then has a further detect: Indicates the support for DTMF detection. The <detect>
child element, <dtmf-type>. The <dtmf-type> element has two element has no attributes. The <detect> element then has a
attributes, 'name' and 'package. The 'name' attribute provides
the type of DTMF being used. The 'package' attribute provides the
name of the Media Control Channel Framework package for which the
DTMF type applies.
generate: has no attributes. The <generate> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used. The 'package' attribute provides the type of DTMF being used, and it can only be either
provides the name of the Media Control Channel Framework package 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: has no attributes. The <passthrough> element then has generate: Indicates the support for DTMF generation. The
a further child element, <dtmf-type>. The <dtmf-type> element has <generate> element has no attributes. The <generate> element then
two attributes, 'name' and 'package. The 'name' attribute has a further child element, <dtmf-type>. The <dtmf-type> element
provides the type of DTMF being used. The 'package' attribute has two attributes, 'name' and 'package. The 'name' attribute
provides the name of the Media Control Channel Framework package provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the support for passing DTMF through without
re-encoding. The <passthrough> element has no attributes. The
<passthrough> element then has a further child element, <dtmf-
type>. The <dtmf-type> element has two attributes, 'name' and
'package. The 'name' attribute provides the type of DTMF being
used, and it can only be either 'RFC4733' [RFC4733] or 'Media'
(tones as signals in the audio stream). The 'package' attribute
provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies.
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 is optional. presentation layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements: The <mixing-modes> element has the following child elements:
audio-mixing-modes: Is a container representing the available audio-mixing-modes: Is a container representing the available
algorithms for audio mixing. The <audio-mixing-modes> element has algorithms for audio mixing. The <audio-mixing-modes> element has
no attributes. The <audio-mixing-modes> element has one child no attributes. The <audio-mixing-modes> element has one child
element. The child element, <audio-mixing-mode>, contains a element. The child element, <audio-mixing-mode>, contains a
specific available algorithm. It has a single attribute, specific available algorithm. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support Control Channel Framework package, compliant with the
applies. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the algorithm support applies.
video-mixing-modes: Is a container representing the available video video-mixing-modes: Is a container representing the available video
presentation layouts and the supported functionality for what presentation layouts and the supported functionality for what
concerns video mixing. The <video-mixing-modes> element has two concerns video mixing. The <video-mixing-modes> element has two
attributes, 'vas' and 'activespeakermix'. The 'vas' attribute is attributes, 'vas' and 'activespeakermix'. The 'vas' attribute is
of type boolean with a value of 'true' indicating the Media Server of type 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 a element. The child element, <video-mixing-mode>, contains a
specific video presentation layout. It has a single attribute, specific video presentation layout. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support Control Channel Framework package, compliant with the
applies. specification in the related IANA registry (e.g., "msc-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) and supported referring to both country codes support (ISO 3166-1 [ISO.3166-1]) and
functionality (H.248.1v3/ITU-T Q.1950/..). The element is optional. supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).
The element MAY be present.
The <supported-tones> element has no attributes. The <supported-tones> element has no attributes.
The <supported-tones> element has the following child elements: The <supported-tones> element has the following child elements:
supported-country-codes: Is a container representing the supported supported-country-codes: Is a container representing the supported
country codes with respect to tones. The <supported-country- country codes with respect to tones. The <supported-country-
codes> element has no attributes. The <supported-country-codes> codes> element has no attributes. The <supported-country-codes>
has one child element. The child element, <country-code>, reports has one child element. The child element, <country-code>, reports
support for a specific country code, compliant with the ISO 3166-1 support for a specific country code, compliant with the ISO 3166-1
specification. The <country-code> element has a single attribute, [ISO.3166-1] specification. The <country-code> element has a
'package'. The attribute 'package' provides the name of the Media single attribute, 'package'. The attribute 'package' provides the
Control Channel Framework package in which the tones from the name of the Media Control Channel Framework package, compliant
specified country code are supported. with the specification in the related IANA registry (e.g., "msc-
ivr/1.0"), in which the tones from the specified country code are
supported.
supported-h248-codes: Is a container representing the supported supported-h248-codes: Is a container representing the supported
H.248 codes with respect to tones. The <supported-h248-codes> H.248 codes with respect to tones. The <supported-h248-codes>
element has no attributes. The <supported-h248-codes> has one element has no attributes. The <supported-h248-codes> has one
child element. The child element, <h248-code>, reports support child element. The child element, <h248-code>, reports support
for a specific H.248 code, compliant with the H.248.1v3/ITU-T for a specific H.248 code, compliant with the ITU-T Recommendation
Q.1950/... specification. The codes can be either specific (e.g. Q.1950 [ITU-T.Q.1950] specification. The codes can be either
cg/dt to only report the Dial Tone from the Call Progress Tones specific (e.g., cg/dt to only report the Dial Tone from the Call
package) or generic (e.g. cg/* to report all the tones from the Progress Tones package) or generic (e.g., cg/* to report all the
Call Progress Tones package) using wildcards. The <h248-code> tones from the Call Progress Tones package) using wildcards. The
element has a single attribute, 'package'. The attribute <h248-code> element has a single attribute, 'package'. The
'package' provides the name of the Media Control Channel Framework attribute 'package' provides the name of the Media Control Channel
package in which the specified codes are supported. Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), in which the specified codes
are supported.
5.1.4.15. <streaming-modes> 5.1.4.15. <streaming-modes>
The <streaming-modes> element allows the Media Server to specify The <streaming-modes> element allows the Media Server to specify
which protocols are supported for streaming to a Media Server for which protocols are supported for streaming to a Media Server for
each Media Control Channel Framework package type. For example, 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 is optional. NFS, etc protocols. The element MAY be present.
The <streaming-modes> element has no attributes. The <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child element: The <streaming-modes> element has 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. The 'package' attribute provides the name of the Media streaming (e.g., "HTTP", "RTSP", etc.). The 'package' attribute
Control Channel Framework package for which the streaming protocol provides the name of the Media Control Channel Framework package,
applies. compliant with the specification in the related IANA registry
(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 <asr-tts-support> codes) for what regards both ASR and TTS. The <asr-tts-support>
element has no attributes. The <asr-tts-support> element has the element has no attributes. The <asr-tts-support> element has the
following child elements: following child elements:
skipping to change at page 25, line 41 skipping to change at page 27, line 17
support> has one child element. The child element, <language>, support> has one child element. The child element, <language>,
reports the MS supports tts for a specific language. The reports the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The <language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of attribute 'xml:lang' contains 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, or RFC5552). The element is through (e.g., via the control framework, or RFC5552 [RFC5552]). The
optional. element MAY be present.
The <vxml-support> element has a single attribute 'support'. The The <vxml-support> element has a single attribute 'support'. The
'support' attribute is of type boolean with a value of 'true' 'support' attribute is of type boolean with a value of 'true'
indicating that the media server does support VXML, and a value of indicating that the media server does support VXML, and a value of
'false' indicating it does not support VXML. The default value is 'false' indicating it does not support VXML. The default value is
'false'. 'false'.
The <vxml-support> element has the following child element: The <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 for which the VXML support applies. The Framework package, compliant with the specification in the related
'support' attribute provides the type of VXML support provided by IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
the Media Server (RFC5552 or IVR-Package). applies. The 'support' attribute provides the type of VXML
support provided by the Media Server (RFC5552 [RFC5552] or IVR-
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 RFC5139. The element is Civic Address Schema standardized in RFC 5139 [RFC5139]. The element
optional. MAY be present.
The <media-server-location> element has no attributes. The <media-server-location> element has no attributes.
The <media-server-location> element one child element: The <media-server-location> element one child element:
civicAddress: Is a container representing the civic address civicAddress: Is a container representing the civic address
location of the media server, whose representation refers to the location of the media server, whose representation refers to the
Section 4 of RFC 5139 [RFC5139]. Section 4 of RFC 5139 [RFC5139].
5.1.4.19. <label> 5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the information that will be understood by the MRB. For example, the
Media Server can declare if 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. Its arbitrary as opposed to doing it purely on classification, and as such is not meant to provide any explicit
features. The element is optional. information associated with the features of a MS. The element MAY be
present.
The <label> element has no attributes. The <label> element has no attributes.
The <label> element has no child elements. The <label> element has no child elements.
5.1.4.20. <media-server-address> 5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct URI address. The element is optional. direct SIP URI address where it can be reached (e.g., the URI AS
would call to in order to setup a Control Channel and relay call
legs). The element MAY be present.
The <media-server-address> element has no attributes. The <media-server-address> element has no attributes.
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 <encyption> 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 is optional. support RFC 3711 [RFC3711] for RTP. The element MAY be present.
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.1.5. <mrbresponse> 5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <response> element from
Section 7. Section 7.
The <response> element has following attributes: The <response> element has following attributes:
status: numeric code indicating the response status. The attribute status: numeric code indicating the response status. The attribute
is mandatory. MUST be present.
The following status codes are defined: reason: string specifying a reason for the response status. The
attribute MAY be present.
The following status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | | | | |
| 400 | Syntax error | | 400 | Syntax error |
| | | | | |
| 401 | Unable to create Subscription | | 401 | Unable to create Subscription |
| | | | | |
skipping to change at page 27, line 45 skipping to change at page 29, line 32
| | | | | |
| 404 | Subscription does not exist | | 404 | Subscription does not exist |
| | | | | |
| 405 | Subscription already exists | | 405 | Subscription already exists |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <response> status codes Table 1: <response> status codes
In case a new subscription request made by an MRB (action='create')
has been accepted, the MS MUST reply with a <mrbresponse> with status
code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MS.
A subscription request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used
instead. Specifically, if the MS fails to handle a request due to a
syntax error in the request itself (e.g., incorrext XML, violation of
the schema constraints or invalid values in any of the attributes/
elements) the MS MUST reply with a <mrbresponse> with status code
400. If a syntactically correct request fails because the request
also includes any attribute/element the MS doesn't understand, the MS
MUST reply with a <mrbresponse> with status code 420. If a
syntactically correct request fails because the MRB wants to create a
new subscription, but the provided intended id for the subscription
already exists, the MS MUST reply with a <mrbresponse> with status
code 405. If a syntactically correct request failes because the MRB
wants to update/remove a subscription that doesn't exist, the MS MUST
reply with a <mrbresponse> with status code 404. If the MS is unable
to accept a request for any other reason (e.g., the MRB has no more
resources to fulfil the request), the MS MUST reply with a
<mrbresponse> with status code 401/402/403, depending on the action
the MRB provided in its request:
o action='create' --> 401;
o action='update' --> 402;
o action='remove' --> 403;
As explained in Section 5.1.3.1, even in case of an accepted
subscription request the MS might change the suggested 'expires' and
'frequency' values provided by the MRB in its <mrbrequest>, if it
considers them unacceptable (e.g., the requested frequency is too
high). In such a case, the MS MUST add an additional <subscription>
element to the response, including the updated values, to inform the
MRB about the change. The MS MAY include such element if the values
have been accepted or were omitted in the request.
5.2. Media Service Resource Consumer Interface 5.2. Media Service Resource Consumer Interface
The Media Server Consumer interface provides the ability for clients The Media Server Consumer interface provides the ability for clients
of an MRB, such as Application Servers, to request an appropriate of an MRB, such as Application Servers, to request an appropriate
Media Server to satisfy specific criteria. The interface allows a Media Server to satisfy specific criteria. The interface allows a
client to pass detailed meta-information to the MRB to help select an client to pass detailed meta-information to the MRB to help select an
appropriate Media Server. The MRB is then able to make an informed appropriate Media Server. The MRB is then able to make an informed
decision and provide the client with an appropriate media server decision and provide the client with an appropriate media server
resource. The MRB Consumer interface can be used in association with resource. The MRB Consumer interface can be used in association with
both the Session Initiation Protocol (SIP) and the Hypertext Transfer both the Session Initiation Protocol (SIP) and the Hypertext Transfer
skipping to change at page 29, line 15 skipping to change at page 31, line 42
in Section 5.3.2). in Section 5.3.2).
The media resource query, as defined by the <mediaResourceRequest> The media resource query, as defined by the <mediaResourceRequest>
element from Section 8, MUST be carried in a SIP INVITE request. The element from Section 8, MUST be carried in a SIP INVITE request. The
INVITE request will be constructed as it would have been to connect INVITE request will be constructed as it would have been to connect
to a media server, as defined by the Media Control Channel Framework to a media server, as defined by the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework]. The following additional [I-D.ietf-mediactrl-sip-control-framework]. The following additional
steps MUST be followed when using the Consumer interface: steps MUST be followed when using the Consumer interface:
o Include a payload in the SIP INVITE request of type 'multipart/ o Include a payload in the SIP INVITE request of type 'multipart/
mixed'[RFC2046]. The first part to be included in the 'mixed' mixed'[RFC2046]. One of the parts to be included in the
payload MUST be the 'application/sdp' format which is constructed 'multipart/mixed' payload MUST be the 'application/sdp' format
as specified in the Media Control Channel Framework which is constructed as specified in the Media Control Channel
[I-D.ietf-mediactrl-sip-control-framework]. Framework [I-D.ietf-mediactrl-sip-control-framework].
o The second part of the 'multipart/mixed payload MUST be of type o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and 'application/mrb-consumer+xml', as specified in this document and
defined in Section 8. Only the <mediaResourceRequest> and its defined in Section 8. Only the <mediaResourceRequest> and its
child elements can be included in the payload. child elements can be included in the payload.
o The INVITE request will then be dispatched to the MRB, as defined o The INVITE request will then be dispatched to the MRB, as defined
by [I-D.ietf-mediactrl-sip-control-framework]. by [I-D.ietf-mediactrl-sip-control-framework].
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 8, SHOULD be carried in <mediaResourceResponse> element from Section 8, MUST be carried in
the payload of a SIP 2xx class response to the original SIP INVITE the payload of a SIP 2xx class response to the original SIP INVITE
request. It MAY be carried in the payload of a SIP 3xx response. It request. The 2xx class response will be constructed as it would have
should be noted that the use of a SIP 3xx response aligns with the been to connect from a media server, as defined by the Media Control
request/response query approach used by HTTP in Section 5.2.1. Using Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The
2xx aligns with the 'in-line' approach where the MRB sits in the following additional steps MUST be followed when using the Consumer
signaling path between the client and the media resource. The 2xx interface:
class response will be constructed as it would have been to connect
from a media server, as defined by the Media Control Channel
Framework [I-D.ietf-mediactrl-sip-control-framework]. A standard 3xx
response can also be generated. The following additional steps MUST
be followed when using the Consumer interface:
o Include a payload in the SIP 2xx class response of type o Include a payload in the SIP 2xx class response of type
'multipart/mixed'RFC 2046 [RFC2046]. The first part to be 'multipart/mixed'RFC 2046 [RFC2046]. One of the parts to be
included in the 'mixed' payload MUST be the 'application/sdp' included in the 'multipart/mixed' payload MUST be the
format which is constructed as specified in the Media Control 'application/sdp' format which is constructed as specified in the
Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. A Media Control Channel Framework
3xx response will not include payload of type 'multipart/mixed' [I-D.ietf-mediactrl-sip-control-framework].
and will only include a single payload of type 'application/
mrb-consumer+xml', as discussed in the next point.
o The second part of the 'multipart/mixed payload MUST be of type o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and 'application/mrb-consumer+xml', as specified in this document and
defined in Section 8. Only the <mediaResourceResponse> and its defined in Section 8. Only the <mediaResourceResponse> and its
child elements can be included in the payload. child elements can be included in the payload.
o The SIP 2xx/3xx class response will then be dispatched from the o The SIP 2xx class response will then be dispatched from the MRB.
o A SIP ACK to the 2xx class response will then be sent back to the
MRB. MRB.
5.2.3. Consumer Interface Lease Mechanism 5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 8 and Section 8 allows a The Consumer interface defined in Section 5.2 and Section 8 allows a
client to request an appropriate media resource based on information client to request an appropriate media resource based on information
included in the request (either a HTTP POST or SIP INVITE message). included in the request (either a HTTP POST or SIP INVITE message).
In case of success, the response that is returned to the client MUST In case of success, the response that is returned to the client MUST
contain a <session-info> element in either the SIP 2xx class or HTTP contain a <session-info> element in either the SIP 2xx class or HTTP
200 response. The information contained in the <session-info> 200 response. The information contained in the <session-info>
element allows a Consumer client to monitor the life time of the element allows a Consumer client to monitor the life time of the
resources it has successfully requested, as well as amending them. resources it has successfully requested, as well as amending them.
The <mediaResourceResponse> element returned from the MRB contains a Before delving into the details of such lease mechanism, though, it's
<session-info> element if the request is successful. The <session- worthwhile to first clarify its role within the context of the
info> element has the following child elements which provide the Consumer interface. As explained in Section 5.1, the knowledge the
appropriate resource session information: MRB has of the resources of all the MS it handles is imperfect. As
such, how an MRB actually manages such resources depends on how it is
implemented: one may choose to have the MRB keeping track and state
of the allocated resources, or simply depend on the MS themselves to
provide the information by means of the publishing interface
notifications. Further information may be inferred by the
signalling, in case the MRB is in the path of call legs. This means
that the MRB may or may not be able to enforce the leasing mechanism
it provides: such functionality is demanded, if necessary, to the
actual deployment of a compliant entity, with the help of the
information herein provided.
That said, the <mediaResourceResponse> element returned from the MRB
contains a <session-info> element if the request is successful. The
<session-info> element has the following child elements which provide
the appropriate resource session information:
o <session-id> is a unique identifier that enables a Consumer client 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
skipping to change at page 31, line 28 skipping to change at page 34, line 18
element in the initial <mediaResourceResponse>). On issuing any element in the initial <mediaResourceResponse>). On issuing any
future requests related to the specific media resource session (as future requests related to the specific media resource session (as
determined by the <session-id> element) the consumer client MUST determined by the <session-id> element) the consumer client MUST
increment the value returned in the <seq> element from the initial increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows counter to and in conjunction with the unique <session-id> allows
for unique identification of a request. for unique identification of a request.
o <action> element provides the operation to be carried out by the o <action> element provides the operation to be carried out by the
MRB on receiving the request. The value of 'update' is a request MRB on receiving the request:
by the Consumer client to update the existing session at the MRB
with alternate requirements which are contained in the remainder * The value of 'update' is a request by the Consumer client to
of the request. If the requested resource information is update the existing session at the MRB with alternate
identical to the existing MRB session, the MRB will attempt a requirements which are contained in the remainder of the
session refresh. If the information has changed, the MRB will request. If the requested resource information is identical to
attempt to update the existing session with the new information. the existing MRB session, the MRB will attempt a session
If the operation is successful, the 200 response is returned in refresh. If the information has changed, the MRB will attempt
the status attribute of the <mediaResourceResponseType> element. to update the existing session with the new information. If
If the operation is not successful, a 409 response is returned in the operation is successful, the 200 status code in the
the status attribute of the <mediaResourceResponseType> element. response is returned in the status attribute of the
The value of 'remove' is a request by the Consumer client to <mediaResourceResponseType> element. If the operation is not
remove the session at the MRB. This provides a mechanism for successful, a 409 status code in the response is returned in
Consumer clients to release unwanted resources before they expire. the status attribute of the <mediaResourceResponseType>
If the operation is successful, a 200 response is returned in the element.
status attribute of the <mediaResourceResponseType> element. If
the operation is not successful, a 410 response is returned in the * The value of 'remove' is a request by the Consumer client to
status attribute of the <mediaResourceResponseType> element. remove the session at the MRB. This provides a mechanism for
Consumer clients to release unwanted resources before they
expire. If the operation is successful, a 200 status code in
the response is returned in the status attribute of the
<mediaResourceResponseType> element. If the operation is not
successful, a 410 status code in the response is returned in
the status attribute of the <mediaResourceResponseType>
element.
Omitting the 'action' attribute means requesting a new set of
resources.
When used with SIP the <session-info> element MUST be included in When used with SIP the <session-info> element MUST be included in
either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as
defined in[RFC3311]) request. When used with HTTP the <session-info> defined in[RFC3311]) request. When used with HTTP the <session-info>
element MUST be included in a HTTP POST message (as defined in element MUST be included in a HTTP POST message (as defined in
[RFC2616]). [RFC2616]).
5.2.4. Media Service Resource Request 5.2.4. Media Service Resource Request
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 8. found in Section 8.
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 <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 is mandatory. attribute MUST be present.
The <mrbconsumer> element has the following child elements, only one The <mrbconsumer> element has the following child elements, only one
of which is allowed to occur. 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.
skipping to change at page 32, line 46 skipping to change at page 35, line 46
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 container 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
<generalInfo> element has <session-info> and <packages> as child following sub-sections describe the elements of the <generalInfo>
elements and are described in the following sub-sections. 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 is optional. described in more detail in Section 5.2.3. The element MAY be
present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child elements: The <max-prepared-duration> element has the following child 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 about its use is provided in Section 5.2.3. More information about its use is provided in Section 5.2.3.
action: provides the operation that should be carried out on an action: provides the operation that should be carried out on an
existing media resource session on an MRB. The value of 'update' existing media resource session on an MRB:
instructs the MRB to attempt to update the existing media resource
session with the information contained in the <ivrInfo> and * The value of 'update' instructs the MRB to attempt to update
<mixerInfo> elements. The value of 'remove' instructs the MRB to the existing media resource session with the information
attempt to remove the existing media resource session. More contained in the <ivrInfo> and <mixerInfo> elements.
information on its use is provided in Section 5.2.3.
* The value of 'remove' instructs the MRB to attempt to remove
the existing media resource session. More information on its
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 is optional. client. The element MAY be present.
The <packages> element has no attributes. The <packages> element has no attributes.
The <packages> element has the following child element: The <packages> element has 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. The <package> element can appear multiple times. A valid value is
a Control Package name as specified in the related IANA registry
(e.g., "msc-ivr/1.0")
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 a container for general Consumer
request information that is IVR specific. The <ivrInfo> element has request information that is IVR specific. The following sub-sections
<ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, describe the elements of the <ivrInfo> element, <ivr-sessions>,
<location>, <encryption>, <application-data>, <max-prepared-duration> <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>,
and <stream-mode> as child elements and are described in the <encryption>, <application-data>, <max-prepared-duration> and
following sub-sections. <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 is Consumer client requires from a media resource. The element MAY be
optional. present.
The <ivr-sessions> element has no attributes. The <ivr-sessions> element has no attributes.
The <ivr-sessions> element has the following child element: The <ivr-sessions> element has the following child element:
rtp-codec: child element contains has a single attribute, 'name'. rtp-codec: child element contains has a single attribute, 'name'.
The 'name' attribute provides the name of the codec required for The 'name' attribute provides the name of the codec required for
an IVR session and is an appropriately registered token. The an IVR session and is an appropriately registered token. A valid
<rtp-codec> element has two child elements. The child element, value is a MIME media type which, depending on its definition, can
<decoding>, represents the number of RTP sessions for which include additional parameters (e.g., [RFC4281]). The <rtp-codec>
decoding using the specified codec is requested. The child element has two child elements. The child element, <decoding>,
element, <encoding>, represents the number of RTP sessions for represents the number of RTP sessions for which decoding using the
which encoding using the specified codec is requested. specified codec is requested. The child element, <encoding>,
represents the number of RTP sessions for which encoding using the
specified codec is requested.
5.2.4.1.2.2. <file-formats> element 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 making announcements. The element is optional. for the purpose of playing media. The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has the following child element: The <file-formats> element has the following child element:
supported-format: has a single attribute, 'name', which provides supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format> the type of file format that is supported. The <supported-format>
element then has a further child element, <supported-file- element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package for which the file of the Media Control Channel Framework package, compliant with the
format support applies. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
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 is optional. and to generate them. The element MAY be present.
The <dtmf> element has no attributes. The <dtmf> element has no attributes.
The <dtmf> element has the following child elements: The <dtmf> element has the following child elements:
detect: has no attributes. The <detect> element then has a further detect: Indicates the required support for DTMF detection. The
child element, <dtmf-type>. The <dtmf-type> element has two <detect> element has no attributes. The <detect> element then has
attributes, 'name' and 'package. The 'name' attribute provides a further child element, <dtmf-type>. The <dtmf-type> element has
the type of DTMF required. The 'package' attribute provides the
name of the Media Control Channel Framework package for which the
DTMF type applies.
generate: has no attributes. The <generate> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF required. The 'package' attribute provides the type of DTMF being needed, and it can only be either
provides the name of the Media Control Channel Framework package 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: has no attributes. The <passthrough> element then has generate: Indicates the required support for DTMF generation. The
a further child element, <dtmf-type>. The <dtmf-type> element has <generate> element has no attributes. The <generate> element then
two attributes, 'name' and 'package. The 'name' attribute has a further child element, <dtmf-type>. The <dtmf-type> element
provides the type of DTMF required. The 'package' attribute has two attributes, 'name' and 'package. The 'name' attribute
provides the name of the Media Control Channel Framework package provides the type of DTMF being needed, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the required support for passing DTMF
through without re-encoding. The <passthrough> element has no
attributes. The <passthrough> element then has a further child
element, <dtmf-type>. The <dtmf-type> element has two attributes,
'name' and 'package. The 'name' attribute provides the type of
DTMF being needed, and it can only be either 'RFC4733' [RFC4733]
or 'Media' (tones as signals in the audio stream). The 'package'
attribute provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
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) and requested functionality (H.248.1v3/ codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
ITU-T Q.1950/..). The element is optional. (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present.
The <tones> element has no attributes. The <tones> element has no attributes.
The <tones> element has the following child elements: The <tones> element has the following child elements:
country-codes: Is a container representing the requested country country-codes: Is a container representing the requested country
codes with respect to tones. The <country-codes> element has no codes with respect to tones. The <country-codes> element has no
attributes. The <country-codes> has one child element. The child attributes. The <country-codes> has one child element. The child
element, <country-code>, requests a specific country code, element, <country-code>, requests a specific country code,
compliant with the ISO 3166-1 specification. The <country-code> compliant with the ISO 3166-1 [ISO.3166-1] specification. The
element has a single attribute, 'package'. The attribute <country-code> element has a single attribute, 'package'. The
'package' provides the name of the Media Control Channel Framework attribute 'package' provides the name of the Media Control Channel
package in which the tones from the specified country code are Framework package, compliant with the specification in the related
requested. IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested.
h248-codes: Is a container representing the requested H.248 codes h248-codes: Is a container representing the requested H.248 codes
with respect to tones. The <h248-codes> element has no with respect to tones. The <h248-codes> element has no
attributes. The <h248-codes> has one child element. The child attributes. The <h248-codes> has one child element. The child
element, <h248-code>, requests a specific H.248 code, compliant element, <h248-code>, requests a specific H.248 code, compliant
with the H.248.1v3/ITU-T Q.1950/... specification. The codes can with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
be either specific (e.g. cg/dt to only report the Dial Tone from The codes can be either specific (e.g., cg/dt to only report the
the Call Progress Tones package) or generic (e.g. cg/* to report Dial Tone from the Call Progress Tones package) or generic (e.g.,
all the tones from the Call Progress Tones package) using cg/* to report all the tones from the Call Progress Tones package)
wildcards. The <h248-code> element has a single attribute, using wildcards. The <h248-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package in which the specified codes are Control Channel Framework package, compliant with the
requested. specification in the 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 <asr-tts-support>
element has no attributes. The <asr-tts-support> element has the element has no attributes. The <asr-tts-support> element has the
following child elements: following child elements:
skipping to change at page 36, line 36 skipping to change at page 40, line 16
TTS. The <tts-support> element has no attributes. The <tts- TTS. The <tts-support> element has no attributes. The <tts-
support> has one child element. The child element, <language>, support> has one child element. The child element, <language>,
requests the MS supports tts for a specific language. The requests the MS supports tts for a specific language. The
<language> element has a single attribute, 'xml:lang'. The <language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of attribute 'xml:lang' contains 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, or RFC5552). The element is optional. via the control framework, or RFC5552 [RFC5552]). The element MAY be
present.
The <vxml> element has a single attribute 'support'. The 'support' The <vxml> element has a single attribute 'support'. The 'support'
attribute is of type boolean with a value of 'true' indicating that attribute is of type boolean with a value of 'true' indicating that
the Consumer client requires VXML support, and a value of 'false' the Consumer client requires VXML support, and a value of 'false'
indicating it does not require VXML support. The default value is indicating it does not require VXML support. The default value is
'false'. 'false'.
The <vxml> element has the following child element: The <vxml> element has the following child element:
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 for which the VXML support applies. The Framework package, compliant with the specification in the related
'require' attribute specifies the type of VXML support required by IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
the Consumer client (RFC5552 or IVR-Package). applies. The 'require' attribute specifies the type of VXML
support required by the Consumer client (RFC5552 [RFC5552] or IVR-
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 is optional. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The <location> element has no attributes. The <location> element has no attributes.
The <location> element one child element: The <location> element one child element:
civicAddress: Is a container representing the civic address civicAddress: Is a container representing the civic address
location of the requested media server, whose representation location of the requested media server, whose representation
refers to Section 4 of RFC 5139 [RFC5139]. refers to Section 4 of RFC 5139 [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 is optional. The default value is 'false' element MAY be present. The default value is 'false'
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <application-data> element has no child elements. The <application-data> 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 is optional. The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.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 is optional. in the system before it is executed. The element MAY be present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element: The <max-prepared-duration> element has the following child element:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package provides the name of the Media Control Channel Framework package,
for which the time period applies. compliant with the specification in the related IANA registry
(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 is optional. protocols. The element MAY be present.
The <streaming-modes> element has no attributes. The <streaming-modes> element has no attributes.
The <streaming-modes> element has the following child element: The <streaming-modes> element has 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 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 for which the streaming protocol Channel Framework package, compliant with the specification in the
applies. related IANA registry (e.g., "msc-ivr/1.0"), for which the
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 a container for general Consumer
request information that is Mixer specific. The <mixerInfo> element request information that is Mixer specific. The following sub-
has <mixers>, <file-formats>, <dtmf-type>, <tones>, <mixing-mode>, sections describe the elements of the <mixerInfo> element, <mixers>,
<application-data>, <location> and <encryption> are described in the <file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application-
following sub-sections. 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 is optional. mixed RTP sessions. The element MAY be present.
The <mixers> element has no attributes. The <mixers> element has no attributes.
The <mixers> element has the following child element: The <mixers> element has the following child element:
mix: Is a container which represents a required mixed RTP session. mix: Is a container which represents a required mixed RTP session.
The <mix> element has one attribute. The attribute 'users' The <mix> element has one attribute. The attribute 'users'
represents the number of participants required in the mix. The represents the number of participants required in the mix. The
<mix> element has one child elements. The child element, <codec>, <mix> element has one child elements. The child element, <codec>,
contains the same information relating to RTP sessions as defined contains the same information relating to RTP sessions as defined
in Section 5.1.4.3. The element is optional. in 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 making announcements to a by the Consumer client for the purpose of playing media to a mix.
mix. The element is optional. The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has the following child element: The <file-formats> element has 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 supported. The <required-format> type of file format that is supported. 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 for which the file format Control Channel Framework package, compliant with the
support applies. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
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 is optional. and to generate them in a mix. The element MAY be present.
The <dtmf> element has no attributes. The <dtmf> element has no attributes.
The <dtmf> element has the following child elements: The <dtmf> element has the following child elements:
detect: has no attributes. The <detect> element then has a further detect: Indicates the required support for DTMF detection. The
child element, <dtmf-type>. The <dtmf-type> element has two <detect> element has no attributes. The <detect> element then has
attributes, 'name' and 'package. The 'name' attribute provides a further child element, <dtmf-type>. The <dtmf-type> element has
the type of DTMF required. The 'package' attribute provides the
name of the Media Control Channel Framework package for which the
DTMF type applies.
generate: has no attributes. The <generate> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF required. The 'package' attribute provides the type of DTMF being used, and it can only be either
provides the name of the Media Control Channel Framework package 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: has no attributes. The <passthrough> element then has generate: Indicates the required support for DTMF generation. The
a further child element, <dtmf-type>. The <dtmf-type> element has <generate> element has no attributes. The <generate> element then
two attributes, 'name' and 'package. The 'name' attribute has a further child element, <dtmf-type>. The <dtmf-type> element
provides the type of DTMF required. The 'package' attribute has two attributes, 'name' and 'package. The 'name' attribute
provides the name of the Media Control Channel Framework package provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the required support for passing DTMF
through without re-encoding. The <passthrough> element has no
attributes. The <passthrough> element then has a further child
element, <dtmf-type>. The <dtmf-type> element has two attributes,
'name' and 'package. The 'name' attribute provides the type of
DTMF being used, and it can only be either 'RFC4733' [RFC4733] or
'Media' (tones as signals in the audio stream). The 'package'
attribute provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
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) and requested functionality (H.248.1v3/ codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
ITU-T Q.1950/..). The element is optional. (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present.
The <tones> element has no attributes. The <tones> element has no attributes.
The <tones> element has the following child elements: The <tones> element has the following child elements:
country-codes: Is a container representing the requested country country-codes: Is a container representing the requested country
codes with respect to tones. The <country-codes> element has no codes with respect to tones. The <country-codes> element has no
attributes. The <country-codes> has one child element. The child attributes. The <country-codes> has one child element. The child
element, <country-code>, requests a specific country code, element, <country-code>, requests a specific country code,
compliant with the ISO 3166-1 specification. The <country-code> compliant with the ISO 3166-1 [ISO.3166-1] specification. The
element has a single attribute, 'package'. The attribute <country-code> element has a single attribute, 'package'. The
'package' provides the name of the Media Control Channel Framework attribute 'package' provides the name of the Media Control Channel
package in which the tones from the specified country code are Framework package, compliant with the specification in the related
requested. IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested.
h248-codes: Is a container representing the requested H.248 codes h248-codes: Is a container representing the requested H.248 codes
with respect to tones. The <h248-codes> element has no with respect to tones. The <h248-codes> element has no
attributes. The <h248-codes> has one child element. The child attributes. The <h248-codes> has one child element. The child
element, <h248-code>, requests a specific H.248 code, compliant element, <h248-code>, requests a specific H.248 code, compliant
with the H.248.1v3/ITU-T Q.1950/... specification. The codes can with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
be either specific (e.g. cg/dt to only report the Dial Tone from The codes can be either specific (e.g., cg/dt to only report the
the Call Progress Tones package) or generic (e.g. cg/* to report Dial Tone from the Call Progress Tones package) or generic (e.g.,
all the tones from the Call Progress Tones package) using cg/* to report all the tones from the Call Progress Tones package)
wildcards. The <h248-code> element has a single attribute, using wildcards. The <h248-code> element has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package in which the specified codes are Control Channel Framework package, compliant with the
requested. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
in which the 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 is optional. presentation layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The <mixing-modes> element has the following child elements: The <mixing-modes> element has the following child elements:
audio-mixing-modes: Is a container representing the requested audio-mixing-modes: Is a container representing the requested
algorithms for audio mixing. The <audio-mixing-modes> element has algorithms for audio mixing. The <audio-mixing-modes> element has
no attributes. The <audio-mixing-modes> element has one child no attributes. The <audio-mixing-modes> element has one child
element. The child element, <audio-mixing-mode>, contains a element. The child element, <audio-mixing-mode>, contains a
specific requested algorithm. It has a single attribute, specific requested algorithm. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support Control Channel Framework package, compliant with the
is requested. specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the algorithm support is requested.
video-mixing-modes: Is a container representing the requested video video-mixing-modes: Is a container representing the requested video
presentation layouts for video mixing. The <video-mixing-modes> presentation layouts for video mixing. The <video-mixing-modes>
element has two attributes, 'vas' and 'activespeakermix'. The element has two attributes, 'vas' and 'activespeakermix'. The
'vas' attribute is of type boolean with a value of 'true' 'vas' attribute is of type boolean with a value of 'true'
indicating that the Consumer Client requires automatic Voice indicating that the Consumer Client requires automatic Voice
Activated Switching. The 'activespeakermix' attribute is of type Activated Switching. The 'activespeakermix' attribute is of type
boolean with a value of 'true' indicating that the Consumer Client boolean with a value of 'true' indicating that the Consumer Client
requires an additional video stream for the loudest speaker requires an additional video stream for the loudest speaker
participant without its contribution. The <video-mixing-modes> participant without its contribution. The <video-mixing-modes>
element has one child element. The child element, <video-mixing- element has one child element. The child element, <video-mixing-
mode>, contains a requested video presentation layout. It has a mode>, contains a requested video presentation layout. It has a
single attribute, 'package'. The attribute 'package' provides the single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package for which the name of the Media Control Channel Framework package, compliant
algorithm support is requested. with the specification in the related IANA registry (e.g., "msc-
ivr/1.0"), for which the algorithm support is requested.
5.2.4.1.3.6. <application-data> 5.2.4.1.3.6. <application-data>
The <application-data> element provides IVR application level data. The <application-data> element provides IVR application level data.
The element is optional. The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.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 is optional. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The <location> element has no attributes. The <location> element has no attributes.
The <location> element one child element: The <location> element one child element:
civicAddress: Is a container representing the civic address civicAddress: Is a container representing the civic address
location of the requested media server, whose representation location of the requested media server, whose representation
refers to Section 4 of RFC 5139 [RFC5139]. refers to Section 4 of RFC 5139 [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 is optional. The default value is 'false' RTP. The element MAY be present. The default value is 'false'
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <application-data> element has no child elements. The <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> container 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 container for clients
receiving query information from an external MRB entity. receiving query 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: status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | | | | |
| 400 | Syntax error | | 400 | Syntax error |
| | | | | |
| 408 | Unable to find Resource | | 408 | Unable to find Resource |
| | | | | |
skipping to change at page 42, line 48 skipping to change at page 47, line 4
| 400 | Syntax error | | 400 | Syntax error |
| | | | | |
| 408 | Unable to find Resource | | 408 | Unable to find Resource |
| | | | | |
| 409 | Unable to update Resource | | 409 | Unable to update Resource |
| | | | | |
| 410 | Unable to remove Resource | | 410 | Unable to remove Resource |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 2: <response> status codes Table 2: <response> status codes
In case a new media resource request made by an AS (no action) has
been accepted, the MS MUST reply with a <mediaResourceResponse> with
status code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MRB.
A media resource request, nevertheless, may fail for several reasons.
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
syntax error in the request itself (e.g., incorrext XML, violation of
the schema constraints or invalid values in any of the attributes/
elements) the MRB MUST reply with a <mediaResourceResponse> with
status code 400. If a syntactically correct request fails because
the request also includes any attribute/element the MRB doesn't
understand, the MRB MUST reply with a <mediaResourceResponse> with
status code 420. If a syntactically correct request fails because
the MRB couldn't find any MS able to fulfil the requirements
presented by the AS in its request, the MRB MUST reply with a
<mediaResourceResponse> with status code 408. If a syntactically
correct request fails because the MRB couldn't update an existing
request according to the new requirements presented by the AS in its
request, the MRB MUST reply with a <mediaResourceResponse> with
status code 409. If a syntactically correct request fails because
the MRB couldn't remove an existing request and release the related
resources as requested by the AS, the MRB MUST reply with a
<mediaResourceResponse> with status code 410.
Further details on status codes 409 and 410 are presented in
Section 5.2.3, where the leasing mechanism, together with its related
scenarios, is described.
The <mediaResourceResponse> element only has <response-session-info> The <mediaResourceResponse> element only has <response-session-info>
as a child element. This element is used to describe the response of as a child element. This element is used to describe the response of
a Consumer interface query and is covered in the following sub- a Consumer interface query and is covered in the following sub-
section. section.
5.2.5.1.1. <response-session-info> element 5.2.5.1.1. <response-session-info> element
The <response-session-info> element is included in Consumer responses The <response-session-info> element is included in Consumer responses
when an update has been made to an existing media resource session. when an update has been made to 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 is is described in more detail in Section 5.2.3. The element MAY be
optional. present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child elements: The <max-prepared-duration> element has the following child 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.
skipping to change at page 43, line 45 skipping to change at page 48, line 33
'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 timeout period could be
used. For example, if the timeout period is 300 seconds, the used. For example, if the timeout 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: is the SIP URI to reach the MS handling the media-server-address: is the SIP URI to reach the MS handling the
requested media resource. requested media resource.
[Editors' Note: this response should also include a way for the
Consumer Client to contact the MS able to fulfil the request, at
least in case of the HTTP usage of the Consumer interface. Such info
wouldn't be needed in the IAMM case. At the moment this is reported
by means of the <media-server-address> element, which is also used in
the publish interface. Is this SIP URI enough? Do we need to
provide additional details?]
5.3. In-Line MRB Interface 5.3. In-Line MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a An entity acting as an In-Line MRB can act in one of two roles for a
request, as introduced in Section 4.2. The following sub sections request, as introduced in Section 4.2. The following sub sections
provide details for using In-Line Unaware MRB Mode (IUMM) of provide details for using In-Line Unaware MRB Mode (IUMM) of
operation and In-Line Aware MRB Mode (IAMM) of operation. operation and In-Line Aware MRB Mode (IAMM) of operation.
5.3.1. In-line Unaware MRB Mode 5.3.1. In-line Unaware MRB Mode
It should be noted that the introduction of an MRB entity into the It should be noted that the introduction of an MRB entity into the
skipping to change at page 46, line 11 skipping to change at page 51, line 11
acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/ acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then mrb-consumer+xml' information from the SIP INVITE request and then
forwards to the selected Media Server. forwards to the selected Media Server.
6. Examples 6. Examples
This section provides examples of both the Publish and Consumer This section provides examples of both the Publish and Consumer
interfaces. For what concerns the Consumer interface, both Query and interfaces. For what concerns the Consumer interface, both Query and
Inline modes are addressed. Inline modes are addressed.
Note that due to RFC formatting conventions, this section often
splits HTTP, SIP/SDP and CFW across lines whose content would exceed
72 characters. A backslash character marks where this line folding
has taken place. This backslash and its trailing CRLF and whitespace
would not appear in the actual protocol contents. Besides, also note
that the indentation of the XML content is only provided for
readability: actual messages will follow strict XML syntax, which
allows for, but does not require, indentation.
6.1. Publish Example 6.1. Publish Example
The following example assumes a control channel has been established The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework and synced as described in the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]). ([I-D.ietf-mediactrl-sip-control-framework]).
Figure 9 shows the subscription/notification mechanism the Publish Figure 9 shows the subscription/notification mechanism the Publish
interface is based on, as defined in Section 5.1. The MRB subscribes interface is based on, as defined in Section 5.1. The MRB subscribes
for information at the MS (message A1.), and the MS accepts the for information at the MS (message A1.), and the MS accepts the
subscription (A2). Notifications are triggered by the MS (A3.) and subscription (A2). Notifications are triggered by the MS (A3.) and
skipping to change at page 48, line 19 skipping to change at page 53, line 42
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<mrbnotification seqnumber="1" id="QQ6J3c"> <mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id> <media-server-id>a1b2c3d4</media-server-id>
<supported-packages> <supported-packages>
<package name="msc-ivr/1.0"/> <package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/> <package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/> <package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/> <package name="msc-example-pkg/1.0"/>
</supported-packages> </supported-packages>
<active-rtp-sessions> <active-rtp-sessions>
<rtp-codec name="G.711"> <rtp-codec name="audio/basic">
<decoding>10</decoding> <decoding>10</decoding>
<encoding>20</encoding> <encoding>20</encoding>
</rtp-codec> </rtp-codec>
</active-rtp-sessions> </active-rtp-sessions>
<active-mixer-sessions> <active-mixer-sessions>
<active-mix conferenceid="7cfgs43"> <active-mix conferenceid="7cfgs43">
<rtp-codec name="G.711"> <rtp-codec name="audio/basic">
<decoding>3</decoding> <decoding>3</decoding>
<encoding>3</encoding> <encoding>3</encoding>
</rtp-codec> </rtp-codec>
</active-mix> </active-mix>
</active-mixer-sessions> </active-mixer-sessions>
<non-active-rtp-sessions> <non-active-rtp-sessions>
<rtp-codec name="G.711"> <rtp-codec name="audio/basic">
<decoding>50</decoding> <decoding>50</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</non-active-rtp-sessions> </non-active-rtp-sessions>
<non-active-mixer-sessions> <non-active-mixer-sessions>
<non-active-mix available="15"> <non-active-mix available="15">
<rtp-codec name="G.711"/> <rtp-codec name="audio/basic"/>
</non-active-mix> </non-active-mix>
</non-active-mixer-sessions> </non-active-mixer-sessions>
<media-server-status>active</media-server-status> <media-server-status>active</media-server-status>
<supported-codecs> <supported-codecs>
<supported-codecs name="G.711"> <supported-codecs name="audio/basic">
<supported-codec-package name="msc-ivr"> <supported-codec-package name="msc-ivr/1.0">
<supported-actions>encoding</supported-actions> <supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions> <supported-actions>decoding</supported-actions>
</supported-codec-package> </supported-codec-package>
<supported-codec-package name="msc-mixer"> <supported-codec-package name="msc-mixer/1.0">
<supported-actions>encoding</supported-actions> <supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions> <supported-actions>decoding</supported-actions>
</supported-codec-package> </supported-codec-package>
</supported-codecs> </supported-codecs>
</supported-codecs> </supported-codecs>
<application-data>Testbed Prototype</application-data> <application-data>Testbed Prototype</application-data>
<file-formats> <file-formats>
<supported-format name="audio/x-wav"> <supported-format name="audio/x-wav">
<supported-file-package/> <supported-file-package/>
</supported-format> </supported-format>
</file-formats> </file-formats>
<max-prepared-duration> <max-prepared-duration>
<max-time max-time-seconds="3600"> <max-time max-time-seconds="3600">
<max-time-package>msc-ivr</max-time-package> <max-time-package>msc-ivr</max-time-package>
</max-time> </max-time>
</max-prepared-duration> </max-prepared-duration>
<dtmf-support> <dtmf-support>
<detect> <detect>
<dtmf-type package="msc-ivr" name="RFC4733"/> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</detect> </detect>
<generate> <generate>
<dtmf-type package="msc-ivr" name="RFC4733"/> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</generate> </generate>
<passthrough> <passthrough>
<dtmf-type package="msc-ivr" name="RFC4733"/> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</passthrough> </passthrough>
</dtmf-support> </dtmf-support>
<mixing-modes> <mixing-modes>
<audio-mixing-modes> <audio-mixing-modes>
<audio-mixing-mode package="msc-ivr"> <audio-mixing-mode package="msc-ivr/1.0">
nbest nbest
</audio-mixing-mode> </audio-mixing-mode>
</audio-mixing-modes> </audio-mixing-modes>
<video-mixing-modes activespeakermix="true" vas="true"> <video-mixing-modes activespeakermix="true" vas="true">
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
single-view single-view
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
dual-view dual-view
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
dual-view-crop dual-view-crop
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
dual-view-2x1 dual-view-2x1
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
dual-view-2x1-crop dual-view-2x1-crop
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
quad-view quad-view
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
multiple-5x1 multiple-5x1
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
multiple-3x3 multiple-3x3
</video-mixing-mode> </video-mixing-mode>
<video-mixing-mode package="msc-mixer"> <video-mixing-mode package="msc-mixer/1.0">
multiple-4x4 multiple-4x4
</video-mixing-mode> </video-mixing-mode>
</video-mixing-modes> </video-mixing-modes>
</mixing-modes> </mixing-modes>
<supported-tones> <supported-tones>
<supported-country-codes> <supported-country-codes>
<country-code package="msc-ivr">GB</country-code> <country-code package="msc-ivr/1.0">GB</country-code>
<country-code package="msc-ivr">IT</country-code> <country-code package="msc-ivr/1.0">IT</country-code>
<country-code package="msc-ivr">US</country-code> <country-code package="msc-ivr/1.0">US</country-code>
</supported-country-codes> </supported-country-codes>
<supported-h248-codes> <supported-h248-codes>
<h248-code package="msc-ivr">cg/*</h248-code> <h248-code package="msc-ivr/1.0">cg/*</h248-code>
<h248-code package="msc-ivr">biztn/ofque</h248-code> <h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
<h248-code package="msc-ivr">biztn/erwt</h248-code> <h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
<h248-code package="msc-mixer">conftn/*</h248-code> <h248-code package="msc-mixer/1.0">conftn/*</h248-code>
</supported-h248-codes> </supported-h248-codes>
</supported-tones> </supported-tones>
<streaming-modes> <streaming-modes>
<stream-mode package="msc-ivr" name="HTTP"/> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes> </streaming-modes>
<asr-tts-support> <asr-tts-support>
<asr-support> <asr-support>
<language xml:lang="en"/> <language xml:lang="en"/>
</asr-support> </asr-support>
<tts-support> <tts-support>
<language xml:lang="en"/> <language xml:lang="en"/>
</tts-support> </tts-support>
</asr-tts-support> </asr-tts-support>
<vxml-support support="false"> <vxml-support support="false">
<vxml-mode package="msc-ivr"/> <vxml-mode package="msc-ivr/1.0"/>
</vxml-support> </vxml-support>
<media-server-location> <media-server-location>
<ca:civicAddress xml:lang="it"> <ca:civicAddress xml:lang="it">
<ca:country>IT</ca:country> <ca:country>IT</ca:country>
<ca:A1>Campania</ca:A1> <ca:A1>Campania</ca:A1>
<ca:A3>Napoli</ca:A3> <ca:A3>Napoli</ca:A3>
<ca:A6>Via Claudio</ca:A6> <ca:A6>Via Claudio</ca:A6>
<ca:HNO>21</ca:HNO> <ca:HNO>21</ca:HNO>
<ca:LMK>University of Napoli Federico II</ca:LMK> <ca:LMK>University of Napoli Federico II</ca:LMK>
<ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM> <ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM>
skipping to change at page 53, line 14 skipping to change at page 58, line 35
<session-id>0GX1jCYZ8WBa</session-id> <session-id>0GX1jCYZ8WBa</session-id>
<seq>1</seq> <seq>1</seq>
</session-info> </session-info>
<packages> <packages>
<package>msc-ivr/1.0</package> <package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package> <package>msc-mixer/1.0</package>
</packages> </packages>
</generalInfo> </generalInfo>
<ivrInfo> <ivrInfo>
<ivr-sessions> <ivr-sessions>
<rtp-codec name="PCMU"> <rtp-codec name="audio/basic">
<decoding>10</decoding> <decoding>10</decoding>
<encoding>10</encoding> <encoding>10</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
<file-formats> <file-formats>
<required-format name="audio/x-wav"/> <required-format name="audio/x-wav"/>
</file-formats> </file-formats>
<streaming-modes> <streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes> </streaming-modes>
skipping to change at page 55, line 5 skipping to change at page 60, line 9
including the SDP part of the original request (3.). The MS including the SDP part of the original request (3.). The MS
negotiates this INVITE as specified in negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing [I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing
the MRB with its own CFW-related SDP. The MRB replies to the the MRB with its own CFW-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body original AS INVITE preparing a SIP 200 OK with another multipart body
(7.): this multipart body includes the Consumer response used by the (7.): this multipart body includes the Consumer response used by the
MRB to determine the right MS and the SDP returned by the MS in 5. MRB to determine the right MS and the SDP returned by the MS in 5.
The AS finally acknowledges the 200 OK (8.), and can start a CFW The AS finally acknowledges the 200 OK (8.), and can start a CFW
connection towards the MS. connection towards the MS.
Please note that, to ease the reading of the protocol contents, a
simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
payload is provided, instead of the actual boundary that would be
inserted in the SIP messages.
AS MRB MS AS MRB MS
| | | | | |
| 1. INVITE | | | 1. INVITE | |
| (multipart/mixed) | | | (multipart/mixed) | |
|---------------------->| | |---------------------->| |
| 2. 100 (Trying) | | | 2. 100 (Trying) | |
|<----------------------| | |<----------------------| |
| |--+ Extract SDP and | | |--+ Extract SDP and |
| | | MRB payloads; handle | | | | MRB payloads; handle |
| |<-+ Consumer request to | | |<-+ Consumer request to |
skipping to change at page 56, line 28 skipping to change at page 62, line 28
only the CFW-related SDP from the original INVITE;. only the CFW-related SDP from the original INVITE;.
3. the 200 OK sent by the MS back to the MRB (5.), to complete the 3. the 200 OK sent by the MS back to the MRB (5.), to complete the
CFW-related negotiation (SDP only); CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the 4. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (7.), containing both the CFW-related information original INVITE (7.), containing both the CFW-related information
sent by the MS and a Consumer <mediaResourceRequest> documenting sent by the MS and a Consumer <mediaResourceRequest> documenting
the MRB's decision to use that MS. the MRB's decision to use that MS.
1. AS -> MRB (INVITE multipart/mixed) 1. AS -> MRB (INVITE multipart/mixed)
[..] -------------------------------------
Content-Type: multipart/mixed; \ [..]
boundary="----=_Part_0_19138361.1261662356915" Content-Type: multipart/mixed;boundary="=_Part"
------=_Part_0_19138361.1261662356915 =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=- 2890844526 2890842807 IN IP4 as.example.com o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl s=MediaCtrl
c=IN IP4 as.example.com c=IN IP4 as.example.com
t=0 0 t=0 0
m=application 48035 TCP cfw m=application 48035 TCP cfw
a=connection:new a=connection:new
a=setup:active a=setup:active
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
------=_Part_0_19138361.1261662356915 ------=_Part_0_19138361.1261662356915
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \ <mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer"> xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest> <mediaResourceRequest>
<generalInfo> <generalInfo>
<session-info> <session-info>
<session-id>q79OYY0q4M6M</session-id> <session-id>q79OYY0q4M6M</session-id>
<seq>1</seq> <seq>1</seq>
</session-info> </session-info>
<packages> <packages>
<package>msc-ivr/1.0</package> <package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package> <package>msc-mixer/1.0</package>
</packages> </packages>
</generalInfo> </generalInfo>
<ivrInfo> <ivrInfo>
<ivr-sessions> <ivr-sessions>
<rtp-codec name="PCMU"> <rtp-codec name="audio/basic">
<decoding>10</decoding> <decoding>10</decoding>
<encoding>10</encoding> <encoding>10</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
<file-formats> <file-formats>
<required-format name="audio/x-wav"/> <required-format name="audio/x-wav"/>
</file-formats> </file-formats>
<streaming-modes> <streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes> </streaming-modes>
</ivrInfo> </ivrInfo>
</mediaResourceRequest> </mediaResourceRequest>
</mrbconsumer> </mrbconsumer>
------=_Part_0_19138361.1261662356915-- =_Part
3. MRB -> MS (INVITE sdp only) 3. MRB -> MS (INVITE sdp only)
[..] ------------------------------
Content-Type: application/sdp [..]
Content-Type: application/sdp
v=0 v=0
o=- 2890844526 2890842807 IN IP4 as.example.com o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl s=MediaCtrl
c=IN IP4 as.example.com c=IN IP4 as.example.com
t=0 0 t=0 0
m=application 48035 TCP cfw m=application 48035 TCP cfw
a=connection:new a=connection:new
a=setup:active a=setup:active
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
5. MRB <- MS (200 OK sdp) 5. MRB <- MS (200 OK sdp)
[..] -------------------------
Content-Type: application/sdp [..]
Content-Type: application/sdp
v=0 v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl s=MediaCtrl
c=IN IP4 ms.example.net c=IN IP4 ms.example.net
t=0 0 t=0 0
m=application 7575 TCP cfw m=application 7575 TCP cfw
a=connection:new a=connection:new
a=setup:passive a=setup:passive
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0 a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0 a=ctrl-package:msc-example-pkg/1.0
7. AS <- MRB (200 OK multipart/mixed) 7. AS <- MRB (200 OK multipart/mixed)
[..] -------------------------------------
Content-Type: multipart/mixed; \ [..]
boundary="----=_Part_1_3022359.1261662358037" Content-Type: multipart/mixed;boundary="=_Part"
------=_Part_1_3022359.1261662358037 =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl s=MediaCtrl
c=IN IP4 ms.example.net c=IN IP4 ms.example.net
t=0 0 t=0 0
m=application 7575 TCP cfw m=application 7575 TCP cfw
a=connection:new a=connection:new
a=setup:passive a=setup:passive
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0 a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0 a=ctrl-package:msc-example-pkg/1.0
------=_Part_1_3022359.1261662358037 ------=_Part_1_3022359.1261662358037
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \ <mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer"> xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200"> <mediaResourceResponse reason="Resource found" status="200">
<response-session-info> <response-session-info>
<session-id>q79OYY0q4M6M</session-id> <session-id>q79OYY0q4M6M</session-id>
<seq>1</seq> <seq>1</seq>
<expires>3600</expires> <expires>3600</expires>
<media-server-address> <media-server-address>
sip:MediaServer@ms.example.net sip:MediaServer@ms.example.net
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
=_Part
The continuation of the scenario (the AS connecting to the MS to The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for start the Control Channel, the SYNC message, etc.) are omitted for
brevity. brevity.
7. Media Service Resource Publisher Interface XML Schema 7. Media Service Resource Publisher Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publish+xml" format. mrb-publish+xml" format.
skipping to change at page 63, line 41 skipping to change at page 69, line 41
##################################################### #####################################################
--> -->
<!-- mrbresponse --> <!-- mrbresponse -->
<xsd:complexType name="mrbresponseType"> <xsd:complexType name="mrbresponseType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
maxOccurs="unbounded" processContents="lax" /> <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="status" type="status.datatype" <xsd:attribute name="status" type="status.datatype"
use="required" /> use="required" />
<xsd:attribute name="reason" type="xsd:string" /> <xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="mrbresponse" type="mrbresponseType" /> <xsd:element name="mrbresponse" type="mrbresponseType" />
<!-- <!--
##################################################### #####################################################
mrbnotification TYPE mrbnotification TYPE
##################################################### #####################################################
--> -->
skipping to change at page 81, line 4 skipping to change at page 87, line 7
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="actions.datatype"> <xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" /> <xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" /> <xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" /> <xsd:enumeration value="passthrough" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="dtmf.datatype"> <xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="INFO" />
<xsd:enumeration value="RFC4733" /> <xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" /> <xsd:enumeration value="Media" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="streammode.datatype"> <xsd:simpleType name="streammode.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="boolean.datatype"> <xsd:simpleType name="boolean.datatype">
skipping to change at page 101, line 34 skipping to change at page 107, line 34
<xsd:simpleType name="action.datatype"> <xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="remove" /> <xsd:enumeration value="remove" />
<xsd:enumeration value="update" /> <xsd:enumeration value="update" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="dtmf.datatype"> <xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="INFO" />
<xsd:enumeration value="RFC4733" /> <xsd:enumeration value="RFC4733" />
<xsd:enumeration value="Media" /> <xsd:enumeration value="Media" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="boolean.datatype"> <xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" /> <xsd:enumeration value="true" />
<xsd:enumeration value="false" /> <xsd:enumeration value="false" />
</xsd:restriction> </xsd:restriction>
skipping to change at page 104, line 5 skipping to change at page 109, line 30
uses either the Hypertext Transfer Protocol (HTTP) or Session uses either the Hypertext Transfer Protocol (HTTP) or Session
Initiation Protocol (SIP) as the mechanism for clients to connect to Initiation Protocol (SIP) as the mechanism for clients to connect to
an MRB to request media resources. In the case of the HTTP use, any an MRB to request media resources. In the case of the HTTP use, any
binding using the Consumer interface MUST be capable of being binding using the Consumer interface MUST be capable of being
transacted over TLS, as described in RFC 2818 [RFC2818]. In the case transacted over TLS, as described in RFC 2818 [RFC2818]. In the case
of the SIP use, the appropriate security considerations included in of the SIP use, the appropriate security considerations included in
the Media Control Channel Framework specification MUST be used in the Media Control Channel Framework specification MUST be used in
conjunction with this specification to protect interactions between a conjunction with this specification to protect interactions between a
client requesting media resources and an MRB. client requesting media resources and an MRB.
It is also worth noting that in In-line mode (both IAMM and IUMM) the
MRB may act as a Back-to-Back User Agent (B2BUA). This means that,
as a B2BUA, the MRB may happen to modify SIP bodies: it is the case,
for instance, of the IAMM handling multipart/mixed payloads. This
impacts the ability to use any SIP security feature that protects the
body (e.g., RFC4474, s/mime, etc.) unless the MRB intermediates the
security association. This should be taken into account when
implementing an MRB compliant with this specification.
Finally, it is worthwhile to also discuss authorization issues
related to the specification. Neither the Publishing nor the
Consumer interface provide an explicit means for implementing
authentication, i.e., they do not envisage protocol messages to make
sure, for instance, that only authorized Application Servers can make
use of the services provided by a MRB. Nevertheless, considering
both the interfaces are transported in well-established protocols
(HTTP, SIP, CFW), support for such an functionality can be expressed
by means of the authentication mechanisms provided by the protocol
themselves. Therefore, any MRB-aware entity (Application Servers,
Media Servers, Media Resource Brokers themselves) MUST support the
HTTP and SIP Digest access authentication. That said, the usage of
such Digest access authentications is recommended and not mandatory,
which means MRB-aware entities MAY exploit it in deployment.
10. IANA Considerations 10. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
10.1. application/mrb-publish+xml MIME Type 10.1. Control Package Registration
MIME media type name: application This section registers a new Media Control Channel Framework package,
per the instructions in Section 13.1 of
[I-D.ietf-mediactrl-sip-control-framework].
MIME subtype name: mrb-publish+xml To: ietf-sip-control@iana.org
Mandatory parameters: none Subject: Registration of new Channel Framework package
Optional parameters: Same as charset parameter application/xml as Package Name: mrb-publish/1.0 [NOTE TO IANA/RFC-EDITOR: Please
specified in RFC 3023 [RFC3023]. replace XXXX with the RFC number for this specification.]
Encoding considerations: Same as encoding considerations of Published Specification(s): RFCXXXX Person and email address to
application/xml as specified in RFC 3023 [RFC3023]. contact for further information: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
Security considerations: See Section 10 of RFC 3023 [RFC3023] and 10.2. application/mrb-publish+xml MIME Type
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none. MIME media type name: application
Published specification: This document. MIME subtype name: mrb-publish+xml
Applications which use this media type: This document type has Mandatory parameters: none
been used to support a Media Resource Broker (MRB) entity.
Additional Information: Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Magic Number: None Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
File Extension: .xdf Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Macintosh file type code: "TEXT" Interoperability considerations: none.
Personal and email address for further information: Chris Published specification: This document.
Boulton, chris@ns-technologies.com
Intended usage: COMMON Applications which use this media type: This document type has been
used to support a Media Resource Broker (MRB) entity.
Author/Change controller: The IETF. Additional Information:
Figure 14 Magic Number: None
10.2. application/mrb-consumer+xml MIME Type File Extension: .xdf
MIME media type name: application Macintosh file type code: "TEXT"
MIME subtype name: mrb-consumer+xml Personal and email address for further information: Chris Boulton,
chris@ns-technologies.com
Mandatory parameters: none Intended usage: COMMON
Optional parameters: Same as charset parameter application/xml as Author/Change controller: The IETF.
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of 10.3. application/mrb-consumer+xml MIME Type
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and MIME media type name: application
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
Interoperability considerations: none. MIME subtype name: mrb-consumer+xml
Published specification: This document. Mandatory parameters: none
Applications which use this media type: This document type has Optional parameters: Same as charset parameter application/xml as
been used to support a Media Resource Broker (MRB) entity. specified in RFC 3023 [RFC3023].
Additional Information: Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Magic Number: None Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].
File Extension: .xdf Interoperability considerations: none.
Macintosh file type code: "TEXT" Published specification: This document.
Personal and email address for further information: Chris Applications which use this media type: This document type has been
Boulton, chris@ns-technologies.com used to support a Media Resource Broker (MRB) entity.
Intended usage: COMMON Additional Information:
Author/Change controller: The IETF. Magic Number: None
Figure 15 File Extension: .xdf
Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton,
chris@ns-technologies.com
Intended usage: COMMON
Author/Change controller: The IETF.
10.4. URN Sub-Namespace Registration for mrb-publish
Please register the URN name space
"urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish".
The template is in Section 7.
10.5. URN Sub-Namespace Registration for mrb-consumer
Please register the URN name space
"urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer".
The template is in Section 8.
10.6. XML Schema Registration for mrb-publish
Please register the schema for mrb-publish:
URI: urn:ietf:params:xml:ns:mrb-publish
ID: mrb-publish
Filename: mbr-publish
Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org)
Schema: The XML for the schema is in Section 7 of this document.
10.7. XML Schema Registration for mrb-consumer
Please register the schema for mrb-consumer:
URI: urn:ietf:params:xml:ns:mrb-consumer
ID: mrb-consumer
Filename: mbr-consumer
Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org)
Schema: The XML for the schema is in Section 8 of this document.
11. Changes 11. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
11.1. Changes from 02 Version 11.1. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are
only provided for readability.
o Clarified the distinction between 'deactivated' and 'unavailable'.
o Added text to the status codes in both Publish and Consumer
responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the
Consumer interface.
o Added additional IANA considerations, that were missing in the
previous versions of the document.
o Added text to the security considerations.
11.2. Changes from 02 Version
o Added examples in Section 6. o Added examples in Section 6.
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.
11.2. Changes from 01 Version 11.3. 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 106, line 40 skipping to change at page 115, line 17
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.
11.3. Changes from 00 Version 11.4. 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.
12. Acknowledgments 12. Acknowledgments
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
design team consisted of Gary Munson, Adnan Saleem, Michael Trank, design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors
would also like to thank John Dally, Simon Romano, Henry Lum and would also like to thank John Dally, Simon Romano, Henry Lum,
Christian Groves for input into this specification. Christian Groves and Jonathan Lennox for input into this
specification.
Ben Campbell carried out the RAI expert review on this specification
and provided a great deal of invaluable input.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ISO.3166-1]
International Organization for Standardization, "Codes for
the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard 3166-
1:1997, 1997.
[ISO.639.1988] [ISO.639.1988]
International Organization for Standardization, "Code for International Organization for Standardization, "Code for
the representation of names of languages, 1st edition", the representation of names of languages, 1st edition",
ISO Standard 639, 1988. ISO Standard 639, 1988.
[ITU-T.Q.1950]
International Telecommunication Union - Telecommunication
Standardization Bureau, "Call Bearer Control (CBC)
Protocol", ITU-T Recommendation Q.1950.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 108, line 50 skipping to change at page 118, line 16
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Nielsen, H., Gudgin, M., Hadley, M., Moreau, J., and N. Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
Framework", World Wide Web Consortium FirstEdition REC- World Wide Web Consortium FirstEdition REC-soap12-part1-
soap12-part1-20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Hadley, M., Mendelsohn, N., Nielsen, H., Moreau, J., and Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H.
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-ivr-control-package]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, McGlashan, S., Melanchuk, T., and C. Boulton, "An
"Media Control Channel Framework (CFW) Call Flow Interactive Voice Response (IVR) Control Package for the
Examples", draft-ietf-mediactrl-call-flows-02 (work in Media Control Channel Framework",
progress), October 2009. draft-ietf-mediactrl-ivr-control-package-08 (work in
progress), February 2010.
[I-D.ietf-mediactrl-sip-control-framework] [I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-11 (work in draft-ietf-mediactrl-sip-control-framework-11 (work in
progress), October 2009. progress), October 2009.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
Parameter for "Bucket" Media Types", RFC 4281,
November 2005.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
Services", RFC 5552, May 2009.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media [RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009. Server Control", RFC 5567, June 2009.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
 End of changes. 236 change blocks. 
574 lines changed or deleted 947 lines changed or added

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