draft-ietf-mediactrl-mrb-13.txt   draft-ietf-mediactrl-mrb-14.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero Intended status: Standards Track L. Miniero
Expires: January 11, 2013 Meetecho Expires: February 21, 2013 Meetecho
G. Munson G. Munson
AT&T AT&T
July 10, 2012 August 20, 2012
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-13 draft-ietf-mediactrl-mrb-14
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2013. This Internet-Draft will expire on February 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publish Interface . . . . . . . . 14 5.1. Media Server Resource Publish Interface . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . 15 5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 19 5.1.4. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbnotification> . . . . . . . . . . . . . . . . . . 20 5.1.5. <mrbnotification> . . . . . . . . . . . . . . . . . . 20
5.2. Media Service Resource Consumer Interface . . . . . . . 31 5.2. Media Service Resource Consumer Interface . . . . . . . 32
5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 32 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 32
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 33
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 35 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 36
5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 38 5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 39
5.2.5. Media Service Resource Request . . . . . . . . . . . 38 5.2.5. Media Service Resource Request . . . . . . . . . . . 39
5.2.6. Media Service Resource Response . . . . . . . . . . . 51 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 . . . . . . . . . . . . . . . . . . . . 56
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 56 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 57
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 57 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 58
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 59 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 60
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 65 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 65
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 65 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 66
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 68 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 68
10. Media Service Resource Publisher Interface XML Schema . . . . 83 10. Media Service Resource Publisher Interface XML Schema . . . . 84
11. Media Service Resource Consumer Interface XML Schema . . . . 106 11. Media Service Resource Consumer Interface XML Schema . . . . 107
12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 12. Security Considerations . . . . . . . . . . . . . . . . . . . 128
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
13.1. Media Control Channel Framework Package Registration . . 130 13.1. Media Control Channel Framework Package Registration . . 131
13.2. application/mrb-publish+xml Media Type . . . . . . . . . 130 13.2. application/mrb-publish+xml Media Type . . . . . . . . . 131
13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 131 13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 132
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 132 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 133
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 132 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 133
13.6. XML Schema Registration for mrb-publish . . . . . . . . 132 13.6. XML Schema Registration for mrb-publish . . . . . . . . 133
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 133 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 134
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.1. Changes from 12 Version . . . . . . . . . . . . . . . . 134 14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 135
14.2. Changes from 11 Version . . . . . . . . . . . . . . . . 134 14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 135
14.3. Changes from 10 Version . . . . . . . . . . . . . . . . 134 14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 135
14.4. Changes from 09 Version . . . . . . . . . . . . . . . . 135 14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 135
14.5. Changes from 08 Version . . . . . . . . . . . . . . . . 135 14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 136
14.6. Changes from 07 Version . . . . . . . . . . . . . . . . 135 14.6. Changes from 08 Version . . . . . . . . . . . . . . . . 136
14.7. Changes from 06 Version . . . . . . . . . . . . . . . . 136 14.7. Changes from 07 Version . . . . . . . . . . . . . . . . 136
14.8. Changes from 05 Version . . . . . . . . . . . . . . . . 136 14.8. Changes from 06 Version . . . . . . . . . . . . . . . . 137
14.9. Changes from 04 Version . . . . . . . . . . . . . . . . 136 14.9. Changes from 05 Version . . . . . . . . . . . . . . . . 137
14.10. Changes from 03 Version . . . . . . . . . . . . . . . . 136 14.10. Changes from 04 Version . . . . . . . . . . . . . . . . 137
14.11. Changes from 02 Version . . . . . . . . . . . . . . . . 137 14.11. Changes from 03 Version . . . . . . . . . . . . . . . . 137
14.12. Changes from 01 Version . . . . . . . . . . . . . . . . 137 14.12. Changes from 02 Version . . . . . . . . . . . . . . . . 138
14.13. Changes from 00 Version . . . . . . . . . . . . . . . . 137 14.13. Changes from 01 Version . . . . . . . . . . . . . . . . 138
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 138 14.14. Changes from 00 Version . . . . . . . . . . . . . . . . 138
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139
16.1. Normative References . . . . . . . . . . . . . . . . . . 139 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 140
16.2. Informative References . . . . . . . . . . . . . . . . . 140 16.1. Normative References . . . . . . . . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 142 16.2. Informative References . . . . . . . . . . . . . . . . . 141
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143
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 work group. It should be possible for a controlling entity
to be assisted in Media Server selection so that the most appropriate to be assisted in Media Server selection so that the most appropriate
resource is selected for a particular operation. The importance resource is selected for a particular operation. The importance
skipping to change at page 7, line 18 skipping to change at page 7, line 18
"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, Media Control Channel Framework [RFC6230] documents. In addition,
the following terms are defined for use in this document and for use the following terms are defined for use in this document and for use
in the context of the MediaCtrl Work group in the IETF: in the context of the MediaCtrl Work group in the IETF:
Media Resource Broker (MRB): A logical entity that is responsible Media Resource Broker (MRB): A logical entity that is responsible
for both collection of appropriate published Media Server (MS) for both collection of appropriate published Media Server (MS)
information and selecting appropriate MS resources on behalf of information and selecting appropriate Media Server resources on
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 provides an interface for an Application Server to retrieve that provides an interface for an Application Server to retrieve
the address of an appropriate Media Server. The result returned the address of an appropriate Media Server. The result returned
to the Application Server can be influenced by information to the Application Server can be influenced by information
contained in the query request. contained in the query request.
In-line MRB: An instantiation of an MRB (See definition) that In-line MRB: An instantiation of an MRB (See previous definition)
directly receives requests on the signalling path. There is no that directly receives requests on the signalling path. There is
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 differently stated, such protocol message needs to be unique. Unless stated otherwise, such
uniqueness will always need to be intended within the scope of the uniqueness will always be within the scope of the Media Servers
Media Servers controlled by the same Media Resource Broker. The controlled by the same Media Resource Broker. The interaction
interaction among different Media Resource Brokers, as the between different Media Resource Broker instances, as the
partitioning of a logical Media Resource Broker, is out of scope to partitioning of a logical Media Resource Broker, is out of scope to
this document. this document.
3. Problem Discussion 3. Problem Discussion
As anticipated in Section 1, the main aim of the MediaCtrl group is As discussed in Section 1, a goal of the MediaCtrl group is to
to produce a solution that must service a wide variety of deployment produce a solution that will service a wide variety of deployment
architectures. These range from the simplest 1:1 relationship architectures. Such architectures range from the simplest 1:1
between Media Servers and Application Servers to potentially linearly relationship between Media Servers and Application Servers to
scaling 1:M, M:1 and M:N deployments. potentially linearly scaling 1:M, M:1 and M:N deployments.
This still does not seem like a major issue for the proposed solution Managing such deployments is itself non-trivial for the proposed
until you add a number of additional factors into the equation that solution until an additional number of factors are included into the
increase complexity. As Media Servers evolve it must be taken into equation that increase complexity. As Media Servers evolve it must
consideration that, where many can exist in a deployment, they may be taken into consideration that, where many can exist in a
not have been produced by the same vendor and may not have the same deployment, they may not have been produced by the same vendor and
capability set. It should be possible for an Application Server that may not have the same capability set. It should be possible for an
exists in a deployment to select a Media Service based on a common, Application Server that exists in a deployment to select a Media
appropriate capability set. In conjunction with capabilities, it is Service based on a common, appropriate capability set. In
also important to take available resources into consideration. The conjunction with capabilities, it is also important to take available
ability to select an appropriate Media Service function is an resources into consideration. The ability to select an appropriate
extremely useful feature but becomes even more powerful when Media Service function is an extremely useful feature but becomes
considered with available resources for servicing a request. even more powerful when considered with available resources for
servicing a request.
In conclusion, the intention is to create a tool set that allows In conclusion, the intention is to create a tool set that allows
MediaCtrl deployments to effectively utilize the available media MediaCtrl deployments to effectively utilize the available media
resources. It should be noted that in the simplest deployments where resources. It should be noted that in the simplest deployments where
only a single media server exists, an MRB function is probably not only a single media server exists, an MRB function is probably not
required. Only a single capability set exists and resource required. Only a single capability set exists and resource
unavailability can be handled using the appropriate underlying availability can be handled using the appropriate underlying
signalling, e.g., SIP response. This document does not prohibit such signalling, e.g., SIP response. This document does not prohibit such
uses of an MRB, it simply provides the tools for various entities to uses of an MRB, it simply provides the tools for various entities to
interact where appropriate. It is also worth noting that the tools interact where appropriate. It is also worth noting that the
provided in this document aim to provide a 'best effort' view of functions specified in this document aim to provide a 'best effort'
media resources at the time of request for initial Media Server view of media resources at the time of request for initial Media
routing decisions. Any dramatic change in media capabilities after a Server routing decisions. Any dramatic change in media capabilities
request has taken place should be handled by the underlying protocol. or capacity after a request has taken place should be handled by the
underlying protocol.
Please note that there may be additional information that it is It should be noted that there may be additional information that it
desirable for the MRB to have for purposes of selecting a MS is desirable for the MRB to have for purposes of selecting a Media
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
MS resource capacity models. How the MRB acquires such information Media Server resource capacity models. How the MRB acquires such
is outside the scope of this document. The techniques used for information is outside the scope of this document. The specific
selecting an appropriate Media Resource by an MRB is outside the techniques used for selecting an appropriate Media Resource by an MRB
scope of this document. is also outside the scope of this document.
4. Deployment Scenario Options 4. Deployment Scenario Options
On researching Media Resource Brokering it became clear that a couple Research into Media Resource Brokering concluded that a couple of
of high level models exist. The general principles of "in-line" and high level models provided an appropriate level of flexibility. The
"query" MRB concepts are discussed in the rest of this section. It general principles of "in-line" and "query" MRB concepts are
should be noted that while the interfaces are different they both use discussed in the rest of this section. It should be noted that while
common mechanisms. the interfaces are different they both use common underlying
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 "ask"
an MRB for an appropriate Media Server, as illustrated in Figure 5. an MRB for an appropriate Media Server, as illustrated in Figure 5.
+---+-----+---+ +---+-----+---+
+------------>| MRB |<----------+----<-----+---+ +------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | | | +-------------+ (1)| | |
skipping to change at page 10, line 7 skipping to change at page 10, line 8
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 an increased accuracy in its response. This particular
interface is discussed in "Media Resource Consumer Interface" in interface is discussed in "Media Resource Consumer Interface" in
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 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 MRB, the MRB is not in the signaling path between the AS with Query mode, the MRB is not directly in the signalling path
and the selected MS resource. between the Application Server and the selected Media Server
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 tool kit 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.
+------------<----------------<---------+----<-----+---+ +------------<----------------<---------+----<-----+---+
skipping to change at page 10, line 36 skipping to change at page 10, line 38
+---+--+--+---+ | +---+-----+---+ | | +---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | | | Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ | | Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ | +-------------+ | +-------------+ |
| | | |
| +---+-----+---+ | | +---+-----+---+ |
+---->| Media | | +---->| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 6: Hybrid Query MRB - AS 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 still exist within the Application Server/MRB interaction but might still exist within the Application Server/MRB interaction but
this is an implementation issue. This type of deployment suits a this is an implementation issue. This type of deployment suits a
single Application Server environment but it should be noted that a single Application Server environment but it should be noted that a
"Media Server Consumer Interface" could then be offered from the "Media Server Consumer Interface" could then be offered from the
skipping to change at page 11, line 25 skipping to change at page 11, line 27
| | Server |<--+-MS Control-+--+ | | Server |<--+-MS Control-+--+
| +-------------+ | | +-------------+ |
| | | |
| +---+--+--+---+ | | +---+--+--+---+ |
+---<-------| Application | | +---<-------| Application | |
| Server |<--+-MS Control-+--+ | Server |<--+-MS Control-+--+
+-------------+ +-------------+
Figure 7: Hybrid Query MRB - MS Hosted Figure 7: Hybrid Query MRB - MS Hosted
This time the MRB has collapsed and is co-hosted by the Media Server. In this example, the MRB has collapsed and is co-hosted by the Media
The "Media Server Consumer Interface" is still available to the Server. The "Media Server Consumer Interface" is still available to
Application Servers (1) to query Media Server resources. This time the Application Servers (1) to query Media Server resources. The
the "Media Server Publish Interface" has collapsed onto the Media "Media Server Publish Interface" has collapsed onto the Media Server.
Server. It might still exist within the Media Server/MRB interaction It might still exist within the Media Server/MRB interaction but this
but this is an implementation issue. This type of deployment suits a is an implementation issue. This type of deployment suits a single
single Media Server environment but it should be noted that a "Media Media Server environment but it should be noted that a "Media Server
Server Publish Interface" could then be offered from the hybrid if Publish Interface" could then be offered from the hybrid if required.
required. A typical use case scenario for such a topology would be a A typical use case scenario for such a topology would be a single
single MS representing a pool of MSs in a cluster. In that case, the Media Server representing a pool of MSs in a cluster. In this case,
MRB would actually be handling a cluster of MSs, rather than one. the MRB would actually be handling a cluster of Media Servers, 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
that was discussed in the previous section. The concept of a discussed in the previous section. The concept of a separate query
separate query disappears. The client of the MRB simply uses the disappears. The client of the MRB simply uses the media resource
media resource control and media dialog signalling to involve the control and media dialog signalling to involve the MRB. This type of
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)| |
+---+--+--+---+ | | +---+-----+---+ | | +---+--+--+---+ | | +---+-----+---+ | |
skipping to change at page 12, line 27 skipping to change at page 12, line 27
| | | |
| (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) is The media server Control (and Media dialogs as well, if required) are
sent to the MRB (2) which then selects an appropriate Media Server sent to the MRB (2) which then selects an appropriate Media Server
(3) and would stay in the signaling path between the AS and the MS (3) and remain in the signalling path between the Application Server
resource for the handled dialogs. and the Media Server resources.
In-line MRB can be split into two distinct logical roles which can be In-line MRB can be split into two distinct logical roles which can be
applied on a per request basis. They are: 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 AS does not provide explicit its operation. In this case the Application Server does not
information on the kind of MS resource it needs (as in provide explicit information on the kind of Media Server resource
Section 5.2) and the MRB is left to deduce it by potentially it needs (as in Section 5.2) and the MRB is left to deduce it by
inspecting other information in the request from the AS; for potentially inspecting other information in the request from the
example, SDP content, or address of the requesting AS, or Application Server; for example, SDP content, or address of the
additional Request-URI parameters as per RFC 4240 [RFC4240]. requesting Application Server, or additional Request-URI
parameters as per RFC 4240 [RFC4240].
In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of
clients requiring media services who are aware of an MRB and its clients requiring media services who are aware of an MRB and its
operation. In particular it allows the AS to explicitly the operation. In particular it allows the Application Server to
convey the same kinds of MS characteristics desired as does the explicitly convey matching characteristics to those provided by
Query MRB mode (as in Section 5.2). media servers, as does the Query MRB mode (as in Section 5.2).
In either role, signalling as specified by the Media Control Channel In either of the previously described roles, signalling as specified
Framework ([RFC6230]) would be involved, and the MRB would deduce by the Media Control Channel Framework ([RFC6230]) would be involved,
that the selected MS resources are no longer needed when the AS or MS and the MRB would deduce that the selected Media Server resources are
terminates the corresponding dialog. The two modes are discussed in no longer needed when the Application Server or Media Server
more detail in Section 5.3. terminates the corresponding SIP dialog. The two modes are discussed
in more detail in Section 5.3.
5. MRB Interface Definitions 5. MRB Interface Definitions
The intention is to provide a tool-kit for a variety of deployment The intention of this specification is to provide a tool-kit for a
architectures where media resource brokering can take place. Two variety of deployment architectures where media resource brokering
main interfaces are required to support the differing requirements. can take place. Two main interfaces are required to support the
The two interfaces are described in the remainder of this section and differing requirements. The two interfaces are described in the
have been named the 'Media Server Resource Publish' and 'Media Server remainder of this section and have been named the '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 fulfil
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 Query
and In-line modes of MRB operation. and In-line modes of MRB operation.
As already anticipated in the introduction, the MRB view of MS As already discussed in the Section 1, the MRB view of Media Server
resource availability will in practice 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 MS resource consumption, the MS may in exhaustive view of current Media Server resource consumption, the
some cases provide a best-effort computed view of resource Media Server may in some cases provide a best-effort computed view of
consumption parameters conveyed in the Publish interface (e.g., DSP's resource consumption parameters conveyed in the Publish interface
with a fixed number of streams versus GPU's with CPU availability). (e.g., DSP's with a fixed number of streams versus GPU's with CPU
Media Resource information may only be reported periodically over the availability). Media Resource information may only be reported
Publish interface to 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
skipping to change at page 18, line 14 skipping to change at page 18, line 14
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
subscription command. The first subscription MUST have 1 as subscription command. The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the 'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
action: provides the operation that should be carried out on the action: provides the operation that should be carried out on the
subscription: subscription:
* The value of 'create' instructs the MS to attempt to set-up a * The value of 'create' instructs the Media Server to attempt to
new subscription. set-up a new subscription.
* The value of 'update' instructs the MS to attempt to update an * The value of 'update' instructs the Media Server to attempt to
existing subscription. update an existing subscription.
* The value of 'remove' instructs the MS to attempt to remove an * The value of 'remove' instructs the Media Server to attempt to
existing subscription and consequently stop any ongoing related remove an existing subscription and consequently stop any
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 in case it is still
interested in receiving notifications from the MS. The element interested in receiving notifications from the Media Server. The
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 MS. The element MAY MRB wishes to receive notifications from the Media Server. The
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 MS. The element MAY MRB wishes to receive notifications from the Media Server. The
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 MS MAY change the proposed by the MRB only act as a suggestion: the Media Server MAY change the
values if it considers the suggestions unacceptable (e.g., if the MRB proposed values if it considers the suggestions unacceptable (e.g.,
has requested a too high notification frequency). In such case, the if the MRB has requested a too high notification frequency). In such
request would not fail, but the updated, acceptable values would be case, the request would not fail, but the updated, acceptable values
reported in the <mrbresponse> accordingly. 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 a <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.
skipping to change at page 19, line 48 skipping to change at page 19, line 48
| 404 | Subscription does not exist | | 404 | Subscription does not exist |
| | | | | |
| 405 | Subscription already exists | | 405 | Subscription already exists |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <mrbresponse> status codes Table 1: <mrbresponse> status codes
In case a new subscription request made by an MRB (action='create') In case a new subscription request made by an MRB (action='create')
has been accepted, the MS MUST reply with a <mrbresponse> with status has been accepted, the Media Server MUST reply with a <mrbresponse>
code 200. The same rule applies whenever a request to update with status code 200. The same rule applies whenever a request to
(action='update') or remove (action='remove') an existing transaction update (action='update') or remove (action='remove') an existing
can be fulfilled by the MS. transaction 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 MS fails to handle a request due to a instead. Specifically, if the Media Server fails to handle a request
syntax error in the request itself (e.g., incorrect XML, violation of due to a syntax error in the request itself (e.g., incorrect XML,
the schema constraints or invalid values in any of the attributes/ violation of the schema constraints or invalid values in any of the
elements) the MS MUST reply with a <mrbresponse> with status code attributes/elements) the Media Server MUST reply with a <mrbresponse>
400. If a syntactically correct request fails because the request with status code 400. If a syntactically correct request fails
also includes any attribute/element the MS doesn't understand, the MS because the request also includes any attribute/element the Media
MUST reply with a <mrbresponse> with status code 420. If a Server doesn't understand, the Media Server MUST reply with a
syntactically correct request fails because the MRB wants to create a <mrbresponse> with status code 420. If a syntactically correct
new subscription, but the provided intended id for the subscription request fails because the MRB wants to create a new subscription, but
already exists, the MS MUST reply with a <mrbresponse> with status the provided unique 'id' for the subscription already exists, the
code 405. If a syntactically correct request fails because the MRB Media Server MUST reply with a <mrbresponse> with status code 405.
wants to update/remove a subscription that doesn't exist, the MS MUST If a syntactically correct request fails because the MRB wants to
reply with a <mrbresponse> with status code 404. If the MS is unable update/remove a subscription that doesn't exist, the Media Server
to accept a request for any other reason (e.g., the MRB has no more MUST reply with a <mrbresponse> with status code 404. If the Media
resources to fulfil the request), the MS MUST reply with a Server is unable to accept a request for any other reason (e.g., the
<mrbresponse> with status code 401/402/403, depending on the action MRB has no more resources to fulfil the request), the Media Server
the MRB provided in its request: MUST reply with a <mrbresponse> with status code 401/402/403,
depending on the action the MRB provided in its request:
o action='create' --> 401; o action='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 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 MS MAY change the suggested 'expires', 'minfrequency' and The Media Server MAY change the suggested 'expires', 'minfrequency'
'maxfrequency' values provided by the MRB in its <mrbrequest>, if it and 'maxfrequency' values provided by the MRB in its <mrbrequest>, if
considers them unacceptable (e.g., the requested frequency range is it considers them unacceptable (e.g., the requested frequency range
too high). In such a case, the response MUST contain a is too high). In such a case, the response MUST contain a
<subscription> element describing the subscription as the MS accepted <subscription> element describing the subscription as the Media
it, and the MS MUST include in the <subscription> element all of Server accepted it, and the Media Server MUST include in the
those values that it modified relative to the request, to inform the <subscription> element all of those values that it modified relative
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 current status. The
Media Server will inform the MRB of its current status as defined by Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element. using the <mrbnotification> element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
skipping to change at page 21, line 22 skipping to change at page 21, line 23
with the subscription session id to identify a specific with the subscription session id to identify a specific
notification update. The first notification MUST have 1 as notification update. The first notification MUST have 1 as
'seqnumber', and following notifications MUST increment by 1 the 'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value. The attribute MUST be present. previous 'seqnumber' value. The attribute MUST be present.
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 a
<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 <mrbsubscription>. In fact, the latter is associated with
subscriptions and would increase at every command issued by the MRB, subscriptions and would increase at every command issued by the MRB,
while the former is associated with the asynchronous notifications while the former is associated with the asynchronous notifications
the MS would trigger according to the subscription, and as such would the Media Server would trigger according to the subscription, and as
increase at every notification message to let the MRB keep track of such would increase at every notification message to enable the MRB
them. keep track of them.
The following subsections provide details of the child elements that The following subsections provide details of the child elements that
are the content of the <mrbnotification> element. are the content 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 chosen such that it is extremely unlikely that two different
media servers would present the same id to a given MRB. media servers would present the same id to a given MRB.
skipping to change at page 22, line 47 skipping to change at page 22, line 48
mix> element has one attribute. The value of the attribute mix> element has one attribute. The value of the attribute
'conferenceid' is the name of the mix. The <active-mix> element 'conferenceid' is the name of the mix. The <active-mix> element
has one child element. The child element, <rtp-codec>, contains has one child element. The child element, <rtp-codec>, contains
the same information relating to RTP sessions as defined in the same information relating to RTP sessions as defined in
Section 5.1.5.3. The element MAY be present. 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 MS can support. The element MAY be present. RTP streams this Media Server can support. The element MAY be
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 zero or more of the
following child elements: following child elements:
<rtp-codec>: Describes a supported codec and the number of non- <rtp-codec>: Describes a supported codec and the number of non-
active sessions for that codec. The <rtp-codec> element has one active sessions for that codec. The <rtp-codec> element has one
attribute. The value of the attribute 'name' is a 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 as content the decimal number of RTP sessions available for has as content the decimal number of RTP sessions available for
decoding using the specified codec. The child element, decoding using the specified codec. The child element,
<encoding>, has as content the decimal number of RTP sessions <encoding>, has as content the decimal number of RTP sessions
available for encoding using the specified codec. available for encoding using the specified codec.
5.1.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 MS can support. The element MAY be more mixing sessions this Media Server can support. The element MAY
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 zero of more of the
following 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
skipping to change at page 24, line 35 skipping to change at page 24, line 41
the name of the Media Control Channel Framework package, compliant the name of the Media Control Channel Framework package, compliant
with the Section 13.1.1 of [RFC6230], for which the codec support with the Section 13.1.1 of [RFC6230], for which the codec support
applies. The <supported-codec-package> element has zero or more applies. 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 MS is able to pass a stream encoded * 'passthrough', meaning the Media Server is able to pass a
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 are 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 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.
skipping to change at page 25, line 28 skipping to change at page 25, line 32
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, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package, compliant with the of the Media Control Channel Framework package, compliant with the
Section 13.1.1 of [RFC6230], for which the file format support Section 13.1.1 of [RFC6230], for which the file format support
applies. 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 preparted 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 before it is executed (see section 4.4.2.2.6 of RFC
6231[RFC6231]. The element MAY be present. 6231[RFC6231]. 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 zero or more of the following The <max-prepared-duration> element has zero or more of the following
child elements: child elements:
<max-time>: has a single attribute, 'max-time-seconds', which <max-time>: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
skipping to change at page 28, line 52 skipping to change at page 29, line 17
<file-transfer-mode>: has two attributes, 'name' and 'package'. <file-transfer-mode>: has two attributes, 'name' and 'package'.
The 'name' attribute provides the scheme name of the protocol that The 'name' attribute provides the scheme name of the protocol that
can be used for file transfer (e.g., "HTTP", "RTSP", etc.): the can be used for file transfer (e.g., "HTTP", "RTSP", etc.): 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 MS supports any flavour of live information about whether or not the Media Server supports any
streaming: for instance, a value of "HTTP" for the IVR Package would flavour of live streaming: for instance, a value of "HTTP" for the
only mean the 'http' scheme makes sense to the MS within the context IVR Package would only mean the 'http' scheme makes sense to the
of that package. Whether or not the MS can make use of HTTP to only Media Server within the context of that package. Whether or not the
fetch resources, or also to attach an HTTP live stream to a call, is Media Server can make use of HTTP to only fetch resources, or also to
to be considered implementation specific to the MS and unrelevant to attach an HTTP live stream to a call, is to be considered
the AS and/or MRB. Besides, the MS supporting a scheme does not implementation specific to the Media Server and irrelevant to the
imply it also supports the related secure versions: for instance, if Application Server and/or MRB. Besides, the Media Server supporting
the MS supports both "HTTP" and "HTTPS", both the schemes will appear a scheme does not imply it also supports the related secure versions:
in the element. A lack of the "HTTPS" value would need to be for instance, if the Media Server supports both "HTTP" and "HTTPS",
interpreted as a lack of support for the 'https' scheme. both the schemes will appear in the element. A lack of the "HTTPS"
value would need to be interpreted as 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 are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988] referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The element MAY be codes) for what regards both ASR and TTS. The element MAY be
present. present.
The <asr-tts-support> element has no attributes. The <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> has
one child element. The child element, <language>, reports the MS one child element. The child element, <language>, reports the
supports ASR for a specific language. The <language> element has Media Server supports ASR for a specific language. The <language>
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains element has a single attribute, 'xml:lang'. The attribute 'xml:
the ISO-639-1 [ISO.639.1988] code of the supported language. lang' contains the ISO-639-1 [ISO.639.1988] 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> has
one child element. The child element, <language>, reports the MS one child element. The child element, <language>, reports the
supports tts for a specific language. The <language> element has Media Server supports tts for a specific language. The <language>
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains element has a single attribute, 'xml:lang'. The attribute 'xml:
the ISO-639-1 [ISO.639.1988] code of the supported language. lang' contains the ISO-639-1 [ISO.639.1988] 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 and if it does which protocols the support is exposed
through (e.g., via the control framework, RFC4240 [RFC4240], or through (e.g., via the control framework, RFC4240 [RFC4240], or
RFC5552 [RFC5552]). The element MAY be present. RFC5552 [RFC5552]). The element MAY be present.
The <vxml-support> element has 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 zero or more of the following child
elements: elements:
<vxml-mode>: has two attributes, 'package' and 'support'. The <vxml-mode>: has two attributes, 'package' and 'support'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support IANA registry (e.g., "msc-ivr/1.0"), for which the VXML support
applies. The 'support' attribute provides the type of VXML applies. The 'support' attribute provides the type of VXML
support provided by the Media Server (e.g., RFC5552 [RFC5552], support provided by the Media Server (e.g., RFC5552 [RFC5552],
RFC4240 [RFC4240] or IVR Package [RFC6231]), and valid values are RFC4240 [RFC4240] or IVR Package [RFC6231]), and valid values are
case insensitive RFC references (e.g., "rfc6231" to specify the MS case insensitive RFC references (e.g., "rfc6231" to specify the
supports VoiceXML as provided by the IVR Package [RFC6231]). Media Server supports 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 the
Media Server does not support VXML at all. 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
skipping to change at page 31, line 8 skipping to change at page 31, line 27
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 address where it can be reached (e.g., the URI AS direct SIP URI address where it can be reached (e.g., the URI
would call to in order to set-up a Control Channel and relay SIP Application Server would call to in order to set-up a Control Channel
media dialogs). The element MAY be present. and relay SIP media dialogs). The element MAY be present.
The <media-server-address> element has a single attribute. The <media-server-address> element has a single attribute.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.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. MAY be present.
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has zero or more of the following child The <encryption> element has zero or more of the following child
elements: elements:
<keying-mechanism>: has no attributes. The element provides the <keying-mechanism>: has no attributes. The element provides the
name of a keying mechanism the MS supports for encrypting RTP name of a keying mechanism the Media Server supports for
media streams. encrypting RTP media streams.
The presence of at least one <keying-mechanism> child element would The presence of at least one <keying-mechanism> child element would
indicate that the Media Server does support RTP media stream indicate that the Media Server does support RTP media stream
encryption as specified by the child element itself. An empty encryption as specified by the child element itself. An empty
<encryption> element would otherwise indicate the Media Server does <encryption> element would otherwise indicate the Media Server does
not support RTP encryption at all. not support RTP encryption at all.
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
skipping to change at page 32, line 34 skipping to change at page 33, line 5
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 like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
a <mrbconsumer> root element with only one child a <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 MRB,
it will send a new request with an <action> element with value it will send a new request with an <action> element with value
'remove' as described in Section 5.2.3 about the use of the Consumer 'remove' as described in Section 5.2.3 about the use of the Consumer
interface lease mechanism. interface lease mechanism.
5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage
This document provides a complete tool-kit for MRB deployment which This document provides a complete tool-kit for MRB deployment which
includes the ability to interact with an MRB using SIP for the includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary Consumer interface. The following information explains the primary
skipping to change at page 33, line 17 skipping to change at page 33, line 37
addresses of the selected media servers are made known to the addresses of the selected media servers are made known to the
requesting application server in the SIP 200 OK response by means of requesting application server in the SIP 200 OK response by means of
one or more <media-server-address> child elements in the <response- one or more <media-server-address> child elements in the <response-
session-info> element (Section 5.2.6). session-info> element (Section 5.2.6).
5.2.2.1. IAMM and Setting up a Control Framework Control Channel 5.2.2.1. IAMM and Setting up a Control Framework Control Channel
The media resource request information, as defined by the The media resource request information, as defined by the
<mediaResourceRequest> element from Section 11, 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]. The following additional steps Control Channel Framework [RFC6230]. It should be noted that this
MUST be followed when using the Consumer interface: specification does not exclude the use of an offer-less INVITE as
defined in RFC3261 [RFC3261]. Using offer-less INVITE messages to an
MRB can potentially cause confusion when applying resource selection
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
appropriately, additional contextual information would need to be
provided with the request which is out of the scope for this
document. The following additional steps MUST be followed when using
the 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 fulfill the request. It will: steps to fulfil 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 MS out of the MSs it selects is implementation specific, specific Media Server out of the Media Servers it selects is
and out of scope to this document. It is important to configure implementation specific, and out of scope to this document. It is
the SIP elements between the MRB and the MS in such a way that important to configure the SIP elements between the MRB and the
that the INVITE will not fork. In case of a failure in reaching Media Server in such a way that that the INVITE will not fork. In
the chosen MS, the MRB SHOULD proceed to the next one, if case of a failure in reaching the chosen Media Server, the MRB
available. SHOULD proceed to the next one, if available.
If none of the available MS can be reached, the MRB MUST reply with a If none of the available Media Server can be reached, the MRB MUST
SIP 503 error message including a Retry-After header with a non-zero reply with a SIP 503 error message including a Retry-After header
value. The AS MUST NOT attempt to setup a new session before the with a non-zero value. The Application Server MUST NOT attempt to
time the MRB asked it to wait has passed. setup a new session before the time the MRB asked it to wait has
passed.
In case at least one MS is reachable, the MRB acts as a Back-to-Back In case at least one Media Server is reachable, the MRB acts as a
UA (B2BUA) that extracts the 'application/mrb-consumer+xml' Back-to-Back UA (B2BUA) that extracts the 'application/
information from the SIP INVITE request and then sends a mrb-consumer+xml' information from the SIP INVITE request and then
corresponding SIP INVITE request to the MS it has selected, to sends a corresponding SIP INVITE request to the Media Server it has
negotiate a control channel as defined in the Media Channel Control selected, to negotiate a control channel as defined in the Media
Framework [RFC6230]. Channel Control Framework [RFC6230].
In case of a failure in negotiating the control channel with the MS, In case of a failure in negotiating the control channel with the
the MRB SHOULD proceed to the next one, if available, as explained Media Server, the MRB SHOULD proceed to the next one, if available,
above. If none of the available MS can be reached, or the as explained above. If none of the available Media Servers can be
negotiation of the control channel with all of them fails, the MRB reached, or the negotiation of the control channel with all of them
MUST reply with a SIP 503 error message including a Retry-After fail, the MRB MUST reply with a SIP 503 error message including a
header with a non-zero value. The AS MUST NOT attempt to setup a new Retry-After header with a non-zero value. The Application Server
session before the time the MRB asked it to wait has passed. MUST NOT attempt to setup a new session before the time the MRB 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 by MRB to a request, as defined by the The media resource response generated by an MRB to a request, as
<mediaResourceResponse> element from Section 11, MUST be carried in defined by the <mediaResourceResponse> element from Section 11, MUST
the payload of a SIP 200 response to the original SIP INVITE request. be carried in the payload of a SIP 200 OK response to the original
The 200 response will be constructed as it would have been to connect SIP INVITE request. The SIP 200 OK response will be constructed as
from a media server, as defined by the Media Control Channel it would have been to connect from a media server, as defined by the
Framework [RFC6230]. The following additional steps MUST be followed Media Control Channel Framework [RFC6230]. The following additional
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 a packet loss, the IAMM relies on a transactions may result in failure, the IAMM relies on a successful
successful INVITE transaction to address the seq increment mechanism. INVITE transaction to address the previously discussed sequence
This means that, if the INVITE is unsuccessful for any reason, the AS (using 'seq' XML element) increment mechanism. This means that, if
MUST use the same seq value as before for the next Consumer request the INVITE is unsuccessful for any reason, the Application Server
it may want to send to the MRB for the same session. 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.
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 interval dialog that initiated the request, or when the lease interval
expires. 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 prior section This scenario is identical to the description in the previous section
for setting up a Control Framework control channel, except for the for setting up a Control Framework control channel with the exception
difference that the application/sdp payload conveys content that the application/sdp payload conveys content appropriate for
appropriate for setting up the media dialog to the media resource, as setting up the media dialog to the media resource, as per RFC 3261
per RFC 3261 [RFC3261], instead of application/sdp payload for [RFC3261], instead of application/sdp payload for setting up a
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 Section 5.2 and Section 11 allows a
client to request an appropriate media resource based on information client to request an appropriate media resource based on information
included in the request (either a HTTP POST or SIP INVITE message). included in the request (either a HTTP POST or SIP INVITE message).
In case of success, the response that is returned to the client MUST In the case of success, the response that is returned to the client
contain a <response-session-info> element in either the SIP 200 or MUST contain a <response-session-info> element in either the SIP 200
HTTP 200 response. The success response contains the description of or HTTP 200 response. The success response contains the description
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, though, it's Before delving into the details of such lease mechanism, it is worth
worthwhile to first clarify its role within the context of the clarifying its role within the context of the Consumer interface. As
Consumer interface. As explained in Section 5.1, the knowledge the explained in Section 5.1, the knowledge the MRB has of the resources
MRB has of the resources of all the MSs it handles is imperfect. As of all the Media Servers it is provisioned to manage is non real-
such, how an MRB actually manages such resources depends on how it is time. How an MRB actually manages such resources is implementation
implemented: one may choose to have the MRB keeping track and state specific - for example an implementation may choose to have the MRB
of the allocated resources, or simply depend on the MSs themselves to keeping track and state of the allocated resources, or simply rely on
provide the information by means of the publishing interface the Media Servers themselves to provide the information using the
notifications. Further information may be inferred by the Publish interface. Further information may be also be inferred by
signalling, in case the MRB is in the path of media dialogs. the signalling, in the case where an MRB is in the path of media
dialogs.
That said, the <mediaResourceResponse> element returned from the MRB The <mediaResourceResponse> element returned from the MRB contains a
contains a <response-session-info> element if the request is <response-session-info> element if the request is successful. The
successful. The <response-session-info> element has zero or more of <response-session-info> element has zero or more of the following
the following child elements which provide the appropriate resource child elements which provide the appropriate resource session
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 <session-id> use later in this
section when constructing a subsequent request). section when constructing a subsequent request).
o <seq> is a numeric value returned to the Consumer client. On o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client (as determined by the <session-id> element) the consumer client
skipping to change at page 36, line 36 skipping to change at page 37, line 20
in the request (see <seq> use later in this section when in the request (see <seq> use later in this section when
constructing a subsequent request). constructing a subsequent request).
o <expires> provides a value which provides the number of seconds o <expires> provides a value which provides the number of seconds
the request for media resources is deemed alive. The Consumer the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later client should issue a refresh of the request, as discussed later
in this section, if the expires timer is due to fire and the media in this section, if the expires timer is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides information representing an o <media-server-address> provides information representing an
assigned MS. More instances of this element may appear, should assigned Media Server. More instances of this element may appear,
the MRB assign more MSs 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
skipping to change at page 37, line 27 skipping to change at page 38, line 11
for unique identification of a request. The first numeric value for unique identification of a request. The first numeric value
for the <seq> element is not meant to be '1', but SHOULD be for the <seq> element is not meant to be '1', but SHOULD be
generated randomly by the MRB: this is to reduce the chances a generated randomly by the MRB: this is to reduce the chances a
malicious MRB disrupts the session created by this MRB, as malicious MRB disrupts the session created by this MRB, as
explained in Section 12. explained in Section 12.
o <action> element provides the operation to be carried out by the o <action> element provides the operation to be carried out by the
MRB on receiving the request: MRB on 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 update the existing session at the MRB with alternate media
requirements which are contained in the remainder of the resource requirements. If the requested resource information
request. If the requested resource information is identical to is identical to the existing MRB session, the MRB will attempt
the existing MRB session, the MRB will attempt a session a session refresh. If the information has changed, the MRB
refresh. If the information has changed, the MRB will attempt will attempt to update the existing session with the new
to update the existing session with the new information. If information. If the operation is successful, the 200 status
the operation is successful, the 200 status code in the code in the response is returned in the status attribute of 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 at 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
skipping to change at page 41, line 9 skipping to change at page 41, line 38
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 zero or more of the following child
element: element:
<rtp-codec>: Describes a required codec and the number of sessions <rtp-codec>: Describes a required codec and the number of sessions
using that codec. The <rtp-codec> element has one attribute. The using that codec. The <rtp-codec> element has one attribute. The
value of the attribute 'name' is a 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
element. The child element, <decoding>, has as content the elements. The child element, <decoding>, contains the number of
decimal number of RTP sessions required for decoding using the RTP sessions required for decoding using the specified codec. The
specified codec. The child element, <encoding>, has as content child element, <encoding>, contains the number of RTP sessions
the decimal number of RTP sessions required for encoding using the required for encoding using the specified codec.
specified codec.
5.2.5.1.2.2. <file-formats> element 5.2.5.1.2.2. <file-formats> element
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
for the purpose of playing media. 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-format" but the name "file-format" is being used due to
existing implementations The element MAY be present. existing implementations The element MAY be present.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
skipping to change at page 41, line 48 skipping to change at page 42, line 28
5.2.5.1.2.3. <dtmf> element 5.2.5.1.2.3. <dtmf> element
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 then has <detect> element has no attributes. The <detect> element has a
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 needed, and it can only be a case provides the type of DTMF required, and is a case insensitive
insensitive string containing either 'RFC4733' [RFC4733] or string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
'Media' (detecting tones as signals from the audio stream). The tones as signals from the audio stream). The 'package' attribute
'package' attribute provides the name of the Media Control Channel provides the name of the Media Control Channel Framework package,
Framework package, compliant with the specification in the related compliant with the specification in the related IANA registry
IANA registry (e.g., "msc-ivr/1.0"), for which the DTMF type (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
applies.
<generate>: Indicates the required support for DTMF generation. <generate>: Indicates the required support for DTMF generation.
The <generate> element has no attributes. The <generate> element The <generate> element has no attributes. The <generate> element
then has a further child element, <dtmf-type>. The <dtmf-type> has a single child element, <dtmf-type>. The <dtmf-type> element
element has two attributes, 'name' and 'package. The 'name' has two attributes, 'name' and 'package. The 'name' attribute
attribute provides the type of DTMF being needed, and it can only provides the type of DTMF required, and is a case insensitive
be a case insensitive string containing either 'RFC4733' [RFC4733] string containing either 'RFC4733' [RFC4733] or 'Media'
or 'Media' (generating tones as signals in the audio stream). The (generating tones as signals in the audio stream). The 'package'
'package' attribute provides the name of the Media Control Channel attribute provides the name of the Media Control Channel Framework
Framework package, compliant with the specification in the related package, compliant with the specification in the related IANA
IANA registry (e.g., "msc-ivr/1.0"), for which the DTMF type registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
applies.
<passthrough>: Indicates the required support for passing DTMF <passthrough>: Indicates the required support for passing DTMF
through without re-encoding. The <passthrough> element has no through without re-encoding. The <passthrough> element has no
attributes. The <passthrough> element then has a further child attributes. The <passthrough> element then has a further child
element, <dtmf-type>. The <dtmf-type> element has two attributes, element, <dtmf-type>. The <dtmf-type> element has two attributes,
'name' and 'package. The 'name' attribute provides the type of 'name' and 'package. The 'name' attribute provides the type of
DTMF being needed, and it can only be a case insensitive string DTMF required, and is a case insensitive string containing either
containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
signals through the audio stream). The 'package' attribute the audio stream). The 'package' attribute provides the name of
provides the name of the Media Control Channel Framework package, the Media Control Channel Framework package, compliant with the
compliant with the specification in the related IANA registry specification in the related IANA registry (e.g., "msc-ivr/1.0"),
(e.g., "msc-ivr/1.0"), for which the DTMF type applies. 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 a media server must
support for IVR. In particular, the request refers to both country support for IVR. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The <tones> element has no attributes. The <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 with respect <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> has one child element. The child element,
<country-code>, requests a specific country code, compliant with <country-code>, requests a specific country code, compliant with
the ISO 3166-1 [ISO.3166-1] specification. The <country-code> the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
element has a single attribute, 'package'. The attribute element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
<h248-codes>: Describes the requested H.248 codes with respect to <h248-codes>: Describes the requested H.248 codes in relation to
tones. The <h248-codes> element has no attributes. The <h248- tones. The <h248-codes> element has no attributes. The <h248-
codes> has one child element. The child element, <h248-code>, codes> has one child element. The child element, <h248-code>,
requests a specific H.248 code, compliant with the ITU-T requests a specific H.248 code, compliant with the ITU-T
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
be either specific (e.g., cg/dt to only report the Dial Tone from be either specific (e.g., cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g., cg/* to report the Call Progress Tones package) or generic (e.g., cg/* to report
all the tones from the Call Progress Tones package) using wild- all the tones from the Call Progress Tones package) using wild-
cards. The <h248-code> element has a single attribute, 'package'. cards. The <h248-code> element has a single attribute, 'package'.
The attribute 'package' provides the name of the Media Control The attribute 'package' provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), in which the related IANA registry (e.g., "msc-ivr/1.0"), in which the
specified codes are requested. specified codes are requested.
5.2.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.1988]
codes) for what regards both ASR and TTS. The <asr-tts> element has codes) in relation to both ASR and TTS. The <asr-tts> element has no
no attributes. The <asr-tts> element has zero or more of the attributes. The <asr-tts> element has zero or more of the following
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> has
one child element. The child element, <language>, requests the MS one child element. The child element, <language>, requests the
supports ASR for a specific language. The <language> element has Media Server supports ASR for a specific language. The <language>
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains element has a single attribute, 'xml:lang'. The attribute 'xml:
the ISO-639-1 [ISO.639.1988] code of the supported language. lang' contains the ISO-639-1 [ISO.639.1988] 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> has
one child element. The child element, <language>, requests the MS one child element. The child element, <language>, requests the
supports tts for a specific language. The <language> element has Media Server supports tts for a specific language. The <language>
a single attribute, 'xml:lang'. The attribute 'xml:lang' contains element has a single attribute, 'xml:lang'. The attribute 'xml:
the ISO-639-1 [ISO.639.1988] code of the supported language. lang' contains the ISO-639-1 [ISO.639.1988] code of the supported
language.
5.2.5.1.2.6. <vxml> element 5.2.5.1.2.6. <vxml> element
The <vxml> element specifies if the Consumer client required VoiceXML The <vxml> element specifies if the Consumer client requires VoiceXML
and if it does which protocols the support is exposed through (e.g., and if so the supported protocols (e.g., via the control framework,
via the control framework, RFC4240 [RFC4240], or RFC5552 [RFC5552]). RFC4240 [RFC4240], or RFC5552 [RFC5552]). The element MAY be
present.
The element MAY be present.
The <vxml> element has zero or more of the following child elements: The <vxml> element has zero or more of the following child elements:
<vxml-mode>: has two attributes, 'package' and 'require'. The <vxml-mode>: has two attributes, 'package' and 'require'. The
'package' attribute provides the name of the Media Control Channel 'package' attribute provides the name of the Media Control Channel
Framework package, compliant with the Section 13.1.1 of [RFC6230], Framework package, compliant with the Section 13.1.1 of [RFC6230],
for which the VXML support applies. The 'require' attribute for which the VXML support applies. The 'require' attribute
specifies the type of VXML support required by the Consumer client specifies the type of VXML support required by the Consumer client
(e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package (e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package
[RFC6231]), and valid values are case insensitive RFC references [RFC6231]), and valid values are case insensitive RFC references
skipping to change at page 44, line 29 skipping to change at page 45, line 11
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 the
Consumer client does not require VXML support. 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 it's More precisely, this section is entirely optional, and is
implementation specific to fill it with just the details each implementation specific in its level of population.
implementor deems necessary for any optimization that may be needed.
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>
skipping to change at page 45, line 31 skipping to change at page 46, line 11
characters are the same as those in XML (viz., tab, carriage return, characters are the same as those in XML (viz., tab, carriage return,
line feed, and the legal characters of Unicode and ISO/IEC 10646 [see line feed, and the legal characters of Unicode and ISO/IEC 10646 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. http://www.w3.org/TR/xml/ section 2.2]). 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 provides the amount of time The <max-prepared-duration> element indicates the amount of time
required by the Consumer client that a media dialog can be prepared 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 the 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 supports fetching media resources via example, does the Media Server support fetching media resources via
RTSP, HTTP, NFS, etc protocols. The element MAY be present. RTSP, HTTP, NFS, etc protocols. 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 'name' attribute provides the scheme name of the protocol The 'name' attribute provides the scheme name of the protocol
required for fetching resources: valid values are case insensitive required for fetching resources: valid values are case insensitive
scheme names (e.g., RTSP, HTTP, HTTPS, NFS, etc.). The 'package' scheme names (e.g., RTSP, HTTP, HTTPS, NFS, etc.). 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 the Section 13.1.1 of [RFC6230], for which
the scheme name applies. the scheme name applies.
The same considerations about file transfer and live streaming The same considerations relating to file transfer and live streaming
explained in Section 5.1.5.15 apply here as well. are explained further in Section 5.1.5.15, whcih apply here as well.
5.2.5.1.3. <mixerInfo> element 5.2.5.1.3. <mixerInfo> element
The <mixerInfo> element provides information for general Consumer The <mixerInfo> element provides information for general Consumer
request information that is Mixer specific. The following sub- request information that is Mixer specific. The following sub-
sections describe the elements of the <mixerInfo> element, <mixers>, sections describe the elements of the <mixerInfo> element, <mixers>,
<file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application- <file-formats>, <dtmf-type>, <tones>, <mixing-mode>, <application-
data>, <location> and <encryption>. data>, <location> and <encryption>.
5.2.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 required mixed RTP sessions. The <mix> element <mix>: Describes the required mixed RTP sessions. The <mix>
has one attribute. The value of the attribute 'users' is the element has one attribute. The value of the attribute, 'users',
number of participants required in the mix. The <mix> element has is the number of participants required in the mix. The <mix>
one child element. The child element, <rtp-codec>, contains the element has one child element. The child element, <rtp-codec>,
same information relating to RTP sessions as defined in contains the same information relating to RTP sessions as defined
Section 5.1.5.3. The element MAY be present. in 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 that is supported. A valid value is a the type of file format supported. A valid value is a media type
media type which, depending on its definition, can include which, depending on its definition, can include additional
additional parameters (e.g., [RFC6381]). The <required-format> parameters (e.g., [RFC6381]). The <required-format> element has a
element then has a further child element, <required-file-package>. child element, <required-file-package>. The <required-file-
The <required-file-package> element contains a single attribute, package> element contains a single attribute, 'required-file-
'required-file-package-name', which contains the name of the Media package-name', which contains the name of the Media Control
Control Channel Framework package, compliant with the Section Channel Framework package, compliant with the Section 13.1.1 of
13.1.1 of [RFC6230], for which the file format support applies. [RFC6230], for which the file format support applies.
5.2.5.1.3.3. <dtmf> element 5.2.5.1.3.3. <dtmf> element
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 can only be a case provides the type of DTMF being used, and it is a case insensitive
insensitive string containing either 'RFC4733' [RFC4733] or string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
'Media' (detecting tones as signals from the audio stream). The tones as signals from the audio stream). The 'package' attribute
'package' attribute provides the name of the Media Control Channel provides the name of the Media Control Channel Framework package,
Framework package, compliant with the specification in the related compliant with the specification in the related IANA registry
IANA registry (e.g., "msc-ivr/1.0"), for which the DTMF type (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
applies.
<generate>: Indicates the required support for DTMF generation. <generate>: Indicates the required support for DTMF generation.
The <generate> element has no attributes. The <generate> element The <generate> element has no attributes. The <generate> element
then has a further child element, <dtmf-type>. The <dtmf-type> has a single child element, <dtmf-type>. The <dtmf-type> element
element has two attributes, 'name' and 'package. The 'name' has two attributes, 'name' and 'package. The 'name' attribute
attribute provides the type of DTMF being used, and it can only be provides the type of DTMF being used, and is a case insensitive
a case insensitive string containing either 'RFC4733' [RFC4733] or string containing either 'RFC4733' [RFC4733] or 'Media'
'Media' (generating tones as signals in the audio stream). The (generating tones as signals in the audio stream). The 'package'
'package' attribute provides the name of the Media Control Channel attribute provides the name of the Media Control Channel Framework
Framework package, compliant with the specification in the related package, compliant with the specification in the related IANA
IANA registry (e.g., "msc-ivr/1.0"), for which the DTMF type registry (e.g., "msc-ivr/1.0"), for which the DTMF type applies.
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 has a single child element,
element, <dtmf-type>. The <dtmf-type> element has two attributes, <dtmf-type>. The <dtmf-type> element has two attributes, 'name'
'name' and 'package. The 'name' attribute provides the type of and 'package. The 'name' attribute provides the type of DTMF
DTMF being used, and it can only be a case insensitive string being used, and is a case insensitive string containing either
containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
signals through the audio stream). The 'package' attribute the audio stream). The 'package' attribute provides the name of
provides the name of the Media Control Channel Framework package, the Media Control Channel Framework package, compliant with the
compliant with the specification in the related IANA registry specification in the related IANA registry (e.g., "msc-ivr/1.0"),
(e.g., "msc-ivr/1.0"), for which the DTMF type applies. 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 a media server must
support for a mix. In particular, the request refers to both country support for a mix. In particular, the request refers to both country
codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality codes support (ISO 3166-1 [ISO.3166-1]) and requested functionality
(ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be
present. present.
The <tones> element has no attributes. The <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 with respect <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> has a single child element. The child element,
<country-code>, requests a specific country code, compliant with <country-code>, requests a specific country code, compliant with
the ISO 3166-1 [ISO.3166-1] specification. The <country-code> the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
element has a single attribute, 'package'. The attribute element has a single attribute, 'package'. The attribute
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), in which the tones from the registry (e.g., "msc-ivr/1.0"), in which the tones from the
specified country code are requested. specified country code are requested.
<h248-codes>: Describes the requested H.248 codes with respect to <h248-codes>: Describes the requested H.248 codes with respect to
tones. The <h248-codes> element has no attributes. The <h248- tones. The <h248-codes> element has no attributes. The <h248-
codes> has one child element. The child element, <h248-code>, codes> has a single child element. The child element, <h248-
requests a specific H.248 code, compliant with the ITU-T code>, requests a specific H.248 code, compliant with the ITU-T
Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can
be either specific (e.g., cg/dt to only report the Dial Tone from be either specific (e.g., cg/dt to only report the Dial Tone from
the Call Progress Tones package) or generic (e.g., cg/* to report the Call Progress Tones package) or generic (e.g., cg/* to report
all the tones from the Call Progress Tones package) using wild- all the tones from the Call Progress Tones package) using wild-
cards. The <h248-code> element has a single attribute, 'package'. cards. The <h248-code> element has a single attribute, 'package'.
The attribute 'package' provides the name of the Media Control The attribute 'package' provides the name of the Media Control
Channel Framework package, compliant with the specification in the Channel Framework package, compliant with the specification in the
related IANA registry (e.g., "msc-ivr/1.0"), in which the related IANA registry (e.g., "msc-ivr/1.0"), in which the
specified codes are requested. specified codes are requested.
5.2.5.1.3.5. <mixing-modes> 5.2.5.1.3.5. <mixing-modes>
The <mixing-modes> element requests information about the support for The <mixing-modes> element requests information relating to support
audio and video mixing of a Media Server, specifically a list of for audio and video mixing; more specifically a list of supported
supported algorithms to mix audio and a list of supported video algorithms to mix audio and a list of supported video presentation
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 specific requested 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 are 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 specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support is requested. 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
skipping to change at page 49, line 42 skipping to change at page 50, line 25
is of type boolean with a value of 'true' indicating that the is of type boolean with a value of 'true' indicating that the
Consumer Client requires automatic Voice Activated Switching. The Consumer Client requires automatic Voice Activated Switching. The
'activespeakermix' attribute is of type boolean with a value of 'activespeakermix' attribute is of type boolean with a value of
'true' indicating that the Consumer Client requires an additional 'true' indicating that the Consumer Client requires an additional
video stream for the loudest speaker participant without its video stream for the loudest speaker participant without its
contribution. The <video-mixing-modes> element has one child contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains the element. The child element, <video-mixing-mode>, contains the
name of a specific video presentation layout. The name may refer name of a specific video presentation layout. The name may refer
to one of predefined video layouts defined in the XCON conference to one of predefined video layouts defined in the XCON conference
information data model, or to non-XCON layouts as well, as long as information data model, or to non-XCON layouts as well, as long as
they are properly prefixed. The <video-mixing-mode> element has a they are appropriately prefixed. The <video-mixing-mode> element
single attribute, 'package'. The attribute 'package' provides the has a single attribute, 'package'. The attribute 'package'
name of the Media Control Channel Framework package, compliant provides the name of the Media Control Channel Framework package,
with the specification in the related IANA registry (e.g., "msc- compliant with the specification in the related IANA registry
ivr/1.0"), for which the algorithm support is requested. (e.g., "msc-ivr/1.0"), 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 are 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 [see
http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.
skipping to change at page 50, line 42 skipping to change at page 51, line 27
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. element MAY be present.
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has zero or more of the following child The <encryption> element has zero or more of the following child
elements: elements:
<keying-mechanism>: has no attributes. The element provides the <keying-mechanism>: has no attributes. The element provides the
name of a keying mechanism the Cosumer client requires for name of a keying mechanism the Consumer client requires for
encrypting mixed RTP media streams. encrypting mixed RTP media streams.
The presence of at least one <keying-mechanism> child element would The presence of at least one <keying-mechanism> child element would
indicate that the Consumer client does require mixed RTP media stream indicate that the Consumer client does require mixed RTP media stream
encryption as specified by the child element itself. An empty encryption as specified by the child element itself. An empty
<encryption> element would otherwise indicate the client does not <encryption> element would otherwise indicate the client does not
require RTP encryption at all. require RTP encryption at all.
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> element
The <mediaResourceResponse> element provides a information for The <mediaResourceResponse> element provides information for clients
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 the client provided in the 'id' attribute in the
<mediaResourceRequest> the response is for. The 'status' attribute <mediaResourceRequest> the response is for. The 'status' attribute
indicates the status code of the operation. The following status indicates the status code of the operation. The following status
codes are defined for 'status': codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
skipping to change at page 51, line 43 skipping to change at page 52, line 26
| | | | | |
| 409 | Unable to update Resource | | 409 | Unable to update Resource |
| | | | | |
| 410 | Unable to remove Resource | | 410 | Unable to remove Resource |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 2: <response> status codes Table 2: <response> status codes
In case a new media resource request made by an AS has been accepted, In case a new media resource request made by an client application
the MRB MUST reply with a <mediaResourceResponse> with status code has been accepted, the MRB MUST reply with a <mediaResourceResponse>
200. The same rule applies whenever a request to update with status code 200. The same rule applies whenever a request to
(action='update') or remove (action='remove') an existing transaction update (action='update') or remove (action='remove') an existing
can be fulfilled by the MRB. transaction 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 MS able to fulfil the requirements the MRB couldn't find any Media Server able to fulfil the
presented by the AS in its request, the MRB MUST reply with a requirements presented by the Application Server in its request, the
<mediaResourceResponse> with status code 408. If a syntactically MRB MUST reply with a <mediaResourceResponse> with status code 408.
correct request fails because the MRB couldn't update an existing If a syntactically correct request fails because the MRB couldn't
request according to the new requirements presented by the AS in its update an existing request according to the new requirements
request, the MRB MUST reply with a <mediaResourceResponse> with presented by the Application Server in its request, the MRB MUST
status code 409. If a syntactically correct request fails because reply with a <mediaResourceResponse> with status code 409. If a
the MRB couldn't remove an existing request and release the related syntactically correct request fails because the MRB couldn't remove
resources as requested by the AS, the MRB MUST reply with a an existing request and release the related resources as requested by
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 presented in Further details on status codes 409 and 410 are included in
Section 5.2.3, where the leasing mechanism, together with its related Section 5.2.3 where the leasing mechanism, along with its related
scenarios, is described. scenarios, are described in more detail.
The <mediaResourceResponse> element only has <response-session-info> The <mediaResourceResponse> element has <response-session-info> as a
as a child element. This element is used to describe the response of child element. This element is used to describe the response of a
a Consumer interface query and is covered in the following sub- Consumer interface query and is covered in the following sub-section.
section.
5.2.6.1.1. <response-session-info> element 5.2.6.1.1. <response-session-info> element
The <response-session-info> element is included in Consumer The <response-session-info> element is included in Consumer
responses. This applies to responses to both requests for new responses. This applies to responses to both requests for new
resources and requests to update an existing media resource session. resources and requests to update an existing media resource session.
The ability to change and remove an existing media resource session The ability to change and remove an existing media resource session
is described in more detail in Section 5.2.3. 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 <response-
session-info> child, which describes the media resource session which session-info> child, which describes the media resource session
was addressed by the request. If the request was not successful, the addressed by the request. If the request was not successful, the
<mediaResourceResponse> MUST NOT have a <response-session-info> <mediaResourceResponse> MUST NOT have a <response-session-info>
child. child.
The contents of a <response-session-info> element has no attributes. The contents of a <response-session-info> element has no attributes.
The contents of a <response-session-info> element has zero or more of The contents of a <response-session-info> element has zero or more of
the following child elements: the following child elements:
<session-id>: is a unique identifier that explicitly references an <session-id>: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
skipping to change at page 53, line 28 skipping to change at page 54, line 11
refreshed before expiry, the MRB will re-claim the resources and refreshed before expiry, the MRB will re-claim the resources and
they will no longer be guaranteed. It is RECOMMENDED that a they will no longer be guaranteed. It is RECOMMENDED that a
minimum value of 300 seconds be used for the value of the minimum value of 300 seconds be used for the value of the
'expires' attribute. It is also RECOMMENDED that a Consumer 'expires' attribute. It is also RECOMMENDED that a Consumer
client refresh the lease at an interval that is not too close to client refresh the lease at an interval that is not too close to
the expiry time. A value of 80% of the time-out period could be the expiry time. A value of 80% of the time-out period could be
used. For example, if the time-out period is 300 seconds, the used. For example, if the time-out period is 300 seconds, the
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 MS <media-server-address>: provides information to reach the Media
handling the requested media resource. One or more instances of Server handling the requested media resource. One or more
these element may appear. The <media-server-address> element has instances of these element may appear. The <media-server-address>
a single attribute named 'uri' which supplies a SIP URI that element has a single attribute named 'uri' which supplies a SIP
reaches the specified media server. It also has three optional URI that reaches the specified media server. It also has three
elements <connection-id>, <ivr-sessions>, and <mixers>. The <ivr- optional elements <connection-id>, <ivr-sessions>, and <mixers>.
sessions> and <mixers> are defined in Section 5.2.5.1.2.1 and The <ivr-sessions> and <mixers> are defined in Section 5.2.5.1.2.1
Section 5.2.5.1.3.1 and have the same meaning but are applied to and Section 5.2.5.1.3.1 and have the same meaning but are applied
individual media server instances as a subset of the overall 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
MSs are assigned in an IAMM operation, exactly one <media-server- Media Servers are assigned in an IAMM operation, exactly one
address> element, the one describing the one that provided the <media-server-address> element, more specifically the media server
media dialog or CFW response, will have a <connection-id> element. that provided the media dialog or CFW response, will have a
For more information on the use of the <connection-id> element for <connection-id> element. Additional information relating to the
media dialogs, instead, see Section 6. use of the <connection-id> element for media dialogs is included
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. In-Line Unaware MRB Mode
(IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation. (IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation.
This section further describes IUMM. This section further describes IUMM.
It should be noted that the introduction of an MRB entity into the It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be network, as specified in this document, requires interfaces to be
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 Section 5.2.1(Query mode) and
Section 5.2.2(IAMM). Nevertheless, an MRB is conceived to also be Section 5.2.2(IAMM). An MRB entity can also act in a client unaware
able to act in a client unaware mode when it is deployed into the mode when deployed into the network. This allows any SIP compliant
network. This allows any SIP compliant client entity, as defined by client entity, as defined by RFC 3261 [RFC3261] and its extensions,
RFC 3261 [RFC3261] and its extensions, to send requests to an MRB to send requests to an MRB which in turn will select an appropriate
which in turn will select an appropriate media server based on media server based on knowledge of media server resources it
knowledge of media server resources it currently has available currently has available transparently to the client entity. Using an
transparently to the client entity. Using an MRB in this mode allows MRB in this mode allows for easy migration of current applications
for easy migration of current applications and services that are and services that are unaware of the MRB concept and would simply
unaware of the MRB concept and would simply require a configuration require a configuration change resulting in the MRB being set as a
change resulting in the MRB being set as a SIP outbound proxy for SIP outbound proxy for clients requiring media services.
clients requiring media services.
With IUMM, the MRB may conclude that an assigned media resource is no With IUMM, the MRB may conclude that an assigned media resource is no
longer needed when it receives a SIP BYE from the application server longer needed when it receives a SIP BYE from the application server
or media server that ends that SIP dialog that initiated the request. or media server that ends that SIP dialog that initiated the request.
As with IAMM, in IUMM the SIP INVITE from the application server As with IAMM, in IUMM the SIP INVITE from the Application Server
could convey application/sdp payload to either set up a media dialog could convey application/sdp payload to either set up a media dialog
or a Control Framework control channel. In either case, in order to or a Control Framework control channel. In either case, in order to
permit the AS to associate a media dialog with a control channel to permit the Application Server to associate a media dialog with a
the same media server using the procedures of [RFC6230] section 6, control channel to the same Media Server, using the procedures of
the MRB should be acting as a SIP proxy (and not a B2BUA) so that the [RFC6230] section 6, the MRB should be acting as a SIP proxy (and not
SIP address of the targeted media server can be transparently passed a B2BUA). This allows the SIP address of the targeted Media Server
back to the application server in the SIP response and so that the to be transparently passed back to the Application Server in the SIP
SIP dialog is between the application server and the media server. response resulting in a SIP dialog directly between the Application
Server and the Media Server.
While IUMM has the least impact on legacy application servers, it While IUMM has the least impact on legacy application servers, it
also provides the least versatility. See Section 8. also provides the least versatility. See Section 8.
6. MRB acting as a B2BUA 6. MRB acting as a B2BUA
An MRB entity can potentially act as a SIP Back-2-Back-User-Agent An MRB entity can act as a SIP Back-2-Back-User-Agent (B2BUA) or a
(B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When SIP Proxy Server as defined in RFC 3261 [RFC3261]. When acting as a
acting as a B2BUA issues can arise when using Media Control Channel B2BUA issues can arise when using Media Control Channel packages such
packages such as the IVR[RFC6231] and Mixer[RFC6505] Packages. as the IVR[RFC6231] and Mixer[RFC6505] Packages. Specifically the
Specifically the Framework attribute 'connectionid' provided in the Framework attribute 'connectionid' provided in the appendix titled
appendix titled 'Appendix: Common Package Components' of Media 'Appendix: Common Package Components' of Media Control Channel
Control Channel Framework[RFC6230] uses a concatenation of the SIP Framework[RFC6230] uses a concatenation of the SIP dialog identifiers
dialog identifiers to be used for referencing SIP dialogs within the to be used for referencing SIP dialogs within the media control
media control channel. When a request traverses an MRB acting as a channel. When a request traverses an MRB acting as a B2BUA, the SIP
B2BUA, the SIP dialog identifiers change and so the 'connectionid' dialog identifiers change and so the 'connectionid' can not be used
can not be used as intended due to the SIP dialog identifiers as intended due to the SIP dialog identifiers changing. For this
changing. For this reason when a MRB wishes to act as a SIP B2BUA reason when a MRB wishes to act as a SIP B2BUA when handling a
when handling a request from an AS to set up a media dialog to a MS request from an Application Server to set up a media dialog to a
it MUST include the optional <connection-id> element in a Consumer Media Server it MUST include the optional <connection-id> element in
interface response with a value that provides the equivalent for the a Consumer interface response with a value that provides the
'connectionid' ('Local Dialog Tag' + 'Remote Dialog Tag') for the far equivalent for the 'connectionid' ('Local Dialog Tag' + 'Remote
side of the B2BUA. If present, this value MUST be used as the value Dialog Tag') for the far side of the B2BUA. If present, this value
for the 'connectionid' in packages where the Common Package MUST be used as the value for the 'connectionid' in packages where
Components are used. The <connection-id> element MUST NOT be the Common Package Components are used. The <connection-id> element
included in a HTTP Consumer interface response. MUST NOT be included in a HTTP Consumer interface response.
It is important to point out that, although more MSs instances may be It is important to point out that, although more Media Server
returned in a Consumer response (i.e., the MRB has assigned more than instances may be returned in a Consumer response (i.e., the MRB has
one MS to a Consumer request to fulfill the AS requirements), in IAMM assigned more than one Media Server to a Consumer request to fulfill
the MRB will only act as a B2BUA with a single MS: in this case, the Application Server requirements), in IAMM the MRB will only act
exactly one <media-server-address> element, the one describing the as a B2BUA with a single Media Server. In this case exactly one
one that provided the media dialog or CFW response, will have a <media-server-address> element, describing the media dialog or CFW
<connection-id> element, which will instead be missing in the other response, will have a <connection-id> element which will not be
<media-server-address> elements. included in any additional <media-server-address> elements.
7. Multi-modal MRB Implementations 7. Multi-modal MRB Implementations
An MRB implementation may operate multi-modally with a collection of An MRB implementation may operate multi-modally with a collection of
application server clients all sharing the same pool of media Application Server clients all sharing the same pool of media
resources. I.e., an MRB may be simultaneously operating in Query resources. I.e., an MRB may be simultaneously operating in Query
mode, IAMM and IUMM. It knows in which mode to act on any particular mode, IAMM and IUMM. It knows in which mode to act on any particular
request from a client depending on the nature of the request: request from a client depending on the context of the request:
o If the received quest is HTTP Post with application/ o If the received request is a HTTP POST message with application/
mrb-consumer+xml content, then MRB processes it in Query mode. mrb-consumer+xml content, then 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 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 MRB
processes it in IUMM. processes it in IUMM.
8. Relative Merits of Query Mode, IAMM, and IUMM 8. Relative Merits of Query Mode, IAMM, and IUMM
At a high level, the possible application server MRB interactions can At a high level, the possible Application Server MRB interactions can
be distinguished among the following basic types: be distinguished by the following basic types:
a. Query mode, in which the client is requesting the assignment by a. Query mode - the client is requesting the assignment by MRB of
MRB of suitable MSs resources; suitable Media Server resources;
b. IAMM in which the client is requesting the assignment by MRB of b. IAMM - the client is requesting the assignment by MRB of suitable
suitable MSs resources and the establishment of a media dialog to Media Server resources and the establishment of a media dialog to
one of the MSs; one of the Media Servers;
c. IAMM in which the client is requesting the assignment by MRB of c. IAMM - the client is requesting the assignment by MRB of suitable
suitable MSs resources and the establishment of a CFW control Media Server resources and the establishment of a CFW control
channel to one of the MSs; channel to one of the Media Servers;
d. IUMM where the client is requesting the establishment of a media d. IUMM - the client is requesting the establishment of a media
dialog to MS resources; dialog to a Media Server resource;
e. IUMM where the client is requesting the establishment of a CFW e. IUMM - the client is requesting the establishment of a CFW
control channel to MS resources. control channel to a Media Server resource.
Each type of interaction has advantages and disadvantages compared to Each type of interaction has advantages and disadvantages, where such
the others, where such considerations may have to do with the considerations related to the versatility of what MRB can provide,
versatility of what MRB can provide, technical aspects such as technical aspects such as efficiency in different application
efficiency in different application scenarios, complexity, delay, use scenarios, complexity, delay, use with legacy Application Servers, or
with legacy application servers, or use with the Media Control use with the Media Control Channel Framework. Depending on the
Channel Framework. Depending on the characteristics of a particular characteristics of a particular setting that an MRB is intended to
setting that an MRB is intended to support, some of the above support, some of the above interaction types may be more appropriate
interaction types may be more appropriate than others. This section than others. This section provides a few observations on relative
makes a few observations on relative merits, but is not intended to merits, but is not intended to be exhaustive. Some constraints of a
be exhaustive. Some constraints of a given interaction type may be given interaction type may be subtle.
subtle.
o About operation with other types of media control: Any of the o Operation with other types of media control: Any of the types of
types of interactions work with the use RFC 4240 [RFC4240] and RFC interactions work with the use RFC 4240 [RFC4240] and RFC 5552
5552 [RFC5552] where initial control instructions are conveyed in [RFC5552] where initial control instructions are conveyed in the
the SIP INVITE from the application server for the media dialog to SIP INVITE from the Application Server for the media dialog to the
the media server and subsequent instructions may be fetched using Media Server and subsequent instructions may be fetched using
HTTP. Query mode (a), IAMM/media dialog (b) and IUMM/media dialog HTTP. Query mode (a), IAMM/media dialog (b) and IUMM/media dialog
(d) work with MSML as per RFC 5707 [RFC5707] or MSCML as per RFC (d) work with MSML as per RFC 5707 [RFC5707] or MSCML as per RFC
5022 [RFC5022]. 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. On the other hand, with IUMM the application Application Server. When using IUMM the Application Server does
server does not specify the characteristics of the type of media not specify the characteristics of the type of media resource it
resource it needs because the <mediaResourceRequest> element is requires as the <mediaResourceRequest> element is not passed to
not passed to the MRB. For IUMM media dialog (d) the best the MRB the MRB. For IUMM media dialog (d), the MRB can deduce an
can do to deduce an appropriate media resource gleaned from appropriate media resource on a best effort basis using
examining other information in the SIP INVITE, such as the SDP information gleaned from examining information in the SIP INVITE.
information for the media dialog, or initial control information This includes the SDP information for the media dialog, or initial
in the SIP Request URI as per RFC 4240 [RFC4240]. With IUMM/ control information in the SIP Request URI as per RFC 4240
control channel (e) there is even less information for the MRB to [RFC4240]. With IUMM/control channel (e) there is even less
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 signaling to send the media dialog to media dialog. I.e., the SIP signalling to send the media dialog
the selected media server must be directly between the application to the selected media server must be directly between the
server and that media server, and not through the MRB. Otherwise, Application Server and that media server, and not through the MRB.
MRB might send the media dialog to a different media server. Unless resources can be confidentially identified, the MRB could
Likewise, if using IUMM/media dialog (d), the subsequent send the media dialog to a different Media Server. Likewise, if
establishment of a control channel should not be done with IUMM/ using IUMM/media dialog (d), the subsequent establishment of a
control channel (e). control channel should not be done with IUMM/control channel (e)
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 their use over conferencing ports) in advance of use and retaining use over a
a period of time, independent of whether there are media dialogs period of time, independent of whether there are media dialogs to
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. Likewise for making a subsequent request to
increase or decrease the amount of resources previously awarded. 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 not 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 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 the
latter would involve setting up an additional control channel latter would involve setting up an additional control channel
every time an AS has a new request for MBR for media resources. every time an Application Server has a new request for MRB for
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. For what concerns the Consumer interface, both Query and interfaces. Both Query and Inline modes are addressed.
Inline modes 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 whitespace
would not appear in the actual protocol contents. Besides, also note would not appear in the actual protocol contents. Besides, also note
that the indentation of the XML content is only provided for that the indentation of the XML content is only provided for
readability: actual messages will follow strict XML syntax, which readability: actual messages will follow strict XML syntax, which
allows for, but does not require, indentation. allows for, but does not require, indentation.
9.1. Publish Example 9.1. Publish Example
The following example assumes a control channel has been established The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework and synced as described in the Media Control Channel Framework
([RFC6230]). ([RFC6230]).
Figure 9 shows the subscription/notification mechanism the Publish Figure 9 shows the subscription/notification mechanism the Publish
interface is based on, as defined in Section 5.1. The MRB subscribes interface is based on, as defined in Section 5.1. The MRB subscribes
for information at the MS (message A1.), and the MS accepts the for information at the Media Server (message A1.), and the Media
subscription (A2). Notifications are triggered by the MS (A3.) and Server accepts the subscription (A2). Notifications are triggered by
acknowledged by the MRB (A4.). the Media Server (A3.) and acknowledged by the MRB (A4.).
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 33 skipping to change at page 61, line 12
. . . .
. . . .
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 MS accepting the subscription (A2), in an <mrbresponse> (CFW 2. the Media Server accepting the subscription (A2), in an
200); <mrbresponse> (CFW 200);
3. a notification (A3), in a <mrbnotification> (CFW CONTROL event); 3. a notification (A3), in a <mrbnotification> (CFW CONTROL event);
4. the ack to the notification (A4), in a framework level 200 4. the ack to the notification (A4), 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
skipping to change at page 65, line 25 skipping to change at page 66, line 7
in two different modes: Query and Inline-aware. When in Query mode, in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of Consumer messages are transported in HTTP messages: an example of
such an approach is presented in Section 9.2.1. When in Inline-aware such an approach is presented in Section 9.2.1. When in Inline-aware
mode, instead, messages are transported as part of SIP negotiations: mode, instead, messages are transported as part of SIP negotiations:
considering that SIP negotiations may be related to either the considering that SIP negotiations may be related to either the
creation of a control channel or to a UAC media dialog, two separate creation of a control channel or to a UAC media dialog, two separate
examples of such an approach are presented in Section 9.2.2. examples of such an approach are presented in Section 9.2.2.
9.2.1. Query Example 9.2.1. Query Example
The following example assumes the interested AS already knows the The following example assumes the interested Application Server
HTTP URL where an MRB is listening for Consumer messages. already knows the HTTP URL where an MRB is listening for Consumer
messages.
Figure 10 shows the HTTP-based transaction between the AS and the Figure 10 shows the HTTP-based transaction between the Application
MRB. The AS sends a consumer request as payload of an HTTP POST Server and the MRB. The Application Server sends a consumer request
message (1.), and the MRB provides an answer in an HTTP 200 OK as payload of an HTTP POST message (1.), and the MRB provides an
message (2.). Specifically, as it will be shown in the dumps, the AS answer in an HTTP 200 OK message (2.). Specifically, as it will be
is interested in 100 IVR ports: the MRB finds two MSs that can shown in the examples, the Application Server is interested in 100
satisfy the request (one providing 60 ports, the other 40 ports) and IVR ports: the MRB finds two Media Servers that can satisfy the
reports them to the AS. request (one providing 60 ports, the other 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 68, line 17 skipping to change at page 68, line 31
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>40</decoding> <decoding>40</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
As the dumps evince, the request and response are associated by means As the example show, the request and response are associated by means
of the 'id' attribute (id="gh11x23v"). Besides, the MRB has picked of the 'id' attribute (id="gh11x23v"). The MRB has picked '9' as the
'9' as the random sequence number that needs to be incremented by the random sequence number that needs to be incremented by the
AS for the following request associated with the same session. Application Server for the following request associated with the 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 AS has the address of two received the 'mediaResourceResponse', the Application Server has the
MSs able to fulfil its media requirements, and can start a Control address of two Media Servers able to fulfil its media requirements,
Dialog with one or both of them. and can start a Control Dialog with one or both of them.
9.2.2. IAMM Example 9.2.2. IAMM Example
As anticipated, two separate examples are presented for the IAMM Two separate examples are presented for the IAMM case: in fact, IAMM-
case: in fact, IAMM-mode can take advantage of two different mode can take advantage of two different approaches with respect to
approaches with respect to the SIP dialogs to be exploited to carry the SIP dialogs to be exploited to carry consumer messages, i.e.: i)
consumer messages, i.e.: i) a SIP control dialog to create a control a SIP control dialog to create a control channel, and, ii) a UAC
channel, and, ii) a UAC media dialog to attach to a MS. To make media dialog to attach to a Media Server. To make things clearer for
things clearer for the reader, the same consumer request as the one the reader, the same consumer request as the one presented in the
presented in the Query mode will be sent, in order to clarify how the Query mode will be sent, in order to clarify how the behaviour of the
behaviour 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 AS already knows the SIP The following example assumes the interested Application Server
URI where an MRB is listening as an UAS. already knows the SIP URI for 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 AS, the MRB and one MS that the MRB chooses from the two between the Application Server, the MRB and one Media Server that the
that are allocated to fulfill the request. The diagram is more MRB chooses from the two that are allocated to fulfil the request.
complex than before. This is basically a scenario envisaging the MRB The diagram is more complex than before. This is basically a
as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW- scenario envisaging the MRB as a B2BUA. The Application Server sends
related SDP and a Consumer request (multipart body). The MRB sends a a SIP INVITE (1.), containing both a CFW-related SDP and a Consumer
provisional response to the AS (2.) and starts working on the request (multipart body). The MRB sends a provisional response to
request. First of all, it makes use of the Consumer request from the the Application Server (2.) and starts working on the request. First
AS to determine which MSs should be exploited. Once the right MSs of all, it makes use of the Consumer request from the Application
have been chosen (MS1 and MS2 in the example), the MRB sends a new Server to determine which Media Servers should be exploited. Once
SIP INVITE to one of the MSs (MS1 in the example) by just including the right Media Servers have been chosen (MS1 and MS2 in the
the SDP part of the original request (3.). That MS negotiates this example), the MRB sends a new SIP INVITE to one of the Media Servers
INVITE as specified in [RFC6230] (4., 5., 6.), providing the MRB with (MS1 in the example) by just including the SDP part of the original
its own CFW-related SDP. The MRB replies to the original AS INVITE request (3.). That Media Server negotiates this INVITE as specified
in [RFC6230] (4., 5., 6.), providing the MRB with its own CFW-related
SDP. The MRB replies to the original Application Server INVITE
preparing a SIP 200 OK with another multipart body (7.): this 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 MSs and the SDP returned by the MS (MS1) in 5. determine the right Media Servers and the SDP returned by the Media
The AS finally acknowledges the 200 OK (8.), and can start a CFW Server (MS1) in 5. The Application Server finally acknowledges the
connection towards that MS (MS1). Since the MRB provided the AS with 200 OK (8.), and can start a CFW connection towards that Media Server
two MSs instances to fulfill its requirements, the AS can use the URI (MS1). Since the MRB provided the Application Server with two Media
in the <media-server-address> element in the <mediaResourceResponse> Server instances to fulfil its requirements, the Application Server
that describes the other MS to establish a CFW channel with that MS can use the URI in the <media-server-address> element in the
(MS2) as well. <mediaResourceResponse> that describes the other Media Server to
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) | | |
skipping to change at page 70, line 46 skipping to change at page 71, line 16
| | | |
| CFW SYNC | | CFW SYNC |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>| |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | |
| | | | | | | |
. . . . . . . .
. . . . . . . .
Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram
The rest of this section includes an almost full dump of the messages The rest of this section includes an almost full trace of the
associated with the previous sequence diagram. Only the relevant SIP messages associated with the previous sequence diagram. Only the
messages are shown (both the INVITEs and the 200 OKs), and only the relevant SIP messages are shown (both the INVITEs and the 200 OKs),
relevant headers are preserved for brevity (Content-Type and and only the relevant headers are preserved for brevity (Content-Type
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 (COMEDIA information to negotiate a new Control Channel) and a
Consumer <mediaResourceRequest>; Consumer <mediaResourceRequest>;
2. the INVITE sent by the MRB to the MS as a B2BUA (3.), containing 2. the INVITE sent by the MRB to the Media Server as a B2BUA (3.),
only the CFW-related SDP from the original INVITE;. containing only the CFW-related SDP from the original INVITE;.
3. the 200 OK sent by the MS back to the MRB (5.), to complete the 3. the 200 OK sent by the Media Server back to the MRB (5.), to
CFW-related negotiation (SDP only); complete the CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the 4. the 200 OK sent by the MRB back to the Application Server in
original INVITE (7.), containing both the CFW-related information response to the original INVITE (7.), containing both the CFW-
sent by the MS and a Consumer <mediaResourceRequest> documenting related information sent by the Media Server and a Consumer
the MRB's decision to use that MS. <mediaResourceRequest> documenting the MRB's decision to use that
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
v=0 v=0
skipping to change at page 74, line 30 skipping to change at page 74, line 50
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
=_Part =_Part
As the dumps evince, the only difference in the response the MRB As the previous example illustrates, the only difference in the
provides the AS with is in the 'connection-id' attribute that is response the MRB provides the Application Server with is in the
added to the first allocated MS instance: this allows the AS to 'connection-id' attribute that is added to the first allocated Media
understand the MRB has sent the CFW channel negotiation to that Server instance: this allows the Application Server to understand the
specific MS, and that the connection-id to be used (should the SIP MRB has sent the CFW channel negotiation to that specific Media
control dialog also include media-related SDP later on) is the one Server, and that the connection-id to be used is the one provided.
provided. This will be more carefully described in the next section, This will be described in more detail in the following section, for
for the media dialog-based approach. the media dialog-based approach.
The continuation of the scenario (the AS connecting to MS1 to start The continuation of the scenario (the Application Server connecting
the Control Channel and the related SYNC message, the AS connecting to MS1 to start the Control Channel and the related SYNC message, the
to MS2 as well later on, all the media dialogs being attached to Application Server connecting to MS2 as well later on, all the media
either MS) are omitted for brevity. dialogs being attached to either Media Server) are omitted for
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 AS already knows the SIP The following example assumes the interested Application Server
URI where an MRB is listening as an UAS. 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 AS, the MRB and the MS that the MRB between a SIP client, the Application Server, the MRB and the Media
chooses. The interaction is basically the same as before (e.g. for Server that the MRB chooses. The interaction is basically the same
what concerns the multipart body) but considering a new party is as previous examples (e.g. contents of the multipart body) but
involved in the communication, the diagram is slightly more complex considering a new party is involved in the communication, the diagram
than before. As before, the MRB acts as a B2BUA. A UAC sends a SIP is slightly more complex than before. As before, the MRB acts as a
INVITE to a SIP URI handled by the AS, since it is interested to its B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the
services (1.). The AS sends a provisional response (2.) and, since Application Server, since it is interested to its services (1.). The
it doesn't have the resources yet, sends to the MRB a new SIP INVITE Application Server sends a provisional response (2.) and, since 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 (multipart body). The MRB sends a provisional response to request (multipart body). The MRB sends a provisional response to
the AS (4.) and starts working on the request. First of all, it the Application Server (4.) and starts working on the request. First
makes use of the Consumer request from the AS to determine which MSs of all, it makes use of the Consumer request from the Application
should be chosen. Once the right MSs have been chosen, the MRB sends Server to determine which Media Servers should be chosen. Once the
a new SIP INVITE to one of the MSs by just including the SDP part of Media Server has been chosen, the MRB sends a new SIP INVITE to one
the original request (5.). The MS negotiates this INVITE as of the Media Servers by including the SDP part of the original
specified in [RFC6230] (6., 7., 8.) to allocate the needed media request (5.). The Media Server negotiates this INVITE as specified
resources to handle the new media dialog, eventually providing the in [RFC6230] (6., 7., 8.) to allocate the needed media resources to
MRB with its own media-related SDP. The MRB replies to the original handle the new media dialog, eventually providing the MRB with its
AS INVITE preparing a SIP 200 OK with another multipart body (9.): own media-related SDP. The MRB replies to the original Application
this multipart body includes the Consumer response from the MRB Server INVITE preparing a SIP 200 OK with a multipart body (9.): this
indicating the chosen MSs and the SDP returned by the MS in 7. The multipart body includes the Consumer response from the MRB indicating
AS finally acknowledges the 200 OK (10.), and ends the scenario by the chosen Media Servers and the SDP returned by the Media Server in
eventually providing the UAC with the SDP it needs to set-up the RTP 7. The Application Server finally acknowledges the 200 OK (10.), and
channels with the chosen MS: a separate direct SIP control dialog may ends the scenario by eventually providing the UAC with the SDP it
be initiated by the AS to the same MS in order to set up a control needs to set-up the RTP channels with the chosen Media Server: a
channel to manipulate the media dialog media. separate direct SIP control dialog may be initiated by the
Application Server to the same Media Server in order to set up a
control channel to manipulate the media dialog media.
As with the IAMM - CFW example in the prior section, this example has As with the IAMM - CFW example in the prior section, this example has
the MRB selecting MS resources across two MS instances. And here the MRB selecting Media Server resources across two Media Server
again the convention can be that the MRB sent the SIP INVITE to the instances. The convention could be that the MRB sent the SIP INVITE
first MS in the list provided to the AS in the Consumer response to the first Media Server in the list provided to the Application
information. For the sake of brevity, the considerations about Server in the Consumer response information. For the sake of
connecting to the other MS as well are omitted, since they have brevity, the considerations about connecting to the other Media
already been addressed in the previous section. Servers as well are omitted, since they have already been addressed
in the previous section.
Please note that, to ease the reading of the protocol contents, a Please note that, to ease the reading of the protocol contents, a
simple '=_Part' is used whenever a boundary for a 'multipart/mixed' simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
payload is provided, instead of the actual boundary that would be payload is provided, instead of the actual boundary that would be
inserted in the SIP messages. inserted in the SIP messages.
UAC AS MRB MS UAC AS MRB MS
| | | | | | | |
| 1. INVITE | | | | 1. INVITE | | |
| (media SDP) | | | | (media SDP) | | |
skipping to change at page 77, line 21 skipping to change at page 77, line 46
| |<<############## TCP CONNECTION #################>>| | |<<############## TCP CONNECTION #################>>|
| | | | | |
| | CFW SYNC | | | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>| | |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | | | |
. . . . . . . .
. . . . . . . .
Figure 12: Consumer Example (IAMM-MediaDialog): Sequence Diagram Figure 12: Consumer Example (IAMM-MediaDialog): Sequence Diagram
The rest of this section includes an almost full dump of the messages The rest of this section includes an trace of the messages associated
associated with the previous sequence diagram. Only the relevant SIP with the previous sequence diagram. Only the relevant SIP messages
messages are shown (both the INVITEs and the 200 OKs), and only the are shown (both the INVITEs and the 200 OKs), and only the relevant
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 original INVITE (3), containing both the media-related SDP
and a Consumer <mediaResourceRequest>; and a Consumer <mediaResourceRequest>;
3. the INVITE sent by the MRB to the MS as a B2BUA (5.), containing 3. the INVITE sent by the MRB to the Media Server as a B2BUA (5.),
only the media-related SDP from the original INVITE; containing only the media-related SDP from the original INVITE;
4. the 200 OK sent by the MS back to the MRB (7.), to complete the 4. the 200 OK sent by the Media Server back to the MRB (7.), to
media-related negotiation (SDP only); complete the media-related negotiation (SDP only);
5. the 200 OK sent by the MRB back to the AS in response to the 5. the 200 OK sent by the MRB back to the Application Server in
original INVITE (9.), containing both the media-related response to the original INVITE (9.), containing both the media-
information sent by the MS and a Consumer <mediaResourceRequest> related information sent by the Media Server and a Consumer
documenting the MRB's decision to use that MS; <mediaResourceRequest> documenting the MRB's decision to use that
Media Server;
6. the 200 OK sent by the AS back to the UAC to have it set-up the 6. the 200 OK sent by the Application Server back to the UAC to have
RTP channel(s) with the MS (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 35 skipping to change at page 83, line 15
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 dumps evinced, as in the IAMM-CFW example, the MRB provides As the examples illustrate, as in the IAMM-CFW example, the MRB
the AS with a 'media-server-address' element in the consumer provides the Application Server with a 'media-server-address' element
response: the 'uri' attribute identifies the specific MS to which the in the consumer response: the 'uri' attribute identifies the specific
MRB has sent the SDP media negotiation, and the 'connection-id' Media Server to which the MRB has sent the SDP media negotiation, and
enables the AS to identify to the MS the dialog between the MRB and the 'connection-id' enables the Application Server to identify to the
MS. This attribute is needed, since, according to the framework Media Server the dialog between the MRB and Media Server. This
specification, the connection-id is built out of the From/To tags of attribute is needed, since, according to the framework specification,
the dialog between the MRB and MS; since the MRB acts as a B2BUA in the connection-id is built out of the From/To tags of the dialog
this scenario, without that attribute the AS does not know the between the MRB and Media Server; since the MRB acts as a B2BUA in
relevant tags, thus preventing the CFW protocol to work as expected. this scenario, without that attribute the Application Server does not
know the relevant tags, thus preventing the CFW protocol to work as
expected.
The continuation of the scenario (the AS connecting to the MS to The continuation of the scenario (the Application Server connecting
start the Control Channel, the SYNC message, etc.) are omitted for to the Media Server to start the Control Channel, the SYNC message,
brevity. etc.) are 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 [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publish+xml" format. mrb-publish+xml" format.
<?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"
skipping to change at page 127, line 11 skipping to change at page 128, line 11
</xsd:schema> </xsd:schema>
Figure 14 Figure 14
12. Security Considerations 12. Security Considerations
The MRB network entity has two primary interfaces, Publish and The MRB network entity has two primary interfaces, Publish and
Consumer, that carry sensitive information and must therefore be Consumer, that carry sensitive information and must therefore be
appropriately protected and secured. appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1, The Publish interface, as defined in, and described in Section 5.1,
uses the Media Control Channel Framework [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 MS is secured: a malicious communication between the MRB and the Media Server is secured: a
entity, in fact, may change or even delete subscriptions to a MS, malicious entity, may change or even delete subscriptions to a Media
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 MS, leading it to wrong choices when media resources available on a Media Server, leading it to incorrect selection when
are being requested by an AS. A malicious entity may even lie about media resources are being requested by an Application Server. A
the resources being available on a MS, for instance to make the MRB malicious entity may even manipulate resources availability on a
think no resources are available at all. Considering the Publish Media Server, for example, to make the MRB think no resources are
interface is a CFW Control Package, the same Security Considerations available at all. Considering the Publish interface is a CFW Control
included in the Media Control Channel Framework specification apply Package, the same Security Considerations included in the Media
here to protect interactions between an MRB and a media server. Control Channel Framework specification apply here to protect
interactions between an MRB and a Media Server.
The Consumer interface, as defined in and described in Section 5.2, The Consumer interface, as defined in and described in Section 5.2,
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 means that malicious users could be able to disrupt or This means that malicious users could be able to disrupt or
manipulate a MRB session should they have access to the above manipulate an MRB session should they have access to the above
mentioned session ID or replicate it somehow: for instance, a mentioned session ID or replicate it somehow: for instance, a
malicious entity could modify an existing session between an AS and malicious entity could modify an existing session between an
the MRB, e.g., requesting less resources than originally requested to Application Server and the MRB, e.g., requesting less resources than
cause media dialogs to be rejected by the AS, or requesting many more originally requested to cause media dialogs to be rejected by the
resources instead to try and lock as many of (if not all) the Application Server, or requesting many more resources instead to try
resources a MRB can provide, thus making them unavailable to other and lock as many of (if not all) the resources a MRB can provide,
legitimate AS in subsequent requests. In order to prevent this, it thus making them unavailable to other legitimate Application Servers
is strongly adviced for MRB implementations to generate very hard to in subsequent requests. In order to prevent this, it is strongly
replicate session identifiers, in order to minimize the chances adviced for MRB implementations to generate very hard to replicate
malicious users could gain access to valid ones just guessing or by session identifiers, in order to minimize the chances malicious users
means of brute force attacks. It is very important, of course, to could gain access to valid ones just guessing or by means of brute
also secure the way these identifiers are transported by the involved force attacks. It is very important, of course, to also secure the
parties, both in requests and responses, in order to prevent network way these identifiers are transported by the involved parties, both
attackers from intercepting Consumer messages and have access to in requests and responses, in order to prevent network attackers from
session IDs. The Consumer interface uses either the Hypertext intercepting Consumer messages and have access to session IDs. The
Transfer Protocol (HTTP) or Session Initiation Protocol (SIP) as the Consumer interface uses either the Hypertext Transfer Protocol (HTTP)
mechanism for clients to connect to an MRB to request media or Session Initiation Protocol (SIP) as the mechanism for clients to
resources. In the case of the HTTP use, any binding using the connect to an MRB to request media resources. In the case of the
Consumer interface MUST be capable of being transacted over TLS, as HTTP use, any binding using the Consumer interface MUST be capable of
described in RFC 2818 [RFC2818]. In the case of the SIP use, the being transacted over TLS, as described in RFC 2818 [RFC2818]. In
same security considerations included in the Media Control Channel the case of the SIP use, the same security considerations included in
Framework specification apply here to protect interactions between a the Media Control Channel Framework specification apply here to
client requesting media resources and an MRB. protect interactions between a client requesting media resources and
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 envisages 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 must match in every request/response. While this adds
complexity to the protocol (implementations must pay attention to complexity to the protocol (implementations must pay attention to
those sequence numbers, since wrong values will cause "Wrong sequence those sequence numbers, since wrong values will cause "Wrong sequence
number" errors and the failure of the related requests), it is an number" errors and the failure of the related requests), it is an
important added value for security. In fact, considering different important added value for security. In fact, considering different
transaction related to the same session could be transported in transaction related to the same session could be transported in
different, unrelated HTTP messages (or SIP INVITEs in case the Inline different, unrelated HTTP messages (or SIP INVITEs in case the Inline
mode is being used), this sequence number protection prevents the mode is being used), this sequence number protection prevents the
chances of session replication or disruption, especially in cases chances of session replication or disruption, especially in cases
where the session ID has been compromised: that is, it should make it where the session ID has been compromised: that is, it should make it
harder to malicious users to manipulate or remove a session they harder for malicious users to manipulate or remove a session for
guessed the ID of. As such, it is strongly adviced that MRB don't which they have obtained the Session ID. It is strongly advised that
choose 1 as the first sequence number for a new session, but rather MRB doesn't choose 1 as the first sequence number for a new session,
pick a random value to start from. The reaction to out of sequence but rather pick a random value to start from. The reaction to out of
transactions is left to MRB implementations: a related error code is sequence transactions is left to MRB implementations: a related error
available, but implementations may decide to enforce further code is available, but implementations may decide to enforce further
limitations or actions upon the receival of too many failed attempts limitations or actions upon the receival of too many failed attempts
in a row, or of what looks like blatant attempts to guess what the in a row, or of what looks like blatant attempts to guess what the
current, valid sequence number is. 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 happen to modify SIP bodies: it is the case, as a B2BUA, the MRB may modify SIP bodies: it is the case, for
for instance, of the IAMM handling multipart/mixed payloads. This instance, of 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., RFC4474, s/mime, etc.) unless the MRB intermediates the
security association. This should be taken into account when security association. This should be taken into account when
implementing an MRB compliant with this specification. implementing an MRB compliant with this specification.
Both the Publishing and Consumer interface may address the location Both the Publishing and Consumer interface may address the location
of a MS: the Publishing interface may be used to make the MRB know of a Media Server: the Publishing interface may be used to inform the
where a MS is located (approximately or precisely), and the Consumer MRB where a Media Server is located (approximately or precisely), and
interface to ask for a MS located somewhere in particular (e.g., a the Consumer interface to ask for a Media Server located somewhere in
conference bridge close to San Francisco). ThisAs such, both MS and particular region (e.g., a conference bridge close to San Francisco).
MRB implementors need to take this into account when deciding whether Both Media Server and MRB implementors need to take this into account
or not make this location information available, and if so how much when deciding whether or not make this location information
bits of information really need to be made available for brokering available, and if so how much bits of information really need to be
purposes. made available for brokering purposes.
Finally, it is worthwhile to also discuss authorization issues It is worthwhile covering authorization issues related to this
related to the specification. Neither the Publishing nor the specification. Neither the Publishing or the Consumer interface
Consumer interface provide an explicit means for implementing provide an explicit means for implementing authentication, i.e., they
authentication, i.e., they do not envisage protocol messages to make do not contain specific protocol interactions to ensure that
sure, for instance, that only authorized Application Servers can make authorized Application Servers can make use of the services provided
use of the services provided by a MRB. Nevertheless, considering by an MRB instance. Considering both the interfaces are transported
both the interfaces are transported in well-established protocols using well-established protocols (HTTP, SIP, CFW), support for such
(HTTP, SIP, CFW), support for such an functionality can be expressed functionality can be expressed by means of the authentication
by means of the authentication mechanisms provided by the protocol mechanisms provided by the protocol themselves. Therefore, any MRB-
themselves. Therefore, any MRB-aware entity (Application Servers, aware entity (Application Servers, Media Servers, Media Resource
Media Servers, Media Resource Brokers themselves) MUST support the Brokers themselves) MUST support the HTTP and SIP Digest access
HTTP and SIP Digest access authentication. That said, the usage of authentication. The usage of such Digest access authentications is
such Digest access authentications is recommended and not mandatory, recommended and not mandatory, which means MRB-aware entities MAY
which means MRB-aware entities MAY exploit it in deployment. exploit it in deployment.
A MRB may want to enforce further constraints on the interactions An MRB may want to enforce further constraints on the interactions
between an AS/MS and a MRB. For instance, it may choose to only between an Application Server/Media Server and an MRB. For example,
accept requests associated with a specific session ID from the IP it may choose to only accept requests associated with a specific
address that originated the first request, or just make use of pre- session ID from the IP address that originated the first request, or
shared certificates to assess the identity of legitimate AS and/or just make use of pre-shared certificates to assess the identity of
MS. legitimate Application Server and/or Media Server.
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].
skipping to change at page 134, line 9 skipping to change at page 135, line 9
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document. Schema: The XML for the schema is in Section 11 of this document.
14. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
14.1. Changes from 12 Version 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 o Several changes and clarifications according to the AD review by
Robert Sparks. Robert Sparks.
o Updated reference for mixer draft (RFC6505). o Updated reference for mixer draft (RFC6505).
14.2. Changes from 11 Version 14.3. Changes from 11 Version
o Fixed a wrong reference to RFC5707 (because of a typo this was o Fixed a wrong reference to RFC5707 (because of a typo this was
RFC5705). RFC5705).
o Changed the registration in 13.1 to match the template required by o Changed the registration in 13.1 to match the template required by
RFC6230. RFC6230.
o Fixed the incorrect URIs for registering the schemas in Sections o Fixed the incorrect URIs for registering the schemas in Sections
13.6 and 13.7. 13.6 and 13.7.
o Removed enumeration types for 'dtmf-type', 'vxml-mode' and o Removed enumeration types for 'dtmf-type', 'vxml-mode' and
'stream-mode' from both the schemas to allow for better 'stream-mode' from both the schemas to allow for better
extensibility, and clarified values are case insensitive where extensibility, and clarified values are case insensitive where
needed. needed.
o Clarified that the use of the civic location of a media server is o Clarified that the use of the civic location of a media server is
entirely optional, and it's implementation specific to fill it entirely optional, and it's implementation specific to fill it
with just the details each implementor deems necessary for any with just the details each implementor deems necessary for any
optimization that may be needed. optimization that may be needed.
14.3. Changes from 10 Version 14.4. Changes from 10 Version
o Editorial changes as a result of Shepherd review. o Editorial changes as a result of Shepherd review.
o Added new attribute 'id' to both <mediaResourceRequest> and o Added new attribute 'id' to both <mediaResourceRequest> and
<mediaResourceResponse> elements in the consumer schema, in order <mediaResourceResponse> elements in the consumer schema, in order
to map a response to a specific request. to map a response to a specific request.
o Renamed 'supported-actions' to 'supported-action' in the Publisher o Renamed 'supported-actions' to 'supported-action' in the Publisher
schema. schema.
skipping to change at page 135, line 18 skipping to change at page 136, line 22
o Clarified the use of the <subscription> element in an o Clarified the use of the <subscription> element in an
<mrbresponse. <mrbresponse.
o Clarified the meaning of TCP CONNECTION in sequence diagrams. o Clarified the meaning of TCP CONNECTION in sequence diagrams.
o Removed useless backslashes from XML examples. o Removed useless backslashes from XML examples.
o Updated references for Framework and IVR drafts (RFC6230, o Updated references for Framework and IVR drafts (RFC6230,
RFC6231). RFC6231).
14.4. Changes from 09 Version 14.5. Changes from 09 Version
o Language changes as a result of Shepherd review. o Language changes as a result of Shepherd review.
14.5. Changes from 08 Version 14.6. Changes from 08 Version
o Fixed Nits. o Fixed Nits.
o Added range for reporting period - as per mailing list. o Added range for reporting period - as per mailing list.
14.6. Changes from 07 Version 14.7. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences; incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests; o Corrected examples after validation tests;
o Fixed a few typos in the text. o Fixed a few typos in the text.
o Clarified language in various places. o Clarified language in various places.
skipping to change at page 136, line 5 skipping to change at page 137, line 9
o Clarifying text related to IAMM and IUMM. o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow o Expanded media-server-address for extra information and to allow
multiples. multiples.
o New B2BUA section. o New B2BUA section.
o Updated Examples. o Updated Examples.
14.7. Changes from 06 Version 14.8. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp- o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed. codec> instances, where needed.
o Fixed a few typos in the text. o Fixed a few typos in the text.
14.8. Changes from 05 Version 14.9. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined o Clarifier that video layouts may refer to either XCON-defined
layouts or others. layouts or others.
o Added RFC4240 as an option for VXML support. o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas. o Fixed a few typos in the text and in the schemas.
14.9. Changes from 04 Version 14.10. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions. 'response-session-info' definitions.
o Clarified that 'response-session-info' is not only included in o Clarified that 'response-session-info' is not only included in
reply to updates, but also to new requests; besides, clarified reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any in successful responses (200), while not needed otherwise (any
error). error).
o Corrected the Query example flow which included a 'session'info' o Corrected the Query example flow which included a 'session'info'
in a new request. in a new request.
14.10. Changes from 03 Version 14.11. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell. o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits). o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version). Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are o Clarified that backslashes and XML indentation in the Examples are
only provided for readability. only provided for readability.
skipping to change at page 137, line 13 skipping to change at page 138, line 16
responses, in order to clarify when they are involved. responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the o Added some text to better clarify the role of leasing in the
Consumer interface. Consumer interface.
o Added additional IANA considerations, that were missing in the o Added additional IANA considerations, that were missing in the
previous versions of the document. previous versions of the document.
o Added text to the security considerations. o Added text to the security considerations.
14.11. Changes from 02 Version 14.12. Changes from 02 Version
o Added examples in Section 9. o Added examples in Section 9.
o Fixed some nits in the schemas (encryption and required mixed=true o Fixed some nits in the schemas (encryption and required mixed=true
elements). elements).
o Completed review nit review comments from Gary Munson. o Completed review nit review comments from Gary Munson.
14.12. Changes from 01 Version 14.13. Changes from 01 Version
o Added description of lease mechanism. o Added description of lease mechanism.
o Added specific HTTP and SIP usage of Consumer interface. o Added specific HTTP and SIP usage of Consumer interface.
o Completed Publish interface schema + associated text. o Completed Publish interface schema + associated text.
o Included Consumer interface schema + associated text. o Included Consumer interface schema + associated text.
o Included supported-packages element. o Included supported-packages element.
skipping to change at page 137, line 44 skipping to change at page 138, line 47
o Removed announce-var element from doc. o Removed announce-var element from doc.
o Expanded Abstract. o Expanded Abstract.
o General scrub of text - input from Simon Romano. o General scrub of text - input from Simon Romano.
o Added IANA Considerations section. o Added IANA Considerations section.
o Added Security Considerations section. o Added Security Considerations section.
14.13. Changes from 00 Version 14.14. Changes from 00 Version
o Included In-line text based on strawman proposal. o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team o Included first attempt at publish interface based on design team
work. work.
15. Acknowledgements 15. Acknowledgements
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
skipping to change at page 140, line 13 skipping to change at page 141, line 13
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Hadley, M., Nielsen, H., and Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
 End of changes. 177 change blocks. 
771 lines changed or deleted 817 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/