draft-ietf-mediactrl-mrb-19.txt   rfc6917.txt 
Network Working Group C. Boulton Internet Engineering Task Force (IETF) C. Boulton
Internet-Draft NS-Technologies Request for Comments: 6917 NS-Technologies
Intended status: Standards Track L. Miniero Category: Standards Track L. Miniero
Expires: August 22, 2013 Meetecho ISSN: 2070-1721 Meetecho
G. Munson G. Munson
AT&T AT&T
February 18, 2013 April 2013
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-19
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl working group in the IETF has proposed an architecture
controlling media services. The Session Initiation Protocol (SIP) is for controlling media services. The Session Initiation Protocol
used as the signalling protocol which provides many inherent (SIP) is used as the signaling protocol that provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signaling
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 signaling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
architectures that include 1:M and M:N combinations of Application architectures that include 1:M and M:N combinations of Application
Servers and Media Servers. This document introduces a Media Resource Servers and Media Servers. This document introduces a Media Resource
Broker (MRB) entity which manages the availability of Media Servers Broker (MRB) entity, which manages the availability of Media Servers
and the media resource demands of Application Servers. The document and the media resource demands of Application Servers. The document
includes potential deployment options for an MRB and appropriate includes potential deployment options for an MRB and appropriate
interfaces to Application Servers and Media Servers. interfaces to Application Servers and Media Servers.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 22, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6917.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology .....................................6
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Discussion ..............................................6
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9 4. Deployment Scenario Options .....................................7
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Query MRB ..................................................8
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB ....................................9
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB ...............................................11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions ......................................12
5.1. Media Server Resource Publish Interface . . . . . . . . 14 5.1. Media Server Resource Publish Interface ...................12
5.1.1. Control Package Definition . . . . . . . . . . . . . 15 5.1.1. Control Package Definition .........................13
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16 5.1.2. Element Definitions ................................15
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> .......................................15
5.1.4. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 19 5.1.4. <mrbresponse> ......................................17
5.1.5. <mrbnotification> . . . . . . . . . . . . . . . . . . 20 5.1.5. <mrbnotification> ..................................19
5.2. Media Service Resource Consumer Interface . . . . . . . 31 5.2. Media Service Resource Consumer Interface .................30
5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 32 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 . . . . . . . . . 36 5.2.3. Consumer Interface Lease Mechanism .................35
5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 38 5.2.4. <mrbconsumer> ......................................38
5.2.5. Media Service Resource Request . . . . . . . . . . . 39 5.2.5. Media Service Resource Request .....................39
5.2.6. Media Service Resource Response . . . . . . . . . . . 50 5.2.6. Media Service Resource Response ....................51
5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 53 5.3. In-Line Unaware MRB Interface .............................54
6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 55 6. MRB Acting as a B2BUA ..........................................54
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 56 7. Multimodal MRB Implementations .................................55
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 57 8. Relative Merits of Query Mode, IAMM, and IUMM ..................56
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. Examples .......................................................58
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 59 9.1. Publish Example ...........................................58
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 64 9.2. Consumer Examples .........................................64
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 64 9.2.1. Query Example ......................................64
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 67 9.2.2. IAMM Examples ......................................68
10. Media Service Resource Publisher Interface XML Schema . . . . 83 10. Media Service Resource Publisher Interface XML Schema .........83
11. Media Service Resource Consumer Interface XML Schema . . . . 106 11. Media Service Resource Consumer Interface XML Schema .........106
12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 12. Security Considerations ......................................127
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 13. IANA Considerations ..........................................130
13.1. Media Control Channel Framework Package Registration . . 130 13.1. Media Control Channel Framework Package Registration ....130
13.2. application/mrb-publish+xml Media Type . . . . . . . . . 130 13.2. application/mrb-publish+xml Media Type ..................130
13.3. application/mrb-consumer+xml Media Type . . . . . . . . 131 13.3. application/mrb-consumer+xml Media Type .................131
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 132 13.4. URN Sub-Namespace Registration for mrb-publish ..........132
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 132 13.5. URN Sub-Namespace Registration for mrb-consumer .........132
13.6. XML Schema Registration for mrb-publish . . . . . . . . 132 13.6. XML Schema Registration for mrb-publish .................132
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 133 13.7. XML Schema Registration for mrb-consumer ................133
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 14. Acknowledgements .............................................133
14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 134 15. References ...................................................133
14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 134 15.1. Normative References ....................................133
14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 134 15.2. Informative References ..................................135
14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 134
14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 135
14.6. Changes from 08 Version . . . . . . . . . . . . . . . . 135
14.7. Changes from 07 Version . . . . . . . . . . . . . . . . 135
14.8. Changes from 06 Version . . . . . . . . . . . . . . . . 136
14.9. Changes from 05 Version . . . . . . . . . . . . . . . . 136
14.10. Changes from 04 Version . . . . . . . . . . . . . . . . 136
14.11. Changes from 03 Version . . . . . . . . . . . . . . . . 136
14.12. Changes from 02 Version . . . . . . . . . . . . . . . . 137
14.13. Changes from 01 Version . . . . . . . . . . . . . . . . 137
14.14. Changes from 00 Version . . . . . . . . . . . . . . . . 137
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 138
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 139
16.1. Normative References . . . . . . . . . . . . . . . . . . 139
16.2. Informative References . . . . . . . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 142
1. Introduction 1. Introduction
As IP based multimedia infrastructures mature, the complexity and As IP-based multimedia infrastructures mature, the complexity and
demands from deployments increase. Such complexity will result in a demands from deployments increase. Such complexity will result in a
wide variety of capabilities from a range of vendors that should all wide variety of capabilities from a range of vendors that should all
be interoperable using the architecture and protocols produced by the be interoperable using the architecture and protocols produced by the
MediaCtrl work group. It should be possible for a controlling entity MediaCtrl working group. It should be possible for a controlling
to be assisted in Media Server selection so that the most appropriate entity to be assisted in Media Server selection so that the most
resource is selected for a particular operation. The importance appropriate resource is selected for a particular operation. The
increases when you introduce a flexible level of deployment importance increases when one introduces a flexible level of
scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567 deployment scenarios, as specified in RFC 5167 [RFC5167] and RFC 5567
[RFC5567] documents. These documents make statements like "it should [RFC5567]. These documents make statements like "it should be
be possible to have a many-to-many relationship between Application 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, to provide what can be effectively described as media resources, to provide what can be effectively described as
Media Resource Brokering. 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
This simply involves a single Application Server and Media Server. This simply involves a single Application Server and Media Server.
Expanding on this view, it is also possible for an Application Server Expanding on this view, it is also possible for an Application Server
to control multiple (greater that 1) Media Server instances at any to control multiple (greater than 1) Media Server instances at any
one time. This deployment view is illustrated in Figure 2. one time. This deployment view is illustrated in Figure 2.
Typically, such architectures are associated with application logic Typically, such architectures are associated with application logic
that requires high demand media services. It is more than possible that requires high-demand media services. It is more than possible
that each media server possesses a different media capability set. that each Media Server possesses a different media capability set.
Media servers may offer different media services as specified in the Media Servers may offer different media services as specified in the
Mediactrl architecture document. A Media server may have similar MediaCtrl architecture document [RFC5567]. A Media Server may have
media functionality but may have different capacity or media codec similar media functionality but may have different capacity or media
support. codec support.
+---+-----+---+ +---+-----+---+
| Media | | Media |
+----->| Server | +----->| Server |
| +-------------+ | +-------------+
| |
+---+-----+---+ | +---+-----+---+ +---+-----+---+ | +---+-----+---+
| Application | | | Media | | Application | | | Media |
| Server |<--MS Control-----+----->| Server | | Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+ +-------------+ | +-------------+
| |
| +---+-----+---+ | +---+-----+---+
+----->| Media | +----->| Media |
| Server | | Server |
+-------------+ +-------------+
Figure 2: Multiple Media Servers Figure 2: Multiple Media Servers
Figure 3 conveys the opposite view to that in Figure 2. In this Figure 3 conveys the opposite view to that in Figure 2. In this
model there are a number of (greater than 1) application servers, model, there are a number of (greater than 1) Application Servers,
possibly supporting dissimilar applications, controlling a single possibly supporting dissimilar applications, controlling a single
media server. Typically, such architectures are associated with Media Server. Typically, such architectures are associated with
application logic that requires low demand media services. application logic that requires low-demand media services.
+---+-----+---+ +---+-----+---+
| Application | | Application |
| Server |<-----+ | Server |<-----+
+-------------+ | +-------------+ |
| |
+---+-----+---+ | +---+-----+---+ +---+-----+---+ | +---+-----+---+
| Application | | | Media | | Application | | | Media |
| Server |<-----+-----MS Control-->| Server | | Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+ +-------------+ | +-------------+
| |
+---+-----+---+ | +---+-----+---+ |
| Application | | | Application | |
| Server |<-----+ | Server |<-----+
+-------------+ +-------------+
Figure 3: Multiple Application Servers Figure 3: Multiple Application Servers
The final deployment view is the most complex. In this model (M:N) The final deployment view is the most complex (Figure 4). In this
there exists any number of Application Servers and any number of model (M:N), there exist any number of Application Servers and any
Media Servers. It is again possible in this model that media servers number of Media Servers. It is again possible in this model that
might not be homogeneous and have different capability sets and Media Servers might not be homogeneous, and they might have different
capacity. capability sets and capacities.
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Application | | Media | | Application | | Media |
| Server |<-----+ +---->| Server | | Server |<-----+ +---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---+-----+---+ | | +---+-----+---+ +---+-----+---+ | | +---+-----+---+
| Application | | | | Media | | Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server | | Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---+-----+---+ | | +---+-----+---+ +---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media | | Application | | +---->| Media |
| Server |<-----+ | Server | | Server |<-----+ | Server |
+-------------+ +---+-----+---+ +-------------+ +---+-----+---+
Figure 4: Basic Architecture Figure 4: Many-to-Many Architecture
The remaining sections in this specification will focus on a new The remaining sections in this specification will focus on a new
entity called a Media Resource Broker (MRB) which can be utilised in entity called a Media Resource Broker (MRB), which can be utilized in
the deployment architectures described previously in this section. the deployment architectures described previously in this section.
The MRB entity provides the ability to obtain media resource The MRB entity provides the ability to obtain media resource
information and appropriately allocate(broker) on behalf of client information and appropriately allocate (broker) on behalf of client
applications. 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 scope for 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 recognized 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 recognized 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document inherits terminology proposed in RFC 5567 [RFC5567] and This document inherits terminology proposed in RFC 5567 [RFC5567] and
Media Control Channel Framework [RFC6230] documents. In addition, in "Media Control Channel Framework" [RFC6230]. In addition, the
the following terms are defined for use in this document and for use following terms are defined for use in this document and for use in
in the context of the MediaCtrl Work group in the IETF: the context of the MediaCtrl working 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 Media Server resources on information and selecting appropriate Media Server resources on
behalf of consuming entities. behalf of consuming entities.
Query MRB: An instantiation of an MRB (See previous definition) Query MRB: An instantiation of an MRB (see previous definition) that
that provides an interface for an Application Server to retrieve provides an interface for an Application Server to retrieve the
the address of an appropriate Media Server. The result returned address of an appropriate Media Server. The result returned to
to the Application Server can be influenced by information the Application Server can be influenced by information contained
contained in the query request. in the query request.
In-line MRB: An instantiation of an MRB (See previous definition) In-line MRB: An instantiation of an MRB (see previous definition)
that directly receives requests on the signalling path. There is that directly receives requests on the signaling path. There is
no separate query. no separate query.
CFW: Media Control Channel Framework, as specified in [RFC6230]. 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 stated otherwise, such protocol message needs to be unique. Unless stated otherwise, such
uniqueness will always be within the scope of the Media Servers uniqueness will always be within the scope of the Media Servers
controlled by the same Media Resource Broker. The interaction controlled by the same MRB. The interaction between different MRB
between different Media Resource Broker instances, as the instances, e.g., the partitioning of a logical MRB, is out of scope
partitioning of a logical Media Resource Broker, is out of scope to for this document.
this document.
3. Problem Discussion 3. Problem Discussion
As discussed in Section 1, a goal of the MediaCtrl group is to As discussed in Section 1, a goal of the MediaCtrl working group is
produce a solution that will service a wide variety of deployment to produce a solution that will service a wide variety of deployment
architectures. Such architectures range from the simplest 1:1 architectures. Such architectures range from the simplest 1:1
relationship between Media Servers and Application Servers to relationship between Media Servers and Application Servers to
potentially linearly scaling 1:M, M:1 and M:N deployments. potentially linearly scaling 1:M, M:1, and M:N deployments.
Managing such deployments is itself non-trivial for the proposed Managing such deployments is itself non-trivial for the proposed
solution until an additional number of factors are included into the solution until an additional number of factors that increase
equation that increase complexity. As Media Servers evolve it must complexity are included in the equation. As Media Servers evolve, it
be taken into consideration that, where many can exist in a must be taken into consideration that, where many can exist in a
deployment, they may not have been produced by the same vendor and deployment, they may not have been produced by the same vendor and
may not have the same capability set. It should be possible for an may not have the same capability set. It should be possible for an
Application Server that exists in a deployment to select a Media Application Server that exists in a deployment to select a media
Service based on a common, appropriate capability set. In service based on a common, appropriate capability set. In
conjunction with capabilities, it is also important to take available conjunction with capabilities, it is also important to take available
resources into consideration. The ability to select an appropriate resources into consideration. The ability to select an appropriate
Media Service function is an extremely useful feature but becomes media service function is an extremely useful feature but becomes
even more powerful when considered with available resources for even more powerful when considered with available resources for
servicing a request. servicing a request.
In conclusion, the intention is to create a tool set that allows In conclusion, the intention is to create a toolkit that allows
MediaCtrl deployments to effectively utilize the available media MediaCtrl deployments to effectively utilize the available media
resources. It should be noted that in the simplest deployments where resources. It should be noted that in the simplest deployments where
only a single media server exists, an MRB function is probably not only a single Media Server exists, an MRB function is probably not
required. Only a single capability set exists and resource required. Only a single capability set exists, and resource
availability can be handled using the appropriate underlying availability can be handled using the appropriate underlying
signalling, e.g., SIP response. This document does not prohibit such signaling, 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 interact where appropriate. It is also worth noting that the
functions specified in this document aim to provide a 'best effort' functions specified in this document aim to provide a 'best effort'
view of media resources at the time of request for initial Media view of media resources at the time of request for initial Media
Server routing decisions. Any dramatic change in media capabilities Server routing decisions. Any dramatic change in media capabilities
or capacity after a request has taken place should be handled by the or capacity after a request has taken place should be handled by the
underlying protocol. underlying protocol.
It should be noted that there may be additional information that it It should be noted that there may be additional information that is
is desirable for the MRB to have for purposes of selecting a Media desirable for the MRB to have for purposes of selecting a Media
Server resource, such as resource allocation rules across different Server 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
Media Server resource capacity models. How the MRB acquires such Media Server resource capacity models. How the MRB acquires such
information is outside the scope of this document. The specific information is outside the scope of this document. The specific
techniques used for selecting an appropriate Media Resource by an MRB techniques used for selecting an appropriate media resource by an MRB
is also outside the scope of this document. is also outside the scope of this document.
4. Deployment Scenario Options 4. Deployment Scenario Options
Research into Media Resource Brokering concluded that a couple of Research into media resource brokering concluded that a couple of
high level models provided an appropriate level of flexibility. The high-level models provided an appropriate level of flexibility. The
general principles of "in-line" and "query" MRB concepts are general principles of "in-line" and "query" MRB concepts are
discussed in the rest of this section. It should be noted that while discussed in the rest of this section. It should be noted that while
the interfaces are different they both use common underlying the interfaces are different, they both use common underlying
mechanisms defined in this specification. mechanisms defined in this specification.
4.1. Query MRB 4.1. Query MRB
The "Query" model for MRB interactions provides the ability for a The "Query" model for MRB interactions provides the ability for a
client of media services (for example an Application Server) to "ask" client of media services (for example, an Application Server) to
an MRB for an appropriate Media Server, as illustrated in Figure 5. "ask" an MRB for an appropriate Media Server, as illustrated in
Figure 5.
+---+-----+---+ +---+-----+---+
+------------>| MRB |<----------+----<-----+---+ +------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | | | +-------------+ (1)| | |
| | | | | | | |
|(2) +---+--+--+---+ | | |(2) +---+--+--+---+ | |
| | Media | | | | | Media | | |
| +---->| Server | | | | +---->| Server | | |
| | +-------------+ | | | | +-------------+ | |
| | (1)| | | | (1)| |
skipping to change at page 9, line 41 skipping to change at page 8, line 33
| Server |<-----+-MS Control-+---->| Server |->-+ | | Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ | +-------------+ (3) | +-------------+ |
| | | |
| +---+-----+---+ (1)| | +---+-----+---+ (1)|
+---->| Media | | +---->| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 5: Query MRB Figure 5: Query MRB
In this deployment, the Media Servers use the "Media Server Resource In this deployment, the Media Servers use the Media Server Resource
Publish Interface", as discussed in Section 5.1, to convey capability Publish interface, as discussed in Section 5.1, to convey capability
sets as well as resource information. This is depicted by (1) in sets as well as resource information. This is depicted by (1) in
Figure 5. It is then the MRB's responsibility to accumulate all Figure 5. It is then the MRB's responsibility to accumulate all
appropriate information relating to media services in the logical appropriate information relating to media services in the logical
deployment cluster. The Application Server (or other media services deployment cluster. The Application Server (or other media services
client) is then able to query the MRB for an appropriate resource (as client) is then able to query the MRB for an appropriate resource (as
identified by (2) in Figure 5). Such a query would carry specific identified by (2) in Figure 5). Such a query would carry specific
information related to the Media Service required and enable the MRB information related to the media service required and enable the MRB
to provide an increased accuracy in its response. This particular to provide increased accuracy in its response. This particular
interface is discussed in "Media Resource Consumer Interface" in interface is discussed in "Media Service Resource Consumer Interface"
Section 5.2. The Application Server is then able to direct control (Section 5.2). The Application Server is then able to direct control
commands (for example create conference) and Media Dialogs to the commands (for example, create a conference) and media dialogs to the
appropriate Media Server, as shown by (3) in Figure 5. Additionally, appropriate Media Server, as shown by (3) in Figure 5. Additionally,
with Query mode, the MRB is not directly in the signalling path with Query mode, the MRB is not directly in the signaling path
between the Application Server and the selected Media Server between the Application Server and the selected Media Server
resource. resource.
4.1.1. Hybrid Query MRB 4.1.1. Hybrid Query MRB
As mentioned previously, it is the intention that a tool kit is As mentioned previously, it is the intention that a toolkit is
provided for MRB functionality within a MediaCtrl architecture. It provided for MRB functionality within a MediaCtrl architecture. It
is expected that in specific deployment scenarios the role of the MRB is expected that in specific deployment scenarios the role of the MRB
might be co-hosted as a hybrid logical entity with an Application might be co-hosted as a hybrid logical entity with an Application
Server, as shown in Figure 6. Server, as shown in Figure 6.
+------------<----------------<---------+----<-----+---+ +------------<----------------<---------+----<-----+---+
| (1) | | | | (1) | | |
| | | | | | | |
| +---+--+--+---+ | | | +---+--+--+---+ | |
| | Media | | | | | Media | | |
skipping to change at page 10, line 41 skipping to change at page 9, line 34
+-------------+ | +-------------+ | +-------------+ | +-------------+ |
| | | |
| +---+-----+---+ | | +---+-----+---+ |
+---->| Media | | +---->| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 6: Hybrid Query MRB - Application Server Hosted Figure 6: Hybrid Query MRB - Application Server Hosted
This diagram is identical to that in Figure 5 with the exception that This diagram is identical to that in Figure 5 with the exception that
the MRB is now hosted on the Application Server. The "Media Server the MRB is now hosted on the Application Server. The Media Server
Publish Interface" is still being used to accumulate resource Publish interface is still being used to accumulate resource
information at the MRB but as it is co-hosted on the Application information at the MRB, but as it is co-hosted on the Application
Server, the "Media Server Consumer Interface" has collapsed. It Server, the Media Server Consumer interface has collapsed. It might
might still exist within the Application Server/MRB interaction but still exist within the Application Server/MRB interaction, but this
this is an implementation issue. This type of deployment suits a is an implementation issue. This type of deployment suits a single
single Application Server environment but it should be noted that a Application Server environment, but it should be noted that a Media
"Media Server Consumer Interface" could then be offered from the Server Consumer interface could then be offered from the hybrid if
hybrid if required. required.
In a similar manner, the Media Server could also act as a hybrid for In a similar manner, the Media Server could also act as a hybrid for
the deployment cluster, as illustrated in Figure 7. the deployment cluster, as illustrated in Figure 7.
(1) +---+-----+---+ (1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB | +---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+ | | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media | | | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server | | | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+ | | +-------------+ | +-------------+
skipping to change at page 11, line 28 skipping to change at page 10, line 28
| +-------------+ | | +-------------+ |
| | | |
| +---+--+--+---+ | | +---+--+--+---+ |
+---<-------| Application | | +---<-------| Application | |
| Server |<--+-MS Control-+--+ | Server |<--+-MS Control-+--+
+-------------+ +-------------+
Figure 7: Hybrid Query MRB - MS Hosted Figure 7: Hybrid Query MRB - MS Hosted
In this example, the MRB has collapsed and is co-hosted by the Media In this example, the MRB has collapsed and is co-hosted by the Media
Server. The "Media Server Consumer Interface" is still available to Server. The Media Server Consumer interface is still available to
the Application Servers (1) to query Media Server resources. The the Application Servers (1) to query Media Server resources. The
"Media Server Publish Interface" has collapsed onto the Media Server. Media Server Publish interface has collapsed onto the Media Server.
It might still exist within the Media Server/MRB interaction but this It might still exist within the Media Server/MRB interaction, but
is an implementation issue. This type of deployment suits a single this is an implementation issue. This type of deployment suits a
Media Server environment but it should be noted that a "Media Server single Media Server environment, but it should be noted that a Media
Publish Interface" could then be offered from the hybrid if required. Server Publish interface could then be offered from the hybrid if
A typical use case scenario for such a topology would be a single required. A typical use case scenario for such a topology would be a
Media Server representing a pool of MSs in a cluster. In this case, single Media Server representing a pool of MSs in a cluster. In this
the MRB would actually be handling a cluster of Media Servers, rather case, the MRB would actually be handling a cluster of Media Servers,
than one. rather than one.
4.2. In-Line MRB 4.2. In-Line MRB
The "In-line" MRB is architecturally different from the "Query" model The "In-line" MRB is architecturally different from the "Query" model
discussed in the previous section. The concept of a separate query discussed in the previous section. The concept of a separate query
disappears. The client of the MRB simply uses the media resource disappears. The client of the MRB simply uses the media resource
control and media dialog signalling to involve the MRB. This type of control and media dialog signaling to involve the MRB. This type of
deployment is illustrated in Figure 8. deployment is illustrated in Figure 8.
+-------<----------+----<-------+---+ +-------<----------+----<-------+---+
| | (1) | | | | (1) | |
| | | | | | | |
| +---+--+--+---+ | | | +---+--+--+---+ | |
| | Media | | | | | Media | | |
| +------>| Server | | | | +------>| Server | | |
| |(3) +-------------+ | | | |(3) +-------------+ | |
| | (1)| | | | (1)| |
+---+--+--+---+ | | +---+-----+---+ | | +---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | | | Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ | | Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ | +-------------+ +---+-----+---+ +-------------+ |
| | | |
| (3) +---+-----+---+ (1)| | (3) +---+-----+---+ (1)|
+------>| Media | | +------>| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 8: In-line MRB Figure 8: In-Line MRB
The Media Servers still use the 'Media Server Publish Interface' to The Media Servers still use the Media Server Publish interface to
convey capabilities and resources to the MRB - as illustrated by (1). convey capabilities and resources to the MRB, as illustrated by (1).
The media server Control (and Media dialogs as well, if required) are The Media Server Control Channels (and media dialogs as well, if
sent to the MRB (2) which then selects an appropriate Media Server required) are sent to the MRB (2), which then selects an appropriate
(3) and remain in the signalling path between the Application Server Media Server (3) and remains in the signaling path between the
and the Media Server resources. Application Server and the Media Server resources.
In-line MRB can be split into two distinct logical roles which can be The In-line MRB can be split into two distinct logical roles that can
applied on a per request basis. They are: be applied on a per-request basis. They are:
In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of
clients requiring media services who are not aware of an MRB or clients requiring media services who are not aware of an MRB or
its operation. In this case the Application Server does not its operation. In this case, the Application Server does not
provide explicit information on the kind of Media Server resource provide explicit information on the kind of Media Server resource
it needs (as in Section 5.2) and the MRB is left to deduce it by it needs (as in Section 5.2), and the MRB is left to deduce it by
potentially inspecting other information in the request from the potentially inspecting other information in the request from the
Application Server; for example, SDP content, or address of the Application Server (for example, Session Description Protocol
requesting Application Server, or additional Request-URI (SDP) content, or address of the requesting Application Server, or
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 Application Server to operation. In particular, it allows the Application Server to
explicitly convey matching characteristics to those provided by explicitly convey matching characteristics to those provided by
media servers, as does the Query MRB mode (as in Section 5.2). Media Servers, as does the Query MRB mode (as in Section 5.2).
In either of the previously described roles, signalling as specified In either of the previously described roles, signaling as specified
by the Media Control Channel Framework ([RFC6230]) would be involved, by the Media Control Channel Framework ([RFC6230]) would be involved,
and the MRB would deduce that the selected Media Server resources are and the MRB would deduce that the selected Media Server resources are
no longer needed when the Application Server or Media Server no longer needed when the Application Server or Media Server
terminates the corresponding SIP dialog. The two modes are discussed terminates the corresponding SIP dialog. The two modes are discussed
in more detail in Section 5.3. in more detail in Section 5.3.
5. MRB Interface Definitions 5. MRB Interface Definitions
The intention of this specification is to provide a tool-kit for a The intention of this specification is to provide a toolkit for a
variety of deployment architectures where media resource brokering variety of deployment architectures where media resource brokering
can take place. Two main interfaces are required to support the can take place. Two main interfaces are required to support the
differing requirements. The two interfaces are described in the differing requirements. The two interfaces are described in the
remainder of this section and have been named the 'Media Server remainder of this section and have been named the Media Server
Resource Publish' and 'Media Server Resource Consumer' interfaces. Resource Publish and Media Server Resource Consumer interfaces.
It is beyond the scope of this document to define exactly how to It is beyond the scope of this document to define exactly how to
construct an MRB using the interfaces described. It is, however, construct an MRB using the interfaces described. It is, however,
important that the two interfaces are complimentary so that important that the two interfaces are complimentary so that
development of appropriate MRB functionality is supported. development of appropriate MRB functionality is supported.
5.1. Media Server Resource Publish Interface 5.1. Media Server Resource Publish Interface
The Media Server Resource Publish interface is responsible for The Media Server Resource Publish interface is responsible for
providing an MRB with appropriate Media Server resource information. providing an MRB with appropriate Media Server resource information.
As such, this interface is assumed to provide both general and As such, this interface is assumed to provide both general and
specific details related to Media Server resources. This information specific details related to Media Server resources. This information
needs to be conveyed using an industry standard mechanism to provide needs to be conveyed using an industry standard mechanism to provide
increased levels of adoption and interoperability. A Control Package increased levels of adoption and interoperability. A Control Package
for the Media Control Channel Framework will be specified to fulfil for the Media Control Channel Framework will be specified to fulfill
this interface requirement. It provides an establishment and this interface requirement. It provides an establishment and
monitoring mechanism to enable a Media Server to report appropriate monitoring mechanism to enable a Media Server to report appropriate
statistics to an MRB. The Publish interface is used with both Query statistics to an MRB. The Publish interface is used with both the
and In-line modes of MRB operation. Query mode and In-line mode of MRB operation.
As already discussed in the Section 1, the MRB view of Media Server As already discussed in Section 1, the MRB view of Media Server
resource availability will in reality be approximate - i.e., partial resource availability will in reality be approximate -- i.e., partial
and imperfect. The MRB Publish interface does not provide an and imperfect. The MRB Publish interface does not provide an
exhaustive view of current Media Server resource consumption, the exhaustive view of current Media Server resource consumption; the
Media Server may in some cases provide a best-effort computed view of Media Server may in some cases provide a best-effort computed view of
resource consumption parameters conveyed in the Publish interface resource consumption parameters conveyed in the Publish interface
(e.g., DSP's with a fixed number of streams versus GPU's with CPU (e.g., Digital Signal Processors (DSPs) with a fixed number of
availability). Media Resource information may only be reported streams versus Graphics Processing Units (GPUs) with CPU
availability). Media resource information may only be reported
periodically over the Publish interface to an MRB. periodically over the Publish interface to an MRB.
It is also worth noting that, while the scope of the MRB is in It is also worth noting that while the scope of the MRB is in
providing interested Application Servers with the available providing interested Application Servers with the available
resources, the MRB also allows for the retrieval of information about resources, the MRB also allows for the retrieval of information about
consumed resources. While this is of course a relevant piece of consumed resources. While this is of course a relevant piece of
information (e.g., for monitoring purposes), such functionality information (e.g., for monitoring purposes), such functionality
inevitably raises security considerations, and implementations should inevitably raises security considerations, and implementations should
take this into account. See Section 12 for more details. take this into account. 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
([RFC6230]) as the basis for interaction between a Media Server and ([RFC6230]) as the basis for interaction between a Media Server and
an MRB. The Media Control Channel Framework uses an extension an MRB. The Media Control Channel Framework uses an extension
mechanism to allow specific usages which are known as control mechanism to allow specific usages that are known as Control
packages. Section 5.1.1 defines the control package that MUST be Packages. Section 5.1.1 defines the Control Package that MUST be
implemented by any Media Server wanting to interact with an MRB implemented by any Media Server wanting to interact with an MRB
entity. entity.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
This section fulfils the mandatory requirement for information that This section fulfills the requirement for information that must be
must be specified during the definition of a Control Framework specified during the definition of a Control Framework package, as
Package, as detailed in Section 8 of [RFC6230]. detailed in Section 8 of [RFC6230].
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
The MRB publish interface allows a media server to convey available The MRB Publish interface allows a Media Server to convey available
capabilities and resources to an MRB entity. capabilities and resources to an MRB entity.
This package defines XML elements in Section 5.1.2 and provides an This package defines XML elements in Section 5.1.2 and provides an
XML Schema in Section 10. XML schema in Section 10.
The XML elements in this package are split into requests, responses The XML elements in this package are split into requests, responses,
and event notifications. Requests are carried in CONTROL message and event notifications. Requests are carried in CONTROL message
bodies; <mrbrequest> element is defined as a package request. This bodies; the <mrbrequest> element is defined as a package request.
request can be used for creating new subscriptions and updating/ This 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 [RFC6230]) codes. Framework error response codes (see Section 7 of [RFC6230])
are used when the request or event notification is invalid; for are used when the request or event notification is invalid; for
example, a request has invalid XML (400), or is not understood (500). example, a request has invalid XML (400) or is not understood (500).
Package level responses are carried in framework 200 response or Package-level responses are carried in framework 200 response or
REPORT message bodies. This package's response codes are defined in REPORT message bodies. This package's response codes are defined in
Section 5.1.4. Section 5.1.4.
5.1.1.3. Common XML Support 5.1.1.3. Common XML Support
The Media Control Channel Framework [RFC6230] requires a Control The Media Control Channel Framework [RFC6230] requires a Control
Package definition to specify if the attributes for media dialog or Package 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.
5.1.1.4. CONTROL Message Body 5.1.1.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in A valid CONTROL message body MUST conform to the schema defined in
Section 10 and described in Section 5.1.2. XML messages appearing in Section 10 and described in Section 5.1.2. XML messages appearing in
CONTROL messages MUST contain either a <mrbrequest> or CONTROL messages MUST contain either an <mrbrequest> or
<mrbnotification> element. <mrbnotification> element.
5.1.1.5. REPORT Message Body 5.1.1.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 10 A valid REPORT message body MUST conform to the schema defined in
and described in Section 5.1.2. XML messages appearing in REPORT Section 10 and described in Section 5.1.2. XML messages appearing in
messages MUST contain a <mrbresponse> element. REPORT messages MUST contain an <mrbresponse> element.
5.1.1.6. Audit 5.1.1.6. Audit
The 'mrb-publish/1.0' Media Control Channel Framework package does The 'mrb-publish/1.0' Media Control Channel Framework package does
not require any additional auditing capability. not require any additional auditing capability.
5.1.2. Element Definitions 5.1.2. Element Definitions
This section defines the XML elements for the Publish interface Media This section defines the XML elements for the Publish interface Media
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 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.5. Publish interface notification element is detailed in Section 5.1.5.
MRB Publish interface response element is contained in Section 5.1.4. The MRB Publish interface response element is detailed in
Section 5.1.4.
The <mrbpublish> element has the following attributes: The <mrbpublish> element has the following attributes:
version: a token specifying the mrb-publish package version. The version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The <mrbpublish> element has the following child elements, and there The <mrbpublish> element has the following child elements, and there
MUST NOT be more than one such child element in any <mrbpublish> MUST NOT be more than one such child element in any <mrbpublish>
message: message:
skipping to change at page 17, line 24 skipping to change at page 15, line 40
<mrbresponse> for sending an MRB response. See Section 5.1.4. <mrbresponse> for sending an MRB response. See Section 5.1.4.
<mrbnotification> for sending an MRB notification. See <mrbnotification> for sending an MRB notification. See
Section 5.1.5. Section 5.1.5.
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 <mrbrequest> element has no defined attributes. The <mrbrequest> element has no defined attributes.
The <mrbrequest> element has the following child elements: The <mrbrequest> element has the following child element:
<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 (known as a subscription session). This element can be used updates (known as a subscription session). This element can be used
either to request a new subscription or to update an existing one either to request a new subscription or to update an existing one
(e.g., to change the frequency of the updates), and to remove ongoing (e.g., to change the frequency of the updates), and to remove ongoing
subscriptions as well (e.g., to stop an indefinite update). The MRB subscriptions as well (e.g., to stop an indefinite update). The MRB
will inform the Media Server how long it wishes to receive updates will inform the Media Server regarding how long it wishes to receive
for and the frequency that updates should be sent. Updates related updates and the frequency that updates should be sent. Updates
to the subscription are sent using the <mrbnotification> element. related to the subscription are sent using the <mrbnotification>
element.
The <subscription> element has the following attributes: The <subscription> element has the following attributes:
id: indicates a unique token representing the 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 contain a non- subscription command. The first subscription MUST contain a
zero number 'seqnumber', and following subscriptions MUST contain non-zero number 'seqnumber', and subsequent subscriptions MUST
a higher number that the previous 'seqnumber' value. If a contain a higher number than the previous 'seqnumber' value. If a
subsequent 'seqnumber' is not higher, a 405 response code is subsequent 'seqnumber' is not higher, a 405 response code is
generated as per section Section 5.1.4. The attribute MUST be generated as per Section 5.1.4. The attribute MUST be present.
present.
action: provides the operation that should be carried out on the action: Provides the operation that should be carried out on the
subscription: subscription:
* The value of 'create' instructs the Media Server to attempt to * The value of 'create' instructs the Media Server to attempt to
set-up a new subscription. set up a new subscription.
* The value of 'update' instructs the Media Server to attempt to * The value of 'update' instructs the Media Server to attempt to
update an existing subscription. update an existing subscription.
* The value of 'remove' instructs the Media Server to attempt to * The value of 'remove' instructs the Media Server to attempt to
remove an existing subscription and consequently stop any remove an existing subscription and consequently stop any
ongoing related notification. ongoing related notification.
The attribute MUST be present. The attribute MUST be present.
The <subscription> element has zero or more of the following child The <subscription> element has zero or more of the following child
elements: elements:
<expires>: Provides the amount of time in seconds that a <expires>: Provides the amount of time in seconds that a
subscription should be installed for notifications at the Media subscription should be installed for notifications at the Media
Server. Once the amount of time has passed, the subscription Server. Once the amount of time has passed, the subscription
expires and the MRB has to subscribe again in case it is still expires, and the MRB has to subscribe again if it is still
interested in receiving notifications from the Media Server. The interested in receiving notifications from the Media Server. The
element MAY be present. 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 Media Server. The MRB wishes to receive notifications from the Media Server. The
element MAY be present. element MAY 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 Media Server. The MRB wishes to receive notifications from the Media Server. The
element MAY be present. element MAY 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 Media Server MAY change the by the MRB only act as a suggestion: the Media Server MAY change the
proposed values if it considers the suggestions unacceptable (e.g., proposed values if it considers the suggestions unacceptable (e.g.,
if the MRB has requested a too high notification frequency). In such if the MRB has requested a notification frequency that is too high).
case, the request would not fail, but the updated, acceptable values In such a case, the request would not fail, but the updated,
would be reported in the <mrbresponse> accordingly. acceptable values would be reported in the <mrbresponse> accordingly.
5.1.4. <mrbresponse> 5.1.4. <mrbresponse>
Responses to requests are indicated by a <mrbresponse> element. Responses to requests are indicated by an <mrbresponse> element.
The <mrbresponse> 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 The <mrbresponse> element has a single child element:
elements:
<subscription> for providing details related to a subscription a <subscription> for providing details related to a subscription
Media Server requested (see below in this section). requested by a Media Server (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 |
| | | | | |
skipping to change at page 19, line 47 skipping to change at page 18, line 29
| | | | | |
| 404 | Subscription does not exist | | 404 | Subscription does not exist |
| | | | | |
| 405 | Wrong sequence number | | 405 | Wrong sequence number |
| | | | | |
| 406 | Subscription already exists | | 406 | Subscription already exists |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <mrbresponse> status codes Table 1: <mrbresponse> Status Codes
In case a new subscription request made by an MRB (action='create') If a new subscription request made by an MRB (action='create') has
has been accepted, the Media Server MUST reply with a <mrbresponse> been accepted, the Media Server MUST reply with an <mrbresponse> with
with status code 200. The same rule applies whenever a request to status code 200. The same rule applies whenever a request to update
update (action='update') or remove (action='remove') an existing (action='update') or remove (action='remove') an existing transaction
transaction can be fulfilled by the Media Server. can be fulfilled by the Media Server.
A subscription request, nevertheless, may fail for several reasons. A subscription request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used In such a case, the status codes defined in Table 1 must be used
instead. Specifically, if the Media Server fails to handle a request instead. Specifically, if the Media Server fails to handle a request
due to a syntax error in the request itself (e.g., incorrect XML, due to a syntax error in the request itself (e.g., incorrect XML,
violation of the schema constraints or invalid values in any of the violation of the schema constraints, or invalid values in any of the
attributes/elements) the Media Server MUST reply with a <mrbresponse> attributes/elements), the Media Server MUST reply with an
with status code 400. If a syntactically correct request fails <mrbresponse> with status code 400. If a syntactically correct
because the request also includes any attribute/element the Media request fails because the request also includes any attribute/element
Server doesn't understand, the Media Server MUST reply with a the Media Server doesn't understand, the Media Server MUST reply with
<mrbresponse> with status code 420. If a syntactically correct an <mrbresponse> with status code 420. If a syntactically correct
request fails because the MRB wants to create a new subscription, but request fails because the MRB wants to create a new subscription, but
the provided unique 'id' for the subscription already exists, the the provided unique 'id' for the subscription already exists, the
Media Server MUST reply with a <mrbresponse> with status code 406. Media Server MUST reply with an <mrbresponse> with status code 406.
If a syntactically correct request fails because the MRB wants to If a syntactically correct request fails because the MRB wants to
update/remove a subscription that doesn't exist, the Media Server update/remove a subscription that doesn't exist, the Media Server
MUST reply with a <mrbresponse> with status code 404. If the Media MUST reply with an <mrbresponse> with status code 404. If the Media
Server is unable to accept a request for any other reason (e.g., the Server is unable to accept a request for any other reason (e.g., the
MRB has no more resources to fulfil the request), the Media Server MRB has no more resources to fulfill the request), the Media Server
MUST reply with a <mrbresponse> with status code 401/402/403, MUST reply with an <mrbresponse> with status code 401/402/403,
depending on the action the MRB provided in its request: depending on the action 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;
A response to a subscription request that has a status of "200" A response to a subscription request that has a status code of 200
indicates that the request is successful. The response MAY also indicates that the request is successful. The response MAY also
contain a <subscription> child that describes the subscription. The contain a <subscription> child that describes the subscription. The
<subscription> child MAY contain 'expires', 'minfrequency' and <subscription> child MAY contain 'expires', 'minfrequency', and
'maxfrequency' values even if they were not contained in the request. 'maxfrequency' values even if they were not contained in the request.
The Media Server can choose to change the suggested 'expires', The Media Server can choose to change the suggested 'expires',
'minfrequency' and 'maxfrequency' values provided by the MRB in its 'minfrequency', and 'maxfrequency' values provided by the MRB in its
<mrbrequest>, if it considers them unacceptable (e.g., the requested <mrbrequest> if it considers them unacceptable (e.g., the requested
frequency range is too high). In such a case, the response MUST frequency range is too high). In such a case, the response MUST
contain a <subscription> element describing the subscription as the contain a <subscription> element describing the subscription as the
Media Server accepted it, and the Media Server MUST include in the Media Server accepted it, and the Media Server MUST include in the
<subscription> element all of those values that it modified relative <subscription> element all of those values that it modified relative
to the request, to inform the MRB about the change. to the request, to inform the MRB about the change.
5.1.5. <mrbnotification> 5.1.5. <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 to current status.
Media Server will inform the MRB of its current status as defined by The Media Server will inform the MRB of its current status as defined
the information in the <subscription> element. Updates are sent by the information in the <subscription> element. Updates are sent
using the <mrbnotification> element. using the <mrbnotification> element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute MUST be present. the <subscription> element. The attribute MUST be present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session ID to identify a specific
notification update. The first notification update MUST contain a notification update. The first notification update MUST contain a
non-zero number 'seqnumber', and following notification updates non-zero number 'seqnumber', and subsequent notification updates
MUST contain a higher number that the previous 'seqnumber' value. MUST contain a higher number than the previous 'seqnumber' value.
If a subsequent 'seqnumber' is not higher the situation should be If a subsequent 'seqnumber' is not higher, the situation should be
considered an error by the entity receiving the notification considered an error by the entity receiving the notification
update. It is implementation specific how the receiving entity update. How the receiving entity deals with this situation is
deals with this situation. The attribute MUST be present. implementation specific. The attribute MUST be present.
It's important to point out that the 'seqnumber' that appears in a It's important to point out that the 'seqnumber' that appears in an
<mrbnotification> is not related to the 'seqnumber' appearing in a <mrbnotification> is not related to the 'seqnumber' appearing in a
<mrbsubscription>. In fact, the latter is associated with <subscription>. In fact, the latter is associated with subscriptions
subscriptions and would increase at every command issued by the MRB, and would increase at every command issued by the MRB, while the
while the former is associated with the asynchronous notifications former is associated with the asynchronous notifications the Media
the Media Server would trigger according to the subscription, and as Server would trigger according to the subscription and as such would
such would increase at every notification message to enable the MRB increase at every notification message to enable the MRB to keep
keep track of them. track of them.
The following subsections provide details of the child elements that The following sub-sections provide details of the child elements that
are the content of the <mrbnotification> element. make up the contents of the <mrbnotification> element.
5.1.5.1. <media-server-id> 5.1.5.1. <media-server-id>
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system-wide
identifier for a Media Server instance. The element MUST be present, identifier for a Media Server instance. The element MUST be present
and MUST chosen such that it is extremely unlikely that two different and MUST be chosen such that it is extremely unlikely that two
media servers would present the same id to a given MRB. different Media Servers would present the same id to a given MRB.
5.1.5.2. <supported-packages> 5.1.5.2. <supported-packages>
The <supported-packages> element provides the list of Media Control The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element MAY be Channel packages supported by the Media Server. The element MAY be
present. present.
The <supported-packages> element has no attributes. The <supported-packages> element has no attributes.
The <supported-packages> element has zero or more of the following The <supported-packages> element has a single child element:
child elements:
<package>: The <package> element gives the name of a package <package>: Gives the name of a package supported by the Media
supported by the media server. The <package> element has a single Server. The <package> element has a single attribute, 'name',
attribute, 'name', which provides the name of the supported Media which provides the name of the supported Media Control Channel
Control Channel Framework package, compliant with the Section Framework package, compliant with Section 13.1.1 of [RFC6230].
13.1.1 of [RFC6230].
5.1.5.3. <active-rtp-sessions> 5.1.5.3. <active-rtp-sessions>
The <active-rtp-sessions> element provides information detailing the The <active-rtp-sessions> element provides information detailing the
current active Real-time Transport Protocol(RTP) sessions. The current active Real-time Transport Protocol (RTP) sessions. The
element MAY be present. element MAY be present.
The <active-rtp-sessions> element has no attributes. The <active-rtp-sessions> element has no attributes.
The <active-rtp-sessions> element has zero or more of the following The <active-rtp-sessions> element has a single child element:
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 media type attribute. The value of the attribute, 'name', is a media type
(which can include parameters per [RFC6381]). 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
has as content the decimal number of RTP sessions being decoded as content the decimal number of RTP sessions being decoded using
using the specified codec. The child element, <encoding>, has as the specified codec, and 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.5.4. <active-mixer-sessions> 5.1.5.4. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element MAY be present. the current active mixed RTP sessions. The element MAY be present.
The <active-mixer-sessions> element has no attributes. The <active-mixer-sessions> element has no attributes.
The <active-mixer-sessions> element has zero or more of the following The <active-mixer-sessions> element has a single child element:
child elements:
<active-mix>: Describes a mixed active RTP session. The <active- <active-mix>: Describes a mixed active RTP session. The
mix> element has one attribute. The value of the attribute <active-mix> element has one attribute. The value of the
'conferenceid' is the name of the mix. The <active-mix> element attribute, 'conferenceid', is the name of the mix. The
has one child element. The child element, <rtp-codec>, contains <active-mix> element has one child element. The child element,
the same information relating to RTP sessions as defined in <rtp-codec>, contains the same information relating to RTP
Section 5.1.5.3. The element MAY be present. sessions as that defined in Section 5.1.5.3. The element MAY be
present.
5.1.5.5. <non-active-rtp-sessions> 5.1.5.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, that is, how many more the currently available inactive RTP sessions, that is, how many more
RTP streams this Media Server can support. The element MAY be RTP streams this Media Server can support. The element MAY be
present. present.
The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has no attributes.
The <non-active-rtp-sessions> element has zero or more of the The <non-active-rtp-sessions> element has a single child element:
following child elements:
<rtp-codec>: Describes a supported codec and the number of non- <rtp-codec>: Describes a supported codec and the number of
active sessions for that codec. The <rtp-codec> element has one non-active sessions for that codec. The <rtp-codec> element has
attribute. The value of the attribute 'name' is a media type one attribute. The value of the attribute, 'name', is a media
(which can include parameters per [RFC6381]). The <rtp-codec> type (which can include parameters per [RFC6381]). The
element has two child elements. The child element, <decoding>, <rtp-codec> element has two child elements. The child element
has as content the decimal number of RTP sessions available for <decoding> has as content the decimal number of RTP sessions
decoding using the specified codec. The child element, available for decoding using the specified codec, and the child
<encoding>, has as content the decimal number of RTP sessions element <encoding> has as content the decimal number of RTP
available for encoding using the specified codec. sessions available for encoding using the specified codec.
5.1.5.6. <non-active-mixer-sessions> 5.1.5.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, that is, how many detailing the current inactive mixed RTP sessions, that is, how many
more mixing sessions this Media Server can support. The element MAY more mixing sessions this Media Server can support. The element MAY
be present. be present.
The <non-active-mixer-sessions> element has no attributes. The <non-active-mixer-sessions> element has no attributes.
The <non-active-mixer-sessions> element has zero of more of the The <non-active-mixer-sessions> element has a single child element:
following child element:
<non-active-mix>: Describes available mixed RTP sessions. The <non-active-mix>: Describes available mixed RTP sessions. The
<non-active-mix> element has one attribute. The value of the <non-active-mix> element has one attribute. The value of the
attribute 'available' is the number of mixes that could be used attribute, 'available', is the number of mixes that could be used
using that profile. The <non-active-mix> element has one child using that profile. The <non-active-mix> element has one child
element. The child element, <rtp-codec>, contains the same element. The child element, <rtp-codec>, contains the same
information relating to RTP sessions as defined in information relating to RTP sessions as that defined in
Section 5.1.5.5. The element MAY be present. Section 5.1.5.5. The element MAY be present.
5.1.5.7. <media-server-status> 5.1.5.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: Indicates that the Media Server is available for service.
deactivated: Indicating that the Media Server has been withdrawn deactivated: Indicates that the Media Server has been withdrawn from
from service, and as such requests should not be sent to it before service, and as such requests should not be sent to it before it
it becomes 'active' again. becomes 'active' again.
unavailable: Indicating that the Media Server continues to process unavailable: Indicates that the Media Server continues to process
past requests but cannot accept new requests, and as such should past requests but cannot accept new requests, and as such should
not be contacted before it becomes 'active' again. not be contacted before it becomes 'active' again.
The <media-server-status> element has no attributes. The <media-server-status> element has no attributes.
The <media-server-status> element has no child elements. The <media-server-status> element has no child elements.
5.1.5.8. <supported-codecs> 5.1.5.8. <supported-codecs>
The <supported-codecs> element provides information detailing the The <supported-codecs> element provides information detailing the
current codecs supported by a media server and associated actions. current codecs supported by a Media Server and associated actions.
The element MAY be present. The element MAY be present.
The <supported-codecs> element has no attributes. The <supported-codecs> element has no attributes.
The <supported-codecs> element has zero or more of the following The <supported-codecs> element has a single child element:
child element:
<supported-codec>: has a single attribute, 'name', which provides <supported-codec>: Has a single attribute, 'name', which provides
the name of the codec about which this element provides the name of the codec about which this element provides
information. A valid value is a media type which, depending on information. A valid value is a media type that, depending on its
its definition, can include additional parameters (e.g., definition, can include additional parameters (e.g., [RFC6381]).
[RFC6381]). The <supported-codec> element then has a further The <supported-codec> element then has a further child element,
child element, <supported-codec-package>. The <supported-codec- <supported-codec-package>. The <supported-codec-package> element
package> element has a single attribute, 'name', which provides has a single attribute, 'name', which provides the name of the
the name of the Media Control Channel Framework package, compliant Media Control Channel Framework package, compliant with
with the Section 13.1.1 of [RFC6230], for which the codec support Section 13.1.1 of [RFC6230], for which the codec support applies.
applies. The <supported-codec-package> element has zero or more The <supported-codec-package> element has zero or more
<supported-action> children, each one of which describes an action <supported-action> children, each one of which describes an action
that a Media Server can apply to this codec: that a Media Server can apply to this codec:
* 'decoding', meaning a decoder for this codec is available; * 'decoding', meaning a decoder for this codec is available;
* 'encoding', meaning an encoder for this codec is available; * 'encoding', meaning an encoder for this codec is available;
* 'passthrough', meaning the Media Server is able to pass a * 'passthrough', meaning the Media Server is able to pass a
stream encoded using that codec through without re-encoding. stream encoded using that codec through, without re-encoding.
5.1.5.9. <application-data> 5.1.5.9. <application-data>
The <application-data> element provides an arbitrary string of The <application-data> element provides an arbitrary string of
characters as application level data. This data is meant to only characters as application-level data. This data is meant to only
have meaning at the application level logic and as such is not have meaning at the application-level logic and as such is not
otherwise restricted by this specification. The set of allowed otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return, characters is the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see line feed, and the legal characters of Unicode and ISO/IEC 10646
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. [ISO.10646.2012] (see also Section 2.2 of
<http://www.w3.org/TR/xml/>)). The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.1.5.10. <file-formats> 5.1.5.10. <file-formats>
The <file-formats> element provides a list of file formats supported The <file-formats> element provides a list of file formats supported
for the purpose of playing media. The element MAY be present. for the purpose of playing media. The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has zero of more the following child The <file-formats> element has zero of more the 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
media type which, depending on its definition, can include media type that, depending on its definition, can include
additional parameters (e.g., [RFC6381]). 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,
package>. The <supported-file-package> element provides the name <supported-file-package>. The <supported-file-package> element
of the Media Control Channel Framework package, compliant with the provides the name of the Media Control Channel Framework package,
Section 13.1.1 of [RFC6230], for which the file format support compliant with Section 13.1.1 of [RFC6230], for which the file
applies. format support applies.
5.1.5.11. <max-prepared-duration> 5.1.5.11. <max-prepared-duration>
The <max-prepared-duration> element provides the maximum amount of The <max-prepared-duration> element provides the maximum amount of
time a media dialog will be kept in the prepared state before timing time a media dialog will be kept in the prepared state before timing
out before it is executed (see section 4.4.2.2.6 of RFC out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231]. The element MAY be
6231[RFC6231]. The element MAY be present. present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has zero or more of the following The <max-prepared-duration> element has a single child element:
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 Section 13.1.1 of [RFC6230], for which the time compliant with Section 13.1.1 of [RFC6230], for which the time
period applies. period applies.
5.1.5.12. <dtmf-support> 5.1.5.12. <dtmf-support>
The <dtmf-support> element specifies 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. Dual-Tone Multi-Frequency (DTMF) tones and to generate them. The
element MAY be present.
The <dtmf-support> element has no attributes. The <dtmf-support> element has no attributes.
The <dtmf-support> element has zero of more of the following child The <dtmf-support> element has zero of more of the 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 a case provides the type of DTMF being used, and it can only be a case-
insensitive string containing either 'RFC4733' [RFC4733] or insensitive string containing either 'RFC4733' [RFC4733] or
'Media' (detecting tones as signals from the audio stream). The 'Media' (detecting tones as signals from the audio stream). 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 Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the DTMF type applies. 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 a case provides the type of DTMF being used, and it can only be a case-
insensitive string containing either 'RFC4733' [RFC4733] or insensitive string containing either 'RFC4733' [RFC4733] or
'Media' (generating tones as signals in the audio stream). The 'Media' (generating tones as signals in the audio stream). 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 Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the DTMF type applies. which the DTMF type applies.
<passthrough>: Indicates the support for passing DTMF through <passthrough>: Indicates the support for passing DTMF through
without re-encoding. The <passthrough> element has no attributes. without re-encoding. The <passthrough> element has no attributes.
The <passthrough> element then has a further child element, <dtmf- The <passthrough> element then has a further child element,
type>. The <dtmf-type> element has two attributes, 'name' and <dtmf-type>. The <dtmf-type> element has two attributes: 'name'
'package. The 'name' attribute provides the type of DTMF being and 'package'. The 'name' attribute provides the type of DTMF
used, and it can only be a case insensitive string containing being used, and it can only be a case-insensitive string
either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as
through the audio stream). The 'package' attribute provides the signals through the audio stream). The 'package' attribute
name of the Media Control Channel Framework package, compliant provides the name of the Media Control Channel Framework package,
with the Section 13.1.1 of [RFC6230], for which the DTMF type compliant with Section 13.1.1 of [RFC6230], for which the DTMF
applies. type applies.
5.1.5.13. <mixing-modes> 5.1.5.13. <mixing-modes>
The <mixing-modes> element provides information about the support for The <mixing-modes> element provides information about the support for
audio and video mixing of a Media Server, specifically a list of audio and video mixing of a Media Server, specifically a list of
supported algorithms to mix audio and a list of supported video supported algorithms to mix audio and a list of supported video
presentation layouts. The element MAY be present. presentation layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The <mixing-modes> element has zero or more of the following child The <mixing-modes> element has zero or more of the 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. Valid values for the <audio-mixing-mode> element are algorithm. Valid values for the <audio-mixing-mode> element are
algorithm names, e.g., 'nbest' and 'controller' as defined in algorithm names, e.g., 'nbest' and 'controller' as defined in
[RFC6505]. The element has a single attribute, 'package'. The [RFC6505]. The element has a single attribute, 'package'. The
attribute 'package' provides the name of the Media Control Channel attribute 'package' provides the name of the Media Control Channel
Framework package, compliant with the Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the algorithm support applies. which the algorithm support 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 related to video mixing.
mixing. The <video-mixing-modes> element has two attributes, The <video-mixing-modes> element has two attributes: 'vas' and
'vas' and 'activespeakermix'. The 'vas' attribute is of type 'activespeakermix'. The 'vas' attribute is of type boolean with a
boolean with a value of 'true' indicating the Media Server value of 'true' indicating that the Media Server supports
supports automatic Voice Activated Switching. The automatic Voice Activated Switching. The 'activespeakermix' is of
'activespeakermix' is of type boolean with a value of 'true' type boolean with a value of 'true' indicating that the Media
indicating that the Media Server is able to prepare an additional Server is able to prepare an additional video stream for the
video stream for the loudest speaker participant without its loudest speaker participant without its contribution. The
contribution. The <video-mixing-modes> element has one child <video-mixing-modes> element has one child element. The child
element. The child element, <video-mixing-mode>, contains the element, <video-mixing-mode>, contains the name of a specific
name of a specific video presentation layout. The name may refer video presentation layout. The name may refer to one of the
to one of predefined video layouts defined in the XCON conference predefined video layouts defined in the XCON conference
information data model, or to non-XCON layouts as well, as long as information data model [RFC6501], or to non-XCON layouts as well,
they are properly prefixed according to the schema they belong to. as long as they are properly prefixed according to the schema they
The <video-mixing-mode> element has a single attribute, 'package'. belong to. The <video-mixing-mode> element has a single
The attribute 'package' provides the name of the Media Control attribute, 'package'. The attribute 'package' provides the name
Channel Framework package, compliant with the Section 13.1.1 of of the Media Control Channel Framework package, compliant with
[RFC6230], for which the algorithm support applies. Section 13.1.1 of [RFC6230], for which the algorithm support
applies.
5.1.5.14. <supported-tones> 5.1.5.14. <supported-tones>
The <supported-tones> element provides information about which tones The <supported-tones> element provides information about which tones
a media server is able to play and recognize. In particular, the a Media Server is able to play and recognize. In particular, the
support is reported referring to both country codes support (ISO support is reported by referring to both support for country codes
3166-1 [ISO.3166-1]) and supported functionality (ITU-T (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T
Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present. Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
The <supported-tones> element has no attributes. The <supported-tones> element has no attributes.
The <supported-tones> element has zero or more of the following child The <supported-tones> element has zero or more of the following child
elements: elements:
<supported-country-codes>: Describes the supported country codes <supported-country-codes>: Describes the supported country codes
with respect to tones. The <supported-country-codes> element has with respect to tones. The <supported-country-codes> element has
no attributes. The <supported-country-codes> has one child no attributes. The <supported-country-codes> element has one
element. The child element, <country-code>, reports support for a child element. The child element, <country-code>, reports support
specific country code, compliant with the ISO 3166-1 [ISO.3166-1] for a specific country code, compliant with the ISO 3166-1
specification. The <country-code> element has a single attribute, [ISO.3166-1] specification. The <country-code> element has a
'package'. The attribute 'package' provides the name of the Media single attribute, 'package'. The attribute 'package' provides the
Control Channel Framework package, compliant with the Section name of the Media Control Channel Framework package, compliant
13.1.1 of [RFC6230], in which the tones from the specified country with Section 13.1.1 of [RFC6230], in which the tones from the
code are supported. 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> element has one child
The child element, <h248-code>, reports support for a specific element. The child element, <h248-code>, reports support for a
H.248 code, compliant with the ITU-T Recommendation Q.1950 specific H.248 code, compliant with the ITU-T Recommendation
[ITU-T.Q.1950] specification. The codes can be either specific Q.1950 [ITU-T.Q.1950] specification. The codes can be either
(e.g., cg/dt to only report the Dial Tone from the Call Progress specific (e.g., cg/dt to only report the Dial Tone from the Call
Tones package) or generic (e.g., cg/* to report all the tones from Progress Tones package) or generic (e.g., cg/* to report all the
the Call Progress Tones package) using wild-cards. The <h248- tones from the Call Progress Tones package), using wildcards. The
code> element has a single attribute, 'package'. The attribute <h248-code> element has a single attribute, 'package'. The
'package' provides the name of the Media Control Channel Framework attribute 'package' provides the name of the Media Control Channel
package, compliant with the Section 13.1.1 of [RFC6230], in which Framework package, compliant with Section 13.1.1 of [RFC6230], in
the specified codes are supported. which the specified codes are supported.
5.1.5.15. <file-transfer-modes> 5.1.5.15. <file-transfer-modes>
The <file-transfer-modes> element allows the Media Server to specify The <file-transfer-modes> element allows the Media Server to specify
which scheme names are supported for transferring files to a Media which scheme names are supported for transferring files to a Media
Server for each Media Control Channel Framework package type. For Server for each Media Control Channel Framework package type, for
example, whether the Media Server supports fetching resources via example, whether the Media Server supports fetching resources via
HTTP, HTTPS, NFS etc protocols. The element MAY be present. HTTP, HTTPS, NFS, etc. The element MAY be present.
The <file-transfer-modes> element has no attributes. The <file-transfer-modes> element has no attributes.
The <file-transfer-modes> element has zero or more of the following The <file-transfer-modes> element has a single child element:
child element:
<file-transfer-mode>: has two attributes, 'name' and 'package'. <file-transfer-mode>: Has two attributes: 'name' and 'package'. The
The 'name' attribute provides the scheme name of the protocol that 'name' attribute provides the scheme name of the protocol that can
can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.): be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.); the
the value of the attribute is case insensitive. The 'package' value of the attribute is case insensitive. 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 scheme name applies. registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.
It is important to point out that this element provides no It is important to point out that this element provides no
information about whether or not the Media Server supports any information about whether or not the Media Server supports any flavor
flavour of live streaming: for instance, a value of "HTTP" for the of live streaming: for instance, a value of "HTTP" for the IVR
IVR (Interactive Voice Response) Package would only mean the 'http' (Interactive Voice Response) Package would only mean the 'http'
scheme makes sense to the Media Server within the context of that scheme makes sense to the Media Server within the context of that
package. Whether or not the Media Server can make use of HTTP to package. Whether or not the Media Server can make use of HTTP to
only fetch resources, or also to attach an HTTP live stream to a only fetch resources, or also to attach an HTTP live stream to a
call, is to be considered implementation specific to the Media Server call, is to be considered implementation specific to the Media Server
and irrelevant to the Application Server and/or MRB. Besides, the and irrelevant to the Application Server and/or MRB. Besides, the
Media Server supporting a scheme does not imply it also supports the Media Server supporting a scheme does not imply that it also supports
related secure versions: for instance, if the Media Server supports the related secure versions: for instance, if the Media Server
both "HTTP" and "HTTPS", both the schemes will appear in the element. supports both HTTP and HTTPS, both the schemes will appear in the
A lack of the "HTTPS" value would need to be interpreted as a lack of element. A lack of the "HTTPS" value would need to be interpreted as
support for the 'https' scheme. a lack of support for the 'https' scheme.
5.1.5.16. <asr-tts-support> 5.1.5.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 is 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.2002]
codes) for what regards both ASR and TTS. The element MAY be codes) regarding both ASR and TTS. The element MAY be present.
present.
The <asr-tts-support> element has no attributes. The <asr-tts-support> element has no attributes.
The <asr-tts-support> element has zero or more of the following child The <asr-tts-support> element has zero or more of the following child
elements: elements:
<asr-support>: Describes the available languages for ASR. The <asr-support>: Describes the available languages for ASR. The
<asr-support> element has no attributes. The <asr-support> has <asr-support> element has no attributes. The <asr-support>
one child element. The child element, <language>, reports the element has one child element. The child element, <language>,
Media Server supports ASR for a specific language. The <language> reports that the Media Server supports ASR for a specific
element has a single attribute, 'xml:lang'. The attribute 'xml: language. The <language> element has a single attribute,
lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
language. [ISO.639.2002] code of the supported language.
<tts-support>: Describes the available languages for TTS. The <tts-support>: Describes the available languages for TTS. The
<tts-support> element has no attributes. The <tts-support> has <tts-support> element has no attributes. The <tts-support>
one child element. The child element, <language>, reports the element has one child element. The child element, <language>,
Media Server supports tts for a specific language. The <language> reports that the Media Server supports TTS for a specific
element has a single attribute, 'xml:lang'. The attribute 'xml: language. The <language> element has a single attribute,
lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
language. [ISO.639.2002] code of the supported language.
5.1.5.17. <vxml-support> 5.1.5.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 (VXML) and, if it does, through which protocols the support
through (e.g., via the control framework, RFC4240 [RFC4240], or is exposed (e.g., via the control framework, RFC 4240 [RFC4240], or
RFC5552 [RFC5552]). The element MAY be present. RFC 5552 [RFC5552]). The element MAY be present.
The <vxml-support> element has no attributes. The <vxml-support> element has no attributes.
The <vxml-support> element has zero or more of the following child The <vxml-support> element has a single 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 Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the VXML support applies. The 'support' attribute which the VXML support applies. The 'support' attribute provides
provides the type of VXML support provided by the Media Server the type of VXML support provided by the Media Server (e.g.,
(e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package
[RFC6231]), and valid values are case insensitive RFC references [RFC6231]), and valid values are case-insensitive RFC references
(e.g., "rfc6231" to specify the Media Server supports VoiceXML as (e.g., "rfc6231" to specify that the Media Server supports
provided by the IVR Package [RFC6231]). VoiceXML as provided by the IVR Package [RFC6231]).
The presence of at least one <vxml-mode> child element would indicate The presence of at least one <vxml-mode> child element would indicate
that the Media Server does support VXML as specified by the child that the Media Server does support VXML as specified by the child
element itself. An empty <vxml> element would otherwise indicate the element itself. An empty <vxml> element would otherwise indicate
Media Server does not support VXML at all. that the Media Server does not support VXML at all.
5.1.5.18. <media-server-location> 5.1.5.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. More precisely, this section is entirely optional, MAY be present. More precisely, this section is entirely optional,
and it's implementation specific to fill it with just the details and it's implementation specific to fill it with just the details
each implementor deems necessary for any optimization that may be each implementer deems necessary for any optimization that may be
needed. needed.
The <media-server-location> element has no attributes. The <media-server-location> element has no attributes.
The <media-server-location> element has zero or more of the following The <media-server-location> element has a single child element:
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 Section 4 of RFC 5139
[RFC5139]. [RFC5139].
5.1.5.19. <label> 5.1.5.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. The element MAY be present. classification. The element MAY be present.
The <label> element has no attributes. The <label> element has no attributes.
The <label> element has no child elements. The <label> element has no child elements.
5.1.5.20. <media-server-address> 5.1.5.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 where it can be reached (e.g., the URI Application direct SIP URI where it can be reached (e.g., the URI that the
Server would call to in order to set-up a Control Channel and relay Application Server would call in order to set up a Control Channel
SIP media dialogs). The element MAY be present. and relay SIP media dialogs). The element MAY be present.
The <media-server-address> element has no attributes. The <media-server-address> element has no attributes.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.5.21. <encryption> 5.1.5.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]. The element encrypting RTP media streams using RFC 3711 [RFC3711]. The element
MAY be present. If the element is present, then the Media Server MAY be present. If the element is present, then the Media Server
supports DTLS-SRTP [RFC5763]. supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP)
extension for Datagram Transport Layer Security (DTLS)) [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has no child elements. The <encryption> element has no child elements.
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. This 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) the In-line
MRB Mode (IAMM) that uses the Session Initiation Protocol (SIP) and Aware MRB Mode (IAMM), which uses the Session Initiation Protocol
2) Query mode that uses the Hypertext Transfer Protocol (HTTP) (SIP) and 2) the Query mode, which uses the Hypertext Transfer
[RFC2616]. The MRB Consumer interface does not include In-Line Protocol (HTTP) [RFC2616]. The MRB Consumer interface does not
Unaware Mode (IUMM) which is further explained in Section 5.3. The include the In-line Unaware Mode (IUMM), which is further explained
following subsections provide guidance on using the Consumer in Section 5.3. The following sub-sections provide guidance on
interface, which is represented by the 'application/mrb-consumer+xml using the Consumer interface, which is represented by the
media type in Section 11, with HTTP and SIP. 'application/mrb-consumer+xml' media type 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 an HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the and encourages the use of common tools that are widely available in
industry today. The following information explains the primary the 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, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport
for a query for media resource and the appropriate response. for a query for a media 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 media type contained in the HTTP/HTTPS request/ POST request. The media 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, such as '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
a <mrbconsumer> root element with only one child an <mrbconsumer> root element with only one child
<mediaResourceRequest> element as defined in Section 11. <mediaResourceRequest> element as defined in Section 11.
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 media type contained in the HTTP/HTTPS request/ POST request. The media 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, such as '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
a <mrbconsumer> root element with only one child an <mrbconsumer> root element with only one child
<mediaResourceResponse> element as defined in Section 11. <mediaResourceResponse> element as defined in Section 11.
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 an
it will send a new request with an <action> element with value MRB, it will send a new request with an <action> element with value
'remove' as described in Section 5.2.3 about the use of the Consumer 'remove', as described in Section 5.2.3 ("Consumer Interface Lease
interface lease mechanism. 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 toolkit for MRB deployment that
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, by making use of SIP [RFC3261] as transport for a request for MRB, by making use of SIP [RFC3261] as transport for a request for
media resources and the appropriate response when used with IAMM of media resources, and the appropriate response when using IAMM as the
operation (as discussed in Section 5.2.2.1). mode of operation (as discussed in Section 5.2.2.1).
Use of IAMM, besides having the MRB select appropriate media The use of IAMM, besides having the MRB select appropriate media
resources 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 one of the media servers (Section 5.2.2.1) or a media Server and one of the Media Servers (Section 5.2.2.1) or a media
dialog session between an application server and one of the media dialog session between an Application Server and one of the Media
servers (Section 5.2.2.2). Note that in either case the SIP URIs of Servers (Section 5.2.2.2). Note that in either case the SIP URIs of
the selected media servers are made known to the requesting the selected Media Servers are made known to the requesting
application server in the SIP 200 OK response by means of one or more Application Server in the SIP 200 OK response by means of one or more
<media-server-address> child elements in the <response-session-info> <media-server-address> child elements in the <response-session-info>
element (Section 5.2.6). 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, is carried in a SIP <mediaResourceRequest> element from Section 11, is carried in a SIP
INVITE request. The INVITE request will be constructed as it would INVITE request. The INVITE request will be constructed as it would
have been to connect to a Media Server, as defined by the Media have been to connect to a Media Server, as defined by the Media
Control Channel Framework [RFC6230]. It should be noted that this Control Channel Framework [RFC6230]. It should be noted that this
specification does not exclude the use of an offer-less INVITE as specification does not exclude the use of an offerless INVITE as
defined in RFC3261 [RFC3261]. Using offer-less INVITE messages to an defined in RFC 3261 [RFC3261]. Using offerless INVITE messages to an
MRB can potentially cause confusion when applying resource selection MRB can potentially cause confusion when applying resource selection
algorithms and an MRB, like any other SIP device, can choose to algorithms, and an MRB, like any other SIP device, can choose to
reject with a 4xx response. For an offer-less INVITE to be treated reject with a 4xx response. For an offerless INVITE to be treated
appropriately, additional contextual information would need to be appropriately, additional contextual information would need to be
provided with the request which is out of the scope for this provided with the request; this is out of scope for this document.
document. The following additional steps MUST be followed when using The following additional steps MUST be followed when using the
the Consumer interface: Consumer interface:
o The Consumer Client will Include a payload in the SIP INVITE o The Consumer client will include a payload in the SIP INVITE
request of type 'multipart/mixed' [RFC2046]. One of the parts to request of type 'multipart/mixed' [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 [RFC6230]. Media Control Channel 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. The body part MUST be an XML document defined in Section 11. The body part MUST be an XML document
without prolog and whose root element is <mediaResourceRequest>. 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 [RFC6230]. 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 fulfil 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 (or media servers, if more than one is deemed to be Media Server (or Media Servers, if more than one is deemed to be
needed) should be selected to service the request. needed) should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it as o Extract the 'application/sdp' part from the payload and use it as
the body of a new SIP INVITE request for connecting the client to the body of a new SIP INVITE request for connecting the client to
one of the selected media servers, as defined in the Media Channel one of the selected Media Servers, as defined in the Media Channel
Control Framework [RFC6230]. The policy the MRB follows to pick a Control Framework [RFC6230]. The policy the MRB follows to pick a
specific Media Server out of the Media Servers it selects is specific Media Server out of the Media Servers it selects is
implementation specific, and out of scope to this document. It is implementation specific and out of scope for this document. It is
important to configure the SIP elements between the MRB and the important to configure the SIP elements between the MRB and the
Media Server in such a way that that the INVITE will not fork. In Media Server in such a way that the INVITE will not fork. In the
case of a failure in reaching the chosen Media Server, the MRB case of a failure in reaching the chosen Media Server, the MRB
SHOULD proceed to the next one, if available. SHOULD proceed to the next one, if available.
If none of the available Media Server can be reached, the MRB MUST If none of the available Media Servers can be reached, the MRB MUST
reply with a SIP 503 error message including a Retry-After header reply with a SIP 503 error message that includes a Retry-After header
with a non-zero value. The Application Server MUST NOT attempt to with a non-zero value. The Application Server MUST NOT attempt to
setup a new session before the time the MRB asked it to wait has set up a new session before the time that the MRB asked it to wait
passed. has passed.
In case at least one Media Server is reachable, the MRB acts as a If at least one Media Server is reachable, the MRB acts as a Back-to-
Back-to-Back UA (B2BUA) that extracts the 'application/ Back User Agent (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then mrb-consumer+xml' information from the SIP INVITE request and then
sends a corresponding SIP INVITE request to the Media Server it has sends a corresponding SIP INVITE request to the Media Server it has
selected, to negotiate a control channel as defined in the Media selected, to negotiate a Control Channel as defined in the Media
Channel Control Framework [RFC6230]. Channel Control Framework [RFC6230].
In case of a failure in negotiating the control channel with the In the case of a failure in negotiating the Control Channel with the
Media Server, the MRB SHOULD proceed to the next one, if available, Media Server, the MRB SHOULD proceed to the next one, if available,
as explained above. If none of the available Media Servers can be as explained above. If none of the available Media Servers can be
reached, or the negotiation of the control channel with all of them reached, or the negotiations of the Control Channel with all of them
fail, the MRB MUST reply with a SIP 503 error message including a fail, the MRB MUST reply with a SIP 503 error message that includes a
Retry-After header with a non-zero value. The Application Server Retry-After header with a non-zero value. The Application Server
MUST NOT attempt to setup a new session before the time the MRB asked MUST NOT attempt to set up a new session before the time that the MRB
it to wait has expired. asked it to wait has expired.
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 generated by an MRB to a request, as The media resource response generated by an MRB to a request, as
defined by the <mediaResourceResponse> element from Section 11, MUST defined by the <mediaResourceResponse> element from Section 11, MUST
be carried in the payload of a SIP 200 OK response to the original be carried in the payload of a SIP 200 OK response to the original
SIP INVITE request. The SIP 200 OK response will be constructed as SIP INVITE request. The SIP 200 OK response will be constructed as
it would have been to connect from a media server, as defined by the it would have been to connect from a Media Server, as defined by the
Media Control Channel Framework [RFC6230]. The following additional Media Control Channel Framework [RFC6230]. The following additional
steps MUST be followed when using the Consumer interface: steps MUST be followed when using the Consumer interface:
o Include a payload in the SIP 200 response of type 'multipart/ o Include a payload in the SIP 200 response of type 'multipart/
mixed' as per RFC 2046 [RFC2046]. One of the parts to be included mixed' as per RFC 2046 [RFC2046]. One of the parts to be included
in the 'multipart/mixed' payload MUST be the 'application/sdp' in the 'multipart/mixed' payload MUST be the 'application/sdp'
format which is constructed as specified in the Media Control format, which is constructed as specified in the Media Control
Channel Framework [RFC6230] and based on the incoming response Channel Framework [RFC6230] and based on the incoming response
from the selected Media Resource. from the selected media resource.
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 200 response will then be dispatched from the MRB. o The SIP 200 response will then be dispatched from the MRB.
o A SIP ACK to the 200 response will then be sent back to the MRB. o A SIP ACK to the 200 response will then be sent back to the MRB.
Considering that the use of SIP as a transport for Consumer Considering that the use of SIP as a transport for Consumer
transactions may result in failure, the IAMM relies on a successful transactions may result in failure, the IAMM relies on a successful
INVITE transaction to address the previously discussed sequence INVITE transaction to address the previously discussed sequence
(using 'seq' XML element) increment mechanism. This means that, if (using the 'seq' XML element) increment mechanism. This means that
the INVITE is unsuccessful for any reason, the Application Server if the INVITE is unsuccessful for any reason, the Application Server
MUST use the same 'seq' value as previously used for the next MUST use the same 'seq' value as previously used for the next
Consumer request it may want to send to the MRB for the same session. Consumer request that it may want to send to the MRB for the same
session.
An MRB implementation may be programmed to conclude that the An MRB implementation may be programmed to conclude that the
requested resources are no longer needed when it receives a SIP BYE requested resources are no longer needed when it receives a SIP BYE
from the Application Server or Media Server that concludes the SIP from the Application Server or Media Server that concludes the SIP
dialog that initiated the request, or when the lease(Section 5.2.3) dialog that initiated the request, or when the lease (Section 5.2.3)
interval expires. interval expires.
5.2.2.2. IAMM and Setting up a Media Dialog 5.2.2.2. IAMM and Setting Up a Media Dialog
This scenario is identical to the description in the previous section This scenario is identical to the description in the previous section
for setting up a Control Framework control channel with the exception for setting up a Control Framework Control Channel, with the
that the application/sdp payload conveys content appropriate for exception that the application/sdp payload conveys content
setting up the media dialog to the media resource, as per RFC 3261 appropriate for setting up the media dialog to the media resource, as
[RFC3261], instead of application/sdp payload for setting up a per RFC 3261 [RFC3261], instead of setting up a Control Channel.
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 Sections 5.2 and 11 allows a client
client to request an appropriate media resource based on information 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 an HTTP POST or SIP INVITE message).
In the case of success, the response that is returned to the client In the case of success, the response that is returned to the client
MUST contain a <response-session-info> element in either the SIP 200 MUST contain a <response-session-info> element in either the SIP 200
or HTTP 200 response. The success response contains the description or HTTP 200 response. The success response contains the description
of certain resources that have been reserved to a specific Consumer of certain resources that have been reserved to a specific Consumer
client in a (new or revised) "resource session", which is identified client in a (new or revised) "resource session", which is identified
in the <response-session-info>. The resource session is a "lease", in the <response-session-info>. The resource session is a "lease",
in that the reservation is scheduled to expire at a particular time in that the reservation is scheduled to expire at a particular time
in the future, releasing the resources to be assigned for other uses. in the future, releasing the resources to be assigned for other uses.
The lease may be extended or terminated earlier by future Consumer The lease may be extended or terminated earlier by future Consumer
client requests that identify and reference a specific resource client requests that identify and reference a specific resource
session. session.
Before delving into the details of such lease mechanism, it is worth Before delving into the details of such a lease mechanism, it is
clarifying its role within the context of the Consumer interface. As worth clarifying its role within the context of the Consumer
explained in Section 5.1, the knowledge the MRB has of the resources interface. As explained in Section 5.1, the knowledge the MRB has of
of all the Media Servers it is provisioned to manage is non real- the resources of all the Media Servers it is provisioned to manage is
time. How an MRB actually manages such resources is implementation not real-time. How an MRB actually manages such resources is
specific - for example an implementation may choose to have the MRB implementation specific -- for example, an implementation may choose
keeping track and state of the allocated resources, or simply rely on to have the MRB keeping track and state of the allocated resources,
the Media Servers themselves to provide the information using the or simply rely on the Media Servers themselves to provide the
Publish interface. Further information may be also be inferred by information using the Publish interface. Further information may
the signalling, in the case where an MRB is in the path of media also be inferred by the signaling, in the case where an MRB is in the
dialogs. path of media dialogs.
The <mediaResourceResponse> element returned from the MRB contains a The <mediaResourceResponse> element returned from the MRB contains a
<response-session-info> element if the request is successful. The <response-session-info> element if the request is successful. The
<response-session-info> element has zero or more of the following <response-session-info> element has zero or more of the following
child elements which provide the appropriate resource session child elements, which provide the appropriate resource session
information: 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 the <session-id> paragraph
section when constructing a subsequent request). later in this section, where constructing a subsequent request is
discussed).
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 it in the request (see the <seq> paragraph later in this section,
constructing a subsequent request). Its value is a non-negative where constructing a subsequent request is discussed). Its value
integer, which MUST be limited within the 0..2^31-1 range. is a non-negative integer that MUST be limited within the
0..2^31-1 range.
o <expires> provides a value which provides the number of seconds o <expires> provides a value indicating the number of seconds that
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 expiry is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides information representing an o <media-server-address> provides information representing an
assigned Media Server. More instances of this element may appear, assigned Media Server. More instances of this element may appear
should the MRB assign more Media Servers to a Consumer request. should the MRB assign more Media Servers 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
to indicate the appropriate existing media resource session to be to indicate the appropriate existing media resource session to be
manipulated by the MRB for this request. The value was provided manipulated by the MRB for this request. The value was provided
by the MRB in the initial request for media resources, as by the MRB in the initial request for media resources, as
discussed earlier in this section (<session-id> element included discussed earlier in this section (<session-id> element included
as part of the <session-info> element in the initial as part of the <session-info> element in the initial
<mediaResourceResponse>). <mediaResourceResponse>).
o <seq> is a numeric value returned to Consumer client in the o <seq> is a numeric value returned to the Consumer client in the
initial request for media resources, as discussed earlier in this initial request for media resources, as discussed earlier in this
section (<seq> element included as part of the <session-info> section (<seq> element included as part of the <session-info>
element in the initial <mediaResourceResponse>). On issuing any element in the initial <mediaResourceResponse>). On issuing any
future requests related to the specific media resource session (as future requests related to the specific media resource session (as
determined by the <session-id> element) the consumer client MUST determined by the <session-id> element), the Consumer client MUST
increment the value returned in the <seq> element from the initial increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows counter and when used in conjunction with the unique <session-id>
for unique identification of a request. As anticipated before, allows for unique identification of a request. As anticipated
the value of a <seq> value is limited to the 0..2^31-1 range: in before, the <seq> value is limited to the 0..2^31-1 range: in the
the unlikely case the counter increases to reach the highest unlikely case that the counter increases to reach the highest
allowed value, the <seq> value MUST be set to 0. The first allowed value, the <seq> value MUST be set to 0. The first
numeric value for the <seq> element is not meant to be '1', but numeric value for the <seq> element is not meant to be '1' but
SHOULD be generated randomly by the MRB: this is to reduce the SHOULD be generated randomly by the MRB: this is to reduce the
chances a malicious MRB disrupts the session created by this MRB, chances of a malicious MRB disrupting the session created by this
as explained in Section 12. MRB, as explained in Section 12.
o <action> element provides the operation to be carried out by the o <action> provides the operation to be carried out by the MRB on
MRB on receiving the request: receiving the request:
* The value of 'update' is a request by the Consumer client to * The value of 'update' is a request by the Consumer client to
update the existing session at the MRB with alternate media update the existing session on the MRB with alternate media
resource requirements. If the requested resource information resource requirements. If the requested resource information
is identical to the existing MRB session, the MRB will attempt is identical to the existing MRB session, the MRB will attempt
a session refresh. If the information has changed, the MRB a session refresh. If the information has changed, the MRB
will attempt to update the existing session with the new will attempt to update the existing session with the new
information. If the operation is successful, the 200 status information. If the operation is successful, the 200 status
code in the response is returned in the status attribute of the code in 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 409 status code in the response is returned in successful, a 409 status code in the response is returned in
the status attribute of the <mediaResourceResponseType> the status attribute of the <mediaResourceResponseType>
element. element.
* The value of 'remove' is a request by the Consumer client to * The value of 'remove' is a request by the Consumer client to
remove the session at the MRB. This provides a mechanism for remove the session on the MRB. This provides a mechanism for
Consumer clients to release unwanted resources before they Consumer clients to release unwanted resources before they
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 HTTP the <session-info> element MUST be included in a When used with HTTP, the <session-info> element MUST be included in
HTTP POST message (as defined in [RFC2616]). When used with SIP, an HTTP POST message (as defined in [RFC2616]). When used with SIP,
instead, the <session-info> element MUST be included in either a SIP the <session-info> element MUST instead be included in either a SIP
INVITE, or a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP
(as defined in[RFC3311]) request: in fact, any SIP dialog, be it a UPDATE (as defined in [RFC3311]) request: in fact, any SIP dialog, be
new or an existing one, can be exploited to carry leasing it a new or an existing one, can be exploited to carry leasing
information, and as such new SIP INVITE messages can update other information, and as such new SIP INVITE messages can update other
leases as well as requesting a new one. leases as well as request 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 media dialog. That BYE contains no Consumer interface Channel or a media dialog. That BYE contains no Consumer interface
lease information. lease information.
5.2.4. <mrbconsumer> 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.5.1. MRB Consumer request element is detailed in Section 5.2.5.1. The MRB Consumer
interface response element is contained in Section 5.2.6.1. interface response element is detailed in Section 5.2.6.1.
The <mrbconsumer> element has the following attributes: The <mrbconsumer> element has the following attributes:
version: a token specifying the mrb-consumer package version. The version: a token specifying the mrb-consumer package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The <mrbconsumer> element may have zero or more children of one of The <mrbconsumer> element may have zero or more children of one of
the following child element types: the following child element types:
<mediaResourceRequest> for sending a Consumer request. See <mediaResourceRequest> for sending a Consumer request. See
Section 5.2.5.1. Section 5.2.5.1.
<mediaResourceResponse> for sending a Consumer response. See <mediaResourceResponse> for sending a Consumer response. See
Section 5.2.6.1. Section 5.2.6.1.
5.2.5. Media Service Resource Request 5.2.5. Media Service Resource Request
This section provides the element definitions for use in Consumer This section provides the element definitions for use in Consumer
interface requests. The requests are carried in the interface requests. The requests are carried in the
<mediaResourceRequest> element. <mediaResourceRequest> element.
5.2.5.1. <mediaResourceRequest> element 5.2.5.1. <mediaResourceRequest>
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 a single mandatory attribute, 'id': this attribute element has a single mandatory attribute, 'id': this attribute
contains a random identifier, generated by the client, which will be contains a random identifier, generated by the client, that will be
included in the response in order to map it to a specific request. included in the response in order to map it to a specific request.
The <mediaResourceRequest> element has <generalInfo>, <ivrInfo> and The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and
<mixerInfo> as child elements. These three elements are used to <mixerInfo> as child elements. These three elements are used to
describe the requirements of a client requesting a Media Server and describe the requirements of a client requesting a Media Server and
are covered in the following sub-sections. are covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3,
respectively.
5.2.5.1.1. <generalInfo> element 5.2.5.1.1. <generalInfo>
The <generalInfo> element provides a information for general Consumer The <generalInfo> element provides general Consumer request
request information that is neither IVR or Mixer specific. This information that is neither IVR specific nor 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 <session-info> and <packages>
element, <session-info> and <packages>. elements, as used by the <generalInfo> element.
5.2.5.1.1.1. <session-info> element 5.2.5.1.1.1. <session-info>
The <session-info> element is included in Consumer requests when an The <session-info> element is included in Consumer requests when an
update is being made to an existing media resource session. The update is being made to an existing media resource session. The
ability to change and remove an existing media resource session is ability to change and remove an existing media resource session is
described in more detail in Section 5.2.3. The element MAY be described in more detail in Section 5.2.3. The element MAY be
present. present.
The <session-info> element has no attributes. The <session-info> element has no attributes.
The <session-info> element has zero or more of the following child The <session-info> element has zero or more of the following child
elements: elements:
<session-id>: is a unique identifier that explicitly references an <session-id>: 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>: 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.
Its value is a non-negative integer, which MUST be limited within Its value is a non-negative integer that MUST be limited within
the 0..2^31-1 range. In the unlikely case the counter increases the 0..2^31-1 range. In the unlikely case that the counter
to reach the highest allowed value, the <seq> value MUST be set to increases to reach the highest allowed value, the <seq> value MUST
0. More information about its use is provided in Section 5.2.3. be set to 0. 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.5.1.1.2. <packages> element 5.2.5.1.1.2. <packages>
The <packages> element provides a list of Media Control Channel The <packages> element provides a list of Media Control Channel
Framework compliant packages that are required by the Consumer Framework compliant packages that are required by the Consumer
client. The element MAY be present. client. The element MAY be present.
The <packages> element has no attributes. The <packages> element has no attributes.
The <packages> element has zero or more of the following child The <packages> element has a single child element:
element:
<package>: child element contains a string representing the Media <package>: Contains a string representing the Media Control Channel
Control Channel Framework package required by the Consumer client. Framework package required by the Consumer client. The <package>
The <package> element can appear multiple times. A valid value is element can appear multiple times. A valid value is a Control
a Control Package name compliant with the Section 13.1.1 of Package name compliant with Section 13.1.1 of [RFC6230].
[RFC6230].
5.2.5.1.2. <ivrInfo> element 5.2.5.1.2. <ivrInfo>
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>. <file-transfer-modes>.
5.2.5.1.2.1. <ivr-sessions> element 5.2.5.1.2.1. <ivr-sessions>
The <ivr-sessions> element indicates the number of IVR sessions a The <ivr-sessions> element indicates the number of IVR sessions that
Consumer client requires from a media resource. The element MAY be a Consumer client requires from a media resource. The element MAY be
present. present.
The <ivr-sessions> element has no attributes. The <ivr-sessions> element has no attributes.
The <ivr-sessions> element has zero or more of the following child The <ivr-sessions> element has a single 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 media type (which can include value of the attribute, 'name', is a media type (which can include
parameters per [RFC6381]). The <rtp-codec> element has two child parameters per [RFC6381]). The <rtp-codec> element has two child
elements. The child element, <decoding>, contains the number of elements. The child element <decoding> contains the number of RTP
RTP sessions required for decoding using the specified codec. The sessions required for decoding using the specified codec, and the
child element, <encoding>, contains the number of RTP sessions child element <encoding> contains the number of RTP sessions
required for encoding using the specified codec. required for encoding using the specified codec.
5.2.5.1.2.2. <file-formats> element 5.2.5.1.2.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
for the purpose of playing media. It should be noted that this for the purpose of playing media. It should be noted that this
element describes media types, and might better have been named element describes media types and might better have been named
"media-format" but the name "file-format" is being used due to "media-formats", but due to existing implementations the name
existing implementations The element MAY be present. "file-formats" is being used. The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has zero or more of the following child The <file-formats> element has a single child element:
element:
<required-format>: has a single attribute, 'name', which provides <required-format>: Has a single attribute, 'name', which provides
the type of file format that is required. A valid value is a the type of file format that is required. A valid value is a
media type which, depending on its definition, can include media type that, depending on its definition, can include
additional parameters (e.g., [RFC6381]). 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 has a single attribute, The <required-file-package> element has a single attribute,
'required-file-package-name', which contains the name of the Media 'required-file-package-name', which contains the name of the Media
Control Channel Framework package, compliant with the Section Control Channel Framework package, compliant with Section 13.1.1
13.1.1 of [RFC6230], for which the file format support applies. of [RFC6230], for which the file format support applies.
5.2.5.1.2.3. <dtmf> element 5.2.5.1.2.3. <dtmf>
The <dtmf> element specifies the required methods to detect DTMF The <dtmf> element specifies the required methods to detect DTMF
tones and to generate them. The element MAY be present. tones and to generate them. The element MAY be present.
The <dtmf> element has no attributes. The <dtmf> element has no attributes.
The <dtmf> element has zero or more of the following child elements: The <dtmf> element has zero or more of the following child elements:
<detect>: Indicates the required support for DTMF detection. The <detect>: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element has a <detect> element has no attributes. The <detect> element 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 required, and is a case insensitive provides the type of DTMF required and is a case-insensitive
string containing either 'RFC4733' [RFC4733] or 'Media' (detecting string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
tones as signals from the audio stream). The 'package' attribute tones as signals from 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 Section 13.1.1 of [RFC6230], for which the DTMF compliant with Section 13.1.1 of [RFC6230], for which the DTMF
type applies. type applies.
<generate>: Indicates the required support for DTMF generation. <generate>: Indicates the required support for DTMF generation. The
The <generate> element has no attributes. The <generate> element <generate> element has no attributes. The <generate> element has
has a single child element, <dtmf-type>. The <dtmf-type> element a single child element, <dtmf-type>. The <dtmf-type> element has
has two attributes, 'name' and 'package. The 'name' attribute two attributes: 'name' and 'package'. The 'name' attribute
provides the type of DTMF required, and is a case insensitive provides the type of DTMF required and is a case-insensitive
string containing either 'RFC4733' [RFC4733] or 'Media' string containing either 'RFC4733' [RFC4733] or 'Media'
(generating tones as signals in the audio stream). The 'package' (generating 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 Section 13.1.1 of [RFC6230], for which package, compliant with Section 13.1.1 of [RFC6230], for which the
the DTMF type applies. 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 required, and is a case insensitive string containing either DTMF required and is a case-insensitive string containing either
'RFC4733' [RFC4733] or 'Media' (passing tones as signals through 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
the audio stream). The 'package' attribute provides the name of the audio stream). The 'package' attribute provides the name of
the Media Control Channel Framework package, compliant with the the Media Control Channel Framework package, compliant with
Section 13.1.1 of [RFC6230], for which the DTMF type applies. Section 13.1.1 of [RFC6230], for which the DTMF type applies.
5.2.5.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 that 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 support
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality for country codes (ISO 3166-1 [ISO.3166-1]) and requested
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The
present. element MAY be present.
The <tones> element has no attributes. The <tones> element has no attributes.
The <tones> element has zero or more of the following child elements: The <tones> element has zero or more of the following child elements:
<country-codes>: Describes the requested country codes in relation <country-codes>: Describes the requested country codes in relation
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> element 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 Section 13.1.1 of [RFC6230], in which package, compliant with Section 13.1.1 of [RFC6230], in which the
the tones from the specified country code are requested. tones from the specified country code are requested.
<h248-codes>: Describes the requested H.248 codes in relation to <h248-codes>: Describes the requested H.248 codes in relation to
tones. The <h248-codes> element has no attributes. The <h248- tones. The <h248-codes> element has no attributes. The
codes> has one child element. The child element, <h248-code>, <h248-codes> element has one child element. The child element,
requests a specific H.248 code, compliant with the ITU-T <h248-code>, requests a specific H.248 code, compliant with the
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. The
be either specific (e.g., cg/dt to only report the Dial Tone from codes can be either specific (e.g., cg/dt to only report the Dial
the Call Progress Tones package) or generic (e.g., cg/* to report Tone from the Call Progress Tones package) or generic (e.g., cg/*
all the tones from the Call Progress Tones package) using wild- to report all the tones from the Call Progress Tones package),
cards. The <h248-code> element has a single attribute, 'package'. using wildcards. The <h248-code> element has a single attribute,
The attribute 'package' provides the name of the Media Control 'package'. The attribute 'package' provides the name of the Media
Channel Framework package, compliant with the Section 13.1.1 of Control Channel Framework package, compliant with Section 13.1.1
[RFC6230], in which the specified codes are requested. of [RFC6230], in which the specified codes are requested.
5.2.5.1.2.5. <asr-tts> 5.2.5.1.2.5. <asr-tts>
The <asr-tts> element requests information about the support for The <asr-tts> element requests information about the support 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.2002]
codes) in relation to both ASR and TTS. The <asr-tts> element has no codes) in relation to both ASR and TTS. The <asr-tts> element has no
attributes. The <asr-tts> element has zero or more of the following attributes. The <asr-tts> element has zero or more of the following
child elements: child elements:
<asr-support>: Describes the available languages for ASR. The <asr-support>: Describes the available languages for ASR. The
<asr-support> element has no attributes. The <asr-support> has <asr-support> element has no attributes. The <asr-support>
one child element. The child element, <language>, requests the element has one child element. The child element, <language>,
Media Server supports ASR for a specific language. The <language> requests that the Media Server supports ASR for a specific
element has a single attribute, 'xml:lang'. The attribute 'xml: language. The <language> element has a single attribute,
lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
language. [ISO.639.2002] code of the supported language.
<tts-support>: Describes the available languages for TTS. The <tts-support>: Describes the available languages for TTS. The
<tts-support> element has no attributes. The <tts-support> has <tts-support> element has no attributes. The <tts-support>
one child element. The child element, <language>, requests the element has one child element. The child element, <language>,
Media Server supports tts for a specific language. The <language> requests that the Media Server supports TTS for a specific
element has a single attribute, 'xml:lang'. The attribute 'xml: language. The <language> element has a single attribute,
lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
language. [ISO.639.2002] code of the supported language.
5.2.5.1.2.6. <vxml> element 5.2.5.1.2.6. <vxml>
The <vxml> element specifies if the Consumer client requires VoiceXML The <vxml> element specifies if the Consumer client requires VoiceXML
and if so the supported protocols (e.g., via the control framework, and, if so, which protocols are supported (e.g., via the control
RFC4240 [RFC4240], or RFC5552 [RFC5552]). The element MAY be framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]). The element
present. MAY be present.
The <vxml> element has zero or more of the following child elements: The <vxml> element has a single child element:
<vxml-mode>: has two attributes, 'package' and 'require'. The <vxml-mode>: Has two attributes: 'package' and 'require'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the VXML support applies. The 'require' attribute which the VXML support applies. The 'require' attribute specifies
specifies the type of VXML support required by the Consumer client the type of VXML support required by the Consumer client (e.g.,
(e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]),
[RFC6231]), and valid values are case insensitive RFC references and valid values are case-insensitive RFC references (e.g.,
(e.g., "rfc6231" to specify the Client requests support for "rfc6231" to specify that the client requests support for VoiceXML
VoiceXML as provided by the IVR Package [RFC6231]). as provided by the IVR Package [RFC6231]).
The presence of at least one <vxml> child element would indicate that The presence of at least one <vxml> child element would indicate that
the Consumer client requires VXML support as specified by the child the Consumer client requires VXML support as specified by the child
element itself. An empty <vxml> element would otherwise indicate the element itself. An empty <vxml> element would otherwise indicate
Consumer client does not require VXML support. that the Consumer client does not require VXML support.
5.2.5.1.2.7. <location> 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.
More precisely, this section is entirely optional, and is More precisely, this section is entirely optional and is
implementation specific in its level of population. implementation specific in its level of population.
The <location> element has no attributes. The <location> element has no attributes.
The <location> element has a single child element: The <location> element has a single child element:
<civicAddress>: Describes the civic address location of the <civicAddress>: Describes the civic address location of the
requested media server, whose representation refers to Section 4 requested Media Server, whose representation refers to Section 4
of RFC 5139 [RFC5139]. of RFC 5139 [RFC5139].
5.2.5.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]. The for encrypting RTP media streams using RFC 3711 [RFC3711]. The
element MAY be present. If the element is present, then the Media element MAY be present. If the element is present, then the Media
Server supports DTLS-SRTP [RFC5763]. Server supports DTLS-SRTP [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has no child elements: The <encryption> element has no child elements.
5.2.5.1.2.9. <application-data> 5.2.5.1.2.9. <application-data>
The <application-data> element provides an arbitrary string of The <application-data> element provides an arbitrary string of
characters as IVR application level data. This data is meant to only characters as IVR application-level data. This data is meant to only
have meaning at the application level logic and as such is not have meaning at the application-level logic and as such is not
otherwise restricted by this specification. The set of allowed otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return, characters is the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see line feed, and the legal characters of Unicode and ISO/IEC 10646
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. [ISO.10646.2012] (see also Section 2.2 of
<http://www.w3.org/TR/xml/>)). The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.2.5.1.2.10. <max-prepared-duration> 5.2.5.1.2.10. <max-prepared-duration>
The <max-prepared-duration> element indicates the amount of time The <max-prepared-duration> element indicates the amount of time
required by the Consumer client representing media dialog preparation required by the Consumer client representing media dialog preparation
in the system before it is executed. The element MAY be present. in the system before it is executed. The element MAY be present.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has a single child element: The <max-prepared-duration> element has a single child element:
<max-time>: has a single attribute, 'max-time-seconds', which <max-time>: Has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the Section 13.1.1 of [RFC6230], for which the time compliant with Section 13.1.1 of [RFC6230], for which the time
period applies. period applies.
5.2.5.1.2.11. <file-transfer-modes> 5.2.5.1.2.11. <file-transfer-modes>
The <file-transfer-modes> element allows the Consumer client to The <file-transfer-modes> element allows the Consumer client to
specify which scheme names are required for file transfer to a Media specify which scheme names are required for file transfer to a Media
Server for each Media Control Channel Framework package type. For Server for each Media Control Channel Framework package type. For
example, does the Media Server support fetching media resources via example, does the Media Server support fetching media resources via
HTTP, HTTPS, NFS, etc protocols. The element MAY be present. HTTP, HTTPS, NFS, etc.? The element MAY be present.
The <file-transfer-modes> element has no attributes. The <file-transfer-modes> element has no attributes.
The <file-transfer-modes> element has a single child element: The <file-transfer-modes> element has a single child element:
<file-transfer-mode>: has two attributes, 'name' and 'package'. <file-transfer-mode>: Has two attributes: 'name' and 'package'. The
The 'name' attribute provides the scheme name of the protocol 'name' attribute provides the scheme name of the protocol required
required for fetching resources: valid values are case insensitive for fetching resources: valid values are case-insensitive scheme
scheme names (e.g. HTTP, HTTPS, NFS, etc.). The 'package' names (e.g., HTTP, HTTPS, NFS, etc.). The 'package' attribute
attribute provides the name of the Media Control Channel Framework provides the name of the Media Control Channel Framework package,
package, compliant with the Section 13.1.1 of [RFC6230], for which compliant with Section 13.1.1 of [RFC6230], for which the scheme
the scheme name applies. name applies.
The same considerations relating to file transfer and live streaming The same considerations relating to file transfer and live streaming
are explained further in Section 5.1.5.15, whcih apply here as well. are explained further in Section 5.1.5.15 and apply here as well.
5.2.5.1.3. <mixerInfo> element 5.2.5.1.3. <mixerInfo>
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
sections describe the elements of the <mixerInfo> element, <mixers>, sub-sections describe the elements of the <mixerInfo> element:
<file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application- <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>,
data>, <location> and <encryption>. <application-data>, <location>, and <encryption>.
5.2.5.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 <mixers> element has no attributes. The <mixers> element has no attributes.
The <mixers> element has a single child element: The <mixers> element has a single child element:
<mix>: Describes the required mixed RTP sessions. The <mix> <mix>: Describes the required mixed RTP sessions. The <mix> element
element has one attribute. The value of the attribute, 'users', has one attribute. The value of the attribute, 'users', is the
is the number of participants required in the mix. The <mix> number of participants required in the mix. The <mix> element has
element has one child element. The child element, <rtp-codec>, one child element. The child element, <rtp-codec>, contains the
contains the same information relating to RTP sessions as defined same information relating to RTP sessions as that defined in
in Section 5.1.5.3. The element MAY be present. Section 5.1.5.3. The element MAY be present.
5.2.5.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 <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <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 <required-format>: Has a single attribute, 'name', which provides
the type of file format supported. A valid value is a media type the type of file format supported. A valid value is a media type
which, depending on its definition, can include additional that, depending on its definition, can include additional
parameters (e.g., [RFC6381]). The <required-format> element has a parameters (e.g., [RFC6381]). The <required-format> element has a
child element, <required-file-package>. The <required-file- child element, <required-file-package>. The
package> element contains a single attribute, 'required-file- <required-file-package> element contains a single attribute,
package-name', which contains the name of the Media Control 'required-file-package-name', which contains the name of the Media
Channel Framework package, compliant with the Section 13.1.1 of Control Channel Framework package, compliant with Section 13.1.1
[RFC6230], for which the file format support applies. of [RFC6230], for which the file format support applies.
5.2.5.1.3.3. <dtmf> element 5.2.5.1.3.3. <dtmf>
The <dtmf> element specifies the required methods to detect DTMF The <dtmf> element specifies the required methods to detect DTMF
tones 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 <dtmf> element has no attributes. The <dtmf> element has no attributes.
The <dtmf> element has zero or more of the following child elements: The <dtmf> element has zero or more of the following child elements:
<detect>: Indicates the required support for DTMF detection. The <detect>: Indicates the required support for DTMF detection. The
<detect> element has no attributes. The <detect> element then has <detect> element has no attributes. The <detect> element then has
a further child element, <dtmf-type>. The <dtmf-type> element has a further child element, <dtmf-type>. The <dtmf-type> element has
two attributes, 'name' and 'package. The 'name' attribute two attributes: 'name' and 'package'. The 'name' attribute
provides the type of DTMF being used, and it is a case insensitive provides the type of DTMF being used and is a case-insensitive
string containing either 'RFC4733' [RFC4733] or 'Media' (detecting string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
tones as signals from the audio stream). The 'package' attribute tones as signals from 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 Section 13.1.1 of [RFC6230], for which the DTMF compliant with Section 13.1.1 of [RFC6230], for which the DTMF
type applies. type applies.
<generate>: Indicates the required support for DTMF generation. <generate>: Indicates the required support for DTMF generation. The
The <generate> element has no attributes. The <generate> element <generate> element has no attributes. The <generate> element has
has a single child element, <dtmf-type>. The <dtmf-type> element a single child element, <dtmf-type>. The <dtmf-type> element has
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 is a case insensitive provides the type of DTMF being used and is a case-insensitive
string containing either 'RFC4733' [RFC4733] or 'Media' string containing either 'RFC4733' [RFC4733] or 'Media'
(generating tones as signals in the audio stream). The 'package' (generating 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 Section 13.1.1 of [RFC6230], for which package, compliant with Section 13.1.1 of [RFC6230], for which the
the DTMF type applies. 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 has a single child element, attributes. The <passthrough> element has a single child element,
<dtmf-type>. The <dtmf-type> element has two attributes, 'name' <dtmf-type>. The <dtmf-type> element has two attributes: 'name'
and 'package. The 'name' attribute provides the type of DTMF and 'package'. The 'name' attribute provides the type of DTMF
being used, and is a case insensitive string containing either being used and is a case-insensitive string containing either
'RFC4733' [RFC4733] or 'Media' (passing tones as signals through 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
the audio stream). The 'package' attribute provides the name of the audio stream). The 'package' attribute provides the name of
the Media Control Channel Framework package, compliant with the the Media Control Channel Framework package, compliant with
Section 13.1.1 of [RFC6230], for which the DTMF type applies. Section 13.1.1 of [RFC6230], for which the DTMF type applies.
5.2.5.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 that 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 support
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality for country codes (ISO 3166-1 [ISO.3166-1]) and requested
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The
present. element MAY be present.
The <tones> element has no attributes. The <tones> element has no attributes.
The <tones> element has zero or more of the following child elements: The <tones> element has zero or more of the following child elements:
<country-codes>: Describes the requested country codes in relation <country-codes>: Describes the requested country codes in relation
to tones. The <country-codes> element has no attributes. The to tones. The <country-codes> element has no attributes. The
<country-codes> has a single child element. The child element, <country-codes> element has a single child element. The child
<country-code>, requests a specific country code, compliant with element, <country-code>, requests a specific country code,
the ISO 3166-1 [ISO.3166-1] specification. The <country-code> compliant with the ISO 3166-1 [ISO.3166-1] specification. The
element has a single attribute, 'package'. The attribute <country-code> element has a single attribute, 'package'. The
'package' provides the name of the Media Control Channel Framework attribute 'package' provides the name of the Media Control Channel
package, compliant with the specification in the related IANA Framework package, compliant with the specification in the related
registry (e.g., "msc-ivr/1.0"), in which the tones from the IANA 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
codes> has a single child element. The child element, <h248- <h248-codes> element has a single child element. The child
code>, requests a specific H.248 code, compliant with the ITU-T element, <h248-code>, requests a specific H.248 code, compliant
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
be either specific (e.g., cg/dt to only report the Dial Tone from The codes can be either specific (e.g., cg/dt to only report the
the Call Progress Tones package) or generic (e.g., cg/* to report Dial Tone from the Call Progress Tones package) or generic (e.g.,
all the tones from the Call Progress Tones package) using wild- cg/* to report all the tones from the Call Progress Tones
cards. The <h248-code> element has a single attribute, 'package'. package), using wildcards. The <h248-code> element has a single
attribute, 'package'. The attribute 'package' provides the name
The attribute 'package' provides the name of the Media Control of the Media Control Channel Framework package, compliant with
Channel Framework package, compliant with the Section 13.1.1 of Section 13.1.1 of [RFC6230], in which the specified codes are
[RFC6230], in which the specified codes are requested. requested.
5.2.5.1.3.5. <mixing-modes> 5.2.5.1.3.5. <mixing-modes>
The <mixing-modes> element requests information relating to support The <mixing-modes> element requests information relating to support
for audio and video mixing; more specifically a list of supported for audio and video mixing, more specifically a list of supported
algorithms to mix audio and a list of supported video presentation algorithms to mix audio and a list of supported video presentation
layouts. The element MAY be present. layouts. The element MAY be present.
The <mixing-modes> element has no attributes. The <mixing-modes> element has no attributes.
The <mixing-modes> element has zero or more of the following child The <mixing-modes> element has zero or more of the 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 requested mixing element, <audio-mixing-mode>, contains a requested mixing
algorithm. Valid values for the <audio-mixing-mode> element are algorithm. Valid values for the <audio-mixing-mode> element are
are algorithm names, e.g., 'nbest' and 'controller' as defined in algorithm names, e.g., 'nbest' and 'controller' as defined in
[RFC6505]. The element has a single attribute, 'package'. The [RFC6505]. The element has a single attribute, 'package'. The
attribute 'package' provides the name of the Media Control Channel attribute 'package' provides the name of the Media Control Channel
Framework package, compliant with the Section 13.1.1 of [RFC6230], Framework package, compliant with Section 13.1.1 of [RFC6230], for
for which the algorithm support is requested. which the algorithm support is 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 the predefined video layouts defined in the XCON
information data model, or to non-XCON layouts as well, as long as conference information data model, or to non-XCON layouts as well,
they are appropriately prefixed. The <video-mixing-mode> element as long as they are appropriately prefixed. The
has a single attribute, 'package'. The attribute 'package' <video-mixing-mode> element has a single attribute, 'package'.
provides the name of the Media Control Channel Framework package, The attribute 'package' provides the name of the Media Control
compliant with the Section 13.1.1 of [RFC6230], for which the Channel Framework package, compliant with Section 13.1.1 of
algorithm support is requested. [RFC6230], for which the algorithm support is requested.
5.2.5.1.3.6. <application-data> 5.2.5.1.3.6. <application-data>
The <application-data> element provides an arbitrary string of The <application-data> element provides an arbitrary string of
characters as Mixer application level data. This data is meant to characters as mixer application-level data. This data is meant to
only have meaning at the application level logic and as such is not only have meaning at the application-level logic and as such is not
otherwise restricted by this specification. The set of allowed otherwise restricted by this specification. The set of allowed
characters are the same as those in XML (viz., tab, carriage return, characters is the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see line feed, and the legal characters of Unicode and ISO/IEC 10646
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. [ISO.10646.2012] (see also Section 2.2 of
<http://www.w3.org/TR/xml/>)). The element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.2.5.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.
More precisely, this section is entirely optional, and it's More precisely, this section is entirely optional, and it's
implementation specific to fill it with just the details each implementation specific to fill it with just the details each
implementor deems necessary for any optimization that may be needed. implementer deems necessary for any optimization that may be needed.
The contents of a <location> element has no attributes. The <location> element has no attributes.
The contents of a <location> element has a single child element: The <location> element has a single child element:
<civicAddress>: Describes the civic address location of the <civicAddress>: Describes the civic address location of the
requested media server, whose representation refers to Section 4 requested Media Server, whose representation refers to Section 4
of RFC 5139 [RFC5139]. of RFC 5139 [RFC5139].
5.2.5.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]. The for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. The
element MAY be present. If the element is present, then the Media element MAY be present. If the element is present, then the Media
Server supports DTLS-SRTP [RFC5763]. Server supports DTLS-SRTP [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has no child elements. The <encryption> element has no child elements.
5.2.6. 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.6.1. <mediaResourceResponse> element 5.2.6.1. <mediaResourceResponse>
The <mediaResourceResponse> element provides information for clients The <mediaResourceResponse> element provides information for clients
receiving response information from an external MRB entity. receiving response information from an external MRB entity.
The <mediaResourceResponse> element has two mandatory attributes, The <mediaResourceResponse> element has two mandatory attributes:
'id' and 'status'. The 'id' attribute must contain the same value 'id' and 'status'. The 'id' attribute must contain the same value
the client provided in the 'id' attribute in the that the client provided in the 'id' attribute in the
<mediaResourceRequest> the response is for. The 'status' attribute <mediaResourceRequest> to which the response is mapped. The 'status'
indicates the status code of the operation. The following status attribute indicates the status code of the operation. The following
codes are defined for 'status': status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | | | | |
| 400 | Syntax error | | 400 | Syntax error |
| | | | | |
| 405 | Wrong sequence number | | 405 | Wrong sequence number |
| | | | | |
| 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: <mediaResourceResponse> Status Codes
In case a new media resource request made by an client application If a new media resource request made by a client application has been
has been accepted, the MRB MUST reply with a <mediaResourceResponse> accepted, the MRB MUST reply with a <mediaResourceResponse> with
with status code 200. The same rule applies whenever a request to status code 200. The same rule applies whenever a request to update
update (action='update') or remove (action='remove') an existing (action='update') or remove (action='remove') an existing transaction
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 2 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 it status code 420. If a syntactically correct request fails because it
contains a wrong sequence number, that is, a 'seq' value not contains a wrong sequence number, that is, a 'seq' value not
consistent with the increment the MRB expects according to consistent with the increment the MRB expects according to
Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with
status code 405. If a syntactically correct request fails because status code 405. If a syntactically correct request fails because
the MRB couldn't find any Media Server able to fulfil the the MRB couldn't find any Media Server able to fulfill the
requirements presented by the Application Server in its request, the requirements presented by the Application Server in its request, the
MRB MUST reply with a <mediaResourceResponse> with status code 408. MRB MUST reply with a <mediaResourceResponse> with status code 408.
If a syntactically correct request fails because the MRB couldn't If a syntactically correct request fails because the MRB couldn't
update an existing request according to the new requirements update an existing request according to the new requirements
presented by the Application Server in its request, the MRB MUST presented by the Application Server in its request, the MRB MUST
reply with a <mediaResourceResponse> with status code 409. If a reply with a <mediaResourceResponse> with status code 409. If a
syntactically correct request fails because the MRB couldn't remove syntactically correct request fails because the MRB couldn't remove
an existing request and release the related resources as requested by an existing request and release the related resources as requested by
the Application Server, the MRB MUST reply with a the Application Server, the MRB MUST reply with a
<mediaResourceResponse> with status code 410. <mediaResourceResponse> with status code 410.
Further details on status codes 409 and 410 are included in Further details on status codes 409 and 410 are included in
Section 5.2.3 where the leasing mechanism, along with its related Section 5.2.3, where the leasing mechanism, along with its related
scenarios, are described in more detail. scenarios, is described in more detail.
The <mediaResourceResponse> element has <response-session-info> as a The <mediaResourceResponse> element has <response-session-info> as a
child element. This element is used to describe the response of a child element. This element is used to describe the response of a
Consumer interface query and is covered in the following sub-section. Consumer interface query and is covered in the following sub-section.
5.2.6.1.1. <response-session-info> element 5.2.6.1.1. <response-session-info>
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. If the request was is described in more detail in Section 5.2.3. If the request was
successful, the <mediaResourceResponse> MUST have one <response- successful, the <mediaResourceResponse> MUST have one
session-info> child, which describes the media resource session <response-session-info> child, which describes the media resource
addressed by the request. If the request was not successful, the session addressed by the request. If the request was not successful,
<mediaResourceResponse> MUST NOT have a <response-session-info> the <mediaResourceResponse> MUST NOT have a <response-session-info>
child. child.
The contents of a <response-session-info> element has no attributes. The <response-session-info> element has no attributes.
The contents of a <response-session-info> element has zero or more of The <response-session-info> element has zero or more of the following
the following child elements: child elements:
<session-id>: is a unique identifier that explicitly references an <session-id>: 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>: 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 on 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 reclaim 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 timeout period could be
used. For example, if the time-out period is 300 seconds, the used. For example, if the timeout period is 300 seconds, the
Consumer Client would refresh the transaction at 240 seconds. Consumer client would refresh the transaction at 240 seconds.
More information on its use is provided in Section 5.2.3. More information on its use is provided in Section 5.2.3.
<media-server-address>: provides information to reach the Media <media-server-address>: Provides information to reach the Media
Server handling the requested media resource. One or more Server handling the requested media resource. One or more
instances of these element may appear. The <media-server-address> instances of these elements may appear. The
element has a single attribute named 'uri' which supplies a SIP <media-server-address> element has a single attribute named 'uri',
URI that reaches the specified media server. It also has three which supplies a SIP URI that reaches the specified Media Server.
optional elements <connection-id>, <ivr-sessions>, and <mixers>. It also has three optional elements: <connection-id>,
The <ivr-sessions> and <mixers> are defined in Section 5.2.5.1.2.1 <ivr-sessions>, and <mixers>. The <ivr-sessions> and <mixers>
and Section 5.2.5.1.3.1 and have the same meaning but are applied elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1,
to individual media server instances as a subset of the overall respectively, and have the same meaning but are applied to
individual Media Server instances as a subset of the overall
resources reported in the <connection-id> element. If multiple resources reported in the <connection-id> element. If multiple
Media Servers are assigned in an IAMM operation, exactly one Media Servers are assigned in an IAMM operation, exactly one
<media-server-address> element, more specifically the media server <media-server-address> element, more specifically the Media Server
that provided the media dialog or CFW response, will have a that provided the media dialog or CFW response, will have a
<connection-id> element. Additional information relating to the <connection-id> element. Additional information relating to the
use of the <connection-id> element for media dialogs is included use of the <connection-id> element for media dialogs is included
in Section 6. in 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: the In-line Unaware MRB Mode
(IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation. (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of
This section further describes IUMM. operation. 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
implemented by those requesting Media Server resources (for example implemented by those requesting Media Server resources (for example,
an Application Server). This applies when using the Consumer an Application Server). This applies when using the Consumer
interface as discussed in Section 5.2.1(Query mode) and interface as discussed in Sections 5.2.1 (Query mode) and 5.2.2
Section 5.2.2(IAMM). An MRB entity can also act in a client unaware (IAMM). An MRB entity can also act in a client-unaware mode when
mode when deployed into the network. This allows any SIP compliant deployed into the network. This allows any SIP-compliant client
client entity, as defined by RFC 3261 [RFC3261] and its extensions, entity, as defined by RFC 3261 [RFC3261] and its extensions, to send
to send requests to an MRB which in turn will select an appropriate requests to an MRB that in turn will select an appropriate Media
media server based on knowledge of media server resources it Server based on knowledge of Media Server resources it currently has
currently has available transparently to the client entity. Using an available transparently to the client entity. Using an MRB in this
MRB in this mode allows for easy migration of current applications mode allows for easy migration of current applications and services
and services that are unaware of the MRB concept and would simply that are unaware of the MRB concept and would simply require a
require a configuration change resulting in the MRB being set as a configuration change resulting in the MRB being set as a SIP outbound
SIP outbound proxy for clients requiring media services. proxy for 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 the 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 media dialog could convey the application/sdp payload to either set up a media
or a Control Framework control channel. In either case, in order to dialog or a Control Framework Control Channel. In either case, in
permit the Application Server to associate a media dialog with a order to permit the Application Server to associate a media dialog
control channel to the same Media Server, using the procedures of with a Control Channel to the same Media Server, using the procedures
[RFC6230] section 6, the MRB should be acting as a SIP proxy (and not of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and
a B2BUA). This allows the SIP URI of the targeted Media Server to be not a B2BUA). This allows the SIP URI of the targeted Media Server
transparently passed back to the Application Server in the SIP to be transparently passed back to the Application Server in the SIP
response resulting in a SIP dialog directly between the Application response, resulting in a direct SIP dialog between the Application
Server and the Media Server. 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 act as a SIP Back-2-Back-User-Agent (B2BUA) or a An MRB entity can act as a SIP Back-to-Back User Agent (B2BUA) or a
SIP Proxy Server as defined in RFC 3261 [RFC3261]. When acting as a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When an MRB acts
B2BUA issues can arise when using Media Control Channel packages such as a B2BUA, issues can arise when using Media Control Channel
as the IVR[RFC6231] and Mixer[RFC6505] Packages. Specifically the packages such as the IVR [RFC6231] and mixer [RFC6505] packages.
Framework attribute 'connectionid' provided in the appendix titled Specifically, the framework attribute 'connectionid' as provided in
'Appendix: Common Package Components' of Media Control Channel Appendix A ("Common Package Components") of [RFC6230] uses a
Framework[RFC6230] uses a concatenation of the SIP dialog identifiers concatenation of the SIP dialog identifiers to be used for
to be used for referencing SIP dialogs within the media control referencing SIP dialogs within the Media Control Channel. When a
channel. When a request traverses an MRB acting as a B2BUA, the SIP request traverses an MRB acting as a B2BUA, the SIP dialog
dialog identifiers change and so the 'connectionid' can not be used identifiers change, and so the 'connectionid' cannot be used as
as intended due to the SIP dialog identifiers changing. For this intended due to this change. For this reason, when an MRB wishes to
reason when a MRB wishes to act as a SIP B2BUA when handling a act as a SIP B2BUA when handling a request from an Application Server
request from an Application Server to set up a media dialog to a to set up a media dialog to a Media Server, it MUST include the
Media Server it MUST include the optional <connection-id> element in optional <connection-id> element in a Consumer interface response
a Consumer interface response with a value that provides the with a value that provides the equivalent for the 'connectionid'
equivalent for the 'connectionid' ('Local Dialog Tag' + 'Remote ('Local Dialog Tag' + 'Remote Dialog Tag') for the far side of the
Dialog Tag') for the far side of the B2BUA. If present, this value B2BUA. If present, this value MUST be used as the value for the
MUST be used as the value for the 'connectionid' in packages where 'connectionid' in packages where the Common Package Components are
the Common Package Components are used. The <connection-id> element used. The <connection-id> element MUST NOT be included in an HTTP
MUST NOT be included in a HTTP Consumer interface response. Consumer interface response.
It is important to point out that, although more Media Server It is important to point out that although more Media Server
instances may be returned in a Consumer response (i.e., the MRB has instances may be returned in a Consumer response (i.e., the MRB has
assigned more than one Media Server to a Consumer request to fulfill assigned more than one Media Server to a Consumer request to fulfill
the Application Server requirements), in IAMM the MRB will only act the Application Server requirements), in IAMM the MRB will only act
as a B2BUA with a single Media Server. In this case exactly one as a B2BUA with a single Media Server. In this case, exactly one
<media-server-address> element, describing the media dialog or CFW <media-server-address> element, describing the media dialog or CFW
response, will have a <connection-id> element which will not be response, will have a <connection-id> element that will not be
included in any additional <media-server-address> elements. included in any additional <media-server-address> elements.
7. Multi-modal MRB Implementations 7. Multimodal MRB Implementations
An MRB implementation may operate multi-modally with a collection of An MRB implementation may operate multimodally 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. That is, 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
request from a client depending on the context of the request: particular request from a client, depending on the context of the
request:
o If the received request is a HTTP POST message with application/ o If the received request is an HTTP POST message with application/
mrb-consumer+xml content, then MRB processes it in Query mode. mrb-consumer+xml content, then the MRB processes it in Query mode.
o If the received request is a SIP INVITE with application/ o If the received request is a SIP INVITE with application/
mrb-consumer+xml content and application/sdp content, then MRB mrb-consumer+xml content and application/sdp content, then the MRB
processes it in IAMM. processes it in IAMM.
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
processes it in IUMM. the MRB 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 by the following basic types: be distinguished by the following basic types:
a. Query mode - the client is requesting the assignment by MRB of a. Query mode - the client is requesting the assignment by the MRB
suitable Media Server resources; of suitable Media Server resources;
b. IAMM - the client is requesting the assignment by MRB of suitable b. IAMM/media dialog - the client is requesting the assignment by
Media Server resources and the establishment of a media dialog to the MRB of suitable Media Server resources and the establishment
one of the Media Servers; of a media dialog to one of the Media Servers;
c. IAMM - the client is requesting the assignment by MRB of suitable c. IAMM/Control Channel - the client is requesting the assignment by
Media Server resources and the establishment of a CFW control the MRB of suitable Media Server resources and the establishment
channel to one of the Media Servers; of a CFW Control Channel to one of the Media Servers;
d. IUMM - the client is requesting the establishment of a media d. IUMM/media dialog - the client is requesting the establishment of
dialog to a Media Server resource; a media dialog to a Media Server resource;
e. IUMM - the client is requesting the establishment of a CFW e. IUMM/Control Channel - the client is requesting the establishment
control channel to a Media Server resource. of a CFW Control Channel to a Media Server resource.
Each type of interaction has advantages and disadvantages, where such Each type of interaction has advantages and disadvantages, where such
considerations related to the versatility of what MRB can provide, considerations relate to the versatility of what the MRB can provide,
technical aspects such as efficiency in different application technical aspects such as efficiency in different application
scenarios, complexity, delay, use with legacy Application Servers, or scenarios, complexity, delay, use with legacy Application Servers, or
use with the Media Control Channel Framework. Depending on the use with the Media Control Channel Framework. Depending on the
characteristics of a particular setting that an MRB is intended to characteristics of a particular setting that an MRB is intended to
support, some of the above interaction types may be more appropriate support, some of the above interaction types may be more appropriate
than others. This section provides a few observations on relative than others. This section provides a few observations on relative
merits, but is not intended to be exhaustive. Some constraints of a merits but is not intended to be exhaustive. Some constraints of a
given interaction type may be subtle. given interaction type may be subtle.
o Operation with other types of media control: Any of the types of o Operation with other types of media control: Any of the types of
interactions work with the use RFC 4240 [RFC4240] and RFC 5552 interactions work with the mechanisms described in RFC 4240
[RFC5552] where initial control instructions are conveyed in the [RFC4240] and RFC 5552 [RFC5552] where initial control
SIP INVITE from the Application Server for the media dialog to the instructions are conveyed in the SIP INVITE from the Application
Media Server and subsequent instructions may be fetched using Server for the media dialog to the Media Server and subsequent
HTTP. Query mode (a), IAMM/media dialog (b) and IUMM/media dialog instructions may be fetched using HTTP. Query mode (a), IAMM/
(d) work with MSML as per RFC 5707 [RFC5707] or MSCML as per RFC media dialog (b), and IUMM/media dialog (d) work with the Media
5022 [RFC5022]. Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the
Media Server Control Markup Language (MSCML) as per RFC 5022
[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. When using IUMM the Application Server does Application Server. When using IUMM, the Application Server does
not specify the characteristics of the type of media resource it not specify the characteristics of the type of media resource it
requires as the <mediaResourceRequest> element is not passed to requires, as the <mediaResourceRequest> element is not passed to
the MRB. For IUMM media dialog (d), the MRB can deduce an the MRB. For IUMM/media dialog (d), the MRB can deduce an
appropriate media resource on a best effort basis using appropriate media resource on a best-effort basis using
information gleaned from examining information in the SIP INVITE. information gleaned from examining information in the SIP INVITE.
This includes the SDP information for the media dialog, or initial This includes the SDP information for the media dialog, or initial
control information in the SIP Request URI as per RFC 4240 control information in the SIP Request-URI as per RFC 4240
[RFC4240]. With IUMM/control channel (e) there is even less [RFC4240]. With IUMM/Control Channel (e), there is even less
information for the MRB to use. information for the MRB to use.
o If using IUMM/control channel (e), the subsequent sending of the o If using IUMM/Control Channel (e), the subsequent sending of the
media dialog to the media server should not be done using IUMM/ media dialog to the Media Server should not be done using IUMM/
media dialog. I.e., the SIP signalling to send the media dialog media dialog. That is, the SIP signaling to send the media dialog
to the selected media server must be directly between the to the selected Media Server must be directly between the
Application Server and that media server, and not through the MRB. Application Server and that Media Server, and not through the MRB.
Unless resources can be confidentially identified, the MRB could Unless resources can be confidentially identified, the MRB could
send the media dialog to a different Media Server. Likewise, if send the media dialog to a different Media Server. Likewise, if
using IUMM/media dialog (d), the subsequent establishment of a using IUMM/media dialog (d), the subsequent establishment of a
control channel should not be done with IUMM/control channel (e) Control Channel should not be done with IUMM/Control Channel (e)
unless definitive information is available. unless definitive information is available.
o Query mode (a) and IAMM/control channel (c) lend themselves to o Query mode (a) and IAMM/Control Channel (c) lend themselves to
requesting a pool of media resources (e.g., a number of IVR or requesting a pool of media resources (e.g., a number of IVR or
conferencing ports) in advance of use and retaining use over a conferencing ports) in advance of use and retaining use over a
period of time, independent of whether there are media dialogs to period of time, independent of whether there are media dialogs to
those resources at any given moment, whereas the other types of those resources at any given moment, whereas the other types of
interactions do not. Likewise for making a subsequent request to interactions do not. This also applies to making a subsequent
increase or decrease the amount of resources previously awarded. request to increase or decrease the amount of resources previously
awarded.
o While Query mode (a) and IAMM/control channel (c) are the most o While Query mode (a) and IAMM/Control Channel (c) are the most
versatile interaction types, the former is completely decoupled versatile interaction types, the former is completely decoupled
from the use or not of a control channel, whereas the latter from the use or non-use of a Control Channel, whereas the latter
requires the use of a control channel. requires the use of a Control Channel.
o When Media Control Channel Framework control channels are to be o When Media Control Channel Framework Control Channels are to be
used in conjunction with the use of MRB, Query mode (a) would used in conjunction with the use of an MRB, Query mode (a) would
typically result in fewer such channels being established over typically result in fewer such channels being established over
time as compared to IAMM/control channel (c). That is because the time, as compared to IAMM/Control Channel (c). That is because
latter would involve setting up an additional control channel the latter would involve setting up an additional Control Channel
every time an Application Server has a new request for MRB for every time an Application Server has a new request for an MRB for
media resources. media resources.
9. Examples 9. Examples
This section provides examples of both the Publish and Consumer This section provides examples of both the Publish and Consumer
interfaces. Both Query and Inline modes are addressed. interfaces. Both the Query mode and In-line mode are addressed.
Note that due to RFC formatting conventions, this section often Note that due to RFC formatting conventions, this section often
splits HTTP, SIP/SDP and CFW across lines whose content would exceed splits HTTP, SIP/SDP, and CFW across lines whose content would exceed
72 characters. A backslash character marks where this line folding 72 characters. A backslash character marks where this line folding
has taken place. This backslash and its trailing CRLF and whitespace has taken place. This backslash, and its trailing CRLF and
would not appear in the actual protocol contents. Besides, also note whitespace, would not appear in the actual protocol contents. Also
that the indentation of the XML content is only provided for note 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 that a Control Channel has been
and synced as described in the Media Control Channel Framework established and synced as described in the Media Control Channel
([RFC6230]). 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 Media Server (message A1.), and the Media for information at the Media Server (message A1.), and the Media
Server accepts the subscription (A2). Notifications are triggered by Server accepts the subscription (A2.). Notifications are triggered
the Media Server (A3.) and acknowledged by the MRB (A4.). by the Media Server (B1.) and acknowledged by the MRB (B2.).
MRB MS MRB MS
| | | |
| A1. CONTROL (MRB subscription) | | A1. CONTROL (MRB subscription) |
|--------------------------------------------->| |--------------------------------------------->|
| A2. 200 OK | | A2. 200 OK |
|<---------------------------------------------| |<---------------------------------------------|
| | | |
. . . .
. . . .
skipping to change at page 60, line 10 skipping to change at page 59, line 37
|--------------------------------------------->| |--------------------------------------------->|
| | | |
. . . .
. . . .
Figure 9: Publish Example: Sequence Diagram Figure 9: Publish Example: Sequence Diagram
The rest of this section includes a full dump of the messages The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically: associated with the previous sequence diagram, specifically:
1. the subscription (A1), in an <mrbrequest> (CFW CONTROL); 1. the subscription (A1.), in an <mrbrequest> (CFW CONTROL);
2. the Media Server accepting the subscription (A2), in an 2. the Media Server accepting the subscription (A2.), in an
<mrbresponse> (CFW 200); <mrbresponse> (CFW 200);
3. a notification (A3), in a <mrbnotification> (CFW CONTROL event); 3. a notification (B1.), in an <mrbnotification> (CFW CONTROL);
4. the ack to the notification (A4), in a framework level 200 4. the ack to the notification (B2.), in a framework-level 200
message (CFW 200); message (CFW 200).
A1. MRB -> MS (CONTROL, publish request) A1. MRB -> MS (CONTROL, publish request)
---------------------------------------- ----------------------------------------
CFW lidc30BZObiC CONTROL CFW lidc30BZObiC 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: 337 Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
skipping to change at page 64, line 32 skipping to change at page 64, line 19
<label>TestbedPrototype-01</label> <label>TestbedPrototype-01</label>
<media-server-address>sip:MS1@ms.example.net</media-server-address> <media-server-address>sip:MS1@ms.example.net</media-server-address>
<encryption/> <encryption/>
</mrbnotification> </mrbnotification>
</mrbpublish> </mrbpublish>
B2. MRB -> MS (200 to CONTROL) B2. MRB -> MS (200 to CONTROL)
------------------------------ ------------------------------
CFW 03fff52e7b7a 200 CFW 03fff52e7b7a 200
9.2. Consumer Example 9.2. Consumer Examples
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 In-line 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 In-line
mode, instead, messages are transported as part of SIP negotiations: aware mode, messages are instead transported as part of SIP
considering that SIP negotiations may be related to either the negotiations: considering that SIP negotiations may be related to
creation of a control channel or to a UAC media dialog, two separate either the creation of a Control Channel or to a User Agent Client
examples of such an approach are presented in Section 9.2.2. (UAC) media dialog, two separate 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 Application Server The following example assumes that the interested Application Server
already knows the HTTP URL where an MRB is listening for Consumer already knows the HTTP URL where an MRB is listening for Consumer
messages. messages.
Figure 10 shows the HTTP-based transaction between the Application Figure 10 shows the HTTP-based transaction between the Application
Server and the MRB. The Application Server sends a consumer request Server (AS, as shown in the figure) and the MRB. The Application
as payload of an HTTP POST message (1.), and the MRB provides an Server sends a Consumer request as payload of an HTTP POST message
answer in an HTTP 200 OK message (2.). Specifically, as it will be (1.), and the MRB provides an answer in an HTTP 200 OK message (2.).
shown in the examples, the Application Server is interested in 100 Specifically, as will be shown in the examples, the Application
IVR ports: the MRB finds two Media Servers that can satisfy the Server is interested in 100 IVR ports: the MRB finds two Media
request (one providing 60 ports, the other 40 ports) and reports them Servers that can satisfy the request (one providing 60 ports and the
to the Application Server. other providing 40 ports) and reports them to the Application Server.
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 65, line 37 skipping to change at page 65, line 39
|<-+ with first MS reported by MRB | |<-+ with first MS reported by MRB |
| | | |
. . . .
. . . .
Figure 10: Consumer Example (Query): Sequence Diagram Figure 10: Consumer Example (Query): Sequence Diagram
The rest of this section includes a full dump of the messages The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically: associated with the previous sequence diagram, specifically:
1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST, 1. the Consumer request (1.), in a <mediaResourceRequest> (HTTP
Content-Type 'application/mrb-consumer+xml'); POST, Content-Type 'application/mrb-consumer+xml');
2. the Consumer response (2), in an <mediaResourceResponse> (HTTP 2. the Consumer response (2.), in a <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: 893 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)
skipping to change at page 67, line 27 skipping to change at page 67, line 43
<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 example show, the request and response are associated by means As the example shows, the request and response are associated by
of the 'id' attribute (id="gh11x23v"). The MRB has picked '9' as the means of the 'id' attribute (id="gh11x23v"). The MRB has picked '9'
random sequence number that needs to be incremented by the as the random sequence number that needs to be incremented by the
Application Server for the following request associated with the same Application Server for the subsequent request associated with the
session. same session.
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 Application Server has the received the 'mediaResourceResponse', the Application Server has the
URIs of two Media Servers able to fulfil its media requirements, and URIs of two Media Servers able to fulfill its media requirements and
can start a Control Dialog with one or both of them. can start a control dialog with one or both of them.
9.2.2. IAMM Example 9.2.2. IAMM Examples
Two separate examples are presented for the IAMM case: in fact, IAMM- Two separate examples are presented for the IAMM case: in fact, IAMM
mode can take advantage of two different approaches with respect to can take advantage of two different approaches with respect to the
the SIP dialogs to be exploited to carry consumer messages, i.e.: i) SIP dialogs to be exploited to carry Consumer messages, i.e., i) a
a SIP control dialog to create a control channel, and, ii) a UAC SIP control dialog to create a Control Channel, and ii) a UAC media
media dialog to attach to a Media Server. To make things clearer for dialog to attach to a Media Server. To make things clearer for the
the reader, the same consumer request as the one presented in the reader, the same Consumer request as the one presented in the Query
Query mode will be sent, in order to clarify how the behaviour of the mode will be sent, in order to clarify how the behavior of the
involved parties may differ. 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 Application Server The following example assumes that the interested Application Server
already knows the SIP URI for an MRB. already knows the SIP URI of an MRB.
Figure 11 shows the first approach, i.e. SIP-based transactions Figure 11 shows the first approach, i.e., SIP-based transactions
between the Application Server, the MRB and one Media Server that the between the Application Server, the MRB, and one Media Server that
MRB chooses from the two that are allocated to fulfil the request. the MRB chooses from the two that are allocated to fulfill the
The diagram is more complex than before. This is basically a request. The diagram is more complex than before. This is basically
scenario envisaging the MRB as a B2BUA. The Application Server sends a scenario envisaging the MRB as a B2BUA. The Application Server
a SIP INVITE (1.), containing both a CFW-related SDP and a Consumer sends a SIP INVITE (1.) containing both a CFW-related SDP and a
request (multipart body). The MRB sends a provisional response to Consumer request (multipart body). The MRB sends a provisional
the Application Server (2.) and starts working on the request. First response to the Application Server (2.) and starts working on the
of all, it makes use of the Consumer request from the Application request. First of all, it makes use of the Consumer request from the
Server to determine which Media Servers should be exploited. Once Application Server to determine which Media Servers should be
the right Media Servers have been chosen (MS1 and MS2 in the exploited. Once the right Media Servers have been chosen (MS1 and
example), the MRB sends a new SIP INVITE to one of the Media Servers MS2 in the example), the MRB sends a new SIP INVITE (3.) to one of
(MS1 in the example) by just including the SDP part of the original the Media Servers (MS1 in the example) by just including the SDP part
request (3.). That Media Server negotiates this INVITE as specified of the original request. That Media Server negotiates this INVITE as
in [RFC6230] (4., 5., 6.), providing the MRB with its own CFW-related specified in [RFC6230] (4., 5., 6.), providing the MRB with its own
SDP. The MRB replies to the original Application Server INVITE CFW-related SDP. The MRB replies to the original Application Server
preparing a SIP 200 OK with another multipart body (7.): this INVITE preparing a SIP 200 OK with another multipart body (7.): this
multipart body includes the Consumer response used by the MRB to multipart body includes the Consumer response used by the MRB to
determine the right Media Servers and the SDP returned by the Media determine the right Media Servers and the SDP returned by the Media
Server (MS1) in 5. The Application Server finally acknowledges the Server (MS1) in (5.). The Application Server finally acknowledges
200 OK (8.), and can start a CFW connection towards that Media Server the 200 OK (8.), and can start a CFW connection towards that Media
(MS1). Since the MRB provided the Application Server with two Media Server (MS1). Since the MRB provided the Application Server with two
Server instances to fulfil its requirements, the Application Server Media Server instances to fulfill its requirements, the Application
can use the URI in the <media-server-address> element in the Server can use the URI in the <media-server-address> element in the
<mediaResourceResponse> that describes the other Media Server to <mediaResourceResponse> that describes the other Media Server to
establish a CFW channel with that Media Server (MS2) as well. establish a CFW channel with that Media Server (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 MS1 MS2 AS MRB MS1 MS2
| | | | | | | |
| 1. INVITE | | | | 1. INVITE | | |
| (multipart/mixed) | | | | (multipart/mixed) | | |
|---------------------->| | | |---------------------->| | |
| 2. 100 (Trying) | | | | 2. 100 (Trying) | | |
skipping to change at page 69, line 46 skipping to change at page 70, line 12
|-------------------------------------------------->| | |-------------------------------------------------->| |
| | | | | |
|<<############## TCP CONNECTION #################>>| | |<<############## TCP CONNECTION #################>>| |
| | | | | |
| CFW SYNC | | | CFW SYNC | |
|++++++++++++++++++++++++++++++++++++++++++++++++++>| | |++++++++++++++++++++++++++++++++++++++++++++++++++>| |
| | | | | |
. . . . . . . .
. . . . . . . .
| | | | | |
| Negotiate SIP Control Dialog with MS2 | | Negotiate SIP control dialog with MS2 |
|<------------------------------------------------------------------>| |<------------------------------------------------------------------>|
| Create TCP CFW channel towards MS2 as well (if needed) | | Create TCP CFW channel towards MS2 as well (if needed) |
|------------------------------------------------------------------->| |------------------------------------------------------------------->|
| | | |
|<<######################## TCP CONNECTION ########################>>| |<<######################## TCP CONNECTION ########################>>|
| | | |
| CFW SYNC | | CFW SYNC |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>| |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | |
| | | | | | | |
. . . . . . . .
. . . . . . . .
Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram
The rest of this section includes an almost full trace of the The rest of this section includes an almost full trace of the
messages associated with the previous sequence diagram. Only the messages associated with the previous sequence diagram. Only the
relevant SIP messages are shown (both the INVITEs and the 200 OKs), relevant SIP messages are shown (both the INVITEs and the 200 OKs),
and only the relevant headers are preserved for brevity (Content-Type and only the relevant headers are preserved for brevity (Content-Type
and multipart-related information). Specifically: and 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
(COMEDIA information to negotiate a new Control Channel) and a (Connection-Oriented Media (COMEDIA) information to negotiate a
Consumer <mediaResourceRequest>; new Control Channel) and a Consumer <mediaResourceRequest>;
2. the INVITE sent by the MRB to the Media Server as a B2BUA (3.), 2. the INVITE sent by the MRB (acting as a B2BUA) to the Media
containing only the CFW-related SDP from the original INVITE;. Server (3.), containing only the CFW-related SDP from the
original INVITE;
3. the 200 OK sent by the Media Server back to the MRB (5.), to 3. the 200 OK sent by the Media Server back to the MRB (5.) to
complete the CFW-related negotiation (SDP only); complete the CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the Application Server in 4. the 200 OK sent by the MRB back to the Application Server in
response to the original INVITE (7.), containing both the CFW- response to the original INVITE (7.), containing both the
related information sent by the Media Server and a Consumer CFW-related information sent by the Media Server and a Consumer
<mediaResourceRequest> documenting the MRB's decision to use that <mediaResourceRequest> documenting the MRB's decision to use that
Media Server. Media Server.
1. AS -> MRB (INVITE multipart/mixed) 1. AS -> MRB (INVITE multipart/mixed)
------------------------------------- -------------------------------------
[..] [..]
Content-Type: multipart/mixed;boundary="=_Part" Content-Type: multipart/mixed;boundary="=_Part"
=_Part =_Part
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 73, line 49 skipping to change at page 74, line 16
</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 the previous example illustrates, the only difference in the As the previous example illustrates, the only difference in the
response the MRB provides the Application Server with is in the response that the MRB provides to the Application Server is in the
'connection-id' attribute that is added to the first allocated Media 'connection-id' attribute that is added to the first allocated Media
Server instance: this allows the Application Server to understand the Server instance: this allows the Application Server to understand
MRB has sent the CFW channel negotiation to that specific Media that the MRB has sent the CFW channel negotiation to that specific
Server, and that the connection-id to be used is the one provided. Media Server and that the connection-id to be used is the one
This will be described in more detail in the following section, for provided. This will be described in more detail in the following
the media dialog-based approach. section for the media dialog-based approach.
The continuation of the scenario (the Application Server connecting The continuation of the scenario (the Application Server connecting
to MS1 to start the Control Channel and the related SYNC message, the to MS1 to start the Control Channel and the related SYNC message, the
Application Server connecting to MS2 as well later on, all the media Application Server connecting to MS2 as well later on, all the media
dialogs being attached to either Media Server) are omitted for dialogs being attached to either Media Server) is omitted for
brevity. brevity.
9.2.2.2. IAMM Example: Media dialog-based approach 9.2.2.2. IAMM Example: Media Dialog-Based Approach
The following example assumes the interested Application Server The following example assumes that the interested Application Server
already knows the SIP URI of an MRB. already knows the SIP URI of an MRB.
Figure 12 shows the second approach, i.e. SIP-based transactions Figure 12 shows the second approach, i.e., SIP-based transactions
between a SIP client, the Application Server, the MRB and the Media between a SIP client, the Application Server, the MRB, and the Media
Server that the MRB chooses. The interaction is basically the same Server that the MRB chooses. The interaction is basically the same
as previous examples (e.g. contents of the multipart body) but as previous examples (e.g., contents of the multipart body), but
considering a new party is involved in the communication, the diagram considering that a new party is involved in the communication, the
is slightly more complex than before. As before, the MRB acts as a diagram is slightly more complex than before. As before, the MRB
B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the acts as a B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by
Application Server, since it is interested to its services (1.). The the Application Server, since it is interested to its services (1.).
Application Server sends a provisional response (2.) and, since it The Application Server sends a provisional response (2.) and, since
doesn't have the resources yet, sends to the MRB a new SIP INVITE it doesn't have the resources yet, sends to the MRB a new SIP INVITE
(3.), containing both the UAC media-related SDP and a Consumer (3.) containing both the UAC media-related SDP and a Consumer request
request (multipart body). The MRB sends a provisional response to (multipart body). The MRB sends a provisional response to the
the Application Server (4.) and starts working on the request. First Application Server (4.) and starts working on the request. First of
of all, it makes use of the Consumer request from the Application all, it makes use of the Consumer request from the Application Server
Server to determine which Media Servers should be chosen. Once the to determine which Media Servers should be chosen. Once the Media
Media Server has been chosen, the MRB sends a new SIP INVITE to one Server has been chosen, the MRB sends a new SIP INVITE to one of the
of the Media Servers by including the SDP part of the original Media Servers by including the SDP part of the original request (5.).
request (5.). The Media Server negotiates this INVITE as specified
in [RFC6230] (6., 7., 8.) to allocate the needed media resources to The Media Server negotiates this INVITE as specified in [RFC6230]
handle the new media dialog, eventually providing the MRB with its (6., 7., 8.) to allocate the needed media resources to handle the new
own media-related SDP. The MRB replies to the original Application media dialog, eventually providing the MRB with its own media-related
Server INVITE preparing a SIP 200 OK with a multipart body (9.): this SDP. The MRB replies to the original Application Server INVITE
multipart body includes the Consumer response from the MRB indicating preparing a SIP 200 OK with a multipart body (9.): this multipart
the chosen Media Servers and the SDP returned by the Media Server in body includes the Consumer response from the MRB indicating the
7. The Application Server finally acknowledges the 200 OK (10.), and chosen Media Servers and the SDP returned by the Media Server in
ends the scenario by eventually providing the UAC with the SDP it (7.). The Application Server finally acknowledges the 200 OK (10.)
needs to set-up the RTP channels with the chosen Media Server: a and ends the scenario by eventually providing the UAC with the SDP it
needs to set up the RTP channels with the chosen Media Server: a
separate direct SIP control dialog may be initiated by the separate direct SIP control dialog may be initiated by the
Application Server to the same Media Server in order to set up a Application Server to the same Media Server in order to set up a
control channel to manipulate the media dialog media. Control Channel to manipulate the media dialog.
As with the IAMM - CFW example in the prior section, this example has As with the IAMM/Control Channel example in the prior section, this
the MRB selecting Media Server resources across two Media Server example has the MRB selecting Media Server resources across two Media
instances. The convention could be that the MRB sent the SIP INVITE Server instances. The convention could be that the MRB sent the SIP
to the first Media Server in the list provided to the Application INVITE to the first Media Server in the list provided to the
Server in the Consumer response information. For the sake of Application Server in the Consumer response information. For the
brevity, the considerations about connecting to the other Media sake of brevity, considerations related to connecting to the other
Servers as well are omitted, since they have already been addressed Media Servers as well are omitted, since they have already been
in the previous section. 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) | | |
|-------------->| | | |-------------->| | |
| 2. 100 Trying | | | | 2. 100 Trying | | |
skipping to change at page 76, line 42 skipping to change at page 77, line 26
| |-------------------------------------------------->| | |-------------------------------------------------->|
| | | | | |
| |<<############## TCP CONNECTION #################>>| | |<<############## TCP CONNECTION #################>>|
| | | | | |
| | CFW SYNC | | | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>| | |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | | | |
. . . . . . . .
. . . . . . . .
Figure 12: Consumer Example (IAMM-MediaDialog): Sequence Diagram Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram
The rest of this section includes an trace of the messages associated The rest of this section includes a trace of the messages associated
with the previous sequence diagram. Only the relevant SIP messages with the previous sequence diagram. Only the relevant SIP messages
are shown (both the INVITEs and the 200 OKs), and only the relevant are shown (both the INVITEs and the 200 OKs), and only the relevant
headers are preserved for brevity (Content-Type, From/To and headers are preserved for brevity (Content-Type, From/To, and
multipart-related information). Specifically: multipart-related information). Specifically:
1. the original INVITE (1), containing the media-related SDP sent by 1. the original INVITE (1.) containing the media-related SDP sent by
a UAC; a UAC;
2. the original INVITE (3), containing both the media-related SDP 2. the INVITE sent by the AS to the MRB (3.), containing both the
and a Consumer <mediaResourceRequest>; media-related SDP and a Consumer <mediaResourceRequest>;
3. the INVITE sent by the MRB to the Media Server as a B2BUA (5.), 3. the INVITE sent by the MRB (acting as a B2BUA) to the Media
containing only the media-related SDP from the original INVITE; Server (5.), containing only the media-related SDP from the
original INVITE;
4. the 200 OK sent by the Media Server back to the MRB (7.), to 4. the 200 OK sent by the Media Server back to the MRB (7.) to
complete the media-related negotiation (SDP only); complete the media-related negotiation (SDP only);
5. the 200 OK sent by the MRB back to the Application Server in 5. the 200 OK sent by the MRB back to the Application Server in
response to the original INVITE (9.), containing both the media- response to the original INVITE (9.), containing both the
related information sent by the Media Server and a Consumer media-related information sent by the Media Server and a Consumer
<mediaResourceRequest> documenting the MRB's decision to use that <mediaResourceRequest> documenting the MRB's decision to use that
Media Server; Media Server;
6. the 200 OK sent by the Application Server back to the UAC to have 6. the 200 OK sent by the Application Server back to the UAC to have
it set-up the RTP channel(s) with the Media Server (11.). it set up the RTP channel(s) with the Media Server (11.).
1. UAC -> AS (INVITE with media SDP) 1. UAC -> AS (INVITE with media SDP)
------------------------------------ ------------------------------------
[..] [..]
From: <sip:lminiero@users.example.com>;tag=1153573888 From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
skipping to change at page 82, line 13 skipping to change at page 82, line 49
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 the examples illustrate, as in the IAMM-CFW example, the MRB As the examples illustrate, as in the IAMM/Control Channel example,
provides the Application Server with a 'media-server-address' element the MRB provides the Application Server with a <media-server-address>
in the consumer response: the 'uri' attribute identifies the specific element in the Consumer response: the 'uri' attribute identifies the
Media Server to which the MRB has sent the SDP media negotiation, and specific Media Server to which the MRB has sent the SDP media
the 'connection-id' enables the Application Server to identify to the negotiation, and the 'connection-id' enables the Application Server
Media Server the dialog between the MRB and Media Server. This to identify to the Media Server the dialog between the MRB and Media
attribute is needed, since, according to the framework specification, Server. This attribute is needed, since according to the framework
the connection-id is built out of the From/To tags of the dialog specification [RFC6230] the connection-id is built out of the From/To
between the MRB and Media Server; since the MRB acts as a B2BUA in tags of the dialog between the MRB and Media Server; since the MRB
this scenario, without that attribute the Application Server does not acts as a B2BUA in this scenario, without that attribute the
know the relevant tags, thus preventing the CFW protocol to work as Application Server does not know the relevant tags, thus preventing
expected. the CFW protocol from working as expected.
The continuation of the scenario (the Application Server connecting The continuation of the scenario (the Application Server connecting
to the Media Server to start the Control Channel, the SYNC message, to the Media Server to start the Control Channel, the SYNC message,
etc.) are omitted for brevity. etc.) is omitted for 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
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
mrb-publish+xml" format. "application/mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish" xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation> <xsd:annotation>
skipping to change at page 83, line 37 skipping to change at page 84, line 4
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<!-- <!--
############################################################# #############################################################
SCHEMA IMPORTS SCHEMA IMPORTS
############################################################# #############################################################
--> -->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"> schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the XML attributes for This import brings in the XML attributes for
xml:base, xml:lang, etc xml:base, xml:lang, etc.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<xsd:import <xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes" namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd"> schemaLocation="framework.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the framework attributes for This import brings in the framework attributes for
conferenceid and connectionid. conferenceid and connectionid.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<xsd:import <xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd"> schemaLocation="civicAddress.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the civicAddress specification This import brings in the civicAddress specification
from RFC5139. from RFC 5139.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<!-- <!--
##################################################### #####################################################
Extensible core type Extensible core type
##################################################### #####################################################
--> -->
<xsd:complexType name="Tcore"> <xsd:complexType name="Tcore">
skipping to change at page 84, line 45 skipping to change at page 85, line 11
allow attributes from other namespaces. allow attributes from other namespaces.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence/> <xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType> </xsd:complexType>
<!-- <!--
##################################################### #####################################################
TOP LEVEL ELEMENT: mrbpublish TOP-LEVEL ELEMENT: mrbpublish
##################################################### #####################################################
--> -->
<xsd:complexType name="mrbpublishType"> <xsd:complexType name="mrbpublishType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice> <xsd:choice>
<xsd:element ref="mrbrequest" /> <xsd:element ref="mrbrequest" />
skipping to change at page 105, line 6 skipping to change at page 106, line 4
<xsd:simpleType name="label.datatype"> <xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype"> <xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 13
11. Media Service Resource Consumer Interface XML Schema 11. Media Service Resource Consumer Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
mrb-consumer+xml" format. "application/mrb-consumer+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
skipping to change at page 106, line 42 skipping to change at page 106, line 41
SCHEMA IMPORTS SCHEMA IMPORTS
############################################################# #############################################################
--> -->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"> schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the XML attributes for This import brings in the XML attributes for
xml:base, xml:lang, etc xml:base, xml:lang, etc.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<xsd:import <xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd"> schemaLocation="civicAddress.xsd">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This import brings in the civicAddress specification This import brings in the civicAddress specification
from RFC5139. from RFC 5139.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:import> </xsd:import>
<!-- <!--
##################################################### #####################################################
Extensible core type Extensible core type
##################################################### #####################################################
--> -->
<xsd:complexType name="Tcore"> <xsd:complexType name="Tcore">
skipping to change at page 107, line 33 skipping to change at page 107, line 32
allow attributes from other namespaces. allow attributes from other namespaces.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence/> <xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType> </xsd:complexType>
<!-- <!--
##################################################### #####################################################
TOP LEVEL ELEMENT: mrbconsumer TOP-LEVEL ELEMENT: mrbconsumer
##################################################### #####################################################
--> -->
<xsd:complexType name="mrbconsumerType"> <xsd:complexType name="mrbconsumerType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice> <xsd:choice>
<xsd:element ref="mediaResourceRequest" /> <xsd:element ref="mediaResourceRequest" />
skipping to change at page 108, line 20 skipping to change at page 108, line 19
<xsd:element name="mrbconsumer" type="mrbconsumerType" /> <xsd:element name="mrbconsumer" type="mrbconsumerType" />
<!-- <!--
##################################################### #####################################################
mediaResourceRequest TYPE mediaResourceRequest TYPE
##################################################### #####################################################
--> -->
<!-- mediaResourceRequst --> <!-- mediaResourceRequest -->
<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" />
skipping to change at page 122, line 12 skipping to change at page 122, line 31
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger" <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" /> use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="max-time" type="max-timeType" /> <xsd:element name="max-time" type="max-timeType" />
<!-- stream-mode --> <!-- file-transfer-modes -->
<xsd:complexType name="file-transfer-modesType"> <xsd:complexType name="file-transfer-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="file-transfer-mode" <xsd:element ref="file-transfer-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>
skipping to change at page 126, line 28 skipping to change at page 127, line 4
<xsd:simpleType name="vxml.datatype"> <xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"/> <xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:string" /> <xsd:restriction base="xsd:string" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
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 [RFC6230] as a mechanism to uses the Media Control Channel Framework [RFC6230] as a mechanism to
connect an MRB to a media server. It is very important that the connect an MRB to a Media Server. It is very important that the
communication between the MRB and the Media Server is secured: a communication between the MRB and the Media Server is secured: a
malicious entity, may change or even delete subscriptions to a Media malicious entity may change or even delete subscriptions to a Media
Server, thus affecting the view the MRB has of the resources actually Server, thus affecting the view the MRB has of the resources actually
available on a Media Server, leading it to incorrect selection when available on a Media Server, leading it to incorrect selection when
media resources are being requested by an Application Server. A media resources are being requested by an Application Server. A
malicious entity may even manipulate resources availability on a malicious entity may even manipulate available resources on a Media
Media Server, for example, to make the MRB think no resources are Server, for example, to make the MRB think no resources are available
available at all. Considering the Publish interface is a CFW Control at all. Considering that the Publish interface is a CFW Control
Package, the same Security Considerations included in the Media Package, the same security considerations included in the Media
Control Channel Framework specification apply here to protect Control Channel Framework specification apply here to protect
interactions between an MRB and a Media Server. interactions between an MRB and a Media Server.
The Publish interface also allows a Media Server, as explained in The Publish interface also allows a Media Server, as explained in
Section Section 5.1.5.18, to provide more or less accurate Section 5.1.5.18, to provide more or less accurate information about
information about its geographic location, should Application Servers its geographic location, should Application Servers be interested in
be interested in such kind of details when looking for services at a such details when looking for services at an MRB. While the usage of
Media Resource Broker. While the usage of this information is this information is entirely optional and the level of detail to be
entirely optional and the level of detail to be provided provided is implementation specific, it is important to draw
implementation specific, it is important to draw the attention on the attention to the potential security issues that the disclosure of
potential security issues that the disclosure of such addresses may such addresses may introduce. As such, it is important to make sure
introduce. As such, it is important to make sure MRB implementations MRB implementations don't disclose this information as is to
don't disclose this information as is to interested Application interested Application Servers but only exploit those addresses as
Servers, but only exploit those addresses as part of computation part of computation algorithms to pick the most adequate resources
algorithms to pick the most adequate resources Application Servers Application Servers may be looking for.
may be looking for.
The Consumer interface, as defined in and described in Section 5.2, The Consumer interface, as defined in and described in Section 5.2,
conceives transactions based on a session ID. These transactions may conceives transactions based on a session ID. These transactions may
be transported either by means of HTTP messages, or SIP dialogs. be transported either by means of HTTP messages or SIP dialogs. This
This means that malicious users could be able to disrupt or means that malicious users could be able to disrupt or manipulate an
manipulate an MRB session should they have access to the above MRB session should they have access to the above-mentioned session ID
mentioned session ID or replicate it somehow: for instance, a or replicate it somehow: for instance, a malicious entity could
malicious entity could modify an existing session between an modify an existing session between an Application Server and the MRB,
Application Server and the MRB, e.g., requesting less resources than e.g., requesting less resources than originally requested to cause
originally requested to cause media dialogs to be rejected by the media dialogs to be rejected by the Application Server, or requesting
Application Server, or requesting many more resources instead to try many more resources instead to try and lock as many of (if not all)
and lock as many of (if not all) the resources a MRB can provide, the resources an MRB can provide, thus making them unavailable to
thus making them unavailable to other legitimate Application Servers other legitimate Application Servers in subsequent requests. In
in subsequent requests. In order to prevent this, it is strongly order to prevent this, it is strongly advised that MRB
adviced for MRB implementations to generate very hard to replicate implementations generate session identifiers that are very hard to
session identifiers, in order to minimize the chances malicious users replicate, in order to minimize the chances that malicious users
could gain access to valid ones just guessing or by means of brute could gain access to valid identifiers by just guessing or by means
force attacks. It is very important, of course, to also secure the of brute-force attacks. It is very important, of course, to also
way these identifiers are transported by the involved parties, both secure the way that these identifiers are transported by the involved
in requests and responses, in order to prevent network attackers from parties, in both requests and responses, in order to prevent network
intercepting Consumer messages and have access to session IDs. The attackers from intercepting Consumer messages and having access to
Consumer interface uses either the Hypertext Transfer Protocol (HTTP) session IDs. The Consumer interface uses either the Hypertext
or Session Initiation Protocol (SIP) as the mechanism for clients to Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) as
connect to an MRB to request media resources. In the case of the the mechanism for clients to connect to an MRB to request media
HTTP use, any binding using the Consumer interface MUST be capable of resources. In the case where HTTP is used, any binding using the
being transacted over TLS, as described in RFC 2818 [RFC2818]. In Consumer interface MUST be capable of being transacted over Transport
the case of the SIP use, the same security considerations included in Layer Security (TLS), as described in RFC 2818 [RFC2818]. In the
case where SIP is used, the same security considerations included in
the Media Control Channel Framework specification apply here to the Media Control Channel Framework specification apply here to
protect interactions between a client requesting media resources and protect interactions between a client requesting media resources and
an MRB. an MRB.
Should a valid session ID be compromised somehow (that is, Should a valid session ID be compromised somehow (that is,
intercepted or just guessed by a malicious user), as a further means intercepted or just guessed by a malicious user), as a further means
to prevent disruption, the Consumer interface also prescribes the use to prevent disruption the Consumer interface also prescribes the use
of a sequence number in its transactions. This sequence number is to of a sequence number in its transactions. This sequence number is to
be increased after each successful transaction, starting from a first be increased after each successful transaction, starting from a first
value randomly generated by the MRB when the session is first value randomly generated by the MRB when the session is first
created, and must match in every request/response. While this adds created, and it must match in every request/response. While this
complexity to the protocol (implementations must pay attention to adds complexity to the protocol (implementations must pay attention
those sequence numbers, since wrong values will cause "Wrong sequence to those sequence numbers, since wrong values will cause "Wrong
number" errors and the failure of the related requests), it is an sequence number" errors and the failure of the related requests), it
important added value for security. In fact, considering different is an important added value for security. In fact, considering that
transaction related to the same session could be transported in different transactions related to the same session could be
different, unrelated HTTP messages (or SIP INVITEs in case the Inline transported in different, unrelated HTTP messages (or SIP INVITEs in
mode is being used), this sequence number protection prevents the cases where the In-line mode is being used), this sequence number
chances of session replication or disruption, especially in cases protection prevents the chances of session replication or disruption,
where the session ID has been compromised: that is, it should make it especially in cases where the session ID has been compromised: that
harder for malicious users to manipulate or remove a session for is, it should make it harder for malicious users to manipulate or
which they have obtained the Session ID. It is strongly advised that remove a session for which they have obtained the session ID. It is
MRB doesn't choose 1 as the first sequence number for a new session, strongly advised that the MRB doesn't choose 1 as the first sequence
but rather pick a random value to start from. The reaction to out of number for a new session but rather picks a random value to start
sequence transactions is left to MRB implementations: a related error from. The reaction to transactions that are out of sequence is left
code is available, but implementations may decide to enforce further to MRB implementations: a related error code is available, but
limitations or actions upon the receival of too many failed attempts implementations may decide to enforce further limitations or actions
in a row, or of what looks like blatant attempts to guess what the upon the receipt of too many failed attempts in a row or of what
current, valid sequence number is. looks like blatant attempts to guess what the current, valid sequence
number is.
It is also worth noting that in In-line mode (both IAMM and IUMM) the It is also worth noting that in In-line mode (both IAMM and IUMM) the
MRB may act as a Back-to-Back User Agent (B2BUA). This means that, MRB may act as a Back-to-Back User Agent (B2BUA). This means that
as a B2BUA, the MRB may modify SIP bodies: it is the case, for when acting as a B2BUA the MRB may modify SIP bodies: it is the case,
instance, of the IAMM handling multipart/mixed payloads. This for instance, for the IAMM handling multipart/mixed payloads. This
impacts the ability to use any SIP security feature that protects the impacts the ability to use any SIP security feature that protects the
body (e.g., RFC4474, s/mime, etc.) unless the MRB intermediates the body (e.g., RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as
security association. This should be taken into account when a mediator for the security association. This should be taken into
implementing an MRB compliant with this specification. account when implementing an MRB compliant with this specification.
Both the Publishing and Consumer interface may address the location Both the Publishing interface and Consumer interface may address the
of a Media Server: the Publishing interface may be used to inform the location of a Media Server: the Publishing interface may be used to
MRB where a Media Server is located (approximately or precisely), and inform the MRB where a Media Server is located (approximately or
the Consumer interface to ask for a Media Server located somewhere in precisely), and the Consumer interface may be used to ask for a Media
particular region (e.g., a conference bridge close to San Francisco). Server located somewhere in a particular region (e.g., a conference
Both Media Server and MRB implementors need to take this into account bridge close to San Francisco). Both Media Server and MRB
when deciding whether or not make this location information implementers need to take this into account when deciding whether or
available, and if so how much bits of information really need to be not to make this location information available, and if so how many
made available for brokering purposes. bits of information really need to be made available for brokering
purposes.
It is worthwhile covering authorization issues related to this It is worthwhile to cover authorization issues related to this
specification. Neither the Publishing or the Consumer interface specification. Neither the Publishing interface nor the Consumer
provide an explicit means for implementing authentication, i.e., they interface provides an explicit means for implementing authentication,
do not contain specific protocol interactions to ensure that i.e., they do not contain specific protocol interactions to ensure
authorized Application Servers can make use of the services provided that authorized Application Servers can make use of the services
by an MRB instance. Considering both the interfaces are transported provided by an MRB instance. Considering that both interfaces are
using well-established protocols (HTTP, SIP, CFW), support for such transported using well-established protocols (HTTP, SIP, CFW),
functionality can be expressed by means of the authentication support for such functionality can be expressed by means of the
mechanisms provided by the protocol themselves. Therefore, any MRB- authentication mechanisms provided by the protocols themselves.
aware entity (Application Servers, Media Servers, Media Resource Therefore, any MRB-aware entity (Application Servers, Media Servers,
Brokers themselves) MUST support the HTTP and SIP Digest access MRBs themselves) MUST support HTTP and SIP Digest access
authentication. The usage of such Digest access authentications is authentication. The usage of such Digest access authentications is
recommended and not mandatory, which means MRB-aware entities MAY recommended and not mandatory, which means MRB-aware entities MAY
exploit it in deployment. exploit it in deployment.
An MRB may want to enforce further constraints on the interactions An MRB may want to enforce further constraints on the interactions
between an Application Server/Media Server and an MRB. For example, between an Application Server/Media Server and an MRB. For example,
it may choose to only accept requests associated with a specific it may choose to only accept requests associated with a specific
session ID from the IP address that originated the first request, or session ID from the IP address that originated the first request or
just make use of pre-shared certificates to assess the identity of may just make use of pre-shared certificates to assess the identity
legitimate Application Server and/or Media Server. of legitimate Application Servers and/or Media Servers.
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. Media Control Channel Framework 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 [RFC6230]. per the instructions in Section 13.1 of [RFC6230].
Package Name: mrb-publish/1.0 Package Name: mrb-publish/1.0
Published Specification(s): RFCXXXX Published Specification(s): RFC 6917
Person and email address to contact for further information: IETF, Person and email address to contact for further information: IETF
MEDIACTRL working group, (mediactrl@ietf.org), Chris Boulton MediaCtrl working group (mediactrl@ietf.org), Chris Boulton
(chris@ns-technologies.com). [NOTE TO IANA/RFC-EDITOR: Please (chris@ns-technologies.com).
replace XXXX with the RFC number for this specification.]
13.2. application/mrb-publish+xml Media Type 13.2. application/mrb-publish+xml Media Type
To: application To: application
Subject: Registration of media type application/mrb-publish+xml Subject: Registration of media type application/mrb-publish+xml
Type name: application Type name: application
Subtype name: mrb-publish+xml Subtype name: mrb-publish+xml
Required parameters: none Required parameters: none
Optional parameters: Same as charset parameter of application/xml Optional parameters: Same as charset parameter of application/xml as
as specified in RFC 3023 [RFC3023]. 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 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFC 6917.
XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: Section 10 of RFCXXXX [[NOTE TO RFC- Published specification: Section 10 of RFC 6917.
EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]].
Applications which use this media type: This media type is used to Applications that use this media type: This media type is used to
support a Media Resource Broker (MRB) entity. 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 Person and email address to contact for further information: Chris
<chris at ns-technologies.com> Boulton (chris@ns-technologies.com).
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.3. application/mrb-consumer+xml Media Type 13.3. application/mrb-consumer+xml Media Type
To: application To: application
Subject: Registration of media type application/mrb-consumer+xml Subject: Registration of media type application/mrb-consumer+xml
Type name: application Type name: application
Subtype name: mrb-consumer+xml Subtype name: mrb-consumer+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter of application/xml Optional parameters: Same as charset parameter of application/xml as
as specified in RFC 3023 [RFC3023]. 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 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFC 6917.
XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: Section 11 of RFCXXXX [[NOTE TO RFC- Published specification: Section 11 of RFC 6917.
EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]].
Applications which use this media type: This media type is used to Applications that use this media type: This media type is used to
support a Media Resource Broker (MRB) entity. 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 Person and email address to contact for further information: Chris
<chris at ns-technologies.com> Boulton (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 "urn:ietf:params:xml:ns:mrb-publish", with IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish",
the ID of "mrb-publish". The schema of the XML namespace named with the ID of "mrb-publish". The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-publish" is Section 10. urn:ietf:params:xml:ns:mrb-publish is in Section 10.
13.5. URN Sub-Namespace Registration for mrb-consumer 13.5. URN Sub-Namespace Registration for mrb-consumer
Please register the URN "urn:ietf:params:xml:ns:mrb-consumer", with IANA has registered the URN "urn:ietf:params:xml:ns:mrb-consumer",
the ID of "mrb-consumer". The schema of the XML namespace named with the ID of "mrb-consumer". The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-consumer" is in Section 11. 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: IANA has registered the schema for mrb-publish:
URI: urn:ietf:params:xml:schema:mrb-publish URI: urn:ietf:params:xml:schema:mrb-publish
ID: mrb-publish ID: mrb-publish
Filename: mrb-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:schema:mrb-consumer URI: urn:ietf:params:xml:schema:mrb-consumer
ID: mrb-consumer ID: mrb-consumer
Filename: mrb-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
Note to RFC Editor: Please remove this whole section.
14.1. Changes from 13 Version
o Clarified text for offer-less INVITE.
o General review of text.
14.2. Changes from 12 Version
o Several changes and clarifications according to the AD review by
Robert Sparks.
o Updated reference for mixer draft (RFC6505).
14.3. Changes from 11 Version
o Fixed a wrong reference to RFC5707 (because of a typo this was
RFC5705).
o Changed the registration in 13.1 to match the template required by
RFC6230.
o Fixed the incorrect URIs for registering the schemas in Sections
13.6 and 13.7.
o Removed enumeration types for 'dtmf-type', 'vxml-mode' and
'stream-mode' from both the schemas to allow for better
extensibility, and clarified values are case insensitive where
needed.
o Clarified that the use of the civic location of a media server is
entirely optional, and it's implementation specific to fill it
with just the details each implementor deems necessary for any
optimization that may be needed.
14.4. 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.5. Changes from 09 Version
o Language changes as a result of Shepherd review.
14.6. Changes from 08 Version
o Fixed Nits.
o Added range for reporting period - as per mailing list.
14.7. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests;
o Fixed a few typos in the text.
o Clarified language in various places.
o Added 'Multi-modal MRB Implementations' section.
o Added 'Relative Merits of Query Mode, IAMM, and IUMM' section.
o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow
multiples.
o New B2BUA section.
o Updated Examples.
14.8. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed.
o Fixed a few typos in the text.
14.9. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined
layouts or others.
o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas.
14.10. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions.
o Clarified that 'response-session-info' is not only included in
reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any
error).
o Corrected the Query example flow which included a 'session'info'
in a new request.
14.11. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are
only provided for readability.
o Clarified the distinction between 'deactivated' and 'unavailable'.
o Added text to the status codes in both Publish and Consumer
responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the
Consumer interface.
o Added additional IANA considerations, that were missing in the
previous versions of the document.
o Added text to the security considerations.
14.12. Changes from 02 Version
o Added examples in Section 9.
o Fixed some nits in the schemas (encryption and required mixed=true
elements).
o Completed review nit review comments from Gary Munson.
14.13. Changes from 01 Version
o Added description of lease mechanism.
o Added specific HTTP and SIP usage of Consumer interface.
o Completed Publish interface schema + associated text.
o Included Consumer interface schema + associated text.
o Included supported-packages element.
o Removed announce-var element from doc.
o Expanded Abstract.
o General scrub of text - input from Simon Romano.
o Added IANA Considerations section.
o Added Security Considerations section.
14.14. Changes from 00 Version
o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team
work.
15. Acknowledgements 14. Acknowledgements
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team, who provided valuable input into this document. The
design team consisted of Adnan Saleem, Michael Trank, Victor design team consisted of Adnan Saleem, Michael Trank, Victor
Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also
like to thank John Dally, Bob Epley, Simon Romano, Henry Lum, like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
Christian Groves and Jonathan Lennox for input into this Christian Groves, and Jonathan Lennox for input into this
specification. specification.
Ben Campbell carried out the RAI expert review on the -03 Ben Campbell carried out the RAI expert review on an early version of
specification and provided a great deal of invaluable input. this specification and provided a great deal of invaluable input.
16. References 15. References
16.1. Normative References 15.1. Normative References
[ISO.10646.2012]
International Organization for Standardization,
"Information technology -- Universal Coded Character Set
(UCS)", ISO Standard 10646, 2012.
[ISO.3166-1] [ISO.3166-1]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries and their the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard 3166- subdivisions - Part 1: Country codes", ISO Standard
1:1997, 1997. 3166-1:2006, 2006.
[ISO.639.1988] [ISO.639.2002]
International Organization for Standardization, "Code for International Organization for Standardization, "Codes for
the representation of names of languages, 1st edition", the representation of names of languages -- Part 1:
ISO Standard 639, 1988. Alpha-2 code", ISO Standard 639, 2002.
[ITU-T.Q.1950] [ITU-T.Q.1950]
International Telecommunication Union - Telecommunication International Telecommunication Union, "Bearer independent
Standardization Bureau, "Call Bearer Control (CBC) call bearer control protocol", ITU-T Recommendation
Protocol", ITU-T Recommendation Q.1950, 2002. Q.1950, December 2002.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
skipping to change at page 140, line 11 skipping to change at page 134, line 45
[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.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[W3C.CR-wsdl20-20051215] [W3C.REC-xmlschema-1-20041028]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"Web Services Description Language (WSDL) Version 2.0 Part "XML Schema Part 1: Structures Second Edition", World Wide
1: Core Language", W3C CR CR-wsdl20-20051215, Web Consortium Recommendation REC-xmlschema-1-20041028,
December 2005. October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Hadley, M., Nielsen, H., and
J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-xmlschema-2-20041028]
Hadley, M., Mendelsohn, N., Nielsen, H., Moreau, J., and Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Second Edition", World Wide Web Consortium
Web Consortium FirstEdition REC-soap12-part2-20030624, Recommendation REC-xmlschema-2-20041028, October 2004,
June 2003, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
16.2. Informative References 15.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[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 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022, Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007. 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.
skipping to change at page 141, line 22 skipping to change at page 136, line 5
Control Channel Framework", RFC 6230, May 2011. Control Channel Framework", RFC 6230, May 2011.
[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An [RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework", RFC 6231, May 2011. Media Control Channel Framework", RFC 6231, May 2011.
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and [RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and
'Profiles' Parameters for "Bucket" Media Types", RFC 6381, 'Profiles' Parameters for "Bucket" Media Types", RFC 6381,
August 2011. August 2011.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, March 2012.
[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer [RFC6505] 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",
RFC 6505, March 2012. RFC 6505, March 2012.
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
Napoli 80100 Napoli 80100
Italy Italy
Email: lorenzo@meetecho.com EMail: lorenzo@meetecho.com
Gary Munson Gary Munson
AT&T AT&T
200 Laurel Avenue South 200 Laurel Avenue South
Middletown Middletown, New Jersey 07748
New Jersey 07748
USA USA
Email: gamunson@att.com EMail: gamunson@gmail.com
 End of changes. 561 change blocks. 
1586 lines changed or deleted 1371 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/