draft-ietf-mediactrl-mrb-10.txt   draft-ietf-mediactrl-mrb-11.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: February 2, 2012 Meetecho Expires: July 12, 2012 Meetecho
G. Munson G. Munson
AT&T AT&T
August 1, 2011 January 9, 2012
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-10 draft-ietf-mediactrl-mrb-11
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 2, 2012. This Internet-Draft will expire on July 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publish Interface . . . . . . . . 14 5.1. Media Server Resource Publish Interface . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . 15 5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 29 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 29
5.2. Media Service Resource Consumer Interface . . . . . . . 31 5.2. Media Service Resource Consumer Interface . . . . . . . 31
5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 31 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 31
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 34 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 34
5.2.4. Media Service Resource Request . . . . . . . . . . . 37 5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 37
5.2.5. Media Service Resource Response . . . . . . . . . . . 49 5.2.5. Media Service Resource Request . . . . . . . . . . . 38
5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 51 5.2.6. Media Service Resource Response . . . . . . . . . . . 49
6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 53 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 52
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 54 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 54
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 55 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 55
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 56
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 57 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 63 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 58
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 63 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 64
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 66 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 64
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 67
10. Media Service Resource Publisher Interface XML Schema . . . . 82 10. Media Service Resource Publisher Interface XML Schema . . . . 82
11. Media Service Resource Consumer Interface XML Schema . . . . 104 11. Media Service Resource Consumer Interface XML Schema . . . . 104
12. Security Considerations . . . . . . . . . . . . . . . . . . . 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 125
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126
13.1. Control Package Registration . . . . . . . . . . . . . . 126 13.1. Media Control Channel Framework Package Registration . . 126
13.2. application/mrb-publish+xml MIME Type . . . . . . . . . 126 13.2. application/mrb-publish+xml MIME Type . . . . . . . . . 126
13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 127 13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 127
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 128 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 128
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 128 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 128
13.6. XML Schema Registration for mrb-publish . . . . . . . . 128 13.6. XML Schema Registration for mrb-publish . . . . . . . . 128
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 128 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 129
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14.1. Changes from 09 Version . . . . . . . . . . . . . . . . 130 14.1. Changes from 10 Version . . . . . . . . . . . . . . . . 130
14.2. Changes from 08 Version . . . . . . . . . . . . . . . . 130 14.2. Changes from 09 Version . . . . . . . . . . . . . . . . 130
14.3. Changes from 07 Version . . . . . . . . . . . . . . . . 130 14.3. Changes from 08 Version . . . . . . . . . . . . . . . . 130
14.4. Changes from 06 Version . . . . . . . . . . . . . . . . 130 14.4. Changes from 07 Version . . . . . . . . . . . . . . . . 130
14.5. Changes from 05 Version . . . . . . . . . . . . . . . . 131 14.5. Changes from 06 Version . . . . . . . . . . . . . . . . 131
14.6. Changes from 04 Version . . . . . . . . . . . . . . . . 131 14.6. Changes from 05 Version . . . . . . . . . . . . . . . . 131
14.7. Changes from 03 Version . . . . . . . . . . . . . . . . 131 14.7. Changes from 04 Version . . . . . . . . . . . . . . . . 131
14.8. Changes from 02 Version . . . . . . . . . . . . . . . . 132 14.8. Changes from 03 Version . . . . . . . . . . . . . . . . 132
14.9. Changes from 01 Version . . . . . . . . . . . . . . . . 132 14.9. Changes from 02 Version . . . . . . . . . . . . . . . . 132
14.10. Changes from 00 Version . . . . . . . . . . . . . . . . 132 14.10. Changes from 01 Version . . . . . . . . . . . . . . . . 132
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 133 14.11. Changes from 00 Version . . . . . . . . . . . . . . . . 133
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 134 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 134
16.1. Normative References . . . . . . . . . . . . . . . . . . 134 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 135
16.2. Informative References . . . . . . . . . . . . . . . . . 135 16.1. Normative References . . . . . . . . . . . . . . . . . . 135
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 16.2. Informative References . . . . . . . . . . . . . . . . . 136
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138
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 4, line 26 skipping to change at page 4, line 26
be interoperable using the architecture and protocols produced by the be interoperable using the architecture and protocols produced by the
MediaCtrl work group. It should be possible for a controlling entity MediaCtrl work group. It should be possible for a controlling entity
to be assisted in Media Server selection so that the most appropriate to be assisted in Media Server selection so that the most appropriate
resource is selected for a particular operation. The importance resource is selected for a particular operation. The importance
increases when you introduce a flexible level of deployment increases when you introduce a flexible level of deployment
scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567 scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567
[RFC5567] documents. These documents make statements like "it should [RFC5567] documents. These documents make statements like "it should
be possible to have a many-to-many relationship between Application be possible to have a many-to-many relationship between Application
Servers and Media Servers that use this protocol". This leads to the Servers and Media Servers that use this protocol". This leads to the
following deployment architectures being possible when considering following deployment architectures being possible when considering
media resources. media resources, to provide what can be effectively described as
Media Resource Brokering.
The simplest deployment view is illustrated in Figure 1. The simplest deployment view is illustrated in Figure 1.
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Application | | Media | | Application | | Media |
| Server |<-------MS Control------>| Server | | Server |<-------MS Control------>| Server |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Basic Architecture Figure 1: Basic Architecture
skipping to change at page 6, line 23 skipping to change at page 6, line 23
| Server |<-----+-MS Control-+---->| Server | | Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---+-----+---+ | | +---+-----+---+ +---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media | | Application | | +---->| Media |
| Server |<-----+ | Server | | Server |<-----+ | Server |
+-------------+ +---+-----+---+ +-------------+ +---+-----+---+
Figure 4: Basic Architecture Figure 4: Basic Architecture
The remaining sections in this specification will focus on a new
entity called a Media Resource Broker (MRB) which can be utilised in
the deployment architectures described previously in this section.
The MRB entity provides the ability to obtain media resource
information and appropriately allocate(broker) on behalf of client
applications.
The high level deployment options discussed in this section rely on The high level deployment options discussed in this section rely on
network architecture and policy to prohibit inappropriate use. Such network architecture and policy to prohibit inappropriate use. Such
policies are out of the scope of this document. policies are out of the scope of this document.
This document will take a look at the specific problem areas related This document will take a look at the specific problem areas related
to such deployment architectures. It is recognised that the to such deployment architectures. It is recognised that the
solutions proposed in this document should be equally adaptable to solutions proposed in this document should be equally adaptable to
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and document are to be interpreted as described in RFC 2119 [RFC2119].
"OPTIONAL".
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 [RFC6230] 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 Media Resource Broker (MRB): A logical entity that is responsible
for 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) Query MRB: An instantiation of an MRB (See previous definition)
that provides an interface for an Application Server to retrieve that provides an interface for an Application Server to retrieve
the address of an appropriate Media Server. The result returned the address of an appropriate Media Server. The result returned
to the Application Server can be influenced by information to the Application Server can be influenced by information
contained 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.
CFW: Media Control Channel Framework, as specified in [RFC6230].
Within the context of In-line MRBs, additional terms are defined: Within the context of In-line MRBs, additional terms are defined:
In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1. In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1.
In-line Unaware MRB Mode (IUMM): Defined in Section 5.3. In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
The document will often specify when a specific identifier in a The document will often specify when a specific identifier in a
protocol message needs to be unique. Unless differently stated, such protocol message needs to be unique. Unless differently stated, such
uniqueness will always need to be intended within the scope of the uniqueness will always need to be intended within the scope of the
Media Servers controlled by the same Media Resource Broker. The Media Servers controlled by the same Media Resource Broker. The
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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 a MS
resource, such as resource allocation rules across different resource, such as resource allocation rules across different
applications, planned or unplanned downtime of Media Server applications, planned or unplanned downtime of Media Server
resources, the planned addition of future Media Server resources, or resources, the planned addition of future Media Server resources, or
MS resource capacity models. How the MRB acquires such information MS resource capacity models. How the MRB acquires such information
is outside the scope of this document. The techniques used for is outside the scope of this document. The techniques used for
selecting an appropriate Media Resource by an MRB is outside the selecting an appropriate Media Resource by an MRB is outside the
scope of this document. scope of this document.
4. Deployment Scenario Options 4. Deployment Scenario Options
skipping to change at page 12, line 50 skipping to change at page 12, line 50
inspecting other information in the request from the AS; for inspecting other information in the request from the AS; for
example, SDP content, or address of the requesting AS, or example, SDP content, or address of the requesting AS, or
additional Request-URI parameters as per RFC 4240 [RFC4240]. additional Request-URI parameters as per RFC 4240 [RFC4240].
In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of
clients requiring media services who are aware of an MRB and its clients requiring media services who are aware of an MRB and its
operation. In particular it allows the AS to explicitly the operation. In particular it allows the AS to explicitly the
convey the same kinds of MS characteristics desired as does the convey the same kinds of MS characteristics desired as does the
Query MRB mode (as in Section 5.2). Query MRB mode (as in Section 5.2).
In either role, the MRB would deduce that the selected MS resources In either role, signalling as specified by the Media Control Channel
are no longer needed when the AS or MS terminates the corresponding Framework ([RFC6230]) would be involved, and the MRB would deduce
dialog. The two modes are discussed in more detail in Section 5.3. that the selected MS resources are no longer needed when the AS or MS
terminates the corresponding dialog. The two modes are discussed in
more detail in Section 5.3.
5. MRB Interface Definitions 5. MRB Interface Definitions
As discussed in previous sections in this document, the intention is As discussed in previous sections in this document, the intention is
to provide a tool-kit for a variety of deployment architectures where to provide a tool-kit for a variety of deployment architectures where
media resource brokering can take place. As a result, two main media resource brokering can take place. As a result, two main
interfaces are required to support the differing requirements. The interfaces are required to support the differing requirements. The
two interfaces are described in the remainder of this section and two interfaces are described in the remainder of this section and
have been named the 'Media Server Resource Publish' and 'Media Server have been named the 'Media Server Resource Publish' and 'Media Server
Resource Consumer' interfaces. These two interfaces have extremely Resource Consumer' interfaces. These two interfaces have extremely
skipping to change at page 15, line 15 skipping to change at page 15, line 15
It is also worth noting that, while the scope of the MRB is It is also worth noting that, while the scope of the MRB is
definitely on providing interested Application Servers with the definitely on providing interested Application Servers with the
available resources, the MRB also allows for the retrieval of available resources, the MRB also allows for the retrieval of
information about the currently occupied resources. While this is of information about the currently occupied resources. While this is of
course a relevant piece of information (e.g., for monitoring course a relevant piece of information (e.g., for monitoring
purposes), such a functionality inevitably raises security purposes), such a functionality inevitably raises security
considerations, and implementations should take this into account. considerations, and implementations should take this into account.
See Section 12 for more details. See Section 12 for more details.
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 ([RFC6230]) as the basis for interaction between a Media Server and
interaction between a Media Server and an MRB. The Media Control an MRB. The Media Control Channel Framework uses an extension
Channel Framework uses an extension mechanism to allow specific mechanism to allow specific usages which are known as control
usages which are known as control packages. Section 5.1.1 defines packages. Section 5.1.1 defines the control package that MUST be
the control package that MUST be implemented by any Media Server implemented by any Media Server wanting to interact with an MRB
wanting to interact with an MRB entity. entity.
Please note that it is out of scope how an MRB knows what MSs should Please note that it is out of scope how an MRB knows what MSs should
be queried for publishing information. be queried for publishing information.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
This section fulfils the mandatory requirement for information that This section fulfils the mandatory requirement for information that
must be specified during the definition of a Control Framework must be specified during the definition of a Control Framework
Package, as detailed in Section 8 of Package, as detailed in Section 8 of [RFC6230].
[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".
5.1.1.2. Framework Message Usage 5.1.1.2. Framework Message Usage
skipping to change at page 16, line 9 skipping to change at page 16, line 8
and event notifications. Requests are carried in CONTROL message and event notifications. Requests are carried in CONTROL message
bodies; <mrbrequest> element is defined as a package request. This bodies; <mrbrequest> element is defined as a package request. This
request can be used for creating new subscriptions and updating/ request can be used for creating new subscriptions and updating/
removing existing subscriptions. Event notifications are also removing existing subscriptions. Event notifications are also
carried in CONTROL message bodies; the <mrbnotification> element is carried in CONTROL message bodies; the <mrbnotification> element is
defined for package event notifications. Responses are carried defined for package event notifications. Responses are carried
either in REPORT message or Control Framework 200 response bodies; either in REPORT message or Control Framework 200 response bodies;
the <mrbresponse> element is defined as a package level response. the <mrbresponse> element is defined as a package level response.
Note that package responses are different from framework response Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of codes. Framework error response codes (see Section 7 of [RFC6230])
[I-D.ietf-mediactrl-sip-control-framework]) are used when the request are used when the request or event notification is invalid; for
or event notification is invalid; for example, a request has invalid example, a request has invalid XML (400), or is not understood (500).
XML (400), or is not understood (500). Package level responses are Package level responses are carried in framework 200 response or
carried in framework 200 response or REPORT message bodies. This REPORT message bodies. This package's response codes are defined in
package's response codes are defined in Section 5.1.5. Section 5.1.5.
5.1.1.3. Common XML Support 5.1.1.3. Common XML Support
The Media Control Channel Framework The Media Control Channel Framework [RFC6230] requires a Control
[I-D.ietf-mediactrl-sip-control-framework] requires a Control Package Package definition to specify if the attributes for media dialog or
definition to specify if the attributes for media dialog or
conference references are required. conference references are required.
The Publish interface defined in Section 10 does import and make use The Publish interface defined in Section 10 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
The Consumer interface defined in Section 11 does import and make use The Consumer interface defined in Section 11 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
skipping to change at page 17, line 18 skipping to change at page 17, line 12
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 10. Section 10.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The content of an <mrbpublish> element is zero or more of the The <mrbpublish> element has zero or more of the following
following attributes: attributes:
version: a token specifying the mrb-publish package version. The version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The content of an <mrbpublish> element is the following child The <mrbpublish> element has the following child elements, only one
elements, only one of which is allowed to occur in a request. of which is allowed to occur in a request.
<mrbrequest> for sending an MRB request. See Section 5.1.3. <mrbrequest> for sending an MRB request. See Section 5.1.3.
<mrbresponse> for sending an MRB response. See Section 5.1.5. <mrbresponse> for sending an MRB response. See Section 5.1.5.
<mrbnotification> for sending an MRB notification. See <mrbnotification> for sending an MRB notification. See
Section 5.1.4. Section 5.1.4.
5.1.3. <mrbrequest> 5.1.3. <mrbrequest>
This section defines the <mrbrequest> element used to initiate This section defines the <mrbrequest> element used to initiate
requests from an MRB to a Media Server. The element describes requests from an MRB to a Media Server. The element describes
information relevant for the interrogation of a media server. information relevant for the interrogation of a media server.
The content of an <mrbrequest> element has no defined attributes. The <mrbrequest> element has no defined attributes.
The content of an <mrbrequest> element is zero or more of following The <mrbrequest> element has zero or more of the following child
child elements: elements:
<subscription> for initiating a subscription to a Media Server <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1. from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of Media Server to provide the details relating to the configuration of
updates. This element can be used either to request a new updates. This element can be used either to request a new
subscription or to update an existing one (e.g., to change the subscription or to update an existing one (e.g., to change the
frequency of the updates), and to remove ongoing subscriptions as frequency of the updates), and to remove ongoing subscriptions as
well (e.g., to stop an indefinite update). The MRB will inform the well (e.g., to stop an indefinite update). The MRB will inform the
Media Server how long it wishes to receive updates for and the Media Server how long it wishes to receive updates for and the
frequency that updates should be sent. Updates related to the frequency that updates should be sent. Updates related to the
subscription are sent using the <mrbnotification> element. subscription are sent using the <mrbnotification> element.
The content of a <subscription> element has the following attributes: The <subscription> element has the following attributes:
id: indicates a unique token representing the subscription session id: indicates a unique token representing the subscription session
between the MRB and the Media Server. The attribute MUST be between the MRB and the Media Server. The attribute MUST be
present. present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
subscription command. The first subscription MUST have 1 as subscription command. The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the 'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
skipping to change at page 18, line 44 skipping to change at page 18, line 34
* The value of 'update' instructs the MS to attempt to update an * The value of 'update' instructs the MS to attempt to update an
existing subscription. existing subscription.
* The value of 'remove' instructs the MS to attempt to remove an * The value of 'remove' instructs the MS to attempt to remove an
existing subscription and consequently stop any ongoing related existing subscription and consequently stop any ongoing related
notification. notification.
The attribute MUST be present. The attribute MUST be present.
The content of a <subscription> element has zero or more of the The <subscription> element has zero or more of the following child
following child elements: elements:
expires: Provides the amount of time in seconds that a subscription <expires>: Provides the amount of time in seconds that a
should be installed for notifications at the Media Server. Once subscription should be installed for notifications at the Media
the amount of time has passed, the subscription expires and the Server. Once the amount of time has passed, the subscription
MRB has to subscribe again in case it is still interested in expires and the MRB has to subscribe again in case it is still
receiving notifications from the MS. The element MAY be present. interested in receiving notifications from the MS. The element
MAY be present.
minfrequency: Provides the minimum frequency in seconds that the <minfrequency>: Provides the minimum frequency in seconds that the
MRB wishes to receive notifications from the MS. The element MAY MRB wishes to receive notifications from the MS. The element MAY
be present. be present.
maxfrequency: Provides the maximum frequency in seconds that the <maxfrequency>: Provides the maximum frequency in seconds that the
MRB wishes to receive notifications from the MS. The element MAY MRB wishes to receive notifications from the MS. The element MAY
be present. be present.
Please note that these three optional pieces of information provided Please note that these three optional pieces of information provided
by the MRB only act as a suggestion: the MS MAY change the proposed 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 values if it considers the suggestions unacceptable (e.g., if the MRB
has requested a too high notification frequency). In such case, the has requested a too high notification frequency). In such case, the
request would not fail, but the updated, acceptable values would be request would not fail, but the updated, acceptable values would be
reported in the <mrbresponse> accordingly. reported in the <mrbresponse> accordingly.
5.1.4. <mrbnotification> 5.1.4. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The Server to an MRB to provide the details relating current status. The
Media Server will inform the MRB of its current status as defined by Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element. using the <mrbnotification> element.
The content of an <mrbnotification> element has the following The <mrbnotification> element has the following attributes:
attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute MUST be present. the <subscription> element. The attribute MUST be present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
notification update. The first notification MUST have 1 as notification update. The first notification MUST have 1 as
'seqnumber', and following notifications MUST increment by 1 the 'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
skipping to change at page 20, line 6 skipping to change at page 19, line 46
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system wide
identifier for a Media Server instance. The element MUST be present. identifier for a Media Server instance. The element MUST be present.
5.1.4.2. <supported-packages> 5.1.4.2. <supported-packages>
The <supported-packages> element provides the list of Media Control The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element MAY be Channel Packages supported by the media server. The element MAY be
present. present.
The content of a <supported-packages> element has no attributes. The <supported-packages> element has no attributes.
The content of a <supported-packages> element has zero or more of the The <supported-packages> element has zero or more of the following
following child elements: child elements:
package: The <package> element the name of a package supported by <package>: The <package> element gives the name of a package
the media server. The <package> element has a single attribute, supported by the media server. The <package> element has a single
'name', which provides the name of the supported Media Control attribute, 'name', which provides the name of the supported Media
Channel Framework package, compliant with the specification in the Control Channel Framework package, compliant with the
related IANA registry (e.g., "msc-ivr/1.0"). 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 MAY be present. element MAY be present.
The content of an <active-rtp-sessions> element has no attributes. The <active-rtp-sessions> element has no attributes.
The content of an <active-rtp-sessions> element has zero or more of The <active-rtp-sessions> element has zero or more of the following
the following child elements: child elements:
rtp-codec: Describes a supported codec and the number of active <rtp-codec>: Describes a supported codec and the number of active
sessions using that codec. The <rtp-codec> element has one sessions using that codec. The <rtp-codec> element has one
attribute. The value of the attribute 'name' is a MIME media type attribute. The value of the attribute 'name' is a MIME media type
(which can include parameters per [RFC4281]). The <rtp-codec> (which can include parameters per [RFC6381]). The <rtp-codec>
element has two child elements. The child element, <decoding>, element has two child elements. The child element, <decoding>,
has as content the decimal number of RTP sessions being decoded has as content the decimal number of RTP sessions being decoded
using the specified codec. The child element, <encoding>, has as using the specified codec. The child element, <encoding>, has as
content the decimal number of RTP sessions being encoded using the content the decimal number of RTP sessions being encoded using the
specified codec. specified codec.
5.1.4.4. <active-mixer-sessions> 5.1.4.4. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element MAY be present. the current active mixed RTP sessions. The element MAY be present.
The content of an <active-mixer-sessions> element has no attributes. The <active-mixer-sessions> element has no attributes.
The content of an <active-mixer-sessions> element has zero or more of The <active-mixer-sessions> element has zero or more of the following
the following child elements: child elements:
active-mix: Describes a mixed active RTP session. The <active-mix> <active-mix>: Describes a mixed active RTP session. The <active-
element has one attribute. The value of the attribute mix> element has one attribute. The value of the attribute
'conferenceid' is the name of the mix. The <active-mix> element 'conferenceid' is the name of the mix. The <active-mix> element
has one child element. The child element, <rtp-codec>, contains has one child element. The child element, <rtp-codec>, contains
the same information relating to RTP sessions as defined in the same information relating to RTP sessions as defined in
Section 5.1.4.3. The element MAY be present. Section 5.1.4.3. The 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 MAY be the currently available inactive RTP sessions. The element MAY be
present. present.
The content of a <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The content of a <non-active-rtp-sessions> element has zero or more The <non-active-rtp-sessions> element has zero or more of the
of the following child elements: following child elements:
rtp-codec: Describes a supported codec and the number of non-active <rtp-codec>: Describes a supported codec and the number of non-
sessions for that codec. The <rtp-codec> element has one active sessions for that codec. The <rtp-codec> element has one
attribute. The value of the attribute 'name' is a MIME media type attribute. The value of the attribute 'name' is a MIME media type
(which can include parameters per [RFC4281]). The <rtp-codec> (which can include parameters per [RFC6381]). The <rtp-codec>
element has two child elements. The child element, <decoding>, element has two child elements. The child element, <decoding>,
has as content the decimal number of RTP sessions available for has as content the decimal number of RTP sessions available for
decoding using the specified codec. The child element, decoding using the specified codec. The child element,
<encoding>, has as content the decimal number of RTP sessions <encoding>, has as content the decimal number of RTP sessions
available for encoding using the specified codec. available for encoding using the specified codec.
5.1.4.6. <non-active-mixer-sessions> 5.1.4.6. <non-active-mixer-sessions>
The <non-active-mixer-sessions> element provides information The <non-active-mixer-sessions> element provides information
detailing the current inactive mixed RTP sessions. The element MAY detailing the current inactive mixed RTP sessions. The element MAY
be present. be present.
The content of an <non-active-rtp-sessions> element has no The <non-active-rtp-sessions> element has no attributes.
attributes.
The content of an <non-active-mixer-sessions> element has zero of The <non-active-mixer-sessions> element has zero of more of the
more of the following child element: following child element:
non-active-mix: Describes available mixed RTP sessions. The <non- <non-active-mix>: Describes available mixed RTP sessions. The
active-mix> element has one attribute. The value of the attribute <non-active-mix> element has one attribute. The value of the
'available' is the number of mixes that could be used using that attribute 'available' is the number of mixes that could be used
profile. The <non-active-mix> element has one child element. The using that profile. The <non-active-mix> element has one child
child element, <rtp-codec>, contains the same information relating element. The child element, <rtp-codec>, contains the same
to RTP sessions as defined in Section 5.1.4.5. The element MAY be information relating to RTP sessions as defined in
present. 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 MUST be present. It current status of the media server. The element MUST be present. It
can return one of the following values: can return one of the following values:
active: Indicating that the Media Server is available for service. active: Indicating that the Media Server is available for service.
deactivated: Indicating that the Media Server has been withdrawn deactivated: Indicating that the Media Server has been withdrawn
from service, and as such should not be contacted before it from service, and as such requests should not be sent to it before
becomes 'active' again. it becomes 'active' again.
unavailable: Indicating that the Media Server continues to process unavailable: Indicating that the Media Server continues to process
past requests but cannot accept new requests, and as such should past requests but cannot accept new requests, and as such should
not be contacted before it becomes 'active' again. not be contacted before it becomes 'active' again.
The content of a <media-server-status> element has no attributes. The <media-server-status> element has no attributes.
The content of a <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 MAY be present. The element MAY be present.
The content of a <supported-codecs> element has no attributes. The <supported-codecs> element has no attributes.
The content of a <supported-codecs> element has zero or more of the The <supported-codecs> element has zero or more of the following
following child element: child element:
supported-codec: has a single attribute, 'name', which provides the <supported-codec>: has a single attribute, 'name', which provides
name of the codec providing information. A valid value is a MIME the name of the codec about which this element provides
media type which, depending on its definition, can include information. A valid value is a MIME media type which, depending
additional parameters (e.g., [RFC4281]). The <supported-codec> on its definition, can include additional parameters (e.g.,
element then has a further child element, <supported-codec- [RFC6381]). The <supported-codec> element then has a further
package>. The <supported-codec-package> element has a single child element, <supported-codec-package>. The <supported-codec-
attribute, 'name', which provides the name of the Media Control package> element has a single attribute, 'name', which provides
Channel Framework package, compliant with the specification in the the name of the Media Control Channel Framework package, compliant
related IANA registry (e.g., "msc-ivr/1.0"), for which the codec with the specification in the related IANA registry (e.g., "msc-
support applies. The <supported-codec-package> element has one ivr/1.0"), for which the codec support applies. The <supported-
further child element, <supported-actions>, which provide the codec-package> element has zero or more <supported-action>
actions that a Media Server can apply to this codec: children, each one of which describes an action that a Media
Server can apply to this codec:
* 'decode', meaning a decoder for this codec is available; * 'decode', meaning a decoder for this codec is available;
* 'encode', meaning an encoder for this codec is available; * 'encode', meaning an encoder for this codec is available;
* 'passthrough', meaning the MS is able to pass a stream encoded * 'passthrough', meaning the MS is able to pass a stream encoded
using that codec through without re-encoding. using that codec through without re-encoding.
5.1.4.9. <application-data> 5.1.4.9. <application-data>
The <application-data> element provides arbitrary application level The <application-data> element provides an arbitrary string of
data. This data is meant to only have meaning at the application characters as application level data. This data is meant to only
level logic and as such is arbitrary. The element MAY be present. have meaning at the application level logic and as such is not
otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.
The content of an <application-data> element has no attributes. The <application-data> element has no attributes.
The content of an <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 playing media. The element MAY be present. for the purpose of playing media. The element MAY be present.
The content of a <file-formats> element has no attributes. The <file-formats> element has no attributes.
The content of a <file-formats> element has zero of more the The <file-formats> element has zero of more the following child
following child elements: elements:
supported-format: has a single attribute, 'name', which provides <supported-format>: has a single attribute, 'name', which provides
the type of file format that is supported. A valid value is a the type of file format that is supported. A valid value is a
MIME media type which, depending on its definition, can include MIME media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-format> additional parameters (e.g., [RFC6381]). The <supported-format>
element then has a further child element, <supported-file- element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package, compliant with the of the Media Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.1.4.11. <max-prepared-duration> 5.1.4.11. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time a The <max-prepared-duration> element provides the maximum amount of
media dialog can be prepared in the system before it is executed. time a media dialog can be prepared in the system before it is
The element MAY be present. executed. The element MAY be present.
The content of a <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The content of a <max-prepared-duration> element has zero or more of The <max-prepared-duration> element has zero or more of the following
the following child elements: child elements:
max-time: has a single attribute, 'max-time-seconds', which <max-time>: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the time period applies. (e.g., "msc-ivr/1.0"), for which the time period applies.
5.1.4.12. <dtmf-support> 5.1.4.12. <dtmf-support>
The <dtmf-support> element supplies the supported methods to detect The <dtmf-support> element specifies the supported methods to detect
DTMF tones and to generate them. The element MAY be present. DTMF tones and to generate them. The element MAY be present.
The content of a <dtmf-support> element has no attributes. The <dtmf-support> element has no attributes.
The content of a <dtmf-support> element has zero of more of the The <dtmf-support> element has zero of more of the following child
following child elements: elements:
detect: Indicates the support for DTMF detection. The <detect> <detect>: Indicates the support for DTMF detection. The <detect>
element has no attributes. The <detect> element then has a element has no attributes. The <detect> element then has a
further child element, <dtmf-type>. The <dtmf-type> element has further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used, and it can only be either provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
generate: Indicates the support for DTMF generation. The <generate>: Indicates the support for DTMF generation. The
<generate> element has no attributes. The <generate> element then <generate> element has no attributes. The <generate> element then
has a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element
has two attributes, 'name' and 'package. The 'name' attribute has two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used, and it can only be either provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the support for passing DTMF through without <passthrough>: Indicates the support for passing DTMF through
re-encoding. The <passthrough> element has no attributes. The without re-encoding. The <passthrough> element has no attributes.
<passthrough> element then has a further child element, <dtmf- The <passthrough> element then has a further child element, <dtmf-
type>. The <dtmf-type> element has two attributes, 'name' and type>. The <dtmf-type> element has two attributes, 'name' and
'package. The 'name' attribute provides the type of DTMF being 'package. The 'name' attribute provides the type of DTMF being
used, and it can only be either 'RFC4733' [RFC4733] or 'Media' used, and it can only be either 'RFC4733' [RFC4733] or 'Media'
(tones as signals in the audio stream). The 'package' attribute (tones as signals in the audio stream). The 'package' attribute
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the DTMF type applies. (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.1.4.13. <mixing-modes> 5.1.4.13. <mixing-modes>
The <mixing-modes> element provides information about the support for The <mixing-modes> element provides information about the support for
audio and video mixing of a Media Server, specifically a list of audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video supported algorithms to mix audio and a list of supported video
presentation layouts. The element MAY be present. presentation layouts. The element MAY be present.
The content of a <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The content of a <mixing-modes> element has zero or more of the The <mixing-modes> element has zero or more of the following child
following child elements: elements:
audio-mixing-modes: Describes the available algorithms for audio <audio-mixing-modes>: Describes the available algorithms for audio
mixing. The <audio-mixing-modes> element has no attributes. The mixing. The <audio-mixing-modes> element has no attributes. The
<audio-mixing-modes> element has one child element. The child <audio-mixing-modes> element has one child element. The child
element, <audio-mixing-mode>, contains a specific available element, <audio-mixing-mode>, contains a specific available
algorithm. It has a single attribute, 'package'. The attribute algorithm. It has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the algorithm support registry (e.g., "msc-ivr/1.0"), for which the algorithm support
applies. applies.
video-mixing-modes: Describes the available video presentation <video-mixing-modes>: Describes the available video presentation
layouts and the supported functionality for what concerns video layouts and the supported functionality for what concerns video
mixing. The <video-mixing-modes> element has two attributes, mixing. The <video-mixing-modes> element has two attributes,
'vas' and 'activespeakermix'. The 'vas' attribute is of type 'vas' and 'activespeakermix'. The 'vas' attribute is of type
boolean with a value of 'true' indicating the Media Server boolean with a value of 'true' indicating the Media Server
supports automatic Voice Activated Switching. The supports automatic Voice Activated Switching. The
'activespeakermix' is of type boolean with a value of 'true' 'activespeakermix' is of type boolean with a value of 'true'
indicating that the Media Server is able to prepare an additional indicating that the Media Server is able to prepare an additional
video stream for the loudest speaker participant without its video stream for the loudest speaker participant without its
contribution. The <video-mixing-modes> element has one child contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains the element. The child element, <video-mixing-mode>, contains the
skipping to change at page 26, line 4 skipping to change at page 26, line 11
name of the Media Control Channel Framework package, compliant name of the Media Control Channel Framework package, compliant
with the specification in the related IANA registry (e.g., "msc- with the specification in the related IANA registry (e.g., "msc-
ivr/1.0"), for which the algorithm support applies. ivr/1.0"), for which the algorithm support applies.
5.1.4.14. <supported-tones> 5.1.4.14. <supported-tones>
The <supported-tones> element provides information about which tones The <supported-tones> element provides information about which tones
a media server supports. In particular, the support is reported a media server supports. In particular, the support is reported
referring to both country codes support (ISO 3166-1 [ISO.3166-1]) and referring to both country codes support (ISO 3166-1 [ISO.3166-1]) and
supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).
The element MAY be present. The element MAY be present.
The content of a <supported-tones> element has no attributes. The <supported-tones> element has no attributes.
The content of a <supported-tones> element has zero or more of the The <supported-tones> element has zero or more of the following child
following child elements: elements:
supported-country-codes: Describes the supported country codes with <supported-country-codes>: Describes the supported country codes
respect to tones. The <supported-country-codes> element has no with respect to tones. The <supported-country-codes> element has
attributes. The <supported-country-codes> has one child element. no attributes. The <supported-country-codes> has one child
The child element, <country-code>, reports support for a specific element. The child element, <country-code>, reports support for a
country code, compliant with the ISO 3166-1 [ISO.3166-1] specific country code, compliant with the ISO 3166-1 [ISO.3166-1]
specification. The <country-code> element has a single attribute, specification. The <country-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, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
in which the tones from the specified country code are supported. in which the tones from the specified country code are supported.
supported-h248-codes: Describes the supported H.248 codes with <supported-h248-codes>: Describes the supported H.248 codes with
respect to tones. The <supported-h248-codes> element has no respect to tones. The <supported-h248-codes> element has no
attributes. The <supported-h248-codes> has one child element. attributes. The <supported-h248-codes> has one child element.
The child element, <h248-code>, reports support for a specific The child element, <h248-code>, reports support for a specific
H.248 code, compliant with the ITU-T Recommendation Q.1950 H.248 code, compliant with the ITU-T Recommendation Q.1950
[ITU-T.Q.1950] specification. The codes can be either specific [ITU-T.Q.1950] specification. The codes can be either specific
(e.g., cg/dt to only report the Dial Tone from the Call Progress (e.g., cg/dt to only report the Dial Tone from the Call Progress
Tones package) or generic (e.g., cg/* to report all the tones from Tones package) or generic (e.g., cg/* to report all the tones from
the Call Progress Tones package) using wild-cards. The <h248- the Call Progress Tones package) using wild-cards. The <h248-
code> element has a single attribute, 'package'. The attribute code> element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
skipping to change at page 26, line 46 skipping to change at page 26, line 52
supported. supported.
5.1.4.15. <streaming-modes> 5.1.4.15. <streaming-modes>
The <streaming-modes> element allows the Media Server to specify The <streaming-modes> element allows the Media Server to specify
which protocols are supported for streaming to a Media Server for which protocols are supported for streaming to a Media Server for
each Media Control Channel Framework package type. For example, each Media Control Channel Framework package type. For example,
whether the Media Server supports audio streaming via RTSP, HTTP, whether the Media Server supports audio streaming via RTSP, HTTP,
NFS, etc protocols. The element MAY be present. NFS, etc protocols. The element MAY be present.
The content of a <streaming-modes> element has no attributes. The <streaming-modes> element has no attributes.
The content of a <streaming-modes> element has zero or more of the The <streaming-modes> element has zero or more of the following child
following child element: element:
stream-mode: has two attributes, 'name' and 'package'. The 'name' <stream-mode>: has two attributes, 'name' and 'package'. The
attribute provides the type of protocol that can be used for 'name' attribute provides the type of protocol that can be used
streaming (e.g., "HTTP", "RTSP", etc.). The 'package' attribute for streaming (e.g., "HTTP", "RTSP", etc.). The 'package'
provides the name of the Media Control Channel Framework package, attribute provides the name of the Media Control Channel Framework
compliant with the specification in the related IANA registry package, compliant with the specification in the related IANA
(e.g., "msc-ivr/1.0"), for which the streaming protocol applies. 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 element MAY be codes) for what regards both ASR and TTS. The element MAY be
present. present.
The content of an <asr-tts-support> element has no attributes. The <asr-tts-support> element has no attributes.
The content of an <asr-tts-support> element has zero or more of the The <asr-tts-support> element has zero or more of the following child
following child elements: elements:
asr-support: Describes the available languages for ASR. The <asr- <asr-support>: Describes the available languages for ASR. The
support> element has no attributes. The <asr-support> has one <asr-support> element has no attributes. The <asr-support> has
child element. The child element, <language>, reports the MS one child element. The child element, <language>, reports the MS
supports ASR for a specific language. The <language> element has supports ASR for a specific language. The <language> element has
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
the ISO-639-1 [ISO.639.1988] code of the supported language. the ISO-639-1 [ISO.639.1988] code of the supported language.
tts-support: Describes the available languages for TTS. The <tts- <tts-support>: Describes the available languages for TTS. The
support> element has no attributes. The <tts-support> has one <tts-support> element has no attributes. The <tts-support> has
child element. The child element, <language>, reports the MS one child element. The child element, <language>, reports the MS
supports tts for a specific language. The <language> element has supports tts for a specific language. The <language> element has
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
the ISO-639-1 [ISO.639.1988] code of the supported language. the ISO-639-1 [ISO.639.1988] code of the supported language.
5.1.4.17. <vxml-support> 5.1.4.17. <vxml-support>
The <vxml-support> element specifies if the Media Server supports The <vxml-support> element specifies if the Media Server supports
VoiceXML and if it does which protocols the support is exposed VoiceXML and if it does which protocols the support is exposed
through (e.g., via the control framework, RFC4240 [RFC4240], or through (e.g., via the control framework, RFC4240 [RFC4240], or
RFC5552 [RFC5552]). The element MAY be present. RFC5552 [RFC5552]). The element MAY be present.
The content of a <vxml-support> element has a single attribute The <vxml-support> element has no attributes.
'support'. The 'support' attribute is of type boolean with a value
of 'true' indicating that the media server does support VXML, and a
value of 'false' indicating it does not support VXML. The default
value is 'false'.
The content of a <vxml-support> element has the following child The <vxml-support> element has zero or more of the following child
element: elements:
vxml-mode: has two attributes, 'package' and 'support'. The <vxml-mode>: has two attributes, 'package' and 'support'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'support' attribute provides the type of VXML applies. The 'support' attribute provides the type of VXML
support provided by the Media Server (RFC5552 [RFC5552], RFC4240 support provided by the Media Server (RFC5552 [RFC5552], RFC4240
[RFC4240] or IVR-Package [RFC4240] or IVR-Package [RFC6231]).
[I-D.ietf-mediactrl-ivr-control-package]).
The presence of at least one <vxml-mode> child element would indicate
that the Media Server does support VXML as specified by the child
element itself. An empty <vxml> element would otherwise indicate the
Media Server does not support VXML at all.
5.1.4.18. <media-server-location> 5.1.4.18. <media-server-location>
The <media-server-location> element provides information about the The <media-server-location> element provides information about the
civic location of a media server. Its description makes use of the civic location of a media server. Its description makes use of the
Civic Address Schema standardized in RFC 5139 [RFC5139]. The element Civic Address Schema standardized in RFC 5139 [RFC5139]. The element
MAY be present. MAY be present.
The content of a <media-server-location> element has no attributes. The <media-server-location> element has no attributes.
The content of a <media-server-location> element has zero or more of The <media-server-location> element has zero or more of the following
the following child elements: child elements:
civicAddress: Describes the civic address location of the media <civicAddress>: Describes the civic address location of the media
server, whose representation refers to the Section 4 of RFC 5139 server, whose representation refers to the Section 4 of RFC 5139
[RFC5139]. [RFC5139].
5.1.4.19. <label> 5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the information that will be understood by the MRB. For example, the
Media Server can declare if it's a blue or green one. It's a string Media Server can declare if it's a blue or green one. It's a string
to allow arbitrary values to be returned to allow arbitrary to allow arbitrary values to be returned to allow arbitrary
classification, and as such is not meant to provide any explicit classification, and as such is not meant to provide any explicit
information associated with the features of a MS. The element MAY be information associated with the features of a MS. The element MAY be
present. present.
The content of a <label> element has no attributes. The <label> element has no attributes.
The content of a <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 SIP URI address where it can be reached (e.g., the URI AS direct SIP URI address where it can be reached (e.g., the URI AS
would call to in order to set-up a Control Channel and relay call would call to in order to set-up a Control Channel and relay call
legs). The element MAY be present. legs). The element MAY be present.
The <media-server-address> element has a single attribute. The <media-server-address> element has a single attribute.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.4.21. <encryption> 5.1.4.21. <encryption>
The <encryption> element allows a Media Server to declare support for The <encryption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. A value of encrypting RTP media streams using RFC 3711 [RFC3711]. The element
'true' indicates that a Media Server does support RFC 3711 [RFC3711] has character content 'true' if a Media Server does support RFC 3711
for RTP. A value of 'false' indicates that a Media Server does not [RFC3711] for RTP, and 'false' if it does not. The element MAY be
support RFC 3711 [RFC3711] for RTP. The element MAY be present. present.
The content of an <encryption> element has no attributes. The <encryption> element has no attributes.
The content of an <encryption> element has no child elements. The <encryption> element has no child elements.
5.1.5. <mrbresponse> 5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <mrbresponse> element.
Section 10.
The content of a <response> element has the following attributes: The <mrbresponse> element has the following attributes:
status: numeric code indicating the response status. The attribute status: numeric code indicating the response status. The attribute
MUST be present. MUST be present.
reason: string specifying a reason for the response status. The reason: string specifying a reason for the response status. The
attribute MAY be present. attribute MAY be present.
The <mrbresponse> element has zero or more of the following child
elements:
<subscription> for providing details related to a subscription a
Media Server requested (see below in this section).
The following status codes are defined for 'status': 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 31, line 11 skipping to change at page 31, line 11
resources to fulfil the request), the MS MUST reply with a resources to fulfil the request), the MS MUST reply with a
<mrbresponse> with status code 401/402/403, depending on the action <mrbresponse> with status code 401/402/403, depending on the action
the MRB provided in its request: the MRB provided in its request:
o action='create' --> 401; o action='create' --> 401;
o action='update' --> 402; o action='update' --> 402;
o action='remove' --> 403; o action='remove' --> 403;
As explained in Section 5.1.3.1, even in case of an accepted A response to a subscription request that has a status of "200"
subscription request the MS might change the suggested 'expires', indicates that the request is successful. The response MAY also
'minfrequency' and 'maxfrequency' values provided by the MRB in its contain a <subscription> child that describes the subscription. The
<mrbrequest>, if it considers them unacceptable (e.g., the requested <subscription> child MAY contain 'expires', 'minfrequency' and
frequency range is too high). In such a case, the MS MUST add an 'maxfrequency' values even if they were not contained in the request.
additional <subscription> element to the response, including the
updated values, to inform the MRB about the change. The MS MAY The MS MAY change the suggested 'expires', 'minfrequency' and
include such element if the values have been accepted or were omitted 'maxfrequency' values provided by the MRB in its <mrbrequest>, if it
in the request. considers them unacceptable (e.g., the requested frequency range is
too high). In such a case, the response MUST contain a
<subscription> element describing the subscription as the MS accepted
it, and the MS MUST include in the <subscription> element all of
those values that it modified relative to the request, to inform the
MRB about the change.
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 includes both 1) In-Line Aware resource. The MRB Consumer interface includes both 1) In-Line Aware
skipping to change at page 31, line 45 skipping to change at page 31, line 50
interface, as defined by the 'application/mrb-consumer+xml MIME type interface, as defined by the 'application/mrb-consumer+xml MIME type
in Section 11, with HTTP and SIP. in Section 11, with HTTP and SIP.
5.2.1. Query Mode / HTTP Consumer Interface Usage 5.2.1. Query Mode / HTTP Consumer Interface Usage
An appropriate interface for such a 'query' style interface is in An appropriate interface for such a 'query' style interface is in
fact a HTTP usage. Using HTTP and XML combined reduces complexity fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the and encourages use of common tools that are widely available in the
industry today. The following information explains the primary industry today. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of HTTP MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport
[RFC2616] and HTTPS [RFC2818] as transport for a query for media for a query for media resource and the appropriate response.
resource and the appropriate response.
The media resource query, as defined by the <mediaResourceRequest> The media resource query, as defined by the <mediaResourceRequest>
element from Section 11, MUST be carried in the body of an HTTP/HTTPS element from Section 11, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
the 'mediaResourceRequest' element as defined in Section 11. a <mrbconsumer> root element with only one child
'mediaResourceRequest' is the primary element describing information <mediaResourceRequest> element as defined in Section 11.
related to a media resource request.
The media resource response to a query, as defined by the The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 11, MUST be carried in <mediaResourceResponse> element from Section 11, MUST be carried in
the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
the 'mediaResourceResponse' element as defined in Section 11. a <mrbconsumer> root element with only one child
'mediaResourceResponse' is the primary element describing information <mediaResourceResponse> element as defined in Section 11.
related to a media resource response.
When an application server wants to release previously awarded media When an application server wants to release previously awarded media
resources granted through a prior request/response exchange with MRB, resources granted through a prior request/response exchange with MRB,
it will send a new request with an <action> element with value it will send a new request with an <action> element with value
'remove' as described in Section Section 5.2.3 about the use of the 'remove' as described in Section 5.2.3 about the use of the Consumer
Consumer interface lease mechanism. interface lease mechanism.
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage
This document provides a complete tool-kit for MRB deployment which This document provides a complete tool-kit for MRB deployment which
includes the ability to interact with an MRB using SIP for the includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary Consumer interface. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of SIP MRB, by making use of SIP [RFC3261] as transport for a request for
[RFC3261] as transport for a request for media resources and the media resources and the appropriate response when used with IAMM of
appropriate response when used with IAMM of operation (as discussed operation (as discussed in Section 5.2.2.1).
in Section 5.2.2.1).
Use of IAMM, besides having the MRB select an appropriate media Use of IAMM, besides having the MRB select appropriate media
resource on behalf of a client application, includes setting up resources on behalf of a client application, includes setting up
either a Control Framework control channel between an application either a Control Framework control channel between an application
server and media server (Section 5.2.2.1) or a call leg media session server and one of the media servers (Section 5.2.2.1) or a call leg
between an application server and a media server (Section 5.2.2.2). media session between an application server and one of the media
Note that in either case the SIP address of the selected media server servers (Section 5.2.2.2). Note that in either case the SIP
is made known to the requesting application server in the SIP 200 OK addresses of the selected media servers are made known to the
response as the media-server-address element in the <response- requesting application server in the SIP 200 OK response by means of
session-info> element (Section 5.2.5). one or more <media-server-address> child elements in the <response-
session-info> element (Section 5.2.6).
5.2.2.1. IAMM and Setting up a Control Framework Control Channel 5.2.2.1. IAMM and Setting up a Control Framework Control Channel
The media resource request information, as defined by the The media resource request information, as defined by the
<mediaResourceRequest> element from Section 11, MUST be carried in a <mediaResourceRequest> element from Section 11, MUST be carried in a
SIP INVITE request. The INVITE request will be constructed as it SIP INVITE request. The INVITE request will be constructed as it
would have been to connect to a media server, as defined by the Media would have been to connect to a media server, as defined by the Media
Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. Control Channel Framework [RFC6230]. The following additional steps
The following additional steps MUST be followed when using the MUST be followed when using the Consumer interface:
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]. One of the parts to be included in the mixed'[RFC2046]. One of the parts to be included in the
'multipart/mixed' payload MUST be the 'application/sdp' format 'multipart/mixed' payload MUST be the 'application/sdp' format
which is constructed as specified in the Media Control Channel which is constructed as specified in the Media Control Channel
Framework [I-D.ietf-mediactrl-sip-control-framework]. Framework [RFC6230].
o Another 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 11. Only the <mediaResourceRequest> and its defined in Section 11. The body part MUST be an XML document
child elements can be included in the payload. without prolog and whose root element is <mediaResourceRequest>.
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 [RFC6230].
On receiving a SIP INVITE request containing the multipart mixed On receiving a SIP INVITE request containing the multipart/mixed
payload as specified previously, the MRB will complete a number of payload as specified previously, the MRB will complete a number of
steps to fulfill the request. It will: steps to fulfill the request. It will:
o Extract the multipart MIME payload from the SIP INVITE request. o Extract the multipart MIME payload from the SIP INVITE request.
It will then use the contextual information provided by the client It will then use the contextual information provided by the client
in the 'application/mrb-consumer+xml' part to determine which in the 'application/mrb-consumer+xml' part to determine which
media server should be selected to service the request. media server (or media servers, if more than one is deemed to be
needed) should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it to o Extract the 'application/sdp' part from the payload and use it as
populate a new SIP INVITE request for connecting the client to the the body of a new SIP INVITE request for connecting the client to
selected media server, as defined in the Media Channel Control one of the selected media servers, as defined in the Media Channel
Framework [I-D.ietf-mediactrl-sip-control-framework]. Control Framework [RFC6230]. The policy the MRB follows to pikc a
specific MS out of the MSs it selects is implementation specific,
and out of scope to this document.
The MRB acts as a Back-to-Back-UA (B2BUA) that extracts the The MRB acts as a Back-to-Back UA (B2BUA) that extracts the
'application/mrb-consumer+xml' information from the SIP INVITE 'application/mrb-consumer+xml' information from the SIP INVITE
request and then sends a corresponding SIP INVITE request to the request and then sends a corresponding SIP INVITE request to the
selected Media Server. Media Server it has selected.
Once the MRB receives the SIP response from the selected media Once the MRB receives the SIP response from the selected media
resource (i.e., media server), it will in turn respond to the resource (i.e., media server), it will in turn respond to the
requesting client (i.e., application server). requesting client (i.e., application server).
The media resource response by MRB to a request, as defined by the The media resource response by MRB to a request, as defined by the
<mediaResourceResponse> element from Section 11, MUST be carried in <mediaResourceResponse> element from Section 11, 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. The 2xx class response will be constructed as it would have request. The 2xx class response will be constructed as it would have
been to connect from a media server, as defined by the Media Control been to connect from a media server, as defined by the Media Control
Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The Channel Framework [RFC6230]. The following additional steps MUST be
following additional steps MUST be followed when using the Consumer followed when using the Consumer interface:
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' as perRFC 2046 [RFC2046]. One of the parts to 'multipart/mixed' as perRFC 2046 [RFC2046]. One of the parts to
be included in the 'multipart/mixed' payload MUST be the be included in the 'multipart/mixed' payload MUST be the
'application/sdp' format which is constructed as specified in the 'application/sdp' format which is constructed as specified in the
Media Control Channel Framework Media Control Channel Framework [RFC6230].
[I-D.ietf-mediactrl-sip-control-framework].
o Another 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 11. Only the <mediaResourceResponse> and its defined in Section 11. 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 class response will then be dispatched from the MRB. 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 o A SIP ACK to the 2xx class response will then be sent back to the
MRB. MRB.
skipping to change at page 34, line 46 skipping to change at page 34, line 50
appropriate for setting up the call leg to the media resource, as per appropriate for setting up the call leg to the media resource, as per
RFC 3261 [RFC2046], instead of application/sdp payload for setting up RFC 3261 [RFC2046], instead of application/sdp payload for setting up
a control channel. a control channel.
5.2.3. Consumer Interface Lease Mechanism 5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 5.2 and Section 11 allows a The Consumer interface defined in Section 5.2 and Section 11 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 <response-session-info> element in either the SIP 2xx class
200 response. The information contained in the <response-session- or HTTP 200 response. The success response contains the description
info> element allows a Consumer client to monitor the life time of of certain resources that have been reserved to a specific Consumer
the resources it has successfully requested, as well as amending client in a (new or revised) "resource session", which is identified
them. in the <response-session-info>. The resource session is a "lease",
in that the reservation is scheduled to expire at a particular time
in the future, releasing the resources to be assigned for other uses.
The lease may be extended or terminated earlier by future Consumer
client requests that identify and reference a specific resource
session.
Before delving into the details of such lease mechanism, though, it's Before delving into the details of such lease mechanism, though, it's
worthwhile to first clarify its role within the context of the worthwhile to first clarify its role within the context of the
Consumer interface. As explained in Section 5.1, the knowledge the Consumer interface. As explained in Section 5.1, the knowledge the
MRB has of the resources of all the MS it handles is imperfect. As MRB has of the resources of all the MSs it handles is imperfect. As
such, how an MRB actually manages such resources depends on how it is such, how an MRB actually manages such resources depends on how it is
implemented: one may choose to have the MRB keeping track and state implemented: one may choose to have the MRB keeping track and state
of the allocated resources, or simply depend on the MS themselves to of the allocated resources, or simply depend on the MSs themselves to
provide the information by means of the publishing interface provide the information by means of the publishing interface
notifications. Further information may be inferred by the notifications. Further information may be inferred by the
signalling, in case the MRB is in the path of call legs. signalling, in case the MRB is in the path of call legs.
That said, the <mediaResourceResponse> element returned from the MRB That said, the <mediaResourceResponse> element returned from the MRB
contains a <response-session-info> element if the request is contains a <response-session-info> element if the request is
successful. The content of a <response-session-info> element has successful. The <response-session-info> element has zero or more of
zero or more of the following child elements which provide the the following child elements which provide the appropriate resource
appropriate resource session information: session information:
o <session-id> is a unique identifier that enables a Consumer client o <session-id> is a unique identifier that enables a Consumer client
and MRB to correlate future media resource requests related to an and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included initial media resource request. The <session-id> MUST be included
in all future related requests (see <session-id> use later in this in all future related requests (see <session-id> use later in this
section when constructing a subsequent request). section when constructing a subsequent request).
o <seq> is a numeric value returned to the Consumer client. On o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client (as determined by the <session-id> element) the consumer client
MUST increment the value returned in the <seq> element and include MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when in the request (see <seq> use later in this section when
constructing a subsequent request). constructing a subsequent request).
o <expires> provides a value which provides the number of seconds o <expires> provides a value which provides the number of seconds
the request for media resources is deemed alive. The Consumer the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later client should issue a refresh of the request, as discussed later
in this section, if the expires timer is due to fire and the media in this section, if the expires timer is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides information representing the o <media-server-address> provides information representing an
assigned MS. assigned MS. More instances of this element may appear, should
the MRB assign more MSs to a Consumer request.
The <mediaResourceRequest> element is used in subsequent Consumer The <mediaResourceRequest> element is used in subsequent Consumer
interface requests if the client wishes to manipulate the session. interface requests if the client wishes to manipulate the session.
The Consumer client MUST include the <session-info> element which The Consumer client MUST include the <session-info> element which
enables the receiving MRB to determine an existing media resource enables the receiving MRB to determine an existing media resource
allocation session. The <session-info> element has the following allocation session. The <session-info> element has the following
child elements which provide the appropriate resource session child elements which provide the appropriate resource session
information to the MRB: information to the MRB:
o <session-id> is a unique identifier that allows a Consumer client o <session-id> is a unique identifier that allows a Consumer client
skipping to change at page 37, line 6 skipping to change at page 37, line 14
expire. If the operation is successful, a 200 status code in expire. If the operation is successful, a 200 status code in
the response is returned in the status attribute of the the response is returned in the status attribute of the
<mediaResourceResponseType> element. If the operation is not <mediaResourceResponseType> element. If the operation is not
successful, a 410 status code in the response is returned in successful, a 410 status code in the response is returned in
the status attribute of the <mediaResourceResponseType> the status attribute of the <mediaResourceResponseType>
element. element.
Omitting the 'action' attribute means requesting a new set of Omitting the 'action' attribute means requesting a new set of
resources. resources.
When used with SIP the <session-info> element MUST be included in When used with HTTP the <session-info> element MUST be included in a
either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as HTTP POST message (as defined in [RFC2616]). When used with SIP,
defined in[RFC3311]) request. When used with HTTP the <session-info> instead, the <session-info> element MUST be included in either a SIP
element MUST be included in a HTTP POST message (as defined in INVITE, or a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE
[RFC2616]). (as defined in[RFC3311]) request: in fact, any SIP dialog, be it a
new or an existing one, can be exploited to carry leasing
information, and as such new SIP INVITE messages can update other
leases as well as requesting a new one.
With IAMM, the application server or media server will eventually With IAMM, the application server or media server will eventually
send a SIP BYE to end the SIP session, whether it was for a control send a SIP BYE to end the SIP session, whether it was for a control
channel or a call leg. That BYE contains no Consumer interface lease channel or a call leg. That BYE contains no Consumer interface lease
information. An MRB can be programmed to know that receipt of such a information. In no case should an MRB conclude that the resources
BYE also means to free up the media resources that had been requested are no longer needed once a call leg drops from the MS, since the
and awarded related to that session. associated lease remains valid and the AS might use the resources for
other calls.
5.2.4. Media Service Resource Request 5.2.4. <mrbconsumer>
This section defines the XML elements for the Consumer interface. This section defines the XML elements for the Consumer interface.
The formal XML schema definition for the Consumer interface can be The formal XML schema definition for the Consumer interface can be
found in Section 11. found in Section 11.
The root element is <mrbconsumer>. All other XML elements (requests, The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface responses) are contained within it. The MRB Consumer interface
request element is detailed in Section 5.2.4.1. MRB Consumer request element is detailed in Section 5.2.5.1. MRB Consumer
interface response element is contained in Section 5.2.5.1. interface response element is contained in Section 5.2.6.1.
The content of an <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 MUST be present. attribute MUST be present.
The content of an <mrbconsumer> element has zero or more of the The <mrbconsumer> element may have zero or more children of one of
following child elements, only one of which is allowed to occur. the following child element types:
<mediaResourceRequest> for sending a Consumer request. See <mediaResourceRequest> for sending a Consumer request. See
Section 5.2.4.1. Section 5.2.5.1.
<mediaResourceResponse> for sending a Consumer response. See <mediaResourceResponse> for sending a Consumer response. See
Section 5.2.5.1. Section 5.2.6.1.
5.2.4.1. <mediaResourceRequest> element 5.2.5. Media Service Resource Request
This section provides the element definitions for use in Consumer
interface requests. The requests are carried in the
<mediaResourceRequest> element.
5.2.5.1. <mediaResourceRequest> element
The <mediaResourceRequest> element provides information for clients The <mediaResourceRequest> element provides information for clients
wishing to query an external MRB entity. The <mediaResourceRequest> wishing to query an external MRB entity. The <mediaResourceRequest>
element has <generalInfo>, <ivrInfo> and <mixerInfo> as child element has a single mandatory attribute, 'id': this attribute
elements. These three elements are used to describe the requirements contains a random identifier, generated by the client, which will be
of a client requesting a Media Server and are covered in the included in the response in order to map it to a specific request.
following sub-sections. The <mediaResourceRequest> element has <generalInfo>, <ivrInfo> and
<mixerInfo> as child elements. These three elements are used to
describe the requirements of a client requesting a Media Server and
are covered in the following sub-sections.
5.2.4.1.1. <generalInfo> element 5.2.5.1.1. <generalInfo> element
The <generalInfo> element provides a information for general Consumer The <generalInfo> element provides a information for general Consumer
request information that is neither IVR or Mixer specific. This request information that is neither IVR or Mixer specific. This
includes session information that can be used for subsequent requests includes session information that can be used for subsequent requests
as part of the leasing mechanism described in Section 5.2.3. The as part of the leasing mechanism described in Section 5.2.3. The
following sub-sections describe the elements of the <generalInfo> following sub-sections describe the elements of the <generalInfo>
element, <session-info> and <packages>. element, <session-info> and <packages>.
5.2.4.1.1.1. <session-info> element 5.2.5.1.1.1. <session-info> element
The <session-info> element is included in Consumer requests when an The <session-info> element is included in Consumer requests when an
update is being made to an existing media resource session. The update is being made to an existing media resource session. The
ability to change and remove an existing media resource session is ability to change and remove an existing media resource session is
described in more detail in Section 5.2.3. The element MAY be described in more detail in Section 5.2.3. The element MAY be
present. present.
The content of the <session-info> element has no attributes. The <session-info> element has no attributes.
The content of the <session-info> element has zero or more of the The <session-info> element has zero or more of the following child
following child elements: 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: existing media resource session on an MRB:
* The value of 'update' instructs the MRB to attempt to update * The value of 'update' instructs the MRB to attempt to update
the existing media resource session with the information the existing media resource session with the information
contained in the <ivrInfo> and <mixerInfo> elements. contained in the <ivrInfo> and <mixerInfo> elements.
* The value of 'remove' instructs the MRB to attempt to remove * The value of 'remove' instructs the MRB to attempt to remove
the existing media resource session. More information on its the existing media resource session. More information on its
use is provided in Section 5.2.3. use is provided in Section 5.2.3.
5.2.4.1.1.2. <packages> element 5.2.5.1.1.2. <packages> element
The <packages> element provides a list of Media Control Channel The <packages> element provides a list of Media Control Channel
Framework compliant packages that are required by the Consumer Framework compliant packages that are required by the Consumer
client. The element MAY be present. client. The element MAY be present.
The content of a <packages> element has no attributes. The <packages> element has no attributes.
The content of a <packages> element has zero or more of the following The <packages> element has zero or more of the following child
child element: element:
package: child element contains a string representing the Media <package>: child element contains a string representing the Media
Control Channel Framework package required by the Consumer client. Control Channel Framework package required by the Consumer client.
The <package> element can appear multiple times. A valid value is The <package> element can appear multiple times. A valid value is
a Control Package name as specified in the related IANA registry a Control Package name as specified in the related IANA registry
(e.g., "msc-ivr/1.0") (e.g., "msc-ivr/1.0")
5.2.4.1.2. <ivrInfo> element 5.2.5.1.2. <ivrInfo> element
The <ivrInfo> element provides information for general Consumer The <ivrInfo> element provides information for general Consumer
request information that is IVR specific. The following sub-sections request information that is IVR specific. The following sub-sections
describe the elements of the <ivrInfo> element, <ivr-sessions>, describe the elements of the <ivrInfo> element, <ivr-sessions>,
<file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>,
<encryption>, <application-data>, <max-prepared-duration> and <encryption>, <application-data>, <max-prepared-duration> and
<stream-mode>. <stream-mode>.
5.2.4.1.2.1. <ivr-sessions> element 5.2.5.1.2.1. <ivr-sessions> element
The <ivr-sessions> element indicates the number of IVR sessions a The <ivr-sessions> element indicates the number of IVR sessions a
Consumer client requires from a media resource. The element MAY be Consumer client requires from a media resource. The element MAY be
present. present.
The content of an <ivr-sessions> element has no attributes. The <ivr-sessions> element has no attributes.
The content of an <ivr-sessions> element has zero or more of the The <ivr-sessions> element has zero or more of the following child
following child element: element:
rtp-codec: Describes a required codec and the number of sessions <rtp-codec>: Describes a required codec and the number of sessions
using that codec. The <rtp-codec> element has one attribute. The using that codec. The <rtp-codec> element has one attribute. The
value of the attribute 'name' is a MIME media type (which can value of the attribute 'name' is a MIME media type (which can
include parameters per [RFC4281]). The <rtp-codec> element has include parameters per [RFC6381]). The <rtp-codec> element has
two child elements. The child element, <decoding>, has as content two child elements. The child element, <decoding>, has as content
the decimal number of RTP sessions required for decoding using the the decimal number of RTP sessions required for decoding using the
specified codec. The child element, <encoding>, has as content specified codec. The child element, <encoding>, has as content
the decimal number of RTP sessions required for encoding using the the decimal number of RTP sessions required for encoding using the
specified codec. specified codec.
5.2.4.1.2.2. <file-formats> element 5.2.5.1.2.2. <file-formats> element
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
for the purpose of playing media. The element MAY be present. for the purpose of playing media. The element MAY be present.
The content of a <file-formats> element has no attributes. The <file-formats> element has no attributes.
The content of a <file-formats> element has zero or more of the The <file-formats> element has zero or more of the following child
following child element: element:
required-format: has a single attribute, 'name', which provides the <required-format>: has a single attribute, 'name', which provides
type of file format that is required. A valid value is a MIME the type of file format that is required. A valid value is a MIME
media type which, depending on its definition, can include media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <supported-format> additional parameters (e.g., [RFC6381]). 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 has a single attribute,
'required-file-package-name', which contains the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.2.4.1.2.3. <dtmf> element 5.2.5.1.2.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones The <dtmf> element specifies the required methods to detect DTMF
and to generate them. The element MAY be present. tones and to generate them. The element MAY be present.
The content of a <dtmf> element has no attributes. The <dtmf> element has no attributes.
The content of a <dtmf> element has zero or more of the following The <dtmf> element has zero or more of the following child elements:
child elements:
detect: Indicates the required support for DTMF detection. The <detect>: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element then has <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being needed, and it can only be either provides the type of DTMF being needed, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
generate: Indicates the required support for DTMF generation. The <generate>: Indicates the required support for DTMF generation.
<generate> element has no attributes. The <generate> element then The <generate> element has no attributes. The <generate> element
has a further child element, <dtmf-type>. The <dtmf-type> element then has a further child element, <dtmf-type>. The <dtmf-type>
has two attributes, 'name' and 'package. The 'name' attribute element has two attributes, 'name' and 'package. The 'name'
provides the type of DTMF being needed, and it can only be either attribute provides the type of DTMF being needed, and it can only
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio be either 'RFC4733' [RFC4733] or 'Media' (tones as signals in the
stream). The 'package' attribute provides the name of the Media audio stream). The 'package' attribute provides the name of the
Control Channel Framework package, compliant with the Media Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the required support for passing DTMF <passthrough>: Indicates the required support for passing DTMF
through without re-encoding. The <passthrough> element has no through without re-encoding. The <passthrough> element has no
attributes. The <passthrough> element then has a further child attributes. The <passthrough> element then has a further child
element, <dtmf-type>. The <dtmf-type> element has two attributes, element, <dtmf-type>. The <dtmf-type> element has two attributes,
'name' and 'package. The 'name' attribute provides the type of 'name' and 'package. The 'name' attribute provides the type of
DTMF being needed, and it can only be either 'RFC4733' [RFC4733] DTMF being needed, and it can only be either 'RFC4733' [RFC4733]
or 'Media' (tones as signals in the audio stream). The 'package' or 'Media' (tones as signals in the audio stream). The 'package'
attribute provides the name of the Media Control Channel Framework attribute provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies. registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.2.4.1.2.4. <tones> 5.2.5.1.2.4. <tones>
The <tones> element provides requested tones a media server must The <tones> element provides requested tones a media server must
support for IVR. In particular, the request refers to both country support for IVR. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The content of a <tones> element has no attributes. The <tones> element has no attributes.
The content of a <tones> element has zero or more of the following The <tones> element has zero or more of the following child elements:
child elements:
country-codes: Describes the requested country codes with respect <country-codes>: Describes the requested country codes with respect
to tones. The <country-codes> element has no attributes. The to tones. The <country-codes> element has no attributes. The
<country-codes> has one child element. The child element, <country-codes> has one child element. The child element,
<country-code>, requests a specific country code, compliant with <country-code>, requests a specific country code, compliant with
the ISO 3166-1 [ISO.3166-1] specification. The <country-code> the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
element has a single attribute, 'package'. The attribute element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
h248-codes: Describes the requested H.248 codes with respect to <h248-codes>: Describes the requested H.248 codes with respect to
tones. The <h248-codes> element has no attributes. The <h248- tones. The <h248-codes> element has no attributes. The <h248-
codes> has one child element. The child element, <h248-code>, codes> has one child element. The child element, <h248-code>,
requests a specific H.248 code, compliant with the ITU-T requests a specific H.248 code, compliant with the ITU-T
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
be either specific (e.g., cg/dt to only report the Dial Tone from be either specific (e.g., cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g., cg/* to report the Call Progress Tones package) or generic (e.g., cg/* to report
all the tones from the Call Progress Tones package) using wild- all the tones from the Call Progress Tones package) using wild-
cards. The <h248-code> element has a single attribute, 'package'. cards. The <h248-code> element has a single attribute, 'package'.
The attribute 'package' provides the name of the Media Control The attribute 'package' provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), in which the related IANA registry (e.g., "msc-ivr/1.0"), in which the
specified codes are requested. specified codes are requested.
5.2.4.1.2.5. <asr-tts> 5.2.5.1.2.5. <asr-tts>
The <asr-tts-support> element requests information about the support The <asr-tts> element requests information about the support for
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) 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 content of an <asr- codes) for what regards both ASR and TTS. The <asr-tts> element has
tts-support> element has no attributes. The content of an <asr-tts- no attributes. The <asr-tts> element has zero or more of the
support> element has zero or more of the following child elements: following child elements:
asr-support: Describes the available languages for ASR. The <asr- <asr-support>: Describes the available languages for ASR. The
support> element has no attributes. The <asr-support> has one <asr-support> element has no attributes. The <asr-support> has
child element. The child element, <language>, requests the MS one child element. The child element, <language>, requests the MS
supports ASR for a specific language. The <language> element has supports ASR for a specific language. The <language> element has
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
the ISO-639-1 [ISO.639.1988] code of the supported language. the ISO-639-1 [ISO.639.1988] code of the supported language.
tts-support: Describes the available languages for TTS. The <tts- <tts-support>: Describes the available languages for TTS. The
support> element has no attributes. The <tts-support> has one <tts-support> element has no attributes. The <tts-support> has
child element. The child element, <language>, requests the MS one child element. The child element, <language>, requests the MS
supports tts for a specific language. The <language> element has supports tts for a specific language. The <language> element has
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains a single attribute, 'xml:lang'. The attribute 'xml:lang' contains
the ISO-639-1 [ISO.639.1988] code of the supported language. the ISO-639-1 [ISO.639.1988] code of the supported language.
5.2.4.1.2.6. <vxml> element 5.2.5.1.2.6. <vxml> element
The <vxml> element specifies if the Consumer client required VoiceXML The <vxml> element specifies if the Consumer client required VoiceXML
and if it does which protocols the support is exposed through (e.g., and if it does which protocols the support is exposed through (e.g.,
via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]). via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]).
The element MAY be present. The element MAY be present.
The content of a <vxml> element has a single attribute 'support'. The <vxml> element has zero or more of the following child elements:
The 'support' attribute is of type boolean with a value of 'true'
indicating that the Consumer client requires VXML support, and a
value of 'false' indicating it does not require VXML support. The
default value is 'false'.
The content of a <vxml> element has zero or more of the following
child elements:
vxml-mode: has two attributes, 'package' and 'require'. The <vxml-mode>: has two attributes, 'package' and 'require'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'require' attribute specifies the type of VXML applies. The 'require' attribute specifies the type of VXML
support required by the Consumer client (RFC5552 [RFC5552], support required by the Consumer client (RFC5552 [RFC5552],
RFC4240 [RFC4240] or IVR-Package RFC4240 [RFC4240] or IVR-Package [RFC6231]).
[I-D.ietf-mediactrl-ivr-control-package]).
5.2.4.1.2.7. <location> The presence of at least one <vxml> child element would indicate that
the Consumer client requires VXML support as specified by the child
element itself. An empty <vxml> element would otherwise indicate the
Consumer client does not require VXML support.
5.2.5.1.2.7. <location>
The <location> element requests a civic location for an IVR media The <location> element requests a civic location for an IVR media
server. The request makes use of the Civic Address Schema server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element MAY be present. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The content of the <location> element has no attributes. The <location> element has no attributes.
The content of the <location> element consists of a single child The <location> element has a single child element:
element:
civicAddress: Describes the civic address location of the requested <civicAddress>: Describes the civic address location of the
media server, whose representation refers to Section 4 of RFC 5139 requested media server, whose representation refers to Section 4
[RFC5139]. of RFC 5139 [RFC5139].
5.2.4.1.2.8. <encryption> 5.2.5.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]. The
of 'true' indicates that Consumer client requires support of RFC 3711 element has character content 'true' if a Media Server does support
[RFC3711] for RTP. A value of 'false' indicates that a Consumer RFC 3711 [RFC3711] for RTP, and 'false' if it does not. The element
client does not require support of RFC 3711 [RFC3711] for RTP. The MAY be present. The default value is 'false'
element MAY be present. The default value is 'false'
The content of an <encryption> element has no attributes. The <encryption> element has no attributes.
The content of an <encryption> element has no child elements. The <encryption> element has no child elements.
5.2.4.1.2.9. <application-data> 5.2.5.1.2.9. <application-data>
The <application-data> element provides IVR application level data. The <application-data> element provides an arbitrary string of
The element MAY be present. characters as IVR application level data. This data is meant to only
have meaning at the application level logic and as such is not
otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.
The content of an <application-data> element has no attributes. The <application-data> element has no attributes.
The content of an <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.5.1.2.10. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time The <max-prepared-duration> element provides the amount of time
required by the Consumer client that a media dialog can be prepared required by the Consumer client that a media dialog can be prepared
in the system before it is executed. The element MAY be present. in the system before it is executed. The element MAY be present.
The content of a <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The content of a <max-prepared-duration> element has a single child The <max-prepared-duration> element has a single child element:
element:
max-time: has a single attribute, 'max-time-seconds', which <max-time>: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the time period applies. (e.g., "msc-ivr/1.0"), for which the time period applies.
5.2.4.1.2.11. <streaming-modes> 5.2.5.1.2.11. <streaming-modes>
The <streaming-modes> element allows the Consumer client to specify The <streaming-modes> element allows the Consumer client to specify
which protocols are required for streaming to a Media Server for each which protocols are required for streaming to a Media Server for each
Media Control Channel Framework package type. For example does the Media Control Channel Framework package type. For example does the
Media Server supports audio streaming via RTSP, HTTP, NFS, etc Media Server supports audio streaming via RTSP, HTTP, NFS, etc
protocols. The element MAY be present. protocols. The element MAY be present.
The content of a <streaming-modes> element has no attributes. The <streaming-modes> element has no attributes.
The content of a <streaming-modes> element has a single child The <streaming-modes> element has a single child element:
element:
stream-mode: has two attributes, 'name' and 'package'. The 'name' <stream-mode>: has two attributes, 'name' and 'package'. The
attribute provides the type of protocol required for streaming. 'name' attribute provides the type of protocol required for
The 'package' attribute provides the name of the Media Control streaming. The 'package' attribute provides the name of the Media
Channel Framework package, compliant with the specification in the Control Channel Framework package, compliant with the
related IANA registry (e.g., "msc-ivr/1.0"), for which the specification in the related IANA registry (e.g., "msc-ivr/1.0"),
streaming protocol applies. for which the streaming protocol applies.
5.2.4.1.3. <mixerInfo> element 5.2.5.1.3. <mixerInfo> element
The <mixerInfo> element provides information for general Consumer The <mixerInfo> element provides information for general Consumer
request information that is Mixer specific. The following sub- request information that is Mixer specific. The following sub-
sections describe the elements of the <mixerInfo> element, <mixers>, sections describe the elements of the <mixerInfo> element, <mixers>,
<file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application- <file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application-
data>, <location> and <encryption>. data>, <location> and <encryption>.
5.2.4.1.3.1. <mixers> 5.2.5.1.3.1. <mixers>
The <mixers> element provides information detailing the required The <mixers> element provides information detailing the required
mixed RTP sessions. The element MAY be present. mixed RTP sessions. The element MAY be present.
The content of a <mixers> element has no attributes. The <mixers> element has no attributes.
The content of a <mixers> element has a single child element: The <mixers> element has a single child element:
mix: Describes required mixed RTP sessions. The <mix> element has <mix>: Describes required mixed RTP sessions. The <mix> element
one attribute. The value of the attribute 'users' is the number has one attribute. The value of the attribute 'users' is the
of participants required in the mix. The <mix> element has one number of participants required in the mix. The <mix> element has
child element. The child element, <rtp-codec>, contains the same one child element. The child element, <rtp-codec>, contains the
information relating to RTP sessions as defined in same information relating to RTP sessions as defined in
Section 5.1.4.3. The element MAY be present. Section 5.1.4.3. The element MAY be present.
5.2.4.1.3.2. <file-formats> 5.2.5.1.3.2. <file-formats>
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
by the Consumer client for the purpose of playing media to a mix. by the Consumer client for the purpose of playing media to a mix.
The element MAY be present. The element MAY be present.
The content of a <file-formats> element has no attributes. The <file-formats> element has no attributes.
The content of a <file-formats> element has a single child element: The <file-formats> element has a single child element:
required-format: has a single attribute, 'name', which provides the <required-format>: has a single attribute, 'name', which provides
type of file format that is supported. A valid value is a MIME the type of file format that is supported. A valid value is a
media type which, depending on its definition, can include MIME media type which, depending on its definition, can include
additional parameters (e.g., [RFC4281]). The <required-format> additional parameters (e.g., [RFC6381]). 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 contains a single attribute,
'required-file-package-name', which contains the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the file format support applies. for which the file format support applies.
5.2.4.1.3.3. <dtmf> element 5.2.5.1.3.3. <dtmf> element
The <dtmf> element supplies the required methods to detect DTMF tones The <dtmf> element specifies the required methods to detect DTMF
and to generate them in a mix. The element MAY be present. tones and to generate them in a mix. The element MAY be present.
The content of a <dtmf> element has no attributes. The <dtmf> element has no attributes.
The content of a <dtmf> element has zero or more of the following The <dtmf> element has zero or more of the following child elements:
child elements:
detect: Indicates the required support for DTMF detection. The <detect>: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element then has <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes, 'name' and 'package. The 'name' attribute
provides the type of DTMF being used, and it can only be either provides the type of DTMF being used, and it can only be either
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio 'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio
stream). The 'package' attribute provides the name of the Media stream). The 'package' attribute provides the name of the Media
Control Channel Framework package, compliant with the Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
generate: Indicates the required support for DTMF generation. The <generate>: Indicates the required support for DTMF generation.
<generate> element has no attributes. The <generate> element then The <generate> element has no attributes. The <generate> element
has a further child element, <dtmf-type>. The <dtmf-type> element then has a further child element, <dtmf-type>. The <dtmf-type>
has two attributes, 'name' and 'package. The 'name' attribute element has two attributes, 'name' and 'package. The 'name'
provides the type of DTMF being used, and it can only be either attribute provides the type of DTMF being used, and it can only be
'RFC4733' [RFC4733] or 'Media' (tones as signals in the audio either 'RFC4733' [RFC4733] or 'Media' (tones as signals in the
stream). The 'package' attribute provides the name of the Media audio stream). The 'package' attribute provides the name of the
Control Channel Framework package, compliant with the Media Control Channel Framework package, compliant with the
specification in the related IANA registry (e.g., "msc-ivr/1.0"), specification in the related IANA registry (e.g., "msc-ivr/1.0"),
for which the DTMF type applies. for which the DTMF type applies.
passthrough: Indicates the required support for passing DTMF <passthrough>: Indicates the required support for passing DTMF
through without re-encoding. The <passthrough> element has no through without re-encoding. The <passthrough> element has no
attributes. The <passthrough> element then has a further child attributes. The <passthrough> element then has a further child
element, <dtmf-type>. The <dtmf-type> element has two attributes, element, <dtmf-type>. The <dtmf-type> element has two attributes,
'name' and 'package. The 'name' attribute provides the type of 'name' and 'package. The 'name' attribute provides the type of
DTMF being used, and it can only be either 'RFC4733' [RFC4733] or DTMF being used, and it can only be either 'RFC4733' [RFC4733] or
'Media' (tones as signals in the audio stream). The 'package' 'Media' (tones as signals in the audio stream). The 'package'
attribute provides the name of the Media Control Channel Framework attribute provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies. registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
5.2.4.1.3.4. <tones> 5.2.5.1.3.4. <tones>
The <tones> element provides requested tones a media server must The <tones> element provides requested tones a media server must
support for a mix. In particular, the request refers to both country support for a mix. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The content of a <tones> element has no attributes. The <tones> element has no attributes.
The content of a <tones> element has zero or more of the following The <tones> element has zero or more of the following child elements:
child elements:
country-codes: Describes the requested country codes with respect <country-codes>: Describes the requested country codes with respect
to tones. The <country-codes> element has no attributes. The to tones. The <country-codes> element has no attributes. The
<country-codes> has one child element. The child element, <country-codes> has one child element. The child element,
<country-code>, requests a specific country code, compliant with <country-code>, requests a specific country code, compliant with
the ISO 3166-1 [ISO.3166-1] specification. The <country-code> the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
element has a single attribute, 'package'. The attribute element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
h248-codes: Describes the requested H.248 codes with respect to <h248-codes>: Describes the requested H.248 codes with respect to
tones. The <h248-codes> element has no attributes. The <h248- tones. The <h248-codes> element has no attributes. The <h248-
codes> has one child element. The child element, <h248-code>, codes> has one child element. The child element, <h248-code>,
requests a specific H.248 code, compliant with the ITU-T requests a specific H.248 code, compliant with the ITU-T
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
be either specific (e.g., cg/dt to only report the Dial Tone from be either specific (e.g., cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g., cg/* to report the Call Progress Tones package) or generic (e.g., cg/* to report
all the tones from the Call Progress Tones package) using wild- all the tones from the Call Progress Tones package) using wild-
cards. The <h248-code> element has a single attribute, 'package'. cards. The <h248-code> element has a single attribute, 'package'.
The attribute 'package' provides the name of the Media Control The attribute 'package' provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), in which the related IANA registry (e.g., "msc-ivr/1.0"), in which the
specified codes are requested. specified codes are requested.
5.2.4.1.3.5. <mixing-modes> 5.2.5.1.3.5. <mixing-modes>
The <mixing-modes> element requests information about the support for The <mixing-modes> element requests information about the support for
audio and video mixing of a Media Server, specifically a list of audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video supported algorithms to mix audio and a list of supported video
presentation layouts. The element MAY be present. presentation layouts. The element MAY be present.
The content of a <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The content of a <mixing-modes> element has zero or more of the The <mixing-modes> element has zero or more of the following child
following child elements: elements:
audio-mixing-modes: Describes the requested algorithms for audio <audio-mixing-modes>: Describes the requested algorithms for audio
mixing. The <audio-mixing-modes> element has no attributes. The mixing. The <audio-mixing-modes> element has no attributes. The
<audio-mixing-modes> element has one child element. The child <audio-mixing-modes> element has one child element. The child
element, <audio-mixing-mode>, contains a specific requested element, <audio-mixing-mode>, contains a specific requested
algorithm. It has a single attribute, 'package'. The attribute algorithm. It has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the algorithm support is registry (e.g., "msc-ivr/1.0"), for which the algorithm support is
requested. requested.
video-mixing-modes: Describes the requested video presentation <video-mixing-modes>: Describes the requested video presentation
layouts for video mixing. The <video-mixing-modes> element has layouts for video mixing. The <video-mixing-modes> element has
two attributes, 'vas' and 'activespeakermix'. The 'vas' attribute two attributes, 'vas' and 'activespeakermix'. The 'vas' attribute
is of type boolean with a value of 'true' indicating that the is of type boolean with a value of 'true' indicating that the
Consumer Client requires automatic Voice Activated Switching. The Consumer Client requires automatic Voice Activated Switching. The
'activespeakermix' attribute is of type boolean with a value of 'activespeakermix' attribute is of type boolean with a value of
'true' indicating that the Consumer Client requires an additional 'true' indicating that the Consumer Client requires an additional
video stream for the loudest speaker participant without its video stream for the loudest speaker participant without its
contribution. The <video-mixing-modes> element has one child contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains the element. The child element, <video-mixing-mode>, contains the
name of a specific video presentation layout. The name may refer name of a specific video presentation layout. The name may refer
to one of predefined video layouts defined in the XCON conference to one of predefined video layouts defined in the XCON conference
information data model, or to non-XCON layouts as well, as long as information data model, or to non-XCON layouts as well, as long as
they are properly prefixed. The <video-mixing-mode> element has a they are properly prefixed. The <video-mixing-mode> element has a
single attribute, 'package'. The attribute 'package' provides the single attribute, 'package'. The attribute 'package' provides the
name of the Media Control Channel Framework package, compliant name of the Media Control Channel Framework package, compliant
with the specification in the related IANA registry (e.g., "msc- with the specification in the related IANA registry (e.g., "msc-
ivr/1.0"), for which the algorithm support is requested. ivr/1.0"), for which the algorithm support is requested.
5.2.4.1.3.6. <application-data> 5.2.5.1.3.6. <application-data>
The <application-data> element provides application level data. The The <application-data> element provides an arbitrary string of
element MAY be present. characters as Mixer application level data. This data is meant to
only have meaning at the application level logic and as such is not
otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.
The contents of an <application-data> element has no attributes. The <application-data> element has no attributes.
The contents of an <application-data> element has no child elements. The <application-data> element has no child elements.
5.2.4.1.3.7. <location> 5.2.5.1.3.7. <location>
The <location> element requests a civic location for a mixer media The <location> element requests a civic location for a mixer media
server. The request makes use of the Civic Address Schema server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element MAY be present. standardized in RFC 5139 [RFC5139]. The element MAY be present.
The contents of a <location> element has no attributes. The contents of a <location> element has no attributes.
The contents of a <location> element has a single child element: The contents of a <location> element has a single child element:
civicAddress: Describes the civic address location of the requested <civicAddress>: Describes the civic address location of the
media server, whose representation refers to Section 4 of RFC 5139 requested media server, whose representation refers to Section 4
[RFC5139]. of RFC 5139 [RFC5139].
5.2.4.1.3.8. <encryption> 5.2.5.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]. The
value of 'true' indicates that Consumer client requires support of element has character content 'true' if a Media Server does support
RFC 3711 [RFC3711] for RTP. A value of 'false' indicates that a RFC 3711 [RFC3711] for RTP, and 'false' if it does not. The element
Consumer client does not require support of RFC 3711 [RFC3711] for MAY be present. The default value is 'false'
RTP. The element MAY be present. The default value is 'false'
The contents of an <encryption> element has no attributes. The <encryption> element has no attributes.
The contents of an <application-data> element has no child elements. The <application-data> element has no child elements.
5.2.5. Media Service Resource Response 5.2.6. 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> element. <mediaResourceResponse> element.
5.2.5.1. <mediaResourceResponse> element 5.2.6.1. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a information for The <mediaResourceResponse> element provides a information for
clients receiving response information from an external MRB entity. clients receiving response information from an external MRB entity.
The <mediaResourceResponse> element has a single attribute 'status' The <mediaResourceResponse> element has two mandatory attributes,
which indicates the status code of the operation. The following 'id' and 'status'. The 'id' attribute must contain the same value
status codes are defined for 'status': the client provided in the 'id' attribute in the
<mediaResourceRequest> the response is for. The 'status' attribute
indicates the status code of the operation. The following 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 |
| | | | | |
| 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 In case a new media resource request made by an AS has been accepted,
been accepted, the MRB MUST reply with a <mediaResourceResponse> with the MRB MUST reply with a <mediaResourceResponse> with status code
status code 200. The same rule applies whenever a request to update 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction (action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MRB. can be fulfilled by the MRB.
A media resource request, nevertheless, may fail for several reasons. A media resource request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used In such a case, the status codes defined in Table 2 must be used
instead. Specifically, if the MRB fails to handle a request due to a instead. Specifically, if the MRB fails to handle a request due to a
syntax error in the request itself (e.g., incorrect XML, violation of syntax error in the request itself (e.g., incorrect XML, violation of
the schema constraints or invalid values in any of the attributes/ the schema constraints or invalid values in any of the attributes/
elements) the MRB MUST reply with a <mediaResourceResponse> with elements) the MRB MUST reply with a <mediaResourceResponse> with
status code 400. If a syntactically correct request fails because status code 400. If a syntactically correct request fails because
the request also includes any attribute/element the MRB doesn't the request also includes any attribute/element the MRB doesn't
understand, the MRB MUST reply with a <mediaResourceResponse> with understand, the MRB MUST reply with a <mediaResourceResponse> with
status code 420. If a syntactically correct request fails because status code 420. If a syntactically correct request fails because
the MRB couldn't find any MS able to fulfil the requirements the MRB couldn't find any MS able to fulfil the requirements
presented by the AS in its request, the MRB MUST reply with a presented by the AS in its request, the MRB MUST reply with a
skipping to change at page 50, line 32 skipping to change at page 51, line 10
Further details on status codes 409 and 410 are presented in Further details on status codes 409 and 410 are presented in
Section 5.2.3, where the leasing mechanism, together with its related Section 5.2.3, where the leasing mechanism, together with its related
scenarios, is described. 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.6.1.1. <response-session-info> element
The <response-session-info> element is included in Consumer The <response-session-info> element is included in Consumer
responses. This applies to responses to both requests for new responses. This applies to responses to both requests for new
resources and requests to update an existing media resource session. resources and requests to update an existing media resource session.
The ability to change and remove an existing media resource session The ability to change and remove an existing media resource session
is described in more detail in Section 5.2.3. The element MAY be is described in more detail in Section 5.2.3. If the request was
present: specifically, the element MUST be included in case the successful, the <mediaResourceResponse> MUST have one <response-
request was successful, while it would not appear otherwise (e.g., in session-info> child, which describes the media resource session which
case the request ended up with an error). was addressed by the request. If the request was not successful, the
<mediaResourceResponse> MUST NOT have a <response-session-info>
child.
The contents of a <response-session-info> element has no attributes. The contents of a <response-session-info> element has no attributes.
The contents of a <response-session-info> element has zero or more of The contents of a <response-session-info> element has zero or more of
the following child elements: the following child elements:
session-id: is a unique identifier that explicitly references an <session-id>: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a <seq>: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3. More information its use is provided in Section 5.2.3.
expires: includes the number of seconds that the media resources <expires>: includes the number of seconds that the media resources
are reserved as part of this interaction. If the lease is not are reserved as part of this interaction. If the lease is not
refreshed before expiry, the MRB will re-claim the resources and refreshed before expiry, the MRB will re-claim the resources and
they will no longer be guaranteed. It is RECOMMENDED that a they will no longer be guaranteed. It is RECOMMENDED that a
minimum value of 300 seconds be used for the value of the minimum value of 300 seconds be used for the value of the
'expires' attribute. It is also RECOMMENDED that a Consumer 'expires' attribute. It is also RECOMMENDED that a Consumer
client refresh the lease at an interval that is not too close to client refresh the lease at an interval that is not too close to
the expiry time. A value of 80% of the time-out period could be the expiry time. A value of 80% of the time-out period could be
used. For example, if the time-out period is 300 seconds, the used. For example, if the time-out period is 300 seconds, the
Server would refresh the transaction at 240 seconds. More Server would refresh the transaction at 240 seconds. More
information on its use is provided in Section 5.2.3. information on its use is provided in Section 5.2.3.
media-server-address: provides information to reach the MS handling <media-server-address>: provides information to reach the MS
the requested media resource. The <media-server-address> element handling the requested media resource. One or more instances of
has a single attribute named 'uri' which supplies the direct these element may appear. The <media-server-address> element has
address to a media server. It also has three optional elements a single attribute named 'uri' which supplies a SIP URI that
<connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions> reaches the specified media server. It also has three optional
and <mixers> are defined in Section 5.2.4.1.2.1 and elements <connection-id>, <ivr-sessions>, and <mixers>. The <ivr-
Section 5.2.4.1.3.1 and have the same meaning but are applied to sessions> and <mixers> are defined in Section 5.2.5.1.2.1 and
Section 5.2.5.1.3.1 and have the same meaning but are applied to
individual media server instances as a subset of the overall individual media server instances as a subset of the overall
resources reported in the <connection-id> element. For more resources reported in the <connection-id> element. If multiple
information on the use of the <connection-id> element see MSs are assigned in an IAMM operation, exactly one <media-server-
Section 6. address> element, the one describing the one that provided the
call-leg or CFW response, will have a <connection-id> element.
For more information on the use of the <connection-id> element for
call legs, instead, see Section 6.
5.3. In-Line Unaware MRB Interface 5.3. In-Line Unaware 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. In-Line Unaware MRB Mode request, as introduced in Section 4.2. In-Line Unaware MRB Mode
(IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation. (IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation.
This section further describes IUMM. This section further describes IUMM.
It should be noted that the introduction of an MRB entity into the It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be network, as specified in this document, requires interfaces to be
skipping to change at page 52, line 16 skipping to change at page 52, line 51
unaware of the MRB concept and would simply require a configuration unaware of the MRB concept and would simply require a configuration
change resulting in the MRB being set as a SIP outbound proxy for change resulting in the MRB being set as a SIP outbound proxy for
clients requiring media services. clients requiring media services.
With IUMM, the MRB may conclude that an assigned media resource is no With IUMM, the MRB may conclude that an assigned media resource is no
longer needed when it receives a SIP BYE from the application server longer needed when it receives a SIP BYE from the application server
or media server that ends that SIP dialog that initiated the request. or media server that ends that SIP dialog that initiated the request.
As with IAMM, in IUMM the SIP INVITE from the application server As with IAMM, in IUMM the SIP INVITE from the application server
could convey application/sdp payload to either set up a call leg or a could convey application/sdp payload to either set up a call leg or a
Control Framework control channel. In either case, if the ultimate Control Framework control channel. In either case, in order to
intent is to correlate a call leg with a control channel to the same permit the AS to associate a call leg with a control channel to the
media server, the MRB should be acting as a SIP proxy (and not a same media server using the procedures of [RFC6230] section 6, the
B2BUA) so that the SIP address of the targeted media server can be MRB should be acting as a SIP proxy (and not a B2BUA) so that the SIP
transparently passed back to the application server in the SIP address of the targeted media server can be transparently passed back
response and so that the SIP dialog information is between the to the application server in the SIP response and so that the SIP
application server and the media server. dialog is between the application server and the media server.
While IUMM has the least impact on legacy application servers, it While IUMM has the least impact on legacy application servers, it
also provides the least versatility. See Section 8. also provides the least versatility. See Section 8.
6. MRB acting as a B2BUA 6. MRB acting as a B2BUA
An MRB entity can potentially act as a SIP Back-2-Back-User-Agent An MRB entity can potentially act as a SIP Back-2-Back-User-Agent
(B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When (B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When
acting as a B2BUA issues can arise when using Media Control Channel acting as a B2BUA issues can arise when using Media Control Channel
packages such as the IVR packages such as the IVR[RFC6231] and
Package[I-D.ietf-mediactrl-ivr-control-package] and Mixer Packages Mixer[I-D.ietf-mediactrl-mixer-control-package] Packages.
[I-D.ietf-mediactrl-mixer-control-package]. Specifically the Specifically the Framework attribute 'connectionid' provided in the
Framework attribute 'connectionid' provided in the appendix titled appendix titled 'Appendix: Common Package Components' of Media
'Appendix: Common Package Components' of Media Control Channel Control Channel Framework[RFC6230] uses a concatenation of the SIP
Framework[I-D.ietf-mediactrl-sip-control-framework] uses a dialog identifiers to be used for referencing SIP dialogs within the
concatenation of the SIP dialog identifiers to be used for media control channel. When a request traverses an MRB acting as a
referencing SIP dialogs within the media control channel. When a B2BUA, the SIP dialog identifiers change and so the 'connectionid'
request traverses an MRB acting as a B2BUA, the SIP dialog can not be used as intended due to the SIP dialog identifiers
identifiers change and so the 'connectionid' can not be used as changing. For this reason when a MRB wishes to act as a SIP B2BUA
intended due to the SIP dialog identifiers changing. For this reason when handling a request from an AS to set up a call leg to a MS it
when a MRB wishes to act as a SIP B2BUA when handling a request from MUST include the optional <connection-id> element in a Consumer
an AS to set up a call leg to a MS it MUST include the optional interface response with a value that provides the equivalent for the
<connection-id> element in a Consumer interface response with a value 'connectionid' ('Local Dialog Tag' + 'Remote Dialog Tag') for the far
that provides the equivalent for the 'connectionid' ('Local Dialog side of the B2BUA. If present, this value MUST be used as the value
Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If for the 'connectionid' in packages where the Common Package
present, this value MUST be used as the value for the 'connectionid' Components are used. The <connection-id> element MUST NOT be
in packages where the Common Package Components are used. The included in a HTTP Consumer interface response.
<connection-id> element MUST not be included in a HTTP Consumer
interface response. It is important to point out that, although more MSs instances may be
returned in a Consumer response (i.e., the MRB has assigned more than
one MS to a Consumer request to fulfill the AS requirements), in IAMM
the MRB will only act as a B2BUA with a single MS: in this case,
exactly one <media-server-address> element, the one describing the
one that provided the call-leg or CFW response, will have a
<connection-id> element, which will instead be missing in the other
<media-server-address> elements.
7. Multi-modal MRB Implementations 7. Multi-modal MRB Implementations
An MRB implementation may operate multi-modally with a collection of An MRB implementation may operate multi-modally with a collection of
application server clients all sharing the same pool of media application server clients all sharing the same pool of media
resources. I.e., an MRB may be simultaneously operating in Query resources. I.e., an MRB may be simultaneously operating in Query
mode, IAMM and IUMM. It knows in which mode to act on any particular mode, IAMM and IUMM. It knows in which mode to act on any particular
request from a client depending on the nature of the request: request from a client depending on the nature of the request:
o If the received quest is HTTP Post with application/ o If the received quest is HTTP Post with application/
skipping to change at page 55, line 11 skipping to change at page 56, line 11
o If the received request is a SIP INVITE without application/ o If the received request is a SIP INVITE without application/
mrb-consumer+xml content but with application/sdp content then MRB mrb-consumer+xml content but with application/sdp content then MRB
processes it in IUMM. processes it in IUMM.
8. Relative Merits of Query Mode, IAMM, and IUMM 8. Relative Merits of Query Mode, IAMM, and IUMM
At a high level, the possible application server MRB interactions can At a high level, the possible application server MRB interactions can
be distinguished among the following basic types: be distinguished among the following basic types:
a. Query mode, in which the client is requesting the assignment by a. Query mode, in which the client is requesting the assignment by
MRB of suitable MS resources MRB of suitable MSs resources;
b. IAMM in which the client is requesting the assignment by MRB of b. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a call leg to the suitable MSs resources and the establishment of a call leg to one
MS of the MSs;
c. IAMM in which the client is requesting the assignment by MRB of c. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a CFW control suitable MSs resources and the establishment of a CFW control
channel to the MS channel to one of the MSs;
d. IUMM where the client is requesting the establishment of a call d. IUMM where the client is requesting the establishment of a call
leg to MS resources leg to MS resources;
e. IUMM where the client is requesting the establishment of a CFW e. IUMM where the client is requesting the establishment of a CFW
control channel to MS resources control channel to MS resources.
Each type of interaction has advantages and disadvantages compared to Each type of interaction has advantages and disadvantages compared to
the others, where such considerations may have to do with the the others, where such considerations may have to do with the
versatility of what MRB can provide, technical aspects such as versatility of what MRB can provide, technical aspects such as
efficiency in different application scenarios, complexity, delay, use efficiency in different application scenarios, complexity, delay, use
with legacy application servers, or use with the Media Control with legacy application servers, or use with the Media Control
Channel Framework. Depending on the characteristics of a particular Channel Framework. Depending on the characteristics of a particular
setting that an MRB is intended to support, some of the above setting that an MRB is intended to support, some of the above
interaction types may be more appropriate than others. This section interaction types may be more appropriate than others. This section
makes a few observations on relative merits, but is not intended to makes a few observations on relative merits, but is not intended to
be exhaustive. Some constraints of a given interaction type may be be exhaustive. Some constraints of a given interaction type may be
subtle. subtle.
o About operation with other types of media control: Any of the o About operation with other types of media control: Any of the
types of interactions work with the use RFC 4240 [RFC4240] and RFC types of interactions work with the use RFC 4240 [RFC4240] and RFC
5552 [RFC5552] where initial control instructions are conveyed in 5552 [RFC5552] where initial control instructions are conveyed in
the SIP INVITE from the application server for the call leg to the the SIP INVITE from the application server for the call leg to the
media server and subsequent instructions may be fetched using media server and subsequent instructions may be fetched using
HTTP. Query mode (a), IAMM/call leg (b) and IUMM/call leg (d) HTTP. Query mode (a), IAMM/call leg (b) and IUMM/call leg (d)
work with MSML as per RFC 5705 [RFC5705] or MSCML as per RFC 4722 work with MSML as per RFC 5705 [RFC5705] or MSCML as per RFC 5022
[RFC4722]. [RFC5022].
o As stated previously, IUMM has no interface impacts on an o As stated previously, IUMM has no interface impacts on an
application server. On the other hand, with IUMM the application application server. On the other hand, with IUMM the application
server does not specify the characteristics of the type of media server does not specify the characteristics of the type of media
resource it needs because the <mediaResourceRequest> element is resource it needs because the <mediaResourceRequest> element is
not passed to the MRB. For IUMM call leg (d) the best the MRB can not passed to the MRB. For IUMM call leg (d) the best the MRB can
do to deduce an appropriate media resource gleaned from examining do to deduce an appropriate media resource gleaned from examining
other information in the SIP INVITE, such as the SDP information other information in the SIP INVITE, such as the SDP information
for the call leg, or initial control information in the SIP for the call leg, or initial control information in the SIP
Request URI as per RFC 4240 [RFC4240]. With IUMM/control channel Request URI as per RFC 4240 [RFC4240]. With IUMM/control channel
skipping to change at page 57, line 24 skipping to change at page 58, line 24
has taken place. This backslash and its trailing CRLF and whitespace has taken place. This backslash and its trailing CRLF and whitespace
would not appear in the actual protocol contents. Besides, also note would not appear in the actual protocol contents. Besides, also note
that the indentation of the XML content is only provided for that the indentation of the XML content is only provided for
readability: actual messages will follow strict XML syntax, which readability: actual messages will follow strict XML syntax, which
allows for, but does not require, indentation. allows for, but does not require, indentation.
9.1. Publish Example 9.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]). ([RFC6230]).
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
acknowledged by the MRB (A4.). acknowledged by the MRB (A4.).
MRB MS MRB MS
| | | |
| A1. CONTROL (MRB subscription) | | A1. CONTROL (MRB subscription) |
skipping to change at page 59, line 29 skipping to change at page 60, line 29
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/> <mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish> </mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS) B1. MRB <- MS (CONTROL, event notification from MS)
--------------------------------------------------- ---------------------------------------------------
CFW 03fff52e7b7a CONTROL CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0 Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml Content-Type: application/mrb-publish+xml
Content-Length: 4242 Content-Length: 4234
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" \ <mrbpublish version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-publish"> xmlns="urn:ietf:params:xml:ns:mrb-publish">
<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>
skipping to change at page 60, line 30 skipping to change at page 61, line 30
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>15</decoding> <decoding>15</decoding>
<encoding>15</encoding> <encoding>15</encoding>
</rtp-codec> </rtp-codec>
</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-codec name="audio/basic"> <supported-codec name="audio/basic">
<supported-codec-package name="msc-ivr/1.0"> <supported-codec-package name="msc-ivr/1.0">
<supported-actions>encoding</supported-actions> <supported-action>encoding</supported-action>
<supported-actions>decoding</supported-actions> <supported-action>decoding</supported-action>
</supported-codec-package> </supported-codec-package>
<supported-codec-package name="msc-mixer/1.0"> <supported-codec-package name="msc-mixer/1.0">
<supported-actions>encoding</supported-actions> <supported-action>encoding</supported-action>
<supported-actions>decoding</supported-actions> <supported-action>decoding</supported-action>
</supported-codec-package> </supported-codec-package>
</supported-codec> </supported-codec>
</supported-codecs> </supported-codecs>
<application-data>TestbedPrototype</application-data> <application-data>TestbedPrototype</application-data>
<file-formats> <file-formats>
<supported-format name="audio/x-wav"> <supported-format name="audio/x-wav">
<supported-file-package> <supported-file-package>
msc-ivr/1.0 msc-ivr/1.0
</supported-file-package> </supported-file-package>
</supported-format> </supported-format>
skipping to change at page 62, line 31 skipping to change at page 63, line 31
<stream-mode package="msc-ivr/1.0" 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="true"> <vxml-support>
<vxml-mode package="msc-ivr/1.0" support="IVR-Package"/> <vxml-mode package="msc-ivr/1.0" support="IVR-Package"/>
</vxml-support> </vxml-support>
<media-server-location> <media-server-location>
<civicAddress xml:lang="it"> <civicAddress xml:lang="it">
<country>IT</country> <country>IT</country>
<A1>Campania</A1> <A1>Campania</A1>
<A3>Napoli</A3> <A3>Napoli</A3>
<A6>Via Claudio</A6> <A6>Via Claudio</A6>
<HNO>21</HNO> <HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK> <LMK>University of Napoli Federico II</LMK>
skipping to change at page 63, line 16 skipping to change at page 64, line 16
------------------------------ ------------------------------
CFW 03fff52e7b7a 200 CFW 03fff52e7b7a 200
9.2. Consumer Example 9.2. Consumer Example
As specified in Section 5.2, the Consumer interface can be involved As specified in Section 5.2, the Consumer interface can be involved
in two different modes: Query and Inline-aware. When in Query mode, in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of Consumer messages are transported in HTTP messages: an example of
such an approach is presented in Section 9.2.1. When in Inline-aware such an approach is presented in Section 9.2.1. When in Inline-aware
mode, instead, messages are transported as part of SIP negotiations: mode, instead, messages are transported as part of SIP negotiations:
considering this SIP negotiations may be related to either the considering that SIP negotiations may be related to either the
creation of a control channel or to a UAC call leg, two separate creation of a control channel or to a UAC call leg, two separate
examples of such an approach are presented in Section 9.2.2. examples of such an approach are presented in Section 9.2.2.
9.2.1. Query Example 9.2.1. Query Example
The following example assumes the interested AS already knows the The following example assumes the interested AS already knows the
HTTP URL where an MRB is listening for Consumer messages. HTTP URL where an MRB is listening for Consumer messages.
Figure 10 shows the HTTP-based transaction between the AS and the Figure 10 shows the HTTP-based transaction between the AS and the
MRB. The AS sends a consumer request as payload of an HTTP POST MRB. The AS sends a consumer request as payload of an HTTP POST
message (1.), and the MRB provides an answer in an HTTP 200 OK message (1.), and the MRB provides an answer in an HTTP 200 OK
message (2.). Specifically, as it will be shown in the dumps, the AS message (2.). Specifically, as it will be shown in the dumps, the AS
is interested in 100 IVR ports: the MRB finds two MS that can satisfy is interested in 100 IVR ports: the MRB finds two MSs that can
the request (one providing 60 ports, the other 40 ports) and reports satisfy the request (one providing 60 ports, the other 40 ports) and
them to the AS. reports them to the AS.
AS MRB AS MRB
| | | |
| 1. HTTP POST (Consumer request) | | 1. HTTP POST (Consumer request) |
|--------------------------------------------->| |--------------------------------------------->|
| | | |
| | | |
| |--+ Parse request | |--+ Parse request
| | | and see if any | | | and see if any
| |<-+ MS applies | |<-+ MS applies
skipping to change at page 64, line 39 skipping to change at page 65, line 39
1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST, 1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST,
Content-Type 'application/mrb-consumer+xml'); Content-Type 'application/mrb-consumer+xml');
2. the Consumer response (2), in an <mediaResourceResponse> (HTTP 2. the Consumer response (2), in an <mediaResourceResponse> (HTTP
200 OK, Content-Type 'application/mrb-consumer+xml'). 200 OK, Content-Type 'application/mrb-consumer+xml').
1. AS -> MRB (HTTP POST, Consumer request) 1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------ ------------------------------------------
POST /Mrb/Consumer HTTP/1.1 POST /Mrb/Consumer HTTP/1.1
Content-Length: 879 Content-Length: 893
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080 Host: mrb.example.net:8080
Connection: Keep-Alive Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5) User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest> <mediaResourceRequest id="gh11x23v">
<generalInfo> <generalInfo>
<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="audio/basic"> <rtp-codec name="audio/basic">
<decoding>100</decoding> <decoding>100</decoding>
skipping to change at page 65, line 36 skipping to change at page 66, line 36
--------------------------------------------- ---------------------------------------------
HTTP/1.1 200 OK HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5 X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5 Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 1133 Content-Length: 1133
Date: Mon, 12 Apr 2011 14:59:26 GMT Date: Mon, 12 Apr 2011 14:59:26 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" > <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"> <mediaResourceResponse reason="Resource found" status="200"
id="gh11x23v">
<response-session-info> <response-session-info>
<session-id>5t3Y4IQ84gY1</session-id> <session-id>5t3Y4IQ84gY1</session-id>
<seq>1</seq> <seq>1</seq>
<expires>3600</expires> <expires>3600</expires>
<media-server-address \ <media-server-address
uri="sip:MediaServer@ms.example.com:5080"> uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>60</decoding> <decoding>60</decoding>
<encoding>60</encoding> <encoding>60</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
<media-server-address \ <media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080"> uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>40</decoding> <decoding>40</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
As the dumps evince, the request and response are associated by means
of the 'id' attribute (id="gh11x23v").
The rest of the scenario is omitted for brevity. After having The rest of the scenario is omitted for brevity. After having
received the 'mediaResourceResponse', the AS has the address of two received the 'mediaResourceResponse', the AS has the address of two
MS able to fulfil its media requirements, and can start a Control MSs able to fulfil its media requirements, and can start a Control
Dialog with one or both of them. Dialog with one or both of them.
9.2.2. IAMM Example 9.2.2. IAMM Example
As anticipated, two separate examples are presented for the IAMM As anticipated, two separate examples are presented for the IAMM
case: in fact, IAMM-mode can take advantage of two different case: in fact, IAMM-mode can take advantage of two different
approaches with respect to the SIP dialogs to be exploited to carry approaches with respect to the SIP dialogs to be exploited to carry
consumer messages, i.e.: i) a SIP control dialog to create a control consumer messages, i.e.: i) a SIP control dialog to create a control
channel, and, ii) a UAC call leg to attach to a MS. To make things channel, and, ii) a UAC call leg to attach to a MS. To make things
clearer for the reader, the same consumer request as the one clearer for the reader, the same consumer request as the one
presented in the Query mode will be sent, in order to clarify how the presented in the Query mode will be sent, in order to clarify how the
behaviour of the involved parties may differ. behaviour of the involved parties may differ.
9.2.2.1. IAMM Example: CFW-based approach 9.2.2.1. IAMM Example: CFW-based approach
The following example assumes the interested AS already knows the SIP The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS. URI where an MRB is listening as an UAS.
Figure 11 shows the first approach, i.e. SIP-based transactions Figure 11 shows the first approach, i.e. SIP-based transactions
involving the AS interested in setting up a control channel, the MRB between the AS, the MRB and one MS that the MRB chooses from the two
and the MS that will be chosen eventually. The diagram is more that are allocated to fulfill the request. The diagram is more
complex than before. This is basically a scenario envisaging the MRB complex than before. This is basically a scenario envisaging the MRB
as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW- as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW-
related SDP and a Consumer request (multipart body). The MRB sends a related SDP and a Consumer request (multipart body). The MRB sends a
provisional response to the AS (2.) and starts working on the provisional response to the AS (2.) and starts working on the
request. First of all, it makes use of the Consumer request from the request. First of all, it makes use of the Consumer request from the
AS to determine which MS should be exploited. Once the right MS have AS to determine which MSs should be exploited. Once the right MSs
been chosen, the MRB sends a new SIP INVITE to one of the MS by just have been chosen (MS1 and MS2 in the example), the MRB sends a new
including the SDP part of the original request (3.). The MS SIP INVITE to one of the MSs (MS1 in the example) by just including
negotiates this INVITE as specified in the SDP part of the original request (3.). That MS negotiates this
[I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing INVITE as specified in [RFC6230] (4., 5., 6.), providing the MRB with
the MRB with its own CFW-related SDP. The MRB replies to the its own CFW-related SDP. The MRB replies to the original AS INVITE
original AS INVITE preparing a SIP 200 OK with another multipart body preparing a SIP 200 OK with another multipart body (7.): this
(7.): this multipart body includes the Consumer response used by the multipart body includes the Consumer response used by the MRB to
MRB to determine the right MS and the SDP returned by the MS in 5. determine the right MSs and the SDP returned by the MS (MS1) 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 that MS (MS1). Since the MRB provided the AS with
two MSs instances to fulfill its requirements, the AS can use the URI
in the <media-server-address> element in the <mediaResourceResponse>
that describes the other MS to establish a CFW channel with that MS
(MS2) as well.
Please note that, to ease the reading of the protocol contents, a Please note that, to ease the reading of the protocol contents, a
simple '=_Part' is used whenever a boundary for a 'multipart/mixed' simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
payload is provided, instead of the actual boundary that would be payload is provided, instead of the actual boundary that would be
inserted in the SIP messages. inserted in the SIP messages.
AS MRB MS AS MRB MS1 MS2
| | | | | | |
| 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 | |
| | pick MS | | | pick MSs (MS1 and MS2) | |
| | | | | | |
| | 3. INVITE | | | 3. INVITE | |
| | (only copy SDP from 1.) | | | (only copy SDP from 1.) | |
| |-------------------------->| | |-------------------------->| |
| | 4. 100 (Trying) | | | 4. 100 (Trying) | |
| |<--------------------------| | |<--------------------------| |
| | |--+ Negotiate | | |--+ Negotiate |
| | | | CFW Control | | | | CFW Control |
| | |<-+ Channel | | |<-+ Channel |
| | 5. 200 OK | | | 5. 200 OK | |
| |<--------------------------| | |<--------------------------| |
| | 6. ACK | | | 6. ACK | |
| |-------------------------->| | |-------------------------->| |
| Prepare new +--| | | Prepare new +--| | |
| payload with | | | | payload with | | | |
| SDP from MS and +->| | | SDP from MS and +->| | |
| Consumer reply | | | Consumer reply | | |
| | | | | | |
| 7. 200 OK | | | 7. 200 OK | | |
| (multipart/mixed) | | | (multipart/mixed) | | |
|<----------------------| | |<----------------------| | |
| 8. ACK | | | 8. ACK | | |
|---------------------->| | |---------------------->| | |
| | | | | | |
|--+ Read Cons. reply | | |--+ Read Cons. reply | | |
| | and use SDP to | | | | and use SDP to | | |
|<-+ create CFW Chn. | | |<-+ create CFW Chn. | | |
| | | | | | |
| | | | |
|<<############## TCP CONNECTION #################>>| | Create TCP CFW channel towards MS1 (if needed) | |
| | |-------------------------------------------------->| |
| CFW SYNC | | | |
|++++++++++++++++++++++++++++++++++++++++++++++++++>| |<<############## TCP CONNECTION #################>>| |
| | | | |
. . . | CFW SYNC | |
. . . |++++++++++++++++++++++++++++++++++++++++++++++++++>| |
| | |
. . . .
. . . .
| | |
| Negotiate SIP Control Dialog with MS2 |
|<------------------------------------------------------------------>|
| Create TCP CFW channel towards MS2 as well (if needed) |
|------------------------------------------------------------------->|
| |
|<<######################## TCP CONNECTION ########################>>|
| |
| CFW SYNC |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
| | | |
. . . .
. . . .
Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram
The rest of this section includes an almost full dump of the messages The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP associated with the previous sequence diagram. Only the relevant SIP
messages are shown (both the INVITEs and the 200 OKs), and only the messages are shown (both the INVITEs and the 200 OKs), and only the
relevant headers are preserved for brevity (Content-Type and relevant headers are preserved for brevity (Content-Type and
multipart-related information). Specifically: multipart-related information). Specifically:
1. the original INVITE (1), containing both a CFW-related SDP 1. the original INVITE (1), containing both a CFW-related SDP
skipping to change at page 70, line 4 skipping to change at page 70, line 42
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 =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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 id="pz78hnq1">
<generalInfo> <generalInfo>
<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="audio/basic"> <rtp-codec name="audio/basic">
<decoding>100</decoding> <decoding>100</decoding>
<encoding>100</encoding> <encoding>100</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
<file-formats> <file-formats>
skipping to change at page 71, line 50 skipping to change at page 72, line 43
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 =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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"
id="pz78hnq1">
<response-session-info> <response-session-info>
<session-id>z1skKYZQ3eFu</session-id> <session-id>z1skKYZQ3eFu</session-id>
<seq>1</seq> <seq>1</seq>
<expires>3600</expires> <expires>3600</expires>
<media-server-address \ <media-server-address
uri="sip:MediaServer@ms.example.com:5080"> uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id> <connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>60</decoding> <decoding>60</decoding>
<encoding>60</encoding> <encoding>60</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
<media-server-address \ <media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080"> uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>40</decoding> <decoding>40</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
=_Part =_Part
As it can be evinced from the dumps, the only difference in the As the dumps evince, the only difference in the response the MRB
response the MRB provides the AS with is in the 'connection-id' provides the AS with is in the 'connection-id' attribute that is
attribute that is added to the first allocated MS instance: this added to the first allocated MS instance: this allows the AS to
allows the AS to understand the MRB has sent the CFW channel understand the MRB has sent the CFW channel negotiation to that
negotiation to that specific MS, and that the connection-id to be specific MS, and that the connection-id to be used (should the SIP
used (should the SIP control dialog also include media-related SDP control dialog also include media-related SDP later on) is the one
later on) is the one provided. This will be more carefully described provided. This will be more carefully described in the next section,
in the next section, for the call leg-based approach. for the call leg-based approach.
The continuation of the scenario (the AS connecting to the MS to The continuation of the scenario (the AS connecting to MS1 to start
start the Control Channel, the SYNC message, etc.) are omitted for the Control Channel and the related SYNC message, the AS connecting
brevity. to MS2 as well later on, all the call legs being attached to either
MS) are omitted for brevity.
9.2.2.2. IAMM Example: Call leg-based approach 9.2.2.2. IAMM Example: Call leg-based approach
The following example assumes the interested AS already knows the SIP The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS. URI where an MRB is listening as an UAS.
Figure 12 shows the second approach, i.e. SIP-based transactions Figure 12 shows the second approach, i.e. SIP-based transactions
related to a UAC call leg the AS wants to attach to a MS, the MRB and between a SIP client, the AS, the MRB and the MS that the MRB
the MS that will be chosen eventually. The interaction is basically chooses. The interaction is basically the same as before (e.g. for
the same as before (e.g. for what concerns the multipart body) but what concerns the multipart body) but considering a new party is
considering a new party is involved in the communication, the diagram involved in the communication, the diagram is slightly more complex
is slightly more complex than before. As before, the MRB acts as a than before. As before, the MRB acts as a B2BUA. A UAC sends a SIP
B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the AS, INVITE to a SIP URI handled by the AS, since it is interested to its
since it is interested to its services (1.). The AS sends a services (1.). The AS sends a provisional response (2.) and, since
provisional response (2.) and, since it doesn't have the resources it doesn't have the resources yet, sends to the MRB a new SIP INVITE
yet, sends to the MRB a new SIP INVITE (3.), containing both the UAC (3.), containing both the UAC media-related SDP and a Consumer
media-related SDP and a Consumer request (multipart body). The MRB request (multipart body). The MRB sends a provisional response to
sends a provisional response to the AS (4.) and starts working on the the AS (4.) and starts working on the request. First of all, it
request. First of all, it makes use of the Consumer request from the makes use of the Consumer request from the AS to determine which MSs
AS to determine which MS should be chosen. Once the right MS have should be chosen. Once the right MSs have been chosen, the MRB sends
been chosen, the MRB sends a new SIP INVITE to one of the MS by just a new SIP INVITE to one of the MSs by just including the SDP part of
including the SDP part of the original request (5.). The MS the original request (5.). The MS negotiates this INVITE as
negotiates this INVITE as specified in specified in [RFC6230] (6., 7., 8.) to allocate the needed media
[I-D.ietf-mediactrl-sip-control-framework] (6., 7., 8.) to allocate resources to handle the new call leg, eventually providing the MRB
the needed media resources to handle the new call leg, eventually with its own media-related SDP. The MRB replies to the original AS
providing the MRB with its own media-related SDP. The MRB replies to INVITE preparing a SIP 200 OK with another multipart body (9.): this
the original AS INVITE preparing a SIP 200 OK with another multipart multipart body includes the Consumer response from the MRB indicating
body (9.): this multipart body includes the Consumer response from the chosen MSs and the SDP returned by the MS in 7. The AS finally
the MRB indicating the chosen MS and the SDP returned by the MS in 7. acknowledges the 200 OK (10.), and ends the scenario by eventually
The AS finally acknowledges the 200 OK (10.), and ends the scenario providing the UAC with the SDP it needs to set-up the RTP channels
by eventually providing the UAC with the SDP it needs to set-up the with the chosen MS: a separate direct SIP control dialog may be
RTP channels with the chosen MS: a separate direct SIP control dialog initiated by the AS to the same MS in order to set up a control
may be initiated by the AS to the same MS in order to set up a channel to manipulate the call leg media.
control channel to manipulate the call leg media.
As with the IAMM - CFW example in the prior section, this example has As with the IAMM - CFW example in the prior section, this example has
the MRB selecting MS resources across two MS instances. And here the MRB selecting MS resources across two MS instances. And here
again the convention can be that the MRB sent the SIP INVITE to the again the convention can be that the MRB sent the SIP INVITE to the
first MS in the list provided to the AS in the Consumer response first MS in the list provided to the AS in the Consumer response
information. information. For the sake of brevity, the considerations about
connecting to the other MS as well are omitted, since they have
already been addressed in the previous section.
Please note that, to ease the reading of the protocol contents, a Please note that, to ease the reading of the protocol contents, a
simple '=_Part' is used whenever a boundary for a 'multipart/mixed' simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
payload is provided, instead of the actual boundary that would be payload is provided, instead of the actual boundary that would be
inserted in the SIP messages. inserted in the SIP messages.
UAC AS MRB MS UAC AS MRB MS
| | | | | | | |
| 1. INVITE | | | | 1. INVITE | | |
| (media SDP) | | | | (media SDP) | | |
skipping to change at page 75, line 13 skipping to change at page 76, line 7
| | | | | | | |
|<<*************************** RTP *******************************>>| |<<*************************** RTP *******************************>>|
| | | | | | | |
| |--+ Negotiate | | | |--+ Negotiate | |
| | | CFW channel | | | | | CFW channel | |
| |<-+ towards MS | | | |<-+ towards MS | |
| | (if needed) | | | | (if needed) | |
. . . . . . . .
. . . . . . . .
| | | | | | | |
| | |
| | Create TCP CFW channel towards MS (if needed) |
| |-------------------------------------------------->|
| | |
| |<<############## TCP CONNECTION #################>>| | |<<############## TCP CONNECTION #################>>|
| | | | | |
| | CFW SYNC | | | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>| | |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | | | |
. . . . . . . .
. . . . . . . .
Figure 12: Consumer Example (IAMM-CallLeg): Sequence Diagram Figure 12: Consumer Example (IAMM-CallLeg): Sequence Diagram
skipping to change at page 76, line 14 skipping to change at page 77, line 12
1. UAC -> AS (INVITE with media SDP) 1. UAC -> AS (INVITE with media SDP)
------------------------------------ ------------------------------------
[..] [..]
From: <sip:lminiero@users.example.com>;tag=1153573888 From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1 o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation s=A conversation
c=IN IP4 4.3.2.1 c=IN IP4 203.0.113.2
t=0 0 t=0 0
m=audio 7078 RTP/AVP 0 3 8 101 m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1 a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1 a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1 a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11 a=fmtp:101 0-11
m=video 9078 RTP/AVP 98 m=video 9078 RTP/AVP 98
3. AS -> MRB (INVITE multipart/mixed) 3. AS -> MRB (INVITE multipart/mixed)
skipping to change at page 76, line 38 skipping to change at page 77, line 36
[..] [..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org> To: <sip:Mrb@mrb.example.org>
[..] [..]
Content-Type: multipart/mixed;boundary="=_Part" Content-Type: multipart/mixed;boundary="=_Part"
=_Part =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1 o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation s=A conversation
c=IN IP4 4.3.2.1 c=IN IP4 203.0.113.2
t=0 0 t=0 0
m=audio 7078 RTP/AVP 0 3 8 101 m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1 a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1 a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1 a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11 a=fmtp:101 0-11
m=video 9078 RTP/AVP 98 m=video 9078 RTP/AVP 98
=_Part =_Part
skipping to change at page 77, line 5 skipping to change at page 78, line 4
m=audio 7078 RTP/AVP 0 3 8 101 m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1 a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1 a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1 a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11 a=fmtp:101 0-11
m=video 9078 RTP/AVP 98 m=video 9078 RTP/AVP 98
=_Part =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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 id="ns56g1x0">
<generalInfo> <generalInfo>
<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="audio/basic"> <rtp-codec name="audio/basic">
<decoding>100</decoding> <decoding>100</decoding>
skipping to change at page 77, line 44 skipping to change at page 78, line 42
5. MRB -> MS (INVITE sdp only) 5. MRB -> MS (INVITE sdp only)
------------------------------ ------------------------------
[..] [..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080> To: <sip:MediaServer@ms.example.com:5080>
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1 o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation s=A conversation
c=IN IP4 4.3.2.1 c=IN IP4 203.0.113.2
t=0 0 t=0 0
m=audio 7078 RTP/AVP 0 3 8 101 m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1 a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1 a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1 a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11 a=fmtp:101 0-11
m=video 9078 RTP/AVP 98 m=video 9078 RTP/AVP 98
7. MRB <- MS (200 OK sdp) 7. MRB <- MS (200 OK sdp)
------------------------- -------------------------
[..] [..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4 o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl s=MediaCtrl
c=IN IP4 1.2.3.4 c=IN IP4 203.0.113.1
t=0 0 t=0 0
m=audio 63442 RTP/AVP 0 3 8 101 m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000 a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 a=fmtp:101 0-15
a=ptime:20 a=ptime:20
a=label:7eda834 a=label:7eda834
m=video 33468 RTP/AVP 98 m=video 33468 RTP/AVP 98
skipping to change at page 79, line 4 skipping to change at page 79, line 46
[..] [..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>;tag=117652221 To: <sip:Mrb@mrb.example.org>;tag=117652221
[..] [..]
Content-Type: multipart/mixed;boundary="=_Part" Content-Type: multipart/mixed;boundary="=_Part"
=_Part =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4 o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl s=MediaCtrl
c=IN IP4 1.2.3.4 c=IN IP4 203.0.113.1
t=0 0 t=0 0
m=audio 63442 RTP/AVP 0 3 8 101 m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000 a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 a=fmtp:101 0-15
a=ptime:20 a=ptime:20
a=label:7eda834 a=label:7eda834
m=video 33468 RTP/AVP 98 m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2 a=fmtp:98 CIF=2
a=label:0132ca2 a=label:0132ca2
=_Part =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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"
id="ns56g1x0">
<response-session-info> <response-session-info>
<session-id>z1skKYZQ3eFu</session-id> <session-id>z1skKYZQ3eFu</session-id>
<seq>1</seq> <seq>1</seq>
<expires>3600</expires> <expires>3600</expires>
<media-server-address \ <media-server-address
uri="sip:MediaServer@ms.example.com:5080"> uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id> <connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>60</decoding> <decoding>60</decoding>
<encoding>60</encoding> <encoding>60</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
<media-server-address \ <media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080"> uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>40</decoding> <decoding>40</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
=_Part =_Part
11. UAC <- AS (200 OK sdp) 11. UAC <- AS (200 OK sdp)
-------------------------- --------------------------
[..] [..]
From: <sip:lminiero@users.example.com>;tag=1153573888 From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
[..] [..]
skipping to change at page 80, line 19 skipping to change at page 81, line 18
11. UAC <- AS (200 OK sdp) 11. UAC <- AS (200 OK sdp)
-------------------------- --------------------------
[..] [..]
From: <sip:lminiero@users.example.com>;tag=1153573888 From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4 o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl s=MediaCtrl
c=IN IP4 1.2.3.4 c=IN IP4 203.0.113.1
t=0 0 t=0 0
m=audio 63442 RTP/AVP 0 3 8 101 m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000 a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 a=fmtp:101 0-15
a=ptime:20 a=ptime:20
a=label:7eda834 a=label:7eda834
m=video 33468 RTP/AVP 98 m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2 a=fmtp:98 CIF=2
a=label:0132ca2 a=label:0132ca2
As it can be evinced from the dumps, as in the IAMM-CFW example the As the dumps evinced, as in the IAMM-CFW example, the MRB provides
MRB provides the AS with a 'connection-id' attribute in the consumer the AS with a 'media-server-address' element in the consumer
response: this connection-id allows the AS to understand the MRB has response: the 'uri' attribute identifies the specific MS to which the
sent the SDP media negotiation to that specific MS, and that the MRB has sent the SDP media negotiation, and the 'connection-id'
connection-id to be used in CFW requests is the one provided. This enables the AS to identify to the MS the dialog between the MRB and
attribute is needed, since, according to the framework specification, MS. This attribute is needed, since, according to the framework
the AS should build this connection-id out of the From/To tags specification, the connection-id is built out of the From/To tags of
extracted from the negotiation with the MS: since the MRB acts as a the dialog between the MRB and MS; since the MRB acts as a B2BUA in
B2BUA in this scenario, without that attribute the AS and the MS this scenario, without that attribute the AS does not know the
would refer to different tags and, as a consequence, different relevant tags, thus preventing the CFW protocol to work as expected.
connection-ids, thus preventing the CFW protocol to work as expected.
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.
10. Media Service Resource Publisher Interface XML Schema 10. 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 91, line 32 skipping to change at page 91, line 32
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="supported-codec" type="supported-codecType" /> <xsd:element name="supported-codec" type="supported-codecType" />
<xsd:complexType name="supported-codec-packageType"> <xsd:complexType name="supported-codec-packageType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element name="supported-actions" type="actions.datatype" <xsd:element name="supported-action" type="actions.datatype"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
skipping to change at page 100, line 41 skipping to change at page 100, line 41
<xsd:element name="language" type="languageType" /> <xsd:element name="language" type="languageType" />
<!-- media-server-location --> <!-- media-server-location -->
<xsd:complexType name="media-server-locationType"> <xsd:complexType name="media-server-locationType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element name="civicAddress" type="ca:civicAddress" <xsd:element name="civicAddress" type="ca:civicAddress"
minOccurs="1" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd: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="media-server-location" <xsd:element name="media-server-location"
type="media-server-locationType" /> type="media-server-locationType" />
skipping to change at page 101, line 17 skipping to change at page 101, line 17
<xsd:complexType name="vxml-supportType"> <xsd:complexType name="vxml-supportType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="vxml-mode" <xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" /> <xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType"> <xsd:complexType name="vxml-modeType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
skipping to change at page 103, line 11 skipping to change at page 103, line 9
<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:string" />
</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="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">
skipping to change at page 106, line 32 skipping to change at page 106, line 32
<xsd:complexType name="mediaResourceRequestType"> <xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="generalInfo" minOccurs="0" /> <xsd:element ref="generalInfo" minOccurs="0" />
<xsd:element ref="ivrInfo" minOccurs="0" /> <xsd:element ref="ivrInfo" minOccurs="0" />
<xsd:element ref="mixerInfo" minOccurs="0" /> <xsd:element ref="mixerInfo" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="mediaResourceRequest" <xsd:element name="mediaResourceRequest"
type="mediaResourceRequestType" /> type="mediaResourceRequestType" />
<!-- <!--
##################################################### #####################################################
skipping to change at page 109, line 46 skipping to change at page 109, line 49
<!-- mediaResourceResponse --> <!-- mediaResourceResponse -->
<xsd:complexType name="mediaResourceResponseType"> <xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="response-session-info" minOccurs="0" /> <xsd:element ref="response-session-info" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<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="mediaResourceResponse" <xsd:element name="mediaResourceResponse"
type="mediaResourceResponseType" /> type="mediaResourceResponseType" />
<!-- <!--
#################################################### ####################################################
ELEMENTS ELEMENTS
skipping to change at page 110, line 19 skipping to change at page 110, line 24
type="mediaResourceResponseType" /> type="mediaResourceResponseType" />
<!-- <!--
#################################################### ####################################################
ELEMENTS ELEMENTS
#################################################### ####################################################
--> -->
<!-- session-info --> <!-- response-session-info -->
<xsd:complexType name="response-session-infoType"> <xsd:complexType name="response-session-infoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/> <xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/> <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/> <xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address" <xsd:element ref="media-server-address"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
skipping to change at page 111, line 47 skipping to change at page 112, line 4
<xsd:sequence> <xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" /> <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" /> <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" /> <xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- file-format -->
<!-- file-formats -->
<xsd:complexType name="file-formatsType"> <xsd:complexType name="file-formatsType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="required-format" <xsd:element ref="required-format"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
skipping to change at page 118, line 4 skipping to change at page 118, line 10
<!-- vxml --> <!-- vxml -->
<xsd:complexType name="vxmlType"> <xsd:complexType name="vxmlType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="vxml-mode" <xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="support" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="vxml" type="vxmlType" /> <xsd:element name="vxml" type="vxmlType" />
<xsd:complexType name="vxml-modeType"> <xsd:complexType name="vxml-modeType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
skipping to change at page 118, line 38 skipping to change at page 118, line 41
<xsd:element name="vxml-mode" type="vxml-modeType" /> <xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- location --> <!-- location -->
<xsd:complexType name="locationType"> <xsd:complexType name="locationType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="ca:civicAddress" <xsd:element ref="ca:civicAddress"
minOccurs="1" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd: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="location" type="locationType" /> <xsd:element name="location" type="locationType" />
<!-- encryption --> <!-- encryption -->
<xsd:element name="encryption" type="boolean.datatype" /> <xsd:element name="encryption" type="boolean.datatype" />
<!-- application-data --> <!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" /> <xsd:element name="application-data" type="appdata.datatype" />
<!-- max-prepared-duration --> <!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType"> <xsd:complexType name="max-prepared-durationType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
skipping to change at page 124, line 4 skipping to change at page 124, line 7
<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>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="vxml.datatype"> <xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4240" /> <xsd:enumeration value="RFC4240" />
<xsd:enumeration value="RFC5552" /> <xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" /> <xsd:enumeration value="IVR-Package" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:string" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 14 Figure 14
12. Security Considerations 12. Security Considerations
The MRB network entity has two primary interfaces, Publish and The MRB network entity has two primary interfaces, Publish and
Consumer, that carry sensitive information and must therefore be Consumer, that carry sensitive information and must therefore be
appropriately protected and secured. appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1, The Publish interface, as defined in and described in Section 5.1,
uses the Media Control Channel Framework uses the Media Control Channel Framework [RFC6230] as a mechanism to
[I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect connect an MRB to a media server. The appropriate Security
an MRB to a media server. The appropriate Security Considerations Considerations included in the Media Control Channel Framework
included in the Media Control Channel Framework specification MUST be specification MUST be used in conjunction with this specification to
used in conjunction with this specification to protect interactions protect interactions between an MRB and a media server.
between an MRB and a media server.
The Consumer interface, as defined in and described in Section 5.2, The Consumer interface, as defined in and described in Section 5.2,
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
skipping to change at page 126, line 10 skipping to change at page 126, line 10
Media Servers, Media Resource Brokers themselves) MUST support the Media Servers, Media Resource Brokers themselves) MUST support the
HTTP and SIP Digest access authentication. That said, the usage of HTTP and SIP Digest access authentication. That said, the usage of
such Digest access authentications is recommended and not mandatory, such Digest access authentications is recommended and not mandatory,
which means MRB-aware entities MAY exploit it in deployment. which means MRB-aware entities MAY exploit it in deployment.
13. IANA Considerations 13. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
13.1. Control Package Registration 13.1. Media Control Channel Framework Package Registration
This section registers a new Media Control Channel Framework package, This section registers a new Media Control Channel Framework package,
per the instructions in Section 13.1 of per the instructions in Section 13.1 of [RFC6230].
[I-D.ietf-mediactrl-sip-control-framework].
To: ietf-sip-control@iana.org To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package Subject: Registration of new Media Control Channel Framework
package
Package Name: mrb-publish/1.0 [NOTE TO IANA/RFC-EDITOR: Please Package Name: mrb-publish/1.0
replace XXXX with the RFC number for this specification.]
Published Specification(s): RFCXXXX Person and email address to Published Specification(s): RFCXXXX Person and email address to
contact for further information: IETF, MEDIACTRL working group, contact for further information: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number
for this specification.]
13.2. application/mrb-publish+xml MIME Type 13.2. application/mrb-publish+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-publish+xml MIME subtype name: mrb-publish+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter of application/xml
specified in RFC 3023 [RFC3023]. as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023]. application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]]. XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: Section 10 of RFCXXXX [[NOTE TO RFC-
EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]].
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support a Media Resource Broker (MRB) entity. used to support a Media Resource Broker (MRB) entity.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .xdf File Extension: .xdf
skipping to change at page 127, line 28 skipping to change at page 127, line 31
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.3. application/mrb-consumer+xml MIME Type 13.3. application/mrb-consumer+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-consumer+xml MIME subtype name: mrb-consumer+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter of application/xml
specified in RFC 3023 [RFC3023]. as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023]. application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]]. XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: Section 11 of RFCXXXX [[NOTE TO RFC-
EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]].
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support a Media Resource Broker (MRB) entity. used to support a Media Resource Broker (MRB) entity.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .xdf File Extension: .xdf
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton, Personal and email address for further information: Chris Boulton,
chris@ns-technologies.com chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.4. URN Sub-Namespace Registration for mrb-publish 13.4. URN Sub-Namespace Registration for mrb-publish
skipping to change at page 128, line 17 skipping to change at page 128, line 24
chris@ns-technologies.com chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.4. URN Sub-Namespace Registration for mrb-publish 13.4. URN Sub-Namespace Registration for mrb-publish
Please register the URN name space Please register the URN name space
"urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish".
The template is in Section 10. The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-publish" is Section 10.
13.5. URN Sub-Namespace Registration for mrb-consumer 13.5. URN Sub-Namespace Registration for mrb-consumer
Please register the URN name space Please register the URN name space
"urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer".
The template is in Section 11. The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-consumer" is in Section 11.
13.6. XML Schema Registration for mrb-publish 13.6. XML Schema Registration for mrb-publish
Please register the schema for mrb-publish: Please register the schema for mrb-publish:
URI: urn:ietf:params:xml:ns:mrb-publish URI: urn:ietf:params:xml:ns:mrb-publish
ID: mrb-publish ID: mrb-publish
Filename: mbr-publish Filename: mrb-publish
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 10 of this document. Schema: The XML for the schema is in Section 10 of this document.
13.7. XML Schema Registration for mrb-consumer 13.7. XML Schema Registration for mrb-consumer
Please register the schema for mrb-consumer: Please register the schema for mrb-consumer:
URI: urn:ietf:params:xml:ns:mrb-consumer URI: urn:ietf:params:xml:ns:mrb-consumer
ID: mrb-consumer ID: mrb-consumer
Filename: mbr-consumer Filename: mrb-consumer
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document. Schema: The XML for the schema is in Section 11 of this document.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 09 Version 14.1. Changes from 10 Version
o Editorial changes as a result of Shepherd review.
o Added new attribute 'id' to both <mediaResourceRequest> and
<mediaResourceResponse> elements in the consumer schema, in order
to map a response to a specific request.
o Renamed 'supported-actions' to 'supported-action' in the Publisher
schema.
o Removed 'support' attribute from both the <vxml-support> element
(Publisher schema) and the <vxml> element (Consumer schema): now
an empty element means no VXML support is provided/requested.
o Clarified the scope of the 'application-data' element, and changed
its type from xsd:NMTOKEN to xsd:string in the schema.
o Clarified the use of the <subscription> element in an
<mrbresponse.
o Clarified the meaning of TCP CONNECTION in sequence diagrams.
o Removed useless backslashes from XML examples.
o Updated references for Framework and IVR drafts (RFC6230,
RFC6231).
14.2. Changes from 09 Version
o Language changes as a result of Shepherd review. o Language changes as a result of Shepherd review.
14.2. Changes from 08 Version 14.3. Changes from 08 Version
o Fixed Nits. o Fixed Nits.
o Added range for reporting period - as per mailing list. o Added range for reporting period - as per mailing list.
14.3. Changes from 07 Version 14.4. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences; incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests; o Corrected examples after validation tests;
o Fixed a few typos in the text. o Fixed a few typos in the text.
o Clarified language in various places. o Clarified language in various places.
skipping to change at page 130, line 44 skipping to change at page 131, line 24
o Clarifying text related to IAMM and IUMM. o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow o Expanded media-server-address for extra information and to allow
multiples. multiples.
o New B2BUA section. o New B2BUA section.
o Updated Examples. o Updated Examples.
14.4. Changes from 06 Version 14.5. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp- o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed. codec> instances, where needed.
o Fixed a few typos in the text. o Fixed a few typos in the text.
14.5. Changes from 05 Version 14.6. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined o Clarifier that video layouts may refer to either XCON-defined
layouts or others. layouts or others.
o Added RFC4240 as an option for VXML support. o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas. o Fixed a few typos in the text and in the schemas.
14.6. Changes from 04 Version 14.7. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions. 'response-session-info' definitions.
o Clarified that 'response-session-info' is not only included in o Clarified that 'response-session-info' is not only included in
reply to updates, but also to new requests; besides, clarified reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any in successful responses (200), while not needed otherwise (any
error). error).
o Corrected the Query example flow which included a 'session'info' o Corrected the Query example flow which included a 'session'info'
in a new request. in a new request.
14.7. Changes from 03 Version 14.8. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell. o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits). o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version). Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are o Clarified that backslashes and XML indentation in the Examples are
only provided for readability. only provided for readability.
skipping to change at page 132, line 5 skipping to change at page 132, line 30
responses, in order to clarify when they are involved. responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the o Added some text to better clarify the role of leasing in the
Consumer interface. Consumer interface.
o Added additional IANA considerations, that were missing in the o Added additional IANA considerations, that were missing in the
previous versions of the document. previous versions of the document.
o Added text to the security considerations. o Added text to the security considerations.
14.8. Changes from 02 Version 14.9. Changes from 02 Version
o Added examples in Section 9. o Added examples in Section 9.
o Fixed some nits in the schemas (encryption and required mixed=true o Fixed some nits in the schemas (encryption and required mixed=true
elements). elements).
o Completed review nit review comments from Gary Munson. o Completed review nit review comments from Gary Munson.
14.9. Changes from 01 Version 14.10. 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 132, line 36 skipping to change at page 133, line 13
o Removed announce-var element from doc. o Removed announce-var element from doc.
o Expanded Abstract. o Expanded Abstract.
o General scrub of text - input from Simon Romano. o General scrub of text - input from Simon Romano.
o Added IANA Considerations section. o Added IANA Considerations section.
o Added Security Considerations section. o Added Security Considerations section.
14.10. Changes from 00 Version 14.11. Changes from 00 Version
o Included In-line text based on strawman proposal. o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team o Included first attempt at publish interface based on design team
work. work.
15. Acknowledgements 15. Acknowledgements
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
skipping to change at page 134, line 36 skipping to change at page 135, line 36
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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. 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)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 4722,
November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
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.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H. Mendelsohn, N., Moreau, J., Gudgin, M., Hadley, M., and H.
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Hadley, M., Moreau, J., Gudgin, M., and H. Mendelsohn, N., Moreau, J., Hadley, M., Nielsen, H., and
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-mediactrl-ivr-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework",
draft-ietf-mediactrl-ivr-control-package-11 (work in
progress), January 2011.
[I-D.ietf-mediactrl-mixer-control-package] [I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework", Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-14 (work in draft-ietf-mediactrl-mixer-control-package-14 (work in
progress), January 2011. progress), January 2011.
[I-D.ietf-mediactrl-sip-control-framework] [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-12 (work in
progress), September 2010.
[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 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006. December 2006.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007.
[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 [RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
Services", RFC 5552, May 2009. 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.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230, May 2011.
[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework", RFC 6231, May 2011.
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and
'Profiles' Parameters for "Bucket" Media Types", RFC 6381,
August 2011.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Via Carlo Poerio 89 Via Carlo Poerio 89
 End of changes. 366 change blocks. 
765 lines changed or deleted 886 lines changed or added

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