draft-ietf-mediactrl-mrb-02.txt   draft-ietf-mediactrl-mrb-03.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: June 18, 2010 University of Napoli Expires: August 14, 2010 University of Napoli
December 15, 2009 February 10, 2010
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-02 draft-ietf-mediactrl-mrb-03
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
architectures that include 1:M and M:M combinations of Application architectures that include 1:M and M:N combinations of Application
Servers and Media Servers. This document introduces a Media Resource Servers and Media Servers. This document introduces a Media Resource
Broker (MRB) entity which manages the availability of Media Servers Broker (MRB) entity which manages the availability of Media Servers
and the media resource demands of Application Servers. The document and the media resource demands of Application Servers. The document
includes potential deployment options for an MRB and appropriate includes potential deployment options for an MRB and appropriate
interfaces to Application Servers and Media Servers. interfaces to Application Servers and Media Servers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2010. This Internet-Draft will expire on August 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8
4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9
4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publishing Interface . . . . . . . . 14 5.1. Media Server Resource Publish Interface . . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . . 15 5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 18 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 18
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 27 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Service Resource Consumer Interface . . . . . . . . 28 5.2. Media Service Resource Consumer Interface . . . . . . . . 27
5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 28 5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 28
5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . . 29 5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . 28
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . . 30 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 30
5.2.4. Media Service Resource Request . . . . . . . . . . . . 32 5.2.4. Media Service Resource Request . . . . . . . . . . . 32
5.2.5. Media Service Resource Response . . . . . . . . . . . 42 5.2.5. Media Service Resource Response . . . . . . . . . . . 42
5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 44 5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 44
5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . . 44 5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . 44
5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . . 45 5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . 44
6. Media Service Resource Publisher Interface XML Schema . . . . 47 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7. Media Service Resource Consumer Interface XML Schema . . . . . 71 6.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 92 6.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 6.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 51
9.1. application/mrb-publish+xml MIME Type . . . . . . . . . . 93 6.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 54
9.2. application/mrb-consumer+xml MIME Type . . . . . . . . . . 94 7. Media Service Resource Publisher Interface XML Schema . . . . 60
10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 8. Media Service Resource Consumer Interface XML Schema . . . . 82
10.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 103
10.2. Changes from 00 Version . . . . . . . . . . . . . . . . . 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 10.1. application/mrb-publish+xml MIME Type . . . . . . . . . . 104
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97 10.2. application/mrb-consumer+xml MIME Type . . . . . . . . . 105
12.1. Normative References . . . . . . . . . . . . . . . . . . . 97 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.2. Informative References . . . . . . . . . . . . . . . . . . 98 11.1. Changes from 02 Version . . . . . . . . . . . . . . . . . 106
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 11.2. Changes from 01 Version . . . . . . . . . . . . . . . . . 106
11.3. Changes from 00 Version . . . . . . . . . . . . . . . . . 106
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 108
13.1. Normative References . . . . . . . . . . . . . . . . . . 108
13.2. Informative References . . . . . . . . . . . . . . . . . 109
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110
1. Introduction 1. Introduction
The topic of Media Resource management has been in discussion for a The topic of Media Resource management has been in discussion for a
number of years with varying proprietary solutions being used today. number of years with varying proprietary solutions being used today.
It is clear that, as we move towards a consistent architecture and It is clear that, as we move towards a consistent architecture and
protocol for Media Server Control, a standard mechanism is required protocol for Media Server Control, a standard mechanism is required
for accurate media resource location. for accurate media resource selection.
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
increases when you introduce a flexible level of deployment increases when you introduce a flexible level of deployment
scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567 scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567
skipping to change at page 5, line 23 skipping to change at page 5, line 23
+-------------+ | +-------------+ +-------------+ | +-------------+
| |
| +---+-----+---+ | +---+-----+---+
+----->| Media | +----->| Media |
| Server | | Server |
+-------------+ +-------------+
Figure 2: Multiple Media Servers Figure 2: Multiple Media Servers
Figure 3 conveys the opposite view to that in Figure 2. In this Figure 3 conveys the opposite view to that in Figure 2. In this
model there are a number of (greater than 1) application servers model there are a number of (greater than 1) application servers,
controlling a single media server. Typically, such architectures are possibly supporting dissimilar applications, controlling a single
associated with application logic that requires low demand media media server. Typically, such architectures are associated with
services. application logic that requires low demand media services.
+---+-----+---+ +---+-----+---+
| Application | | Application |
| Server |<-----+ | Server |<-----+
+-------------+ | +-------------+ |
| |
+---+-----+---+ | +---+-----+---+ +---+-----+---+ | +---+-----+---+
| Application | | | Media | | Application | | | Media |
| Server |<-----+-----MS Control-->| Server | | Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+ +-------------+ | +-------------+
| |
+---+-----+---+ | +---+-----+---+ |
| Application | | | Application | |
| Server |<-----+ | Server |<-----+
+-------------+ +-------------+
Figure 3: Multiple Application Servers Figure 3: Multiple Application Servers
The final deployment view is the most complex. In this model (M:M) The final deployment view is the most complex. In this model (M:N)
there exists any number of Application Servers and any number of there exists any number of Application Servers and any number of
Media Servers. It is again possible in this model that media servers Media Servers. It is again possible in this model that media servers
might not be homogenous and have different capability sets and might not be homogenous and have different capability sets and
capacity. capacity.
+---+-----+---+ +---+-----+---+ +---+-----+---+ +---+-----+---+
| Application | | Media | | Application | | Media |
| Server |<-----+ +---->| Server | | Server |<-----+ +---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
skipping to change at page 7, line 21 skipping to change at page 7, line 21
compliant implementations. compliant implementations.
This document inherits terminology proposed in RFC 5567 [RFC5567] and This document inherits terminology proposed in RFC 5567 [RFC5567] and
Media Control Channel Framework Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] documents. In addition, [I-D.ietf-mediactrl-sip-control-framework] documents. In addition,
the following terms are defined for use in this document and for use the following terms are defined for use in this document and for use
in the context of the MediaCtrl Work group in the IETF: in the context of the MediaCtrl Work group in the IETF:
Media Resource Broker (MRB) A logical entity that is responsible for Media Resource Broker (MRB) A logical entity that is responsible for
both collection of appropriate published Media Server (MS) both collection of appropriate published Media Server (MS)
information and supplying of appropriate MS information to information and selecting appropriate MS resources on behalf of
consuming entities. consuming entities.
Query MRB An instantiation of an MRB (See previous definition) that Query MRB An instantiation of an MRB (See previous definition) that
provides an interface for an Application Server to retrieve the provides an interface for an Application Server to retrieve the
location of an appropriate Media Server. The result returned to address of an appropriate Media Server. The result returned to
the Application Server can be influenced by information contained the Application Server can be influenced by information contained
in the query request. in the query request.
In-line MRB An instantiation of an MRB (See definition) that In-line MRB An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. The decision directly receives requests on the signalling path. There is no
making process is totally delegated to the MRB. separate query.
3. Problem Discussion 3. Problem Discussion
It is clear from Section 1 that the MediaCtrl group will be producing It is clear from Section 1 that the MediaCtrl group will be producing
a solution that must service a wide variety of deployment a solution that must service a wide variety of deployment
architectures. These range from the simplest 1:1 relationship architectures. These range from the simplest 1:1 relationship
between Media Servers and Application Servers to potentially linearly between Media Servers and Application Servers to potentially linearly
scaling 1:M, M:1 and M:M deployments. scaling 1:M, M:1 and M:N deployments.
This still does not seem like a major issue for the proposed solution This still does not seem like a major issue for the proposed solution
until you add a number of additional factors into the equation that until you add a number of additional factors into the equation that
increase complexity. As Media Servers evolve it must be taken into increase complexity. As Media Servers evolve it must be taken into
consideration that, where many can exist in a deployment, they may consideration that, where many can exist in a deployment, they may
not have been produced by the same vendor and may not have the same not have been produced by the same vendor and may not have the same
capability set. It should be possible for an Application Server that capability set. It should be possible for an Application Server that
exists in a deployment to select a Media Service based on a common, exists in a deployment to select a Media Service based on a common,
appropriate capability set. In conjunction with capabilities, it is appropriate capability set. In conjunction with capabilities, it is
also important to take available resources into consideration. The also important to take available resources into consideration. The
skipping to change at page 8, line 40 skipping to change at page 8, line 40
required. Only a single capability set exists and resource required. Only a single capability set exists and resource
unavailability can be handled using the appropriate underlying unavailability can be handled using the appropriate underlying
signalling e.g. SIP response. This document does not prohibit such signalling e.g. SIP response. This document does not prohibit such
uses of an MRB, it simply provides the tools for various entities to uses of an MRB, it simply provides the tools for various entities to
interact where appropriate. It is also worth noting that the tools interact where appropriate. It is also worth noting that the tools
provided in this document aim to provide a 'best effort' view of provided in this document aim to provide a 'best effort' view of
media resources at the time of request for initial Media Server media resources at the time of request for initial Media Server
routing decisions. Any dramatic change in media capabilities after a routing decisions. Any dramatic change in media capabilities after a
request has taken place should be handled by the underlying protocol. request has taken place should be handled by the underlying protocol.
Please note that, while the MRB is supposed to provided ASs with as Please note that there may be additional information that it is
much relevant information as possible, there are information pieces desirable for the MRB to have for purposes of selecting an MS
that ASs may be interested to which are out of scope in this resource, such as resource allocation rules across different
document, as for instance MS resource allocation rules, planned or applications, planned or unplanned downtime of Media Server
unplanned downtime of Media Server resources, the planned addition of resources, the planned addition of future Media Server resources, or
future Media Server resources. MS resource capacity models. How the MRB acquires such information
is outside the scope of this document. The techniques used for
selecting an appropriate Media Resource by an MRB is 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 On researching Media Resource Brokering it became clear that a couple
of high level models exist. The general principles of "in-line" and of high level models exist. The general principles of "in-line" and
"query" MRB concepts are discussed in the rest of this section. "query" MRB concepts are discussed in the rest of this section.
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
skipping to change at page 9, line 39 skipping to change at page 9, line 39
+-------------+ (3) | +-------------+ | +-------------+ (3) | +-------------+ |
| | | |
| +---+-----+---+ (1)| | +---+-----+---+ (1)|
+---->| Media | | +---->| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 5: Query MRB Figure 5: Query MRB
In this deployment, the Media Servers use the "Media Server Resource In this deployment, the Media Servers use the "Media Server Resource
Publishing Interface", as discussed in Section 5.1, to convey Publish Interface", as discussed in Section 5.1, to convey capability
capability sets as well as resource information. This is depicted by sets as well as resource information. This is depicted by (1) in
(1) in Figure 5. It is then the MRB's responsibility to accumulate Figure 5. It is then the MRB's responsibility to accumulate all
all appropriate information relating to media services in the logical appropriate information relating to media services in the logical
deployment cluster. The Application Server (or other media services deployment cluster. The Application Server (or other media services
client) is then able to query the MRB for an appropriate resource (as client) is then able to query the MRB for an appropriate resource (as
identified by (2) in Figure 5). Such a query would carry specific identified by (2) in Figure 5). Such a query would carry specific
information related to the Media Service required and enable the MRB information related to the Media Service required and enable the MRB
to provide an increased accuracy in its response. This particular to provide 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. 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
and the selected MS 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
| | | |
| +---+-----+---+ | | +---+-----+---+ |
+---->| Media | | +---->| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 6: Hybrid Query MRB - AS Hosted Figure 6: Hybrid Query MRB - AS 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
Publishing 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
hybrid if required. hybrid if required.
In a similar manner, the Media Server could also act as a hybrid for In a similar manner, the Media Server could also act as a hybrid for
the deployment cluster, as illustrated in Figure 7. the deployment cluster, as illustrated in Figure 7.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
| +---+--+--+---+ | | +---+--+--+---+ |
+---<-------| 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. This time the MRB has collapsed and is co-hosted by the Media Server.
The "Media Server Consumer Interface" is still available to the The "Media Server Consumer Interface" is still available to the
Application Servers (1) to query Media Server resources. This time Application Servers (1) to query Media Server resources. This time
the "Media Server Publishing Interface" has collapsed onto the Media the "Media Server Publish Interface" has collapsed onto the Media
Server. It might still exist within the Media Server/MRB interaction Server. It might still exist within the Media Server/MRB interaction
but this is an implementation issue. This type of deployment suits a but this is an implementation issue. This type of deployment suits a
single Media Server environment but it should be noted that a "Media single Media Server environment but it should be noted that a "Media
Server Publishing Interface" could then be offered from the hybrid if Server Publish Interface" could then be offered from the hybrid if
required. A typical use case scenario for such a topology would be a required. A typical use case scenario for such a topology would be a
single MS representing a pool of MSs in a cluster. In that case, the single MS representing a pool of MSs in a cluster. In that case, the
MRB would actually be handling a cluster of MSs, rather than one. MRB would actually be handling a cluster of MSs, 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 "Media that was discussed in the previous section. The concept of a
Server Consumer Interface" disappears. The client of the MRB simply separate query disappears. The client of the MRB simply uses the
uses the signalling to offload the decision making process - this media resource control and media dialog signalling to involve the
applies to both media server Control and Media dialogs. 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 25 skipping to change at page 12, line 25
| Server |----->| MRB |----->| Server |->-+ | | Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ | +-------------+ +---+-----+---+ +-------------+ |
| | | |
| (3) +---+-----+---+ (1)| | (3) +---+-----+---+ (1)|
+------>| Media | | +------>| Media | |
| Server |--->---+ | Server |--->---+
+---+-----+---+ +---+-----+---+
Figure 8: In-line MRB Figure 8: In-line MRB
The Media Servers still use the 'Media Server Publishing Interface' The Media Servers still use the 'Media Server Publish Interface' to
to convey capabilities and resources to the MRB - as illustrated by convey capabilities and resources to the MRB - as illustrated by (1).
(1). The media server Control and Media dialogs are sent to the MRB The media server Control (and Media dialogs as well, if required) is
(2) which then selects an appropriate Media Server (3). The result sent to the MRB (2) which then selects an appropriate Media Server
of such an architecture is that the signalling decision is left (3) and would stay in the signaling path between the AS and the MS
entirely to the MRB and the Application Server has no choice in the resource for the handled dialogs.
final selection process. This is the opposite to the "Query" model
which provided information that would help influence the Media Server
decision making process on the application server and resulted in it
directly contacting an appropriate Media Server instance. As a by-
product of this decision shift, a lot more emphasis is placed on the
intelligence of the MRB to interpret the required capabilities of the
request. The MRB will actually have to inspect both the SIP
signalling and the media server control protocol PDUs for the purpose
of Media Server selection. This includes, for example, looking for
explicit capabilities in the signalling and session details such as
media types, codecs and bandwidth requirements. Ultimately the
decision making and policy enforcement is removed from the
Application Server and shifted to the MRB logical entity.
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. its operation. In this case the AS does not provide explicit
information on the kind of MS resource it needs (as in
Section 5.2) and the MRB is left to deduce it by potentially
inspecting other information in the request from the AS; for
example, SDP content, or address of the requesting AS, 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. operation. In particular it allows the AS to explicitly the
convey the same kinds of MS characteristics desired as does the
Query MRB mode (as in Section 5.2).
In either role, the MRB would deduce that the selected MS resources
are no longer needed when the AS terminates the corresponding dialog.
The two modes are discussed in more detail in Section 5.3. The two modes are discussed in more detail in Section 5.3.
5. MRB Interface Definitions 5. MRB Interface Definitions
As discussed in previous sections in this document, the intention is As discussed in previous sections in this document, the intention is
to provide a toolkit for a variety of deployment architectures where to provide a toolkit for a variety of deployment architectures where
media resource brokering can take place. As a result, two main media resource brokering can take place. As a result, two main
interfaces are required to support the differing requirements. The interfaces are required to support the differing requirements. The
two interfaces are described in the remainder of this section and two interfaces are described in the remainder of this section and
have been named the 'Media Server Resource Publishing' and 'Media have been named the 'Media Server Resource Publish' and 'Media Server
Server Resource Consumer' interfaces. These two interfaces have Resource Consumer' interfaces. These two interfaces have extremely
extremely differing responsibilities and usages which is reflected in differing responsibilities and usages which is reflected in the
the choice of solutions. choice of solutions.
It is beyond the scope of this document to define exactly how to It is beyond the scope of this document to define exactly how to
construct an MRB. This includes interpreting the data for the Media construct an MRB. This includes interpreting the data for the Media
Service Consumer interface supplied by the Media Server Publishing Service Consumer interface supplied by the Media Server Publish
interface. It is, however, important that the two interfaces are interface. It is, however, important that the two interfaces are
complimentary so that development of appropriate MRB functionality is complimentary so that development of appropriate MRB functionality is
supported. supported.
5.1. Media Server Resource Publishing Interface 5.1. Media Server Resource Publish Interface
The Media Server Resource Publishing interface is responsible for The Media Server Resource Publish interface is responsible for
providing an MRB with appropriate Media Server resource information. providing an MRB with appropriate Media Server resource information.
It is generally accepted that this interface provides both general It is generally accepted that this interface provides both general
and specific details related to Media Server resources. This and specific details related to Media Server resources. This
information needs to be conveyed using an industry standard mechanism information needs to be conveyed using an industry standard mechanism
to provide increased levels of adoption and interoperability. A to provide increased levels of adoption and interoperability. A
Control Package for the Media Control Channel Framework will be Control Package for the Media Control Channel Framework will be
specified to fulfil this interface requirement. It provides the specified to fulfil this interface requirement. It provides the
perfect establishment and monitoring mechanism to enable a Media perfect establishment and monitoring mechanism to enable a Media
Server to report appropriate statistics to an MRB. The Publish Server to report appropriate statistics to an MRB. The Publish
interface is used with both Query and In-line modes of MRB operation. interface is used with both Query and In-line modes of MRB operation.
As already anticipated in the introduction, the information provided As already anticipated in the introduction, the MRB view of MS
by the Media Server is to be considered a best effort. This means resource availability will in practice be approximate - i.e., partial
that while the information is assumed to be as exact as possible, it and imperfect. The MRB Publish interface does not provide an
can only be considered a good approximation rather than the exact exhaustive view of current MS resource consumption, the MS may in
information. It is clear, in fact, that the accuracy of MRB resource some cases provide a best-effort computed view of resource
availability will never be exact due to several reasons which include consumption parameters conveyed in the Publish interface (e.g., DSP's
timing issues, computed as opposed to reserved resource consumption 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 there may be licensing constraints not factored in (e.g., even if
availability), and licensing (e.g., even if lots of CPU and memory lots of CPU and memory are available, licensing or other
are available, licensing or other configuration elements may restrict configuration elements may restrict the number of stream types), and
the number of stream types). This implies that the only way an MS resource information may only be reported periodically over the
Application Server can be sure a specific resource is available is to Publish interface to MRB. Nevertheless, despite such limitations and
reserve it by establishing a session. For the same reason, the with the aid of good engineering the MRB can still perform its
reporting of resources availability has no relation to predictive function well.
resource allocation. A typical example of that is a conference
bridge that allows for oversubscription. The oversubscription must
be taken care of at the application layer in the Application Server,
since requests to the Media Server must be for the actual number of
streams requested.
It is also worth noting that, while the scope of the MRB is It is also worth noting that, while the scope of the MRB is
definitely on providing interested Application Servers with the definitely on providing interested Application Servers with the
available resources, the MRB also allows for the retrieval of available resources, the MRB also allows for the retrieval of
information about the currently occupied resources. While this is of information about the currently occupied resources. While this is of
course a relevant piece of information (e.g. for monitoring course a relevant piece of information (e.g. for monitoring
purposes), such a functionality inevitably raises security purposes), such a functionality inevitably raises security
considerations, and implementations should take this into account. considerations, and implementations should take this into account.
See Section 8 for more details. See Section 9 for more details.
The MRB Publish interface uses the Media Control Channel Framework The MRB Publish interface uses the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]) as the basis for ([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
interaction between a Media Server and an MRB. The Media Control interaction between a Media Server and an MRB. The Media Control
Channel Framework uses an extension mechanism to allow specific Channel Framework uses an extension mechanism to allow specific
usages which are known as control packages. Section 5.1.1 defines usages which are known as control packages. Section 5.1.1 defines
the control package that MUST be implemented by any Media Server the control package that MUST be implemented by any Media Server
wanting to interact with an MRB entity. wanting to interact with an MRB entity.
5.1.1. Control Package Definition 5.1.1. Control Package Definition
skipping to change at page 15, line 42 skipping to change at page 15, line 38
5.1.1.1. Control Package Name 5.1.1.1. Control Package Name
The Media Channel Control Framework requires a Control Package The Media Channel Control Framework requires a Control Package
definition to specify and register a unique name and version. definition to specify and register a unique name and version.
The name and version of this Control Package is "mrb-publish/1.0". The name and version of this Control Package is "mrb-publish/1.0".
5.1.1.2. Framework Message Usage 5.1.1.2. Framework Message Usage
The MRB publishing interface allows a media server to convey The MRB publish interface allows a media server to convey available
available capabilities and resources to an MRB entity. capabilities and resources to an MRB entity.
This package defines XML elements in Section 5.1.2 and provides an This package defines XML elements in Section 5.1.2 and provides an
XML Schema in Section 6. XML Schema in Section 7.
The XML elements in this package are split into requests, responses The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message and event notifications. Requests are carried in CONTROL message
bodies; <mrbrequest> element is defined as a package request. This bodies; <mrbrequest> element is defined as a package request. This
request can be used for creating new subscriptions and update/remove request can be used for creating new subscriptions and updating/
existing subscriptions. Event notifications are also carried in removing existing subscriptions. Event notifications are also
CONTROL message bodies; the <mrbnotification> element is defined for carried in CONTROL message bodies; the <mrbnotification> element is
package event notifications. Responses are carried either in REPORT defined for package event notifications. Responses are carried
message or Control Framework 200 response bodies; the <mrbresponse> either in REPORT message or Control Framework 200 response bodies;
element is defined as a package level response. the <mrbresponse> element is defined as a package level response.
Note that package responses are different from framework response Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of codes. Framework error response codes (see Section 7 of
[I-D.ietf-mediactrl-sip-control-framework]) are used when the request [I-D.ietf-mediactrl-sip-control-framework]) are used when the request
or event notification is invalid; for example, a request has invalid or event notification is invalid; for example, a request has invalid
XML (400), or is not understood (500). Package level responses are XML (400), or is not understood (500). Package level responses are
carried in framework 200 response or REPORT message bodies. This carried in framework 200 response or REPORT message bodies. This
package's response codes are defined in Section 5.1.5. package's response codes are defined in Section 5.1.5.
5.1.1.3. Common XML Support 5.1.1.3. Common XML Support
The Media Control Channel Framework The Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] requires a Control Package [I-D.ietf-mediactrl-sip-control-framework] requires a Control Package
definition to specify if the attributes for media dialog or definition to specify if the attributes for media dialog or
conference references are required. conference references are required.
The Publish interface defined in Section 6 does import and make use The Publish interface defined in Section 7 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
The Consumer interface defined in Section 7 does import and make use The Consumer interface defined in Section 8 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
5.1.1.4. CONTROL Message Body 5.1.1.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in A valid CONTROL body message MUST conform to the schema defined in
Section 6 and described in Section 5.1.2. XML messages appearing in Section 7 and described in Section 5.1.2. XML messages appearing in
CONTROL messages MUST contain either a <mrbrequest> or CONTROL messages MUST contain either a <mrbrequest> or
<mrbnotification> element. <mrbnotification> element.
5.1.1.5. REPORT Message Body 5.1.1.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 6 A valid REPORT body MUST conform to the schema defined in Section 7
and described in Section 5.1.2. XML messages appearing in REPORT and described in Section 5.1.2. XML messages appearing in REPORT
messages MUST contain a <mrbresponse> element. messages MUST contain a <mrbresponse> element.
5.1.1.6. Audit 5.1.1.6. Audit
The 'mrb-publish/1.0' Media Control Channel Framework package does The 'mrb-publish/1.0' Media Control Channel Framework package does
not require any additional auditing capability. not require any additional auditing capability.
5.1.1.7. Examples
[Editors' Note: The Authors will post and review appropriate examples
to the list that will be included in the final version.]
5.1.2. Element Definitions 5.1.2. Element Definitions
This section defines the XML elements for the Publish interface Media This section defines the XML elements for the Publish interface Media
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 6. Section 7.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The <mrbpublish> element has the following attributes: The <mrbpublish> element has the following attributes:
Version: a token specifying the mrb-publish package version. The Version: a token specifying the mrb-publish package version. The
skipping to change at page 19, line 24 skipping to change at page 19, line 10
The attribute is mandatory The attribute is mandatory
The following subsections provide details on the child elements that The following subsections provide details on the child elements that
are contained within an <mrbnotification> element. are contained within an <mrbnotification> element.
5.1.4.1. <media-server-id> 5.1.4.1. <media-server-id>
The <media-server-id> element provides a unique system wide The <media-server-id> element provides a unique system wide
identifier for a Media Server instance. The element is mandatory. identifier for a Media Server instance. The element is mandatory.
[Editors Note: Need to talk more about unique property.]
5.1.4.2. <supported-packages> 5.1.4.2. <supported-packages>
The <supported-packages> element provides the list of Media Control The <supported-packages> element provides the list of Media Control
Channel Packages supported by the media server. The element is Channel Packages supported by the media server. The element is
optional. optional.
The <supported-packages> element has no attributes. The <supported-packages> element has no attributes.
The <supported-packages> element has no child elements: The <supported-packages> element has no child elements:
skipping to change at page 20, line 23 skipping to change at page 20, line 5
5.1.4.4. <active-mixer-sessions> 5.1.4.4. <active-mixer-sessions>
The <active-mixer-sessions> element provides information detailing The <active-mixer-sessions> element provides information detailing
the current active mixed RTP sessions. The element is optional. the current active mixed RTP sessions. The element is optional.
The <active-mixer-sessions> element has no attributes. The <active-mixer-sessions> element has no attributes.
The <active-mixer-sessions> element has the following child element: The <active-mixer-sessions> element has the following child element:
active-mix: Is a container which representing a mixed active RTP active-mix: Is a container which represents a mixed active RTP
session. The <active-mix> element has one attribute. The session. The <active-mix> element has one attribute. The
attribute 'conferenceid' represents the name of the mix being attribute 'conferenceid' represents the name of the mix being
represented. The <active-mix> element has one child elements. represented. The <active-mix> element has one child elements.
The child element, <rtp-codec>, contains the same information The child element, <rtp-codec>, contains the same information
relating to RTP sessions as defined in Section 5.1.4.3. The relating to RTP sessions as defined in Section 5.1.4.3. The
element is optional. element is optional.
5.1.4.5. <non-active-rtp-sessions> 5.1.4.5. <non-active-rtp-sessions>
The <non-active-rtp-sessions> element provides information detailing The <non-active-rtp-sessions> element provides information detailing
skipping to change at page 22, line 44 skipping to change at page 22, line 24
supported-format: has a single attribute, 'name', which provides supported-format: has a single attribute, 'name', which provides
the type of file format that is supported. The <supported-format> the type of file format that is supported. The <supported-format>
element then has a further child element, <supported-file- element then has a further child element, <supported-file-
package>. The <supported-file-package> element provides the name package>. The <supported-file-package> element provides the name
of the Media Control Channel Framework package for which the file of the Media Control Channel Framework package for which the file
format support applies. format support applies.
5.1.4.11. <max-prepared-duration> 5.1.4.11. <max-prepared-duration>
The <max-prepared-duration> element provides the amount of time a The <max-prepared-duration> element provides the amount of time a
media dialog cane be prepared in the system before it is executed. media dialog can be prepared in the system before it is executed.
The element is optional. The element is optional.
The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has no attributes.
The <max-prepared-duration> element has the following child element: The <max-prepared-duration> element has the following child element:
max-time: has a single attribute, 'max-time-seconds', which max-time: has a single attribute, 'max-time-seconds', which
provides the amount of time in seconds that a media dialog can be provides the amount of time in seconds that a media dialog can be
in the prepared state. The <max-time> element then has a further in the prepared state. The <max-time> element then has a further
child element, <max-time-package>. The <max-time-package> element child element, <max-time-package>. The <max-time-package> element
skipping to change at page 24, line 33 skipping to change at page 24, line 9
contribution. The <video-mixing-modes> element has one child contribution. The <video-mixing-modes> element has one child
element. The child element, <video-mixing-mode>, contains a element. The child element, <video-mixing-mode>, contains a
specific video presentation layout. It has a single attribute, specific video presentation layout. It has a single attribute,
'package'. The attribute 'package' provides the name of the Media 'package'. The attribute 'package' provides the name of the Media
Control Channel Framework package for which the algorithm support Control Channel Framework package for which the algorithm support
applies. applies.
5.1.4.14. <supported-tones> 5.1.4.14. <supported-tones>
The <supported-tones> element provides information about which tones The <supported-tones> element provides information about which tones
a media server support. In particular, the support is reported a media server supports. In particular, the support is reported
referring to both country codes support (ISO 3166-1) and supported referring to both country codes support (ISO 3166-1) and supported
functionality (H.248.1v3/ITU-T Q.1950/..). The element is optional. functionality (H.248.1v3/ITU-T Q.1950/..). The element is optional.
The <supported-tones> element has no attributes. The <supported-tones> element has no attributes.
The <supported-tones> element has the following child elements: The <supported-tones> element has the following child elements:
supported-country-codes: Is a container representing the supported supported-country-codes: Is a container representing the supported
country codes with respect to tones. The <supported-country- country codes with respect to tones. The <supported-country-
codes> element has no attributes. The <supported-country-codes> codes> element has no attributes. The <supported-country-codes>
skipping to change at page 27, line 9 skipping to change at page 26, line 30
The <media-server-location> element one child element: The <media-server-location> element one child element:
civicAddress: Is a container representing the civic address civicAddress: Is a container representing the civic address
location of the media server, whose representation refers to the location of the media server, whose representation refers to the
Section 4 of RFC 5139 [RFC5139]. Section 4 of RFC 5139 [RFC5139].
5.1.4.19. <label> 5.1.4.19. <label>
The <label> element allows a Media Server to declare a piece of The <label> element allows a Media Server to declare a piece of
information that will be understood by the MRB. For example, the information that will be understood by the MRB. For example, the
Media Server can declare if it's a blue or green. It's a string to Media Server can declare if it's a blue or green one. It's a string
allow arbitrary values to be returned to allow arbitrary to allow arbitrary values to be returned to allow arbitrary
classification. Its arbitrary as opposed to doing it purely on classification. Its arbitrary as opposed to doing it purely on
features. The element is optional. features. The element is optional.
The <label> element has no attributes. The <label> element has no attributes.
The <label> element has no child elements. The <label> element has no child elements.
5.1.4.20. <media-server-address> 5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
skipping to change at page 27, line 42 skipping to change at page 27, line 14
for RTP. A value of 'false' indicates that a Media Server does not for RTP. A value of 'false' indicates that a Media Server does not
support RFC 3711 [RFC3711] for RTP. The element is optional. support RFC 3711 [RFC3711] for RTP. The element is optional.
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.1.5. <mrbresponse> 5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <response> element from
Section 6. Section 7.
The <response> element has following attributes: The <response> element has following attributes:
status: numeric code indicating the response status. The attribute status: numeric code indicating the response status. The attribute
is mandatory. is mandatory.
The following status codes are defined: The following status codes are defined:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
skipping to change at page 28, line 39 skipping to change at page 28, line 9
The Media Server Consumer interface provides the ability for clients The Media Server Consumer interface provides the ability for clients
of an MRB, such as Application Servers, to request an appropriate of an MRB, such as Application Servers, to request an appropriate
Media Server to satisfy specific criteria. The interface allows a Media Server to satisfy specific criteria. The interface allows a
client to pass detailed meta-information to the MRB to help select an client to pass detailed meta-information to the MRB to help select an
appropriate Media Server. The MRB is then able to make an informed appropriate Media Server. The MRB is then able to make an informed
decision and provide the client with an appropriate media server decision and provide the client with an appropriate media server
resource. The MRB Consumer interface can be used in association with resource. The MRB Consumer interface can be used in association with
both the Session Initiation Protocol (SIP) and the Hypertext Transfer both the Session Initiation Protocol (SIP) and the Hypertext Transfer
Protocol (HTTP) [RFC2616]. The following subsections provide Protocol (HTTP) [RFC2616]. The following subsections provide
guidance on using the Consumer interface, as defined by the guidance on using the Consumer interface, as defined by the
'application/mrb-consumer+xml MIME type in Section 7, with HTTP and 'application/mrb-consumer+xml MIME type in Section 8, with HTTP and
SIP. SIP.
5.2.1. HTTP Consumer Interface Usage 5.2.1. HTTP Consumer Interface Usage
An appropriate interface for such a 'query' style interface is in An appropriate interface for such a 'query' style interface is in
fact a HTTP usage. Using HTTP and XML combined reduces complexity fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the and encourages use of common tools that are widely available in the
industry today. The following information explains the primary industry today. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of HTTP MRB. The following description will describe the use of HTTP
[RFC2616] and HTTPS [RFC2818] as transport for a query for media [RFC2616] and HTTPS [RFC2818] as transport for a query for media
resource and the appropriate response. resource and the appropriate response.
The media resource query, as defined by the <mediaResourceRequest> The media resource query, as defined by the <mediaResourceRequest>
element from Section 7, MUST be carried in the body of an HTTP/HTTPS element from Section 8, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
the 'mediaResourceRequest' element as defined in Section 7. The the 'mediaResourceRequest' element as defined in Section 8. The
'mediaResourceRequest' element is the primary container of 'mediaResourceRequest' element is the primary container of
information related to a media resource request. information related to a media resource request.
The media resource response to a query, as defined by the The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 7, MUST be carried in <mediaResourceResponse> element from Section 8, MUST be carried in
the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
the 'mediaResourceResponse' element as defined in Section 7. The the 'mediaResourceResponse' element as defined in Section 8. The
'mediaResourceResponse' element is the primary container of 'mediaResourceResponse' element is the primary container of
information related to a media resource response. information related to a media resource response.
5.2.2. SIP Consumer Interface Usage 5.2.2. SIP Consumer Interface Usage
This document provides a complete toolkit for MRB deployment which This document provides a complete toolkit for MRB deployment which
includes the ability to interact with an MRB using SIP for the includes the ability to interact with an MRB using SIP for the
Consumer interface. The following information explains the primary Consumer interface. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of SIP MRB. The following description will describe the use of SIP
[RFC3261] as transport for a query for media resource and the [RFC3261] as transport for a query for media resource and the
appropriate response when used with IAMM of operation (as discussed appropriate response when used with IAMM of operation (as discussed
in Section 5.3.2). in Section 5.3.2).
The media resource query, as defined by the <mediaResourceRequest> The media resource query, as defined by the <mediaResourceRequest>
element from Section 7, MUST be carried in a SIP INVITE request. The element from Section 8, MUST be carried in a SIP INVITE request. The
INVITE request will be constructed as it would have been to connect INVITE request will be constructed as it would have been to connect
to a media server, as defined by the Media Control Channel Framework to a media server, as defined by the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework]. The following additional [I-D.ietf-mediactrl-sip-control-framework]. The following additional
steps MUST be followed when using the Consumer interface: steps MUST be followed when using the Consumer interface:
o Include a payload in the SIP INVITE request of type 'multipart/ o Include a payload in the SIP INVITE request of type 'multipart/
mixed'[RFC2046]. The first part to be included in the 'mixed' mixed'[RFC2046]. The first part to be included in the 'mixed'
payload MUST be the 'application/sdp' format which is constructed payload MUST be the 'application/sdp' format which is constructed
as specified in the Media Control Channel Framework as specified in the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
o The second part of the 'multipart/mixed payload MUST be of type o The second 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 7. Only the <mediaResourceRequest> and its defined in Section 8. Only the <mediaResourceRequest> and its
child elements can be included in the payload. child elements can be included in the payload.
o The INVITE request will then be dispatched to the MRB, as defined o The INVITE request will then be dispatched to the MRB, as defined
by [I-D.ietf-mediactrl-sip-control-framework]. by [I-D.ietf-mediactrl-sip-control-framework].
The media resource response to a query, as defined by the The media resource response to a query, as defined by the
<mediaResourceResponse> element from Section 7, MUST be carried in <mediaResourceResponse> element from Section 8, SHOULD be carried in
the payload of a SIP 2xx class response to the original SIP INVITE the payload of a SIP 2xx class response to the original SIP INVITE
request. The 2xx class response will be constructed as it would have request. It MAY be carried in the payload of a SIP 3xx response. It
been to connect from a media server, as defined by the Media Control should be noted that the use of a SIP 3xx response aligns with the
Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The request/response query approach used by HTTP in Section 5.2.1. Using
following additional steps MUST be followed when using the Consumer 2xx aligns with the 'in-line' approach where the MRB sits in the
interface: signaling path between the client and the media resource. The 2xx
class response will be constructed as it would have been to connect
from a media server, as defined by the Media Control Channel
Framework [I-D.ietf-mediactrl-sip-control-framework]. A standard 3xx
response can also be generated. The following additional steps MUST
be followed when using the Consumer interface:
o Include a payload in the SIP 2xx class response of type o Include a payload in the SIP 2xx class response of type
'multipart/mixed'RFC 2046 [RFC2046]. The first part to be 'multipart/mixed'RFC 2046 [RFC2046]. The first part to be
included in the 'mixed' payload MUST be the 'application/sdp' included in the '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 [I-D.ietf-mediactrl-sip-control-framework]. Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. A
3xx response will not include payload of type 'multipart/mixed'
and will only include a single payload of type 'application/
mrb-consumer+xml', as discussed in the next point.
o The second part of the 'multipart/mixed payload MUST be of type o The second 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 7. Only the <mediaResourceResponse> and its defined in Section 8. Only the <mediaResourceResponse> and its
child elements can be included in the payload. child elements can be included in the payload.
o The SIP 2xx class response will then be dispatched from the MRB, o The SIP 2xx/3xx class response will then be dispatched from the
as defined by [I-D.ietf-mediactrl-sip-control-framework]. MRB.
5.2.3. Consumer Interface Lease Mechanism 5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 7 and Section 7 allows a The Consumer interface defined in Section 8 and Section 8 allows a
client to request an appropriate media resource based on information client to request an appropriate media resource based on information
included in the request (either a HTTP POST or SIP INVITE message). included in the request (either a HTTP POST or SIP INVITE message).
In case of success, the response that is returned to the client MUST In case of success, the response that is returned to the client MUST
contain a <session-info> element in either the SIP 2xx class or HTTP contain a <session-info> element in either the SIP 2xx class or HTTP
200 response. The information contained in the <session-info> 200 response. The information contained in the <session-info>
element allows a Consumer client to monitor the life time of the element allows a Consumer client to monitor the life time of the
resources it has successfully requested, as well as amending them. resources it has successfully requested, as well as amending them.
The <mediaResourceResponse> element returned from the MRB contains a The <mediaResourceResponse> element returned from the MRB contains a
<session-info> element if the request is successful. The <session- <session-info> element if the request is successful. The <session-
skipping to change at page 31, line 50 skipping to change at page 31, line 30
determined by the <session-id> element) the consumer client MUST determined by the <session-id> element) the consumer client MUST
increment the value returned in the <seq> element from the initial increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows counter to and in conjunction with the unique <session-id> allows
for unique identification of a request. for unique identification of a request.
o <action> element provides the operation to be carried out by the o <action> element provides the operation to be carried out by the
MRB on receiving the request. The value of 'update' is a request MRB on receiving the request. The value of 'update' is a request
by the Consumer client to update the existing session at the MRB by the Consumer client to update the existing session at the MRB
with information contained in the remainder of the request. If with alternate requirements which are contained in the remainder
the information is identical as the existing request, the MRB will of the request. If the requested resource information is
attempt a session refresh. If the information has changed, the identical to the existing MRB session, the MRB will attempt a
MRB will attempt to update the existing session with the new session refresh. If the information has changed, the MRB will
information. If the operation is successful, the 200 response is attempt to update the existing session with the new information.
returned in the status attribute of the If the operation is successful, the 200 response is returned in
<mediaResourceResponseType> element. If the operation is not the status attribute of the <mediaResourceResponseType> element.
successful, a 409 response is returned in the status attribute of If the operation is not successful, a 409 response is returned in
the <mediaResourceResponseType> element. The value of 'remove' is the status attribute of the <mediaResourceResponseType> element.
a request by the Consumer client to remove the session at the MRB. The value of 'remove' is a request by the Consumer client to
This provides a mechanism for Consumer clients to release unwanted remove the session at the MRB. This provides a mechanism for
resources before they expire. If the operation is successful, a Consumer clients to release unwanted resources before they expire.
200 response is returned in the status attribute of the If the operation is successful, a 200 response is returned in the
<mediaResourceResponseType> element. If the operation is not status attribute of the <mediaResourceResponseType> element. If
successful, a 410 response is returned in the XXX element. the operation is not successful, a 410 response is returned in the
status attribute of the <mediaResourceResponseType> element.
When used with SIP the <session-info> element MUST be included in When used with SIP the <session-info> element MUST be included in
either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as either a SIP re-INVITE (as defined in [RFC3261]) or a SIP UPDATE (as
defined in[RFC3311]) request. When used with HTTP the <session-info> defined in[RFC3311]) request. When used with HTTP the <session-info>
element MUST be included in a HTTP POST message (as defined in element MUST be included in a HTTP POST message (as defined in
[RFC2616]). [RFC2616]).
5.2.4. Media Service Resource Request 5.2.4. Media Service Resource Request
This section defines the XML elements for the Consumer interface. This section defines the XML elements for the Consumer interface.
The formal XML schema definition for the Consumer interface can be The formal XML schema definition for the Consumer interface can be
found in Section 7. found in Section 8.
The root element is <mrbconsumer>. All other XML elements (requests, The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface responses) are contained within it. The MRB Consumer interface
request element is detailed in Section 5.2.4.1. MRB Consumer request element is detailed in Section 5.2.4.1. MRB Consumer
interface response element is contained in Section 5.2.5.1. interface response element is contained in Section 5.2.5.1.
The <mrbconsumer> element has the following attributes: The <mrbconsumer> element has the following attributes:
Version) a token specifying the mrb-consumer package version. The Version) a token specifying the mrb-consumer package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
skipping to change at page 33, line 43 skipping to change at page 33, line 20
session-id: is a unique identifier that explicitly references an session-id: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3. More information about its use is provided in Section 5.2.3.
action: provides the operation that should be carried out on an action: provides the operation that should be carried out on an
existing media resource session on an MRB. The value of 'update' existing media resource session on an MRB. The value of 'update'
instructs the MRB to attempt to update the existing media resource instructs the MRB to attempt to update the existing media resource
session with the information contained in the <ivrInfo> and session with the information contained in the <ivrInfo> and
<mixerInfo> elements. The value of 'remove' instructs the MRB to <mixerInfo> elements. The value of 'remove' instructs the MRB to
attempt to remove the existing media resource session. More attempt to remove the existing media resource session. More
information on its use is provided in Section 5.2.3. information on its use is provided in Section 5.2.3.
5.2.4.1.1.2. <packages> element 5.2.4.1.1.2. <packages> element
skipping to change at page 39, line 22 skipping to change at page 38, line 47
5.2.4.1.3.1. <mixers> 5.2.4.1.3.1. <mixers>
The <mixers> element provides information detailing the required The <mixers> element provides information detailing the required
mixed RTP sessions. The element is optional. mixed RTP sessions. The element is optional.
The <mixers> element has no attributes. The <mixers> element has no attributes.
The <mixers> element has the following child element: The <mixers> element has the following child element:
mix: Is a container which representing a required mixed RTP mix: Is a container which represents a required mixed RTP session.
session. The <mix> element has one attribute. The attribute The <mix> element has one attribute. The attribute 'users'
'users' represents the number of participants required in the mix. represents the number of participants required in the mix. The
The <mix> element has one child elements. The child element, <mix> element has one child elements. The child element, <codec>,
<codec>, contains the same information relating to RTP sessions as contains the same information relating to RTP sessions as defined
defined in Section 5.1.4.3. The element is optional. in Section 5.1.4.3. The element is optional.
5.2.4.1.3.2. <file-formats> 5.2.4.1.3.2. <file-formats>
The <file-formats> element provides a list of file formats required The <file-formats> element provides a list of file formats required
by the Consumer client for the purpose of making announcements to a by the Consumer client for the purpose of making announcements to a
mix. The element is optional. mix. The element is optional.
The <file-formats> element has no attributes. The <file-formats> element has no attributes.
The <file-formats> element has the following child element: The <file-formats> element has the following child element:
skipping to change at page 44, line 6 skipping to change at page 43, line 31
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
seq: is used in association with the <session-id> element in a seq: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
More information its use is provided in Section 5.2.3. More information its use is provided in Section 5.2.3.
expires: includes the number of seconds that the media resources expires: includes the number of seconds that the media resources
reserved as part of this interaction. If the lease is refreshed are reserved as part of this interaction. If the lease is not
before expiry, the MRB will re-claim the resources and they will refreshed before expiry, the MRB will re-claim the resources and
no longer be guaranteed. It is RECOMMENDED that a minimum value they will no longer be guaranteed. It is RECOMMENDED that a
of 300 seconds be used for the value of the 'expires' attribute. minimum value of 300 seconds be used for the value of the
It is also RECOMMENDED that a Consumer client refresh the lease at 'expires' attribute. It is also RECOMMENDED that a Consumer
an interval that is not too close to the expiry time. A value of client refresh the lease at an interval that is not too close to
80% of the timeout period could be used. For example, if the the expiry time. A value of 80% of the timeout period could be
timeout period is 300 seconds, the Server would refresh the used. For example, if the timeout period is 300 seconds, the
transaction at 240 seconds. More information on its use is Server would refresh the transaction at 240 seconds. More
provided in Section 5.2.3. information on its use is provided in Section 5.2.3.
media-server-address: is the SIP URI to reach the MS handling the media-server-address: is the SIP URI to reach the MS handling the
requested media resource. requested media resource.
[Editors' Note: this response should also include a way for the [Editors' Note: this response should also include a way for the
Consumer Client to contact the MS able to fulfil the request, at Consumer Client to contact the MS able to fulfil the request, at
least in case of the HTTP usage of the Consumer interface. Such info least in case of the HTTP usage of the Consumer interface. Such info
wouldn't be needed in the IAMM case. At the moment this is reported wouldn't be needed in the IAMM case. At the moment this is reported
by means of the <media-server-address> element, which is also used in by means of the <media-server-address> element, which is also used in
the publishing interface. Is this SIP URI enough? Do we need to the publish interface. Is this SIP URI enough? Do we need to
provide additional details?] provide additional details?]
5.3. In-Line MRB Interface 5.3. In-Line MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a An entity acting as an In-Line MRB can act in one of two roles for a
request, as introduced in Section 4.2. The following sub sections request, as introduced in Section 4.2. The following sub sections
provide details for using In-Line Unaware MRB Mode (IUMM) of provide details for using In-Line Unaware MRB Mode (IUMM) of
operation and In-Line Aware MRB Mode (IAMM) of operation. operation and In-Line Aware MRB Mode (IAMM) of operation.
5.3.1. In-line Unaware MRB Mode 5.3.1. In-line Unaware MRB Mode
skipping to change at page 45, line 7 skipping to change at page 44, line 33
appropriate media server based on knowledge of media server resources appropriate media server based on knowledge of media server resources
it currently has available transparently to the client entity. it currently has available transparently to the client entity.
Mechanisms used to connect to media servers are detailed in the Media Mechanisms used to connect to media servers are detailed in the Media
Channel Control Framework [I-D.ietf-mediactrl-sip-control-framework]. Channel Control Framework [I-D.ietf-mediactrl-sip-control-framework].
Using an MRB in this mode allows for easy migration of current Using an MRB in this mode allows for easy migration of current
applications and services that are unaware of the MRB concept and applications and services that are unaware of the MRB concept and
would simply require a configuration change resulting in the MRB would simply require a configuration change resulting in the MRB
being set as a SIP outbound proxy for clients requiring media being set as a SIP outbound proxy for clients requiring media
services. Any client of media services wishing to take advantage of services. Any client of media services wishing to take advantage of
the advanced techniques detailed in this document when using In-line the advanced techniques detailed in this document when using In-line
mode would implement IAMM which is covered in Section 5.3.2. The mode would implement IAMM which is covered in Section 5.3.2.
techniques used for selecting an appropriate Media Server by an MRB
acting in IUMM is outside the scope of this document.
5.3.2. In-line Aware MRB Mode 5.3.2. In-line Aware MRB Mode
An In-Line Aware Mode MRB (IAMM) is one that complies to the extended An In-Line Aware Mode MRB (IAMM) is one that complies to the extended
functionality provided in this section. A client entity, such as an functionality provided in this section. A client entity, such as an
application server, wishing to use advanced MRB functionality can application server, wishing to use advanced MRB functionality can
provide additional contextual information to an MRB. This provide additional contextual information to an MRB. This
information is identical to that used in the Consumer interface in information is identical to that used in the Consumer interface in
Section 5.2 with the only difference being the underlying transport Section 5.2 with the only difference being the underlying transport
mechanism of the contextual information, as specified by the mechanism of the contextual information, as specified by the
'application/mrb-consumer+xml' payload in Section 7. A client of an 'application/mrb-consumer+xml' payload in Section 8. A client of an
IAMM, as anticipated in Section 5.2.2, uses SIP signalling to convey IAMM, as anticipated in Section 5.2.2, uses SIP signalling to convey
the 'application/mrb-consumer+xml' payload to the IAMM, unlike the the 'application/mrb-consumer+xml' payload to the IAMM, unlike the
Consumer interface presented in Section 5.2.1, which instead uses Consumer interface presented in Section 5.2.1, which instead uses
HTTP as a transport. A client of an IAMM requiring media services, HTTP as a transport. A client of an IAMM requiring media services,
as well as creating a standard SIP complaint request, MUST use the as well as creating a standard SIP complaint request, MUST use the
following steps (also presented in Section 5.2.2) to ensure that the following steps (also presented in Section 5.2.2) to ensure that the
request is dealt with appropriately: request is dealt with appropriately:
o The client of the IAMM constructs a SIP INVITE request to connect o The client of the IAMM constructs a SIP INVITE request to connect
to a Media Server as detailed in the Media Channel Control to a Media Server as detailed in the Media Channel Control
skipping to change at page 45, line 43 skipping to change at page 45, line 19
o The client of the IAMM includes a MIME content type of multipart/ o The client of the IAMM includes a MIME content type of multipart/
mixed as defined in RFC 2046 [RFC2046]. As part of this mixed mixed as defined in RFC 2046 [RFC2046]. As part of this mixed
payload, the client MUST at least include a content-type of type payload, the client MUST at least include a content-type of type
'application/sdp' and a content type of type 'application/ 'application/sdp' and a content type of type 'application/
mrb-consumer+xml'. The part of type application/sdp represents mrb-consumer+xml'. The part of type application/sdp represents
the media server connection details and MUST adhere to the Media the media server connection details and MUST adhere to the Media
Channel Control Framework Channel Control Framework
[I-D.ietf-mediactrl-sip-control-framework]. The part of type [I-D.ietf-mediactrl-sip-control-framework]. The part of type
'application/mrb-consumer+xml' represents the IAMM contextual 'application/mrb-consumer+xml' represents the IAMM contextual
information and MUST adhere to the schema defined in Section 7. information and MUST adhere to the schema defined in Section 8.
o Once the SIP INVITE request is constructed, it is sent to the o Once the SIP INVITE request is constructed, it is sent to the
recipient as per RFC 3261 [RFC3261]. recipient as per RFC 3261 [RFC3261].
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 IAMM will complete a number of payload as specified previously, the IAMM will complete a number of
steps to fulfil 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
skipping to change at page 47, line 5 skipping to change at page 46, line 5
media server should be selected to service the request. media server should be selected to service the request.
o Extract the 'application/sdp' part from the payload and use it to o Extract the 'application/sdp' part from the payload and use it to
populate a new SIP INVITE request for connecting the client to the populate a new SIP INVITE request for connecting the client to the
selected media server, as defined in the Media Channel Control selected media server, as defined in the Media Channel Control
Framework [I-D.ietf-mediactrl-sip-control-framework]. The IAMM Framework [I-D.ietf-mediactrl-sip-control-framework]. The IAMM
acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/ acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then mrb-consumer+xml' information from the SIP INVITE request and then
forwards to the selected Media Server. forwards to the selected Media Server.
6. Media Service Resource Publisher Interface XML Schema 6. Examples
This section provides examples of both the Publish and Consumer
interfaces. For what concerns the Consumer interface, both Query and
Inline modes are addressed.
6.1. Publish Example
The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]).
Figure 9 shows the subscription/notification mechanism the Publish
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
subscription (A2). Notifications are triggered by the MS (A3.) and
acknowledged by the MRB (A4.).
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
Figure 9: Publish Example: Sequence Diagram
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
1. the subscription (A1), in an <mrbrequest> (CFW CONTROL);
2. the MS accepting the subscription (A2), in an <mrbresponse> (CFW
200);
3. a notification (A3), in a <mrbnotification> (CFW CONTROL event);
4. the ack to the notification (A4), in a framework level 200
message (CFW 200);
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>600</expires>
<frequency>20</frequency>
</subscription>
</mrbrequest>
</mrbpublish>
A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4242
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish" \
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id>
<supported-packages>
<package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/>
</supported-packages>
<active-rtp-sessions>
<rtp-codec name="G.711">
<decoding>10</decoding>
<encoding>20</encoding>
</rtp-codec>
</active-rtp-sessions>
<active-mixer-sessions>
<active-mix conferenceid="7cfgs43">
<rtp-codec name="G.711">
<decoding>3</decoding>
<encoding>3</encoding>
</rtp-codec>
</active-mix>
</active-mixer-sessions>
<non-active-rtp-sessions>
<rtp-codec name="G.711">
<decoding>50</decoding>
<encoding>40</encoding>
</rtp-codec>
</non-active-rtp-sessions>
<non-active-mixer-sessions>
<non-active-mix available="15">
<rtp-codec name="G.711"/>
</non-active-mix>
</non-active-mixer-sessions>
<media-server-status>active</media-server-status>
<supported-codecs>
<supported-codecs name="G.711">
<supported-codec-package name="msc-ivr">
<supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions>
</supported-codec-package>
<supported-codec-package name="msc-mixer">
<supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions>
</supported-codec-package>
</supported-codecs>
</supported-codecs>
<application-data>Testbed Prototype</application-data>
<file-formats>
<supported-format name="audio/x-wav">
<supported-file-package/>
</supported-format>
</file-formats>
<max-prepared-duration>
<max-time max-time-seconds="3600">
<max-time-package>msc-ivr</max-time-package>
</max-time>
</max-prepared-duration>
<dtmf-support>
<detect>
<dtmf-type package="msc-ivr" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/>
</detect>
<generate>
<dtmf-type package="msc-ivr" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/>
</generate>
<passthrough>
<dtmf-type package="msc-ivr" name="RFC4733"/>
<dtmf-type package="msc-mixer" name="RFC4733"/>
</passthrough>
</dtmf-support>
<mixing-modes>
<audio-mixing-modes>
<audio-mixing-mode package="msc-ivr">
nbest
</audio-mixing-mode>
</audio-mixing-modes>
<video-mixing-modes activespeakermix="true" vas="true">
<video-mixing-mode package="msc-mixer">
single-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
dual-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
dual-view-crop
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
dual-view-2x1
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
dual-view-2x1-crop
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
quad-view
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
multiple-5x1
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
multiple-3x3
</video-mixing-mode>
<video-mixing-mode package="msc-mixer">
multiple-4x4
</video-mixing-mode>
</video-mixing-modes>
</mixing-modes>
<supported-tones>
<supported-country-codes>
<country-code package="msc-ivr">GB</country-code>
<country-code package="msc-ivr">IT</country-code>
<country-code package="msc-ivr">US</country-code>
</supported-country-codes>
<supported-h248-codes>
<h248-code package="msc-ivr">cg/*</h248-code>
<h248-code package="msc-ivr">biztn/ofque</h248-code>
<h248-code package="msc-ivr">biztn/erwt</h248-code>
<h248-code package="msc-mixer">conftn/*</h248-code>
</supported-h248-codes>
</supported-tones>
<streaming-modes>
<stream-mode package="msc-ivr" name="HTTP"/>
</streaming-modes>
<asr-tts-support>
<asr-support>
<language xml:lang="en"/>
</asr-support>
<tts-support>
<language xml:lang="en"/>
</tts-support>
</asr-tts-support>
<vxml-support support="false">
<vxml-mode package="msc-ivr"/>
</vxml-support>
<media-server-location>
<ca:civicAddress xml:lang="it">
<ca:country>IT</ca:country>
<ca:A1>Campania</ca:A1>
<ca:A3>Napoli</ca:A3>
<ca:A6>Via Claudio</ca:A6>
<ca:HNO>21</ca:HNO>
<ca:LMK>University of Napoli Federico II</ca:LMK>
<ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM>
<ca:PC>80210</ca:PC>
</ca:civicAddress>
</media-server-location>
<label>TestbedPrototype-01</label>
<media-server-address>
sip:MediaServer@ms.example.com:5080
</media-server-address>
<encryption>false</encryption>
</mrbnotification>
</mrbpublish>
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
6.2. Consumer Example
As specified in Section 5.2, the Consumer interface can be involved
in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of
such an approach is presented in Section 6.2.1. When in Inline-aware
mode, messages are transported as part of SIP negotiations: an
example of such an approach is presented in Section 6.2.2.
6.2.1. Query Example
The following example assumes the interested AS 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
MRB. The AS sends a consumer request as payload of an HTTP POST
message (1.), and the MRB provides an answer in an HTTP 200 OK
message (2.).
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with MS reported by MRB |
| |
. .
. .
Figure 10: Consumer Example (Query): Sequence Diagram
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST,
Content-Type 'application/mrb-consumer+xml');
2. the Consumer response (2), in an <mediaResourceResponse> (HTTP
200 OK, Content-Type 'application/mrb-consumer+xml').
1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------
POST /Mrb/Consumer HTTP/1.1
Content-Length: 1008
Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<session-info>
<session-id>0GX1jCYZ8WBa</session-id>
<seq>1</seq>
</session-info>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="PCMU">
<decoding>10</decoding>
<encoding>10</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
2. AS <- MRB (200 to POST, Consumer response)
---------------------------------------------
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 506
Date: Mon, 08 Feb 2010 16:53:34 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>0GX1jCYZ8WBa</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address>
sip:MediaServer@ms.example.com:5080
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
The rest of the scenario is omitted for brevity. After having
received the 'mediaResourceResponse', the AS has the address of a MS
able to fulfil its media requirements, and can start a Control Dialog
with it.
6.2.2. IAMM Example
The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS.
Figure 10 shows the SIP-based transactions involving the AS, the MRB
and the MS that will be chosen eventually. The diagram is more
complex than before. This is basically a scenario envisaging the MRB
as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW-
related SDP and a Consumer request (multipart body). The MRB sends a
provisional response to the AS (2.) and starts working on the
request. First of all, it makes use of the Consumer request from the
AS to determine which MS should be exploited. Once the right MS has
been chosen, the MRB sends a new SIP INVITE to this MS by just
including the SDP part of the original request (3.). The MS
negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing
the MRB with its own CFW-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body
(7.): this multipart body includes the Consumer response used by the
MRB to determine the right MS and the SDP returned by the MS in 5.
The AS finally acknowledges the 200 OK (8.), and can start a CFW
connection towards the MS.
AS MRB MS
| | |
| 1. INVITE | |
| (multipart/mixed) | |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Extract SDP and |
| | | MRB payloads; handle |
| |<-+ Consumer request to |
| | know MS to use |
| | |
| | 3. INVITE |
| | (only copy SDP from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| Prepare new +--| |
| payload with | | |
| SDP from MS and +->| |
| Consumer reply | |
| | |
| 7. 200 OK | |
| (multipart/mixed) | |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
|--+ Read Cons. reply | |
| | and use SDP to | |
|<-+ create CFW Chn. | |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
Figure 11: Consumer Example (IAMM): Sequence Diagram
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP
messages are shown (both the INVITEs and the 200 OKs), and only the
relevant headers are preserved for brevity (Content-Type and
multipart-related information). Specifically:
1. the original INVITE (1), containing both a CFW-related SDP
(COMEDIA information to negotiate a new Control Channel) and a
Consumer <mediaResourceRequest>;
2. the INVITE sent by the MRB to the MS as a B2BUA (3.), 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
CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (7.), containing both the CFW-related information
sent by the MS and a Consumer <mediaResourceRequest> documenting
the MRB's decision to use that MS.
1. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
[..]
Content-Type: multipart/mixed; \
boundary="----=_Part_0_19138361.1261662356915"
------=_Part_0_19138361.1261662356915
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
------=_Part_0_19138361.1261662356915
Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<session-info>
<session-id>q79OYY0q4M6M</session-id>
<seq>1</seq>
</session-info>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="PCMU">
<decoding>10</decoding>
<encoding>10</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
------=_Part_0_19138361.1261662356915--
3. MRB -> MS (INVITE sdp only)
------------------------------
[..]
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
5. MRB <- MS (200 OK sdp)
-------------------------
[..]
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
7. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
[..]
Content-Type: multipart/mixed; \
boundary="----=_Part_1_3022359.1261662358037"
------=_Part_1_3022359.1261662358037
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
------=_Part_1_3022359.1261662358037
Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>q79OYY0q4M6M</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
------=_Part_1_3022359.1261662358037--
The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for
brevity.
7. Media Service Resource Publisher Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publish+xml" format. mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish" xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
skipping to change at page 57, line 30 skipping to change at page 70, line 30
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="supported-format" type="supported-formatType" /> <xsd:element name="supported-format" type="supported-formatType" />
<xsd:complexType name="supported-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-file-package" <xsd:element name="supported-file-package"
type="supported-file-packageType" /> type="xsd:string" />
<!-- max-prepared-duration --> <!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType"> <xsd:complexType name="max-prepared-durationType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="max-time" /> <xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
skipping to change at page 61, line 4 skipping to change at page 73, line 38
<xsd:element name="mixing-modes" type="mixing-modesType" /> <xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType"> <xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="audio-mixing-mode" <xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" /> <xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType"> <xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" /> <xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType"> <xsd:complexType name="video-mixing-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="video-mixing-mode" <xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
skipping to change at page 61, line 48 skipping to change at page 74, line 29
default="false" /> default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype" <xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" /> default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" /> <xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType"> <xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" /> <xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- supported-tones --> <!-- supported-tones -->
<xsd:complexType name="supported-tonesType"> <xsd:complexType name="supported-tonesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
skipping to change at page 63, line 5 skipping to change at page 75, line 30
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="supported-country-codes" <xsd:element name="supported-country-codes"
type="supported-country-codesType" /> type="supported-country-codesType" />
<xsd:complexType name="country-codeType"> <xsd:complexType name="country-codeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="country-code" type="country-codeType" /> <xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="supported-h248-codesType"> <xsd:complexType name="supported-h248-codesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="h248-code" <xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
skipping to change at page 63, line 31 skipping to change at page 76, line 4
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="h248-code" <xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="supported-h248-codes" <xsd:element name="supported-h248-codes"
type="supported-h248-codesType" /> type="supported-h248-codesType" />
<xsd:complexType name="h248-codeType"> <xsd:complexType name="h248-codeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" /> <xsd:element name="h248-code" type="h248-codeType" />
<!-- streaming-modes --> <!-- streaming-modes -->
<xsd:complexType name="streaming-modesType"> <xsd:complexType name="streaming-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="stream-mode" <xsd:element ref="stream-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
skipping to change at page 67, line 29 skipping to change at page 79, line 47
<!-- label --> <!-- label -->
<xsd:element name="label" type="label.datatype" /> <xsd:element name="label" type="label.datatype" />
<!-- media-server-address --> <!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" /> <xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- encryption --> <!-- encryption -->
<xsd:complexType name="encryptionType"> <xsd:element name="encryption" type="boolean.datatype" />
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="encryption-codec"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption" type="encryptionType" />
<xsd:complexType name="encryption-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="encryption-codec-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption-codec" type="encryption-codecType" />
<xsd:complexType name="encryption-codec-package">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption-codec-package"
type="supported-codec-packageType" />
<!-- <!--
#################################################### ####################################################
DATATYPES DATATYPES
#################################################### ####################################################
--> -->
<xsd:simpleType name="version.datatype"> <xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
skipping to change at page 70, line 26 skipping to change at page 81, line 44
<xsd:simpleType name="label.datatype"> <xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype"> <xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 9 Figure 12
7. Media Service Resource Consumer Interface XML Schema 8. Media Service Resource Consumer Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-consumer+xml" format. mrb-consumer+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
skipping to change at page 82, line 26 skipping to change at page 93, line 26
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="country-codes" <xsd:element name="country-codes"
type="required-country-codesType" /> type="required-country-codesType" />
<xsd:complexType name="country-codeType"> <xsd:complexType name="country-codeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="country-code" type="country-codeType" /> <xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="required-h248-codesType"> <xsd:complexType name="required-h248-codesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="h248-code" <xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
skipping to change at page 83, line 4 skipping to change at page 93, line 49
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="h248-code" <xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="h248-codes" <xsd:element name="h248-codes"
type="required-h248-codesType" /> type="required-h248-codesType" />
<xsd:complexType name="h248-codeType"> <xsd:complexType name="h248-codeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" /> <xsd:element name="h248-code" type="h248-codeType" />
<!-- asr-tts --> <!-- asr-tts -->
<xsd:complexType name="asr-ttsType"> <xsd:complexType name="asr-ttsType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
skipping to change at page 89, line 11 skipping to change at page 99, line 49
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" /> <xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType"> <xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
</xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" /> <xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType"> <xsd:complexType name="video-mixing-modesType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="video-mixing-mode" <xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
skipping to change at page 89, line 46 skipping to change at page 100, line 33
default="false" /> default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype" <xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" /> default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" /> <xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType"> <xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:complexContent> <xsd:sequence>
<xsd:extension base="Tcore"> <xsd:any namespace="##other" minOccurs="0"
<xsd:sequence> maxOccurs="unbounded" processContents="lax" />
<xsd:any namespace="##other" minOccurs="0" </xsd:sequence>
maxOccurs="unbounded" processContents="lax" /> <xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" /> <xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- <!--
#################################################### ####################################################
DATATYPES DATATYPES
#################################################### ####################################################
skipping to change at page 91, line 22 skipping to change at page 102, line 4
<xsd:enumeration value="false" /> <xsd:enumeration value="false" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="vxml.datatype"> <xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC5552" /> <xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" /> <xsd:enumeration value="IVR-Package" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 10 Figure 13
8. Security Considerations 9. Security Considerations
The MRB network entity has two primary interfaces, Publish and The MRB network entity has two primary interfaces, Publish and
Consumer, that carry sensitive information and must therefore be Consumer, that carry sensitive information and must therefore be
appropriately protected and secured. appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1, The Publish interface, as defined in and described in Section 5.1,
uses the Media Control Channel Framework uses the Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect [I-D.ietf-mediactrl-sip-control-framework] as a mechanism to connect
an MRB to a media server. The appropriate Security Considerations an MRB to a media server. The appropriate Security Considerations
included in the Media Control Channel Framework specification MUST be included in the Media Control Channel Framework specification MUST be
skipping to change at page 93, line 5 skipping to change at page 104, line 5
uses either the Hypertext Transfer Protocol (HTTP) or Session uses either the Hypertext Transfer Protocol (HTTP) or Session
Initiation Protocol (SIP) as the mechanism for clients to connect to Initiation Protocol (SIP) as the mechanism for clients to connect to
an MRB to request media resources. In the case of the HTTP use, any an MRB to request media resources. In the case of the HTTP use, any
binding using the Consumer interface MUST be capable of being binding using the Consumer interface MUST be capable of being
transacted over TLS, as described in RFC 2818 [RFC2818]. In the case transacted over TLS, as described in RFC 2818 [RFC2818]. In the case
of the SIP use, the appropriate security considerations included in of the SIP use, the appropriate security considerations included in
the Media Control Channel Framework specification MUST be used in the Media Control Channel Framework specification MUST be used in
conjunction with this specification to protect interactions between a conjunction with this specification to protect interactions between a
client requesting media resources and an MRB. client requesting media resources and an MRB.
9. IANA Considerations 10. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
9.1. application/mrb-publish+xml MIME Type 10.1. application/mrb-publish+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-publish+xml MIME subtype name: mrb-publish+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023]. specified in RFC 3023 [RFC3023].
skipping to change at page 93, line 50 skipping to change at page 104, line 50
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Personal and email address for further information: Chris
Boulton, chris@ns-technologies.com Boulton, chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
Figure 11 Figure 14
9.2. application/mrb-consumer+xml MIME Type 10.2. application/mrb-consumer+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-consumer+xml MIME subtype name: mrb-consumer+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023]. specified in RFC 3023 [RFC3023].
skipping to change at page 94, line 45 skipping to change at page 105, line 45
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Personal and email address for further information: Chris
Boulton, chris@ns-technologies.com Boulton, chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
Figure 12 Figure 15
10. Changes 11. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
10.1. Changes from 01 Version 11.1. Changes from 02 Version
o Added examples in Section 6.
o Fixed some nits in the schemas (encryption and required mixed=true
elements).
o Completed review nit review comments from Gary Munson.
11.2. 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 95, line 31 skipping to change at page 106, line 40
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.
10.2. Changes from 00 Version 11.3. 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.
11. Acknowledgments 12. Acknowledgments
The authors would like to thank the members of the Publish Interface The authors would like to thank the members of the Publish Interface
design team who provided valuable input into this document. The design team who provided valuable input into this document. The
design team consisted of Gary Munson, Adnan Saleem, Michael Trank, design team consisted of Gary Munson, Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors
would also like to thank John Dally, Simon Romano, and Christian would also like to thank John Dally, Simon Romano, Henry Lum and
Groves for input into this specification. Christian Groves for input into this specification.
12. References 13. References
12.1. Normative References 13.1. Normative References
[ISO.639.1988] [ISO.639.1988]
International Organization for Standardization, "Code for International Organization for Standardization, "Code for
the representation of names of languages, 1st edition", the representation of names of languages, 1st edition",
ISO Standard 639, 1988. ISO Standard 639, 1988.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
skipping to change at page 97, line 50 skipping to change at page 108, line 50
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., Moreau, J., Nielsen, H., and Nielsen, H., Gudgin, M., Hadley, M., Moreau, J., and N.
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
World Wide Web Consortium FirstEdition REC-soap12-part1- Framework", World Wide Web Consortium FirstEdition REC-
20030624, June 2003, soap12-part1-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Moreau, J., Hadley, M., Nielsen, H., and Hadley, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
12.2. Informative References 13.2. Informative References
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-call-flows]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
"Media Control Channel Framework (CFW) Call Flow "Media Control Channel Framework (CFW) Call Flow
Examples", draft-ietf-mediactrl-call-flows-02 (work in Examples", draft-ietf-mediactrl-call-flows-02 (work in
progress), October 2009. progress), October 2009.
[I-D.ietf-mediactrl-sip-control-framework] [I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-11 (work in draft-ietf-mediactrl-sip-control-framework-11 (work in
progress), October 2009. progress), October 2009.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media [RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009. Server Control", RFC 5567, June 2009.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
 End of changes. 103 change blocks. 
385 lines changed or deleted 900 lines changed or added

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