draft-ietf-mediactrl-mrb-07.txt   draft-ietf-mediactrl-mrb-08.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: April 17, 2011 Meetecho Expires: October 15, 2011 Meetecho
October 14, 2010 G. Munson
AT&T
April 13, 2011
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-07 draft-ietf-mediactrl-mrb-08
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 43 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2011. This Internet-Draft will expire on October 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 33
4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10
4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 11
5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14
5.1. Media Server Resource Publish Interface . . . . . . . . . 14 5.1. Media Server Resource Publish Interface . . . . . . . . . 14
5.1.1. Control Package Definition . . . . . . . . . . . . . 15 5.1.1. Control Package Definition . . . . . . . . . . . . . 15
5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 17
5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . 17
5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 19
5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 28 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 28
5.2. Media Service Resource Consumer Interface . . . . . . . . 30 5.2. Media Service Resource Consumer Interface . . . . . . . . 30
5.2.1. HTTP Consumer Interface Usage . . . . . . . . . . . . 30 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 30
5.2.2. SIP Consumer Interface Usage . . . . . . . . . . . . 31 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 31
5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 32 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 33
5.2.4. Media Service Resource Request . . . . . . . . . . . 35 5.2.4. Media Service Resource Request . . . . . . . . . . . 36
5.2.5. Media Service Resource Response . . . . . . . . . . . 46 5.2.5. Media Service Resource Response . . . . . . . . . . . 48
5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 49 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . . 50
5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . 49 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 52
5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . 49 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 53
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 54
6.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 51 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 57 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 57 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 62
6.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 59 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 62
7. Media Service Resource Publisher Interface XML Schema . . . . 66 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 65
8. Media Service Resource Consumer Interface XML Schema . . . . 88 10. Media Service Resource Publisher Interface XML Schema . . . . 80
9. Security Considerations . . . . . . . . . . . . . . . . . . . 109 11. Media Service Resource Consumer Interface XML Schema . . . . 102
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 123
10.1. Control Package Registration . . . . . . . . . . . . . . 110 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
10.2. application/mrb-publish+xml MIME Type . . . . . . . . . . 110 13.1. Control Package Registration . . . . . . . . . . . . . . 124
10.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 111 13.2. application/mrb-publish+xml MIME Type . . . . . . . . . . 124
10.4. URN Sub-Namespace Registration for mrb-publish . . . . . 112 13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 125
10.5. URN Sub-Namespace Registration for mrb-consumer . . . . . 112 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 126
10.6. XML Schema Registration for mrb-publish . . . . . . . . . 112 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . . 126
10.7. XML Schema Registration for mrb-consumer . . . . . . . . 112 13.6. XML Schema Registration for mrb-publish . . . . . . . . . 126
11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 126
11.1. Changes from 06 Version . . . . . . . . . . . . . . . . . 114 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.2. Changes from 05 Version . . . . . . . . . . . . . . . . . 114 14.1. Changes from 07 Version . . . . . . . . . . . . . . . . . 128
11.3. Changes from 04 Version . . . . . . . . . . . . . . . . . 114 14.2. Changes from 06 Version . . . . . . . . . . . . . . . . . 128
11.4. Changes from 03 Version . . . . . . . . . . . . . . . . . 114 14.3. Changes from 05 Version . . . . . . . . . . . . . . . . . 128
11.5. Changes from 02 Version . . . . . . . . . . . . . . . . . 115 14.4. Changes from 04 Version . . . . . . . . . . . . . . . . . 129
11.6. Changes from 01 Version . . . . . . . . . . . . . . . . . 115 14.5. Changes from 03 Version . . . . . . . . . . . . . . . . . 129
11.7. Changes from 00 Version . . . . . . . . . . . . . . . . . 115 14.6. Changes from 02 Version . . . . . . . . . . . . . . . . . 129
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 116 14.7. Changes from 01 Version . . . . . . . . . . . . . . . . . 130
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 14.8. Changes from 00 Version . . . . . . . . . . . . . . . . . 130
13.1. Normative References . . . . . . . . . . . . . . . . . . 117 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 131
13.2. Informative References . . . . . . . . . . . . . . . . . 118 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 132
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 16.1. Normative References . . . . . . . . . . . . . . . . . . 132
16.2. Informative References . . . . . . . . . . . . . . . . . 133
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 135
1. Introduction 1. Introduction
The topic of Media Resource management has been in discussion for a The topic of Media Resource management has been in discussion for a
number of years with varying proprietary solutions being used today. number of years with varying proprietary solutions being used today.
It is clear that, as we move towards a consistent architecture and It is clear that, as we move towards a consistent architecture and
protocol for Media Server Control, a standard mechanism is required protocol for Media Server Control, a standard mechanism is required
for accurate media resource selection. for accurate media resource selection.
As IP based multimedia infrastructures mature, the complexity and As IP based multimedia infrastructures mature, the complexity and
skipping to change at page 6, line 23 skipping to change at page 6, line 23
| Server |<-----+-MS Control-+---->| Server | | Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---+-----+---+ | | +---+-----+---+ +---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media | | Application | | +---->| Media |
| Server |<-----+ | Server | | Server |<-----+ | Server |
+-------------+ +---+-----+---+ +-------------+ +---+-----+---+
Figure 4: Basic Architecture Figure 4: Basic Architecture
The high level deployment options discussed in this section rely on
network architecture and policy to prohibit inappropriate use. Such
policies are out of the scope of this document.
This document will take a look at the specific problem areas related This document will take a look at the specific problem areas related
to such deployment architectures. It is recognised that the to such deployment architectures. It is recognised that the
solutions proposed in this document should be equally adaptable to solutions proposed in this document should be equally adaptable to
all of the previously described deployment models. It is also all of the previously described deployment models. It is also
recognised that the solution is far more relevant to some of the recognised that the solution is far more relevant to some of the
previously discussed deployment models and can almost be viewed as previously discussed deployment models and can almost be viewed as
redundant on others. redundant on others.
2. Conventions and Terminology 2. Conventions and Terminology
skipping to change at page 7, line 35 skipping to change at page 7, line 35
the address of an appropriate Media Server. The result returned the address of an appropriate Media Server. The result returned
to the Application Server can be influenced by information to the Application Server can be influenced by information
contained in the query request. contained in the query request.
In-line MRB: An instantiation of an MRB (See definition) that In-line MRB: An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. There is no directly receives requests on the signalling path. There is no
separate query. separate query.
Within the context of In-line MRBs, additional terms are defined: Within the context of In-line MRBs, additional terms are defined:
In-line Aware MRB Mode (IAMM): Defined in Section 5.3.2. In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1.
In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.1. In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
The document will often specify when a specific identifier in a The document will often specify when a specific identifier in a
protocol message needs to be unique. Unless differently stated, such protocol message needs to be unique. Unless differently stated, such
uniqueness will always need to be intended within the scope of the uniqueness will always need to be intended within the scope of the
Media Servers controlled by the same Media Resource Broker. The Media Servers controlled by the same Media Resource Broker. The
interaction among different Media Resource Brokers, as the interaction among different Media Resource Brokers, as the
partitioning of a logical Media Resource Broker, is out of scope to partitioning of a logical Media Resource Broker, is out of scope to
this document. this document.
3. Problem Discussion 3. Problem Discussion
skipping to change at page 12, line 51 skipping to change at page 12, line 51
example, SDP content, or address of the requesting AS, or example, SDP content, or address of the requesting AS, or
additional Request-URI parameters as per RFC 4240 [RFC4240]. additional Request-URI parameters as per RFC 4240 [RFC4240].
In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of
clients requiring media services who are aware of an MRB and its clients requiring media services who are aware of an MRB and its
operation. In particular it allows the AS to explicitly the operation. In particular it allows the AS to explicitly the
convey the same kinds of MS characteristics desired as does the convey the same kinds of MS characteristics desired as does the
Query MRB mode (as in Section 5.2). Query MRB mode (as in Section 5.2).
In either role, the MRB would deduce that the selected MS resources In either role, the MRB would deduce that the selected MS resources
are no longer needed when the AS terminates the corresponding dialog. are no longer needed when the AS or MS terminates the corresponding
dialog. The two modes are discussed in more detail in Section 5.3.
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 Publish' and 'Media Server have been named the 'Media Server Resource Publish' and 'Media Server
Resource Consumer' interfaces. These two interfaces have extremely Resource Consumer' interfaces. These two interfaces have extremely
skipping to change at page 15, line 12 skipping to change at page 15, line 12
is assumed that the provided information is enough to allow MRB is assumed that the provided information is enough to allow MRB
implementors to realize its functionality. implementors to realize its functionality.
It is also worth noting that, while the scope of the MRB is It is also worth noting that, while the scope of the MRB is
definitely on providing interested Application Servers with the definitely on providing interested Application Servers with the
available resources, the MRB also allows for the retrieval of available resources, the MRB also allows for the retrieval of
information about the currently occupied resources. While this is of information about the currently occupied resources. While this is of
course a relevant piece of information (e.g., for monitoring course a relevant piece of information (e.g., for monitoring
purposes), such a functionality inevitably raises security purposes), such a functionality inevitably raises security
considerations, and implementations should take this into account. considerations, and implementations should take this into account.
See Section 9 for more details. See Section 12 for more details.
The MRB Publish interface uses the Media Control Channel Framework The MRB Publish interface uses the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]) as the basis for ([I-D.ietf-mediactrl-sip-control-framework]) as the basis for
interaction between a Media Server and an MRB. The Media Control interaction between a Media Server and an MRB. The Media Control
Channel Framework uses an extension mechanism to allow specific Channel Framework uses an extension mechanism to allow specific
usages which are known as control packages. Section 5.1.1 defines usages which are known as control packages. Section 5.1.1 defines
the control package that MUST be implemented by any Media Server the control package that MUST be implemented by any Media Server
wanting to interact with an MRB entity. wanting to interact with an MRB entity.
Please note that it is out of scope how an MRB knows what MSs should Please note that it is out of scope how an MRB knows what MSs should
skipping to change at page 15, line 45 skipping to change at page 15, line 45
definition to specify and register a unique name and version. definition to specify and register a unique name and version.
The name and version of this Control Package is "mrb-publish/1.0". The name and version of this Control Package is "mrb-publish/1.0".
5.1.1.2. Framework Message Usage 5.1.1.2. Framework Message Usage
The MRB publish interface allows a media server to convey available The MRB publish interface allows a media server to convey available
capabilities and resources to an MRB entity. capabilities and resources to an MRB entity.
This package defines XML elements in Section 5.1.2 and provides an This package defines XML elements in Section 5.1.2 and provides an
XML Schema in Section 7. XML Schema in Section 10.
The XML elements in this package are split into requests, responses The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message and event notifications. Requests are carried in CONTROL message
bodies; <mrbrequest> element is defined as a package request. This bodies; <mrbrequest> element is defined as a package request. This
request can be used for creating new subscriptions and updating/ request can be used for creating new subscriptions and updating/
removing existing subscriptions. Event notifications are also removing existing subscriptions. Event notifications are also
carried in CONTROL message bodies; the <mrbnotification> element is carried in CONTROL message bodies; the <mrbnotification> element is
defined for package event notifications. Responses are carried defined for package event notifications. Responses are carried
either in REPORT message or Control Framework 200 response bodies; either in REPORT message or Control Framework 200 response bodies;
the <mrbresponse> element is defined as a package level response. the <mrbresponse> element is defined as a package level response.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
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 7 does import and make use The Publish interface defined in Section 10 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
The Consumer interface defined in Section 8 does import and make use The Consumer interface defined in Section 11 does import and make use
of the common XML schema defined in the Media Control Channel of the common XML schema defined in the Media Control Channel
Framework. Framework.
5.1.1.4. CONTROL Message Body 5.1.1.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in A valid CONTROL body message MUST conform to the schema defined in
Section 7 and described in Section 5.1.2. XML messages appearing in Section 10 and described in Section 5.1.2. XML messages appearing in
CONTROL messages MUST contain either a <mrbrequest> or CONTROL messages MUST contain either 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 7 A valid REPORT body MUST conform to the schema defined in Section 10
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.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 7. Section 10.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.4. Publish interface notification element is detailed in Section 5.1.4.
MRB Publish interface response element is contained in Section 5.1.5. MRB Publish interface response element is contained in Section 5.1.5.
The <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 14 skipping to change at page 19, line 14
has requested a too high notification frequency). In such case, the has requested a too high notification frequency). In such case, the
request would not fail, but the updated, acceptable values would be request would not fail, but the updated, acceptable values would be
reported in the <mrbresponse> accordingly. reported in the <mrbresponse> accordingly.
5.1.4. <mrbnotification> 5.1.4. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The Server to an MRB to provide the details relating current status. The
Media Server will inform the MRB of its current status as defined by Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element contained in an <mrbrequest> using the <mrbnotification> element.
element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute MUST be present. the <subscription> element. The attribute MUST be present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
notification update. The first notification MUST have 1 as notification update. The first notification MUST have 1 as
skipping to change at page 26, line 40 skipping to change at page 26, line 40
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the specification in the related IANA registry compliant with the specification in the related IANA registry
(e.g., "msc-ivr/1.0"), for which the streaming protocol applies. (e.g., "msc-ivr/1.0"), for which the streaming protocol applies.
5.1.4.16. <asr-tts-support> 5.1.4.16. <asr-tts-support>
The <asr-tts-support> element provides information about the support The <asr-tts-support> element provides information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality are reported by functionality in a media server. The functionality are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988] referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The <asr-tts-support> codes) for what regards both ASR and TTS. The element MAY be
element has no attributes. The <asr-tts-support> element has the present.
following child elements:
The <asr-tts-support> element has no attributes.
The <asr-tts-support> element has the following child elements:
asr-support: Is a container representing the available languages asr-support: Is a container representing the available languages
for ASR. The <asr-support> element has no attributes. The <asr- for ASR. The <asr-support> element has no attributes. The <asr-
support> has one child element. The child element, <language>, support> has one child element. The child element, <language>,
reports the MS supports ASR for a specific language. The reports the MS supports ASR for a specific language. The
<language> element has a single attribute, 'xml:lang'. The <language> element has a single attribute, 'xml:lang'. The
attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of attribute 'xml:lang' contains the ISO-639-1 [ISO.639.1988] code of
the supported language. the supported language.
tts-support: Is a container representing the available languages tts-support: Is a container representing the available languages
skipping to change at page 28, line 26 skipping to change at page 28, line 30
The <label> element has no child elements. The <label> element has no child elements.
5.1.4.20. <media-server-address> 5.1.4.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct SIP URI address where it can be reached (e.g., the URI AS direct SIP URI address where it can be reached (e.g., the URI AS
would call to in order to setup a Control Channel and relay call would call to in order to setup a Control Channel and relay call
legs). The element MAY be present. legs). The element MAY be present.
The <media-server-address> element has no attributes. The <media-server-address> element has a single attribute.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.4.21. <encryption> 5.1.4.21. <encryption>
The <encyption> element allows a Media Server to declare support for The <encyption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. A value of encrypting RTP media streams using RFC 3711 [RFC3711]. A value of
'true' indicates that a Media Server does support RFC 3711 [RFC3711] 'true' indicates that a Media Server does support RFC 3711 [RFC3711]
for RTP. A value of 'false' indicates that a Media Server does not for RTP. A value of 'false' indicates that a Media Server does not
support RFC 3711 [RFC3711] for RTP. The element MAY be present. support RFC 3711 [RFC3711] for RTP. The element MAY be present.
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has no child elements. The <encryption> element has no child elements.
5.1.5. <mrbresponse> 5.1.5. <mrbresponse>
Responses to requests are indicated by a <response> element from Responses to requests are indicated by a <response> element from
Section 7. Section 10.
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
MUST be present. MUST be present.
reason: string specifying a reason for the response status. The reason: string specifying a reason for the response status. The
attribute MAY be present. attribute MAY be present.
The following status codes are defined for 'status': The following status codes are defined for 'status':
skipping to change at page 29, line 30 skipping to change at page 29, line 33
| | | | | |
| 403 | Unable to remove Subscription | | 403 | Unable to remove Subscription |
| | | | | |
| 404 | Subscription does not exist | | 404 | Subscription does not exist |
| | | | | |
| 405 | Subscription already exists | | 405 | Subscription already exists |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <response> status codes Table 1: <mrbresponse> status codes
In case a new subscription request made by an MRB (action='create') In case a new subscription request made by an MRB (action='create')
has been accepted, the MS MUST reply with a <mrbresponse> with status has been accepted, the MS MUST reply with a <mrbresponse> with status
code 200. The same rule applies whenever a request to update code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction (action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MS. can be fulfilled by the MS.
A subscription request, nevertheless, may fail for several reasons. A subscription request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used In such a case, the status codes defined in Table 1 must be used
instead. Specifically, if the MS fails to handle a request due to a instead. Specifically, if the MS fails to handle a request due to a
syntax error in the request itself (e.g., incorrext XML, violation of syntax error in the request itself (e.g., incorrect XML, violation of
the schema constraints or invalid values in any of the attributes/ the schema constraints or invalid values in any of the attributes/
elements) the MS MUST reply with a <mrbresponse> with status code elements) the MS MUST reply with a <mrbresponse> with status code
400. If a syntactically correct request fails because the request 400. If a syntactically correct request fails because the request
also includes any attribute/element the MS doesn't understand, the MS also includes any attribute/element the MS doesn't understand, the MS
MUST reply with a <mrbresponse> with status code 420. If a MUST reply with a <mrbresponse> with status code 420. If a
syntactically correct request fails because the MRB wants to create a syntactically correct request fails because the MRB wants to create a
new subscription, but the provided intended id for the subscription new subscription, but the provided intended id for the subscription
already exists, the MS MUST reply with a <mrbresponse> with status already exists, the MS MUST reply with a <mrbresponse> with status
code 405. If a syntactically correct request failes because the MRB code 405. If a syntactically correct request fails because the MRB
wants to update/remove a subscription that doesn't exist, the MS MUST wants to update/remove a subscription that doesn't exist, the MS MUST
reply with a <mrbresponse> with status code 404. If the MS is unable reply with a <mrbresponse> with status code 404. If the MS is unable
to accept a request for any other reason (e.g., the MRB has no more to accept a request for any other reason (e.g., the MRB has no more
resources to fulfil the request), the MS MUST reply with a resources to fulfil the request), the MS MUST reply with a
<mrbresponse> with status code 401/402/403, depending on the action <mrbresponse> with status code 401/402/403, depending on the action
the MRB provided in its request: the MRB provided in its request:
o action='create' --> 401; o action='create' --> 401;
o action='update' --> 402; o action='update' --> 402;
skipping to change at page 30, line 32 skipping to change at page 30, line 35
have been accepted or were omitted in the request. have been accepted or were omitted in the request.
5.2. Media Service Resource Consumer Interface 5.2. Media Service Resource Consumer Interface
The Media Server Consumer interface provides the ability for clients The Media Server Consumer interface provides the ability for clients
of an MRB, such as Application Servers, to request an appropriate of an MRB, such as Application Servers, to request an appropriate
Media Server to satisfy specific criteria. The interface allows a Media Server to satisfy specific criteria. The interface allows a
client to pass detailed meta-information to the MRB to help select an client to pass detailed meta-information to the MRB to help select an
appropriate Media Server. The MRB is then able to make an informed appropriate Media Server. The MRB is then able to make an informed
decision and provide the client with an appropriate media server decision and provide the client with an appropriate media server
resource. The MRB Consumer interface can be used in association with resource. The MRB Consumer interface includes both 1) In-Line Aware
both the Session Initiation Protocol (SIP) and the Hypertext Transfer MRB Mode (IAMM) that uses the Session Initiation Protocol (SIP) and
Protocol (HTTP) [RFC2616]. The following subsections provide 2) Query mode that uses the Hypertext Transfer Protocol (HTTP)
guidance on using the Consumer interface, as defined by the [RFC2616]. The MRB Consumer interface does not include In-Line
'application/mrb-consumer+xml MIME type in Section 8, with HTTP and Unaware Mode (IUMM) which is further explained in Section 5.3. The
SIP. following subsections provide guidance on using the Consumer
interface, as defined by the 'application/mrb-consumer+xml MIME type
in Section 11, with HTTP and SIP.
5.2.1. HTTP Consumer Interface Usage 5.2.1. Query Mode / HTTP Consumer Interface Usage
An appropriate interface for such a 'query' style interface is in An appropriate interface for such a 'query' style interface is in
fact a HTTP usage. Using HTTP and XML combined reduces complexity fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages use of common tools that are widely available in the and encourages use of common tools that are widely available in the
industry today. The following information explains the primary industry today. The following information explains the primary
operations required to request and then receive information from an operations required to request and then receive information from an
MRB. The following description will describe the use of HTTP MRB. 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 8, MUST be carried in the body of an HTTP/HTTPS element from Section 11, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
the 'mediaResourceRequest' element as defined in Section 8. The the 'mediaResourceRequest' element as defined in Section 11. 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 8, MUST be carried in <mediaResourceResponse> element from Section 11, MUST be carried in
the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS request/ POST request. The MIME type contained in the HTTP/HTTPS request/
response MUST be 'application/mrb-consumer+xml'. This value MUST be response MUST be 'application/mrb-consumer+xml'. This value MUST be
reflected in the appropriate HTTP headers like 'Content-Type' and reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
the 'mediaResourceResponse' element as defined in Section 8. The the 'mediaResourceResponse' element as defined in Section 11. 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 When an application server wants to release previously awarded media
resources granted through a prior request/response exchange with MRB,
it will send a new request with an <action> element with value
'remove' as described in Section Section 5.2.3 about the use of the
Consumer interface lease mechanism.
5.2.2. In-Line Aware Mode / 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 request for media resources 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.2.2.1).
The media resource query, as defined by the <mediaResourceRequest> Use of IAMM, besides having the MRB select an appropriate media
element from Section 8, MUST be carried in a SIP INVITE request. The resource on behalf of a client application, includes setting up
INVITE request will be constructed as it would have been to connect either a Control Framework control channel between an application
to a media server, as defined by the Media Control Channel Framework server and media server (Section 5.2.2.1) or a call leg media session
[I-D.ietf-mediactrl-sip-control-framework]. The following additional between an application server and a media server (Section 5.2.2.2).
steps MUST be followed when using the Consumer interface: Note that in either case the SIP address of the selected media server
is made known to the requesting application server in the SIP 200 OK
response as the media-server-address element in the <response-
session-info> element (Section 5.2.5).
5.2.2.1. IAMM and Setting up a Control Framework Control Channel
The media resource request information, as defined by the
<mediaResourceRequest> element from Section 11, MUST be carried in a
SIP INVITE request. The INVITE request will be constructed as it
would have been to connect to a media server, as defined by the Media
Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework].
The following additional 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]. One of the parts to be included in the mixed'[RFC2046]. One of the parts to be included in the
'multipart/mixed' payload MUST be the 'application/sdp' format 'multipart/mixed' payload MUST be the 'application/sdp' format
which is constructed as specified in the Media Control Channel which is constructed as specified in the Media Control Channel
Framework [I-D.ietf-mediactrl-sip-control-framework]. Framework [I-D.ietf-mediactrl-sip-control-framework].
o Another part of the 'multipart/mixed' payload MUST be of type o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and 'application/mrb-consumer+xml', as specified in this document and
defined in Section 8. Only the <mediaResourceRequest> and its defined in Section 11. 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 On receiving a SIP INVITE request containing the multipart mixed
<mediaResourceResponse> element from Section 8, MUST be carried in payload as specified previously, the MRB will complete a number of
steps to fulfill the request. It will:
o Extract the multipart MIME payload from the SIP INVITE request.
It will then use the contextual information provided by the client
in the 'application/mrb-consumer+xml' part to determine which
media server should be selected to service the request.
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
selected media server, as defined in the Media Channel Control
Framework [I-D.ietf-mediactrl-sip-control-framework].
The MRB acts as a Back-to-Back-UA (B2BUA) that extracts the
'application/mrb-consumer+xml' information from the SIP INVITE
request and then sends a corresponding SIP INVITE request to the
selected Media Server.
Once the MRB receives the SIP response from the selected media
resource (i.e., media server), it will in turn respond to the
requesting client (i.e., application server).
The media resource response by MRB to a request, as defined by the
<mediaResourceResponse> element from Section 11, MUST be carried in
the payload of a SIP 2xx class response to the original SIP INVITE the payload of a SIP 2xx class response to the original SIP INVITE
request. The 2xx class response will be constructed as it would have request. The 2xx class response will be constructed as it would have
been to connect from a media server, as defined by the Media Control been to connect from a media server, as defined by the Media Control
Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. The
following additional steps MUST be followed when using the Consumer following additional steps MUST be followed when using the Consumer
interface: interface:
o Include a payload in the SIP 2xx class response of type o Include a payload in the SIP 2xx class response of type
'multipart/mixed'RFC 2046 [RFC2046]. One of the parts to be 'multipart/mixed' as perRFC 2046 [RFC2046]. One of the parts to
included in the 'multipart/mixed' payload MUST be the be included in the 'multipart/mixed' payload MUST be the
'application/sdp' format which is constructed as specified in the 'application/sdp' format which is constructed as specified in the
Media Control Channel Framework Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
o Another part of the 'multipart/mixed' payload MUST be of type o Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and 'application/mrb-consumer+xml', as specified in this document and
defined in Section 8. Only the <mediaResourceResponse> and its defined in Section 11. Only the <mediaResourceResponse> and its
child elements can be included in the payload. child elements can be included in the payload.
o The SIP 2xx class response will then be dispatched from the MRB. o The SIP 2xx class response will then be dispatched from the MRB.
o A SIP ACK to the 2xx class response will then be sent back to the o A SIP ACK to the 2xx class response will then be sent back to the
MRB. MRB.
An MRB implementation may be programmed to conclude that the
requested resources are no longer needed when it receives a SIP BYE
from the application server or media server that concludes the SIP
dialog that initiated the request, or when the lease interval
expires.
5.2.2.2. IAMM and Setting up a Call Leg
This scenario is identical to the description in the prior section
for setting up a Control Framework control channel, except for the
difference that the application/sdp payload conveys content
appropriate for setting up the call leg to the media resource, as per
RFC 3261 [RFC2046], instead of application/sdp payload for setting up
a control channel.
5.2.3. Consumer Interface Lease Mechanism 5.2.3. Consumer Interface Lease Mechanism
The Consumer interface defined in Section 5.2 and Section 8 allows a The Consumer interface defined in Section 5.2 and Section 11 allows a
client to request an appropriate media resource based on information client to request an appropriate media resource based on information
included in the request (either a HTTP POST or SIP INVITE message). included in the request (either a HTTP POST or SIP INVITE message).
In case of success, the response that is returned to the client MUST In case of success, the response that is returned to the client MUST
contain a <session-info> element in either the SIP 2xx class or HTTP contain a <session-info> element in either the SIP 2xx class or HTTP
200 response. The information contained in the <response-session- 200 response. The information contained in the <response-session-
info> element allows a Consumer client to monitor the life time of info> element allows a Consumer client to monitor the life time of
the resources it has successfully requested, as well as amending the resources it has successfully requested, as well as amending
them. them.
Before delving into the details of such lease mechanism, though, it's Before delving into the details of such lease mechanism, though, it's
worthwhile to first clarify its role within the context of the worthwhile to first clarify its role within the context of the
Consumer interface. As explained in Section 5.1, the knowledge the Consumer interface. As explained in Section 5.1, the knowledge the
skipping to change at page 33, line 6 skipping to change at page 34, line 21
Before delving into the details of such lease mechanism, though, it's Before delving into the details of such lease mechanism, though, it's
worthwhile to first clarify its role within the context of the worthwhile to first clarify its role within the context of the
Consumer interface. As explained in Section 5.1, the knowledge the Consumer interface. As explained in Section 5.1, the knowledge the
MRB has of the resources of all the MS it handles is imperfect. As MRB has of the resources of all the MS it handles is imperfect. As
such, how an MRB actually manages such resources depends on how it is such, how an MRB actually manages such resources depends on how it is
implemented: one may choose to have the MRB keeping track and state implemented: one may choose to have the MRB keeping track and state
of the allocated resources, or simply depend on the MS themselves to of the allocated resources, or simply depend on the MS themselves to
provide the information by means of the publishing interface provide the information by means of the publishing interface
notifications. Further information may be inferred by the notifications. Further information may be inferred by the
signalling, in case the MRB is in the path of call legs. This means signalling, in case the MRB is in the path of call legs.
that the MRB may or may not be able to enforce the leasing mechanism
it provides: such functionality is demanded, if necessary, to the
actual deployment of a compliant entity, with the help of the
information herein provided.
That said, the <mediaResourceResponse> element returned from the MRB That said, the <mediaResourceResponse> element returned from the MRB
contains a <response-session-info> element if the request is contains a <response-session-info> element if the request is
successful. The <response-session-info> element has the following successful. The <response-session-info> element has the following
child elements which provide the appropriate resource session child elements which provide the appropriate resource session
information: information:
o <session-id> is a unique identifier that enables a Consumer client o <session-id> is a unique identifier that enables a Consumer client
and MRB to correlate future media resource requests related to an and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included initial media resource request. The <session-id> MUST be included
skipping to change at page 33, line 37 skipping to change at page 34, line 48
MUST increment the value returned in the <seq> element and include MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when in the request (see <seq> use later in this section when
constructing a subsequent request). constructing a subsequent request).
o <expires> provides a value which represents the number of seconds o <expires> provides a value which represents the number of seconds
the request for media resources is deemed alive. The Consumer the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later client should issue a refresh of the request, as discussed later
in this section, if the expires timer is due to fire and the media in this section, if the expires timer is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides a value which represents the SIP o <media-server-address> provides information representing the
URI where the assigned MS can be contacted to make use of the assigned MS.
required media resources.
The <mediaResourceRequest> element is used in subsequent Consumer The <mediaResourceRequest> element is used in subsequent Consumer
interface requests if the client wishes to manipulate the session. interface requests if the client wishes to manipulate the session.
The Consumer client MUST include the <session-info> element which The Consumer client MUST include the <session-info> element which
enables the receiving MRB to determine an existing media resource enables the receiving MRB to determine an existing media resource
allocation session. The <session-info> element has the following allocation session. The <session-info> element has the following
child elements which provide the appropriate resource session child elements which provide the appropriate resource session
information to the MRB: information to the MRB:
o <session-id> is a unique identifier that allows a Consumer client o <session-id> is a unique identifier that allows a Consumer client
to indicate the appropriate existing media resource session to be to indicate the appropriate existing media resource session to be
manipulated by the MRB for this request. The value was provided manipulated by the MRB for this request. The value was provided
by the MRB in the initial request for media resources, as by the MRB in the initial request for media resources, as
skipping to change at page 35, line 9 skipping to change at page 36, line 18
Omitting the 'action' attribute means requesting a new set of Omitting the 'action' attribute means requesting a new set of
resources. resources.
When used with SIP the <session-info> element MUST be included in When used with 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]).
With IAMM, the application server or media server will eventually
send a SIP BYE to end the SIP session, whether it was for a control
channel or a call leg. That BYE contains no Consumer interface lease
information. An MRB can be programmed to know that receipt of such a
BYE also means to free up the media resources that had been requested
and awarded related to that session.
5.2.4. Media Service Resource Request 5.2.4. Media Service Resource Request
This section defines the XML elements for the Consumer interface. This section defines the XML elements for the Consumer interface.
The formal XML schema definition for the Consumer interface can be The formal XML schema definition for the Consumer interface can be
found in Section 8. found in Section 11.
The root element is <mrbconsumer>. All other XML elements (requests, The root element is <mrbconsumer>. All other XML elements (requests,
responses) are contained within it. The MRB Consumer interface responses) are contained within it. The MRB Consumer interface
request element is detailed in Section 5.2.4.1. MRB Consumer request element is detailed in Section 5.2.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 45, line 48 skipping to change at page 47, line 27
the XCON conference information data model, or to non-XCON layouts the XCON conference information data model, or to non-XCON layouts
as well, as long as they are properly prefixed. The <video- as well, as long as they are properly prefixed. The <video-
mixing-mode> element has a single attribute, 'package'. The mixing-mode> element has a single attribute, 'package'. The
attribute 'package' provides the name of the Media Control Channel attribute 'package' provides the name of the Media Control Channel
Framework package, compliant with the specification in the related Framework package, compliant with the specification in the related
IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support is requested. support is requested.
5.2.4.1.3.6. <application-data> 5.2.4.1.3.6. <application-data>
The <application-data> element provides IVR application level data. The <application-data> element provides application level data. The
The element MAY be present. element MAY be present.
The <application-data> element has no attributes. The <application-data> element has no attributes.
The <application-data> element has no child elements. The <application-data> element has no child elements.
5.2.4.1.3.7. <location> 5.2.4.1.3.7. <location>
The <location> element requests a civic location for a mixer media The <location> element requests a civic location for a mixer media
server. The request makes use of the Civic Address Schema server. The request makes use of the Civic Address Schema
standardized in RFC 5139 [RFC5139]. The element MAY be present. standardized in RFC 5139 [RFC5139]. The element MAY be present.
skipping to change at page 46, line 43 skipping to change at page 48, line 21
5.2.5. Media Service Resource Response 5.2.5. Media Service Resource Response
This section provides the element definitions for use in Consumer This section provides the element definitions for use in Consumer
interface responses. The responses are carried in the interface responses. The responses are carried in the
<mediaResourceResponse> container element. <mediaResourceResponse> container element.
5.2.5.1. <mediaResourceResponse> element 5.2.5.1. <mediaResourceResponse> element
The <mediaResourceResponse> element provides a container for clients The <mediaResourceResponse> element provides a container for clients
receiving query information from an external MRB entity. receiving response information from an external MRB entity.
The <mediaResourceResponse> element has a single attribute 'status' The <mediaResourceResponse> element has a single attribute 'status'
which indicates the status code of the operation. The following which indicates the status code of the operation. The following
status codes are defined for 'status': status codes are defined for 'status':
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| code | description | | code | description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 200 | OK | | 200 | OK |
| | | | | |
skipping to change at page 47, line 24 skipping to change at page 48, line 46
| 409 | Unable to update Resource | | 409 | Unable to update Resource |
| | | | | |
| 410 | Unable to remove Resource | | 410 | Unable to remove Resource |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 2: <response> status codes Table 2: <response> status codes
In case a new media resource request made by an AS (no action) has In case a new media resource request made by an AS (no action) has
been accepted, the MS MUST reply with a <mediaResourceResponse> with been accepted, the MRB MUST reply with a <mediaResourceResponse> with
status code 200. The same rule applies whenever a request to update status code 200. The same rule applies whenever a request to update
(action='update') or remove (action='remove') an existing transaction (action='update') or remove (action='remove') an existing transaction
can be fulfilled by the MRB. can be fulfilled by the MRB.
A media resource request, nevertheless, may fail for several reasons. A media resource request, nevertheless, may fail for several reasons.
In such a case, the status codes defined in Table 1 must be used In such a case, the status codes defined in Table 1 must be used
instead. Specifically, if the MRB fails to handle a request due to a instead. Specifically, if the MRB fails to handle a request due to a
syntax error in the request itself (e.g., incorrext XML, violation of syntax error in the request itself (e.g., incorrext XML, violation of
the schema constraints or invalid values in any of the attributes/ the schema constraints or invalid values in any of the attributes/
elements) the MRB MUST reply with a <mediaResourceResponse> with elements) the MRB MUST reply with a <mediaResourceResponse> with
status code 400. If a syntactically correct request fails because status code 400. If a syntactically correct request fails because
the request also includes any attribute/element the MRB doesn't the request also includes any attribute/element the MRB doesn't
understand, the MRB MUST reply with a <mediaResourceResponse> with understand, the MRB MUST reply with a <mediaResourceResponse> with
status code 420. If a syntactically correct request fails because status code 420. If a syntactically correct request fails because
the MRB couldn't find any MS able to fulfil the requirements the MRB couldn't find any MS able to fulfil the requirements
skipping to change at page 48, line 48 skipping to change at page 50, line 23
refreshed before expiry, the MRB will re-claim the resources and refreshed before expiry, the MRB will re-claim the resources and
they will no longer be guaranteed. It is RECOMMENDED that a they will no longer be guaranteed. It is RECOMMENDED that a
minimum value of 300 seconds be used for the value of the minimum value of 300 seconds be used for the value of the
'expires' attribute. It is also RECOMMENDED that a Consumer 'expires' attribute. It is also RECOMMENDED that a Consumer
client refresh the lease at an interval that is not too close to client refresh the lease at an interval that is not too close to
the expiry time. A value of 80% of the timeout period could be the expiry time. A value of 80% of the timeout period could be
used. For example, if the timeout period is 300 seconds, the used. For example, if the timeout period is 300 seconds, the
Server would refresh the transaction at 240 seconds. More Server would refresh the transaction at 240 seconds. More
information on its use is provided in Section 5.2.3. information on its use is provided in Section 5.2.3.
media-server-address: is the SIP URI to reach the MS handling the media-server-address: provides information to reach the MS handling
requested media resource. the requested media resource. The <media-server-address> element
has a single attribute named 'uri' which supplies the direct
address to a media server. It also has three optional elements
<connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions>
and <mixers> are defined in Section 5.2.4.1.2.1 and
Section 5.2.4.1.3.1 and have the same meaning but are applied to
individual media server instances as a subset of the overall
resources reported in the <connection-id> element. For more
information on the use of the <connection-id> element see
Section 6.
5.3. In-Line MRB Interface 5.3. In-Line Unaware MRB Interface
An entity acting as an In-Line MRB can act in one of two roles for a An entity acting as an In-Line MRB can act in one of two roles for a
request, as introduced in Section 4.2. The following sub sections request, as introduced in Section 4.2. In-Line Unaware MRB Mode
provide details for using In-Line Unaware MRB Mode (IUMM) of (IUMM) of operation and In-Line Aware MRB Mode (IAMM) of operation.
operation and In-Line Aware MRB Mode (IAMM) of operation. This section further describes IUMM.
5.3.1. In-line Unaware MRB Mode
It should be noted that the introduction of an MRB entity into the It should be noted that the introduction of an MRB entity into the
network, as specified in this document, requires interfaces to be network, as specified in this document, requires interfaces to be
implemented by those requesting media server resources (for example implemented by those requesting media server resources (for example
an application server). This applies when using both the Consumer an application server). This applies when using the Consumer
interface as discussed in Section 5.2.1 and IAMM Section 5.2.2. interface as discussed in Section 5.2.1(Query mode) and
Nevertheless, an MRB is conceived to also be able to act in a client Section 5.2.2(IAMM). Nevertheless, an MRB is conceived to also be
unaware mode when it is deployed into the network. This allows any able to act in a client unaware mode when it is deployed into the
SIP compliant client entity, as defined by RFC 3261 [RFC3261] and its network. This allows any SIP compliant client entity, as defined by
extensions, to send requests to an MRB which in turn will select an RFC 3261 [RFC3261] and its extensions, to send requests to an MRB
appropriate media server based on knowledge of media server resources which in turn will select an appropriate media server based on
it currently has available transparently to the client entity. knowledge of media server resources it currently has available
Mechanisms used to connect to media servers are detailed in the Media transparently to the client entity. Using an MRB in this mode allows
Channel Control Framework [I-D.ietf-mediactrl-sip-control-framework]. for easy migration of current applications and services that are
Using an MRB in this mode allows for easy migration of current unaware of the MRB concept and would simply require a configuration
applications and services that are unaware of the MRB concept and change resulting in the MRB being set as a SIP outbound proxy for
would simply require a configuration change resulting in the MRB clients requiring media services.
being set as a SIP outbound proxy for clients requiring media
services. Any client of media services wishing to take advantage of
the advanced techniques detailed in this document when using In-line
mode would implement IAMM which is covered in Section 5.3.2.
5.3.2. In-line Aware MRB Mode With IUMM, the MRB may conclude that an assigned media resource is no
longer needed when it receives a SIP BYE from the application server
or media server that ends that SIP dialog that initiated the request.
An In-Line Aware Mode MRB (IAMM) is one that complies to the extended As with IAMM, in IUMM the SIP INVITE from the application server
functionality provided in this section. A client entity, such as an could convey application/sdp payload to either set up a call leg or a
application server, wishing to use advanced MRB functionality can Control Framework control channel. In either case, if the ultimate
provide additional contextual information to an MRB. This intent is to correlate a call leg with a control channel to the same
information is identical to that used in the Consumer interface in media server, the MRB should be acting as a SIP proxy (and not a
Section 5.2 with the only difference being the underlying transport B2BUA) so that the SIP address of the targeted media server can be
mechanism of the contextual information, as specified by the transparently passed back to the application server in the SIP
'application/mrb-consumer+xml' payload in Section 8. A client of an response and so that the SIP dialog information is between the
IAMM, as anticipated in Section 5.2.2, uses SIP signalling to convey application server and the media server.
the 'application/mrb-consumer+xml' payload to the IAMM, unlike the
Consumer interface presented in Section 5.2.1, which instead uses
HTTP as a transport. A client of an IAMM requiring media services,
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
request is dealt with appropriately:
o The client of the IAMM constructs a SIP INVITE request to connect While IUMM has the least impact on legacy application servers, it
to a Media Server as detailed in the Media Channel Control also provides the least versatility. See Section 8.
Framework [I-D.ietf-mediactrl-sip-control-framework] with one
exception.
o The client of the IAMM includes a MIME content type of multipart/ 6. MRB acting as a B2BUA
mixed as defined in RFC 2046 [RFC2046]. As part of this mixed
payload, the client MUST at least include a content-type of type
'application/sdp' and a content type of type 'application/
mrb-consumer+xml'. The part of type application/sdp represents
the media server connection details and MUST adhere to the Media
Channel Control Framework
[I-D.ietf-mediactrl-sip-control-framework]. The part of type
'application/mrb-consumer+xml' represents the IAMM contextual
information and MUST adhere to the schema defined in Section 8.
o Once the SIP INVITE request is constructed, it is sent to the An MRB entity can potentially act as a SIP Back-2-Back-User-Agent
recipient as per RFC 3261 [RFC3261]. (B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When
acting as a B2BUA issues can arise when using Media Control Channel
packages such as the IVR
Package[I-D.ietf-mediactrl-ivr-control-package] and Mixer Packages
[I-D.ietf-mediactrl-mixer-control-package]. Specifically the
Framework attribute 'connectionid' provided in the appendix titled
'Appendix: Common Package Components' of Media Control Channel
Framework[I-D.ietf-mediactrl-sip-control-framework] uses a
concatenation of the SIP dialog identifiers to be used for
referencing SIP dialogs within the media control channel. When a
request traverses an MRB acting as a B2BUA, the SIP dialog
identifiers change and so the 'connectionid' can not be used as
intended due to the SIP dialog identifiers changing. For this reason
when a MRB wishes to act as a SIP B2BUA when handling a request from
an AS to set up a call leg to a MS it MUST include the optional
<connection-id> element in a Consumer interface response with a value
that represents the equivalent for the 'connectionid' ('Local Dialog
Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If
present, this value MUST be used as the value for the 'connectionid'
in packages where the Common Package Components are used. The
<connection-id> element MUST not be included in a HTTP Consumer
interface response.
On receiving a SIP INVITE request containing the multipart mixed 7. Multi-modal MRB Implementations
payload as specified previously, the IAMM will complete a number of
steps to fulfil the request. It will:
o Extract the multipart MIME payload from the SIP INVITE request. An MRB implementation may operate multi-modally with a collection of
It will then use the contextual information provided by the client application server clients all sharing the same pool of media
in the 'application/mrb-consumer+xml' part to determine which resources. I.e., an MRB may be simultaneously operating in Query
media server should be selected to service the request. mode, IAMM and IUMM. It knows in which mode to act on any particular
request from a client depending on the nature of the request:
o Extract the 'application/sdp' part from the payload and use it to o If the received quest is HTTP Post with application/
populate a new SIP INVITE request for connecting the client to the mrb-consumer+xml content, then MRB processes it in Query mode.
selected media server, as defined in the Media Channel Control
Framework [I-D.ietf-mediactrl-sip-control-framework]. The IAMM
acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/
mrb-consumer+xml' information from the SIP INVITE request and then
forwards to the selected Media Server.
6. Examples o If the received request is a SIP INVITE with application/
mrb-consumer+xml content and application/sdp content, then MRB
processes it in IAMM.
o If the received request is a SIP INVITE without application/
mrb-consumer+xml content but with application/sdp content then MRB
processes it in IUMM.
8. Relative Merits of Query Mode, IAMM, and IUMM
At a high level, the possible application server MRB interactions can
be distinguished among the following basic types:
a. Query mode, in which the client is requesting the assignment by
MRB of suitable MS resources
b. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a call leg to the
MS
c. IAMM in which the client is requesting the assignment by MRB of
suitable MS resources and the establishment of a CFW control
channel to the MS
d. IUMM where the client is requesting the establishment of a call
leg to MS resources
e. IUMM where the client is requesting the establishment of a CFW
control channel to MS resources
Each type of interaction has advantages and disadvantages compared to
the others, where such considerations may have to do with the
versatility of what MRB can provide, technical aspects such as
efficiency in different application scenarios, complexity, delay, use
with legacy application servers, or use with the Media Control
Channel Framework. Depending on the characteristics of a particular
setting that an MRB is intended to support, some of the above
interaction types may be more appropriate than others. This section
makes a few observations on relative merits, but is not intended to
be exhaustive. Some constraints of a given interaction type may be
subtle.
o About operation with other types of media control: Any of the
types of interactions work with the use RFC 4240 [RFC4240] and RFC
5552 [RFC5552] where initial control instructions are conveyed in
the SIP INVITE from the application server for the call leg to the
media server and subsequent instructions may be fetched using
HTTP. Query mode (a), IAMM/call leg (b) and IUMM/call leg (d)
work with MSML as per RFC 5705 [RFC5705] or MSCML as per RFC 4722
[RFC4722].
o As stated previously, IUMM has no interface impacts on an
application server. On the other hand, with IUMM the application
server does not specify the characteristics of the type of media
resource it needs because the <mediaResourceRequest> element is
not passed to the MRB. For IUMM call leg (d) the best the MRB can
do to deduce an appropriate media resource gleaned from examining
other information in the SIP INVITE, such as the SDP information
for the call leg, or initial control information in the SIP
Request URI as per RFC 4240 [RFC4240]. With IUMM/control channel
(e) there is even less information for the MRB to use.
o If using IUMM/control channel (e), the subsequent sending of the
call leg to the media server should not be done using IUMM/call
leg. I.e., the SIP signaling to send the call leg to the selected
media server must be directly between the application server and
that media server, and not through the MRB. Otherwise, MRB might
send the call leg to a different media server. Likewise, if using
IUMM/call leg (d), the subsequent establishment of a control
channel should not be done with IUMM/control channel (e).
o Query mode (a) and IAMM/control channel (c) lend themselves to
requesting in advance a pool of media resources (e.g., a number of
IVR or conferencing ports) in advance of use and retaining their
use over a period of time, independent of whether there are call
legs to those resources at any given moment, whereas the other
types of interactions do not. Likewise for making a subsequent
request to increase or decrease the amount of resources previously
awarded.
o While Query mode (a) and IAMM/control channel (c) are the most
versatile interaction types, the former is completely decoupled
from the use or not of a control channel, whereas the latter
requires the use of a control channel.
o When Media Control Channel Framework control channels are to be
used in conjunction with the use of MRB, Query mode (a) would
typically result in fewer such channels being established over
time as compared to IAMM/control channel (c). That is because the
latter would involve setting up an additional control channel
every time an AS has a new request for MBR for media resources.
9. Examples
This section provides examples of both the Publish and Consumer This section provides examples of both the Publish and Consumer
interfaces. For what concerns the Consumer interface, both Query and interfaces. For what concerns the Consumer interface, both Query and
Inline modes are addressed. Inline modes are addressed.
Note that due to RFC formatting conventions, this section often Note that due to RFC formatting conventions, this section often
splits HTTP, SIP/SDP and CFW across lines whose content would exceed splits HTTP, SIP/SDP and CFW across lines whose content would exceed
72 characters. A backslash character marks where this line folding 72 characters. A backslash character marks where this line folding
has taken place. This backslash and its trailing CRLF and whitespace has taken place. This backslash and its trailing CRLF and whitespace
would not appear in the actual protocol contents. Besides, also note would not appear in the actual protocol contents. Besides, also note
that the indentation of the XML content is only provided for that the indentation of the XML content is only provided for
readability: actual messages will follow strict XML syntax, which readability: actual messages will follow strict XML syntax, which
allows for, but does not require, indentation. allows for, but does not require, indentation.
6.1. Publish Example 9.1. Publish Example
The following example assumes a control channel has been established The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework and synced as described in the Media Control Channel Framework
([I-D.ietf-mediactrl-sip-control-framework]). ([I-D.ietf-mediactrl-sip-control-framework]).
Figure 9 shows the subscription/notification mechanism the Publish Figure 9 shows the subscription/notification mechanism the Publish
interface is based on, as defined in Section 5.1. The MRB subscribes interface is based on, as defined in Section 5.1. The MRB subscribes
for information at the MS (message A1.), and the MS accepts the for information at the MS (message A1.), and the MS accepts the
subscription (A2). Notifications are triggered by the MS (A3.) and subscription (A2). Notifications are triggered by the MS (A3.) and
acknowledged by the MRB (A4.). acknowledged by the MRB (A4.).
skipping to change at page 53, line 31 skipping to change at page 58, line 31
</mrbpublish> </mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS) B1. MRB <- MS (CONTROL, event notification from MS)
--------------------------------------------------- ---------------------------------------------------
CFW 03fff52e7b7a CONTROL CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0 Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml Content-Type: application/mrb-publish+xml
Content-Length: 4242 Content-Length: 4242
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish" \ <mrbpublish version="1.0" \
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="QQ6J3c"> <mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id> <media-server-id>a1b2c3d4</media-server-id>
<supported-packages> <supported-packages>
<package name="msc-ivr/1.0"/> <package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/> <package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/> <package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/> <package name="msc-example-pkg/1.0"/>
</supported-packages> </supported-packages>
<active-rtp-sessions> <active-rtp-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
skipping to change at page 54, line 20 skipping to change at page 59, line 20
</active-mixer-sessions> </active-mixer-sessions>
<non-active-rtp-sessions> <non-active-rtp-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>50</decoding> <decoding>50</decoding>
<encoding>40</encoding> <encoding>40</encoding>
</rtp-codec> </rtp-codec>
</non-active-rtp-sessions> </non-active-rtp-sessions>
<non-active-mixer-sessions> <non-active-mixer-sessions>
<non-active-mix available="15"> <non-active-mix available="15">
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding/> <decoding>15</decoding>
<encoding/> <encoding>15</encoding>
</rtp-codec> </rtp-codec>
</non-active-mix> </non-active-mix>
</non-active-mixer-sessions> </non-active-mixer-sessions>
<media-server-status>active</media-server-status> <media-server-status>active</media-server-status>
<supported-codecs> <supported-codecs>
<supported-codecs name="audio/basic"> <supported-codec name="audio/basic">
<supported-codec-package name="msc-ivr/1.0"> <supported-codec-package name="msc-ivr/1.0">
<supported-actions>encoding</supported-actions> <supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions> <supported-actions>decoding</supported-actions>
</supported-codec-package> </supported-codec-package>
<supported-codec-package name="msc-mixer/1.0"> <supported-codec-package name="msc-mixer/1.0">
<supported-actions>encoding</supported-actions> <supported-actions>encoding</supported-actions>
<supported-actions>decoding</supported-actions> <supported-actions>decoding</supported-actions>
</supported-codec-package> </supported-codec-package>
</supported-codecs> </supported-codec>
</supported-codecs> </supported-codecs>
<application-data>Testbed Prototype</application-data> <application-data>TestbedPrototype</application-data>
<file-formats> <file-formats>
<supported-format name="audio/x-wav"> <supported-format name="audio/x-wav">
<supported-file-package/> <supported-file-package>
msc-ivr/1.0
</supported-file-package>
</supported-format> </supported-format>
</file-formats> </file-formats>
<max-prepared-duration> <max-prepared-duration>
<max-time max-time-seconds="3600"> <max-time max-time-seconds="3600">
<max-time-package>msc-ivr</max-time-package> <max-time-package>msc-ivr/1.0</max-time-package>
</max-time> </max-time>
</max-prepared-duration> </max-prepared-duration>
<dtmf-support> <dtmf-support>
<detect> <detect>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</detect> </detect>
<generate> <generate>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
skipping to change at page 56, line 27 skipping to change at page 61, line 30
<stream-mode package="msc-ivr/1.0" name="HTTP"/> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes> </streaming-modes>
<asr-tts-support> <asr-tts-support>
<asr-support> <asr-support>
<language xml:lang="en"/> <language xml:lang="en"/>
</asr-support> </asr-support>
<tts-support> <tts-support>
<language xml:lang="en"/> <language xml:lang="en"/>
</tts-support> </tts-support>
</asr-tts-support> </asr-tts-support>
<vxml-support support="false"> <vxml-support support="true">
<vxml-mode package="msc-ivr/1.0"/> <vxml-mode package="msc-ivr/1.0" support="IVR-Package"/>
</vxml-support> </vxml-support>
<media-server-location> <media-server-location>
<ca:civicAddress xml:lang="it"> <civicAddress xml:lang="it">
<ca:country>IT</ca:country> <country>IT</country>
<ca:A1>Campania</ca:A1> <A1>Campania</A1>
<ca:A3>Napoli</ca:A3> <A3>Napoli</A3>
<ca:A6>Via Claudio</ca:A6> <A6>Via Claudio</A6>
<ca:HNO>21</ca:HNO> <HNO>21</HNO>
<ca:LMK>University of Napoli Federico II</ca:LMK> <LMK>University of Napoli Federico II</LMK>
<ca:NAM>Dipartimento di Informatica e Sistemistica</ca:NAM> <NAM>Dipartimento di Informatica e Sistemistica</NAM>
<ca:PC>80210</ca:PC> <PC>80210</PC>
</ca:civicAddress> </civicAddress>
</media-server-location> </media-server-location>
<label>TestbedPrototype-01</label> <label>TestbedPrototype-01</label>
<media-server-address> <media-server-address>
sip:MediaServer@ms.example.com:5080 sip:MediaServer@ms.example.net
</media-server-address> </media-server-address>
<encryption>false</encryption> <encryption>false</encryption>
</mrbnotification> </mrbnotification>
</mrbpublish> </mrbpublish>
B2. MRB -> MS (200 to CONTROL) B2. MRB -> MS (200 to CONTROL)
------------------------------ ------------------------------
CFW 03fff52e7b7a 200 CFW 03fff52e7b7a 200
6.2. Consumer Example 9.2. Consumer Example
As specified in Section 5.2, the Consumer interface can be involved As specified in Section 5.2, the Consumer interface can be involved
in two different modes: Query and Inline-aware. When in Query mode, in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of Consumer messages are transported in HTTP messages: an example of
such an approach is presented in Section 6.2.1. When in Inline-aware such an approach is presented in Section 9.2.1. When in Inline-aware
mode, messages are transported as part of SIP negotiations: an mode, instead, messages are transported as part of SIP negotiations:
example of such an approach is presented in Section 6.2.2. considering this SIP negotiations may be related to either the
creation of a control channel or to a UAC call leg, two separate
examples of such an approach are presented in Section 9.2.2.
6.2.1. Query Example 9.2.1. Query Example
The following example assumes the interested AS already knows the The following example assumes the interested AS already knows the
HTTP URL where an MRB is listening for Consumer messages. HTTP URL where an MRB is listening for Consumer messages.
Figure 10 shows the HTTP-based transaction between the AS and the Figure 10 shows the HTTP-based transaction between the AS and the
MRB. The AS sends a consumer request as payload of an HTTP POST MRB. The AS sends a consumer request as payload of an HTTP POST
message (1.), and the MRB provides an answer in an HTTP 200 OK message (1.), and the MRB provides an answer in an HTTP 200 OK
message (2.). message (2.). Specifically, as it will be shown in the dumps, the AS
is interested in 100 IVR ports: the MRB finds two MS that can satisfy
the request (one providing 60 ports, the other 40 ports) and reports
them to the AS.
AS MRB AS MRB
| | | |
| 1. HTTP POST (Consumer request) | | 1. HTTP POST (Consumer request) |
|--------------------------------------------->| |--------------------------------------------->|
| | | |
| | | |
| |--+ Parse request | |--+ Parse request
| | | and see if any | | | and see if any
| |<-+ MS applies | |<-+ MS applies
| | | |
| 2. 200 OK (Consumer response) | | 2. 200 OK (Consumer response) |
|<---------------------------------------------| |<---------------------------------------------|
| | | |
|--+ Parse response and | |--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) | | | start session (SIP/COMEDIA/CFW) |
|<-+ with MS reported by MRB | |<-+ with first MS reported by MRB |
| | | |
. . . .
. . . .
Figure 10: Consumer Example (Query): Sequence Diagram Figure 10: Consumer Example (Query): Sequence Diagram
The rest of this section includes a full dump of the messages The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically: associated with the previous sequence diagram, specifically:
1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST, 1. the Consumer request (1), in a <mediaResourceRequest> (HTTP POST,
Content-Type 'application/mrb-consumer+xml'); Content-Type 'application/mrb-consumer+xml');
2. the Consumer response (2), in an <mediaResourceResponse> (HTTP 2. the Consumer response (2), in an <mediaResourceResponse> (HTTP
200 OK, Content-Type 'application/mrb-consumer+xml'). 200 OK, Content-Type 'application/mrb-consumer+xml').
1. AS -> MRB (HTTP POST, Consumer request) 1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------ ------------------------------------------
POST /Mrb/Consumer HTTP/1.1 POST /Mrb/Consumer HTTP/1.1
Content-Length: 870 Content-Length: 879
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
Host: mrb.example.net:8080 Host: mrb.example.net:8080
Connection: Keep-Alive Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0.1 (java 1.5) User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest> <mediaResourceRequest>
<generalInfo> <generalInfo>
<packages> <packages>
<package>msc-ivr/1.0</package> <package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package> <package>msc-mixer/1.0</package>
</packages> </packages>
</generalInfo> </generalInfo>
<ivrInfo> <ivrInfo>
<ivr-sessions> <ivr-sessions>
<rtp-codec name="audio/basic"> <rtp-codec name="audio/basic">
<decoding>10</decoding> <decoding>100</decoding>
<encoding>10</encoding> <encoding>100</encoding>
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
<file-formats> <file-formats>
<required-format name="audio/x-wav"/> <required-format name="audio/x-wav"/>
</file-formats> </file-formats>
<streaming-modes> <streaming-modes>
<stream-mode package="msc-ivr/1.0" name="HTTP"/> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</streaming-modes> </streaming-modes>
</ivrInfo> </ivrInfo>
</mediaResourceRequest> </mediaResourceRequest>
</mrbconsumer> </mrbconsumer>
2. AS <- MRB (200 to POST, Consumer response) 2. AS <- MRB (200 to POST, Consumer response)
--------------------------------------------- ---------------------------------------------
HTTP/1.1 200 OK HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5 X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.5 Server: Sun GlassFish Communications Server 1.5
Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
Content-Length: 506 Content-Length: 1133
Date: Mon, 08 Feb 2010 16:53:34 GMT Date: Mon, 12 Apr 2011 14:59:26 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" > <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"> <mediaResourceResponse reason="Resource found" status="200">
<response-session-info> <response-session-info>
<session-id>0GX1jCYZ8WBa</session-id> <session-id>5t3Y4IQ84gY1</session-id>
<seq>1</seq> <seq>1</seq>
<expires>3600</expires> <expires>3600</expires>
<media-server-address> <media-server-address \
sip:MediaServer@ms.example.com:5080 uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
The rest of the scenario is omitted for brevity. After having The rest of the scenario is omitted for brevity. After having
received the 'mediaResourceResponse', the AS has the address of a MS received the 'mediaResourceResponse', the AS has the address of two
able to fulfil its media requirements, and can start a Control Dialog MS able to fulfil its media requirements, and can start a Control
with it. Dialog with one or both of them.
6.2.2. IAMM Example 9.2.2. IAMM Example
As anticipated, two separate examples are presented for the IAMM
case: in fact, IAMM-mode can take advantage of two different
approaches with respect to the SIP dialogs to be exploited to carry
consumer messages, i.e.: i) a SIP control dialog to create a control
channel, and, ii) a UAC call leg to attach to a MS. To make things
clearer for the reader, the same consumer request as the one
presented in the Query mode will be sent, in order to clarify how the
behaviour of the involved parties may differ.
9.2.2.1. IAMM Example: CFW-based approach
The following example assumes the interested AS already knows the SIP The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS. URI where an MRB is listening as an UAS.
Figure 10 shows the SIP-based transactions involving the AS, the MRB Figure 11 shows the first approach, i.e. SIP-based transactions
involving the AS interested in setting up a control channel, the MRB
and the MS that will be chosen eventually. The diagram is more and the MS that will be chosen eventually. The diagram is more
complex than before. This is basically a scenario envisaging the MRB complex than before. This is basically a scenario envisaging the MRB
as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW- as a B2BUA. The AS sends a SIP INVITE (1.), containing both a CFW-
related SDP and a Consumer request (multipart body). The MRB sends a related SDP and a Consumer request (multipart body). The MRB sends a
provisional response to the AS (2.) and starts working on the provisional response to the AS (2.) and starts working on the
request. First of all, it makes use of the Consumer request from the request. First of all, it makes use of the Consumer request from the
AS to determine which MS should be exploited. Once the right MS has AS to determine which MS should be exploited. Once the right MS have
been chosen, the MRB sends a new SIP INVITE to this MS by just been chosen, the MRB sends a new SIP INVITE to one of the MS by just
including the SDP part of the original request (3.). The MS including the SDP part of the original request (3.). The MS
negotiates this INVITE as specified in negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing [I-D.ietf-mediactrl-sip-control-framework] (4., 5., 6.), providing
the MRB with its own CFW-related SDP. The MRB replies to the the MRB with its own CFW-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body original AS INVITE preparing a SIP 200 OK with another multipart body
(7.): this multipart body includes the Consumer response used by the (7.): this multipart body includes the Consumer response used by the
MRB to determine the right MS and the SDP returned by the MS in 5. MRB to determine the right MS and the SDP returned by the MS in 5.
The AS finally acknowledges the 200 OK (8.), and can start a CFW The AS finally acknowledges the 200 OK (8.), and can start a CFW
connection towards the MS. connection towards the MS.
skipping to change at page 62, line 5 skipping to change at page 68, line 5
| | | | | |
| | | |
|<<############## TCP CONNECTION #################>>| |<<############## TCP CONNECTION #################>>|
| | | |
| CFW SYNC | | CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>| |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | | |
. . . . . .
. . . . . .
Figure 11: Consumer Example (IAMM): Sequence Diagram Figure 11: Consumer Example (IAMM-CFW): Sequence Diagram
The rest of this section includes an almost full dump of the messages The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP associated with the previous sequence diagram. Only the relevant SIP
messages are shown (both the INVITEs and the 200 OKs), and only the messages are shown (both the INVITEs and the 200 OKs), and only the
relevant headers are preserved for brevity (Content-Type and relevant headers are preserved for brevity (Content-Type and
multipart-related information). Specifically: multipart-related information). Specifically:
1. the original INVITE (1), containing both a CFW-related SDP 1. the original INVITE (1), containing both a CFW-related SDP
(COMEDIA information to negotiate a new Control Channel) and a (COMEDIA information to negotiate a new Control Channel) and a
Consumer <mediaResourceRequest>; Consumer <mediaResourceRequest>;
skipping to change at page 62, line 28 skipping to change at page 68, line 28
only the CFW-related SDP from the original INVITE;. only the CFW-related SDP from the original INVITE;.
3. the 200 OK sent by the MS back to the MRB (5.), to complete the 3. the 200 OK sent by the MS back to the MRB (5.), to complete the
CFW-related negotiation (SDP only); CFW-related negotiation (SDP only);
4. the 200 OK sent by the MRB back to the AS in response to the 4. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (7.), containing both the CFW-related information original INVITE (7.), containing both the CFW-related information
sent by the MS and a Consumer <mediaResourceRequest> documenting sent by the MS and a Consumer <mediaResourceRequest> documenting
the MRB's decision to use that MS. the MRB's decision to use that MS.
1. AS -> MRB (INVITE multipart/mixed) 1. AS -> MRB (INVITE multipart/mixed)
------------------------------------- -------------------------------------
[..] [..]
Content-Type: multipart/mixed;boundary="=_Part" Content-Type: multipart/mixed;boundary="=_Part"
=_Part =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=- 2890844526 2890842807 IN IP4 as.example.com o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl s=MediaCtrl
c=IN IP4 as.example.com c=IN IP4 as.example.com
t=0 0 t=0 0
m=application 48035 TCP cfw m=application 48035 TCP cfw
a=connection:new a=connection:new
a=setup:active a=setup:active
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
=_Part =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mrbconsumer version="1.0" \
<mediaResourceRequest> xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<generalInfo> <mediaResourceRequest>
<packages> <generalInfo>
<package>msc-ivr/1.0</package> <packages>
<package>msc-mixer/1.0</package> <package>msc-ivr/1.0</package>
</packages> <package>msc-mixer/1.0</package>
</generalInfo> </packages>
<ivrInfo> </generalInfo>
<ivr-sessions> <ivrInfo>
<rtp-codec name="audio/basic"> <ivr-sessions>
<decoding>10</decoding> <rtp-codec name="audio/basic">
<encoding>10</encoding> <decoding>100</decoding>
</rtp-codec> <encoding>100</encoding>
</ivr-sessions> </rtp-codec>
<file-formats> </ivr-sessions>
<required-format name="audio/x-wav"/> <file-formats>
</file-formats> <required-format name="audio/x-wav"/>
<streaming-modes> </file-formats>
<stream-mode package="msc-ivr/1.0" name="HTTP"/> <streaming-modes>
</streaming-modes> <stream-mode package="msc-ivr/1.0" name="HTTP"/>
</ivrInfo> </streaming-modes>
</mediaResourceRequest> </ivrInfo>
</mrbconsumer> </mediaResourceRequest>
</mrbconsumer>
=_Part =_Part
3. MRB -> MS (INVITE sdp only) 3. MRB -> MS (INVITE sdp only)
------------------------------ ------------------------------
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=- 2890844526 2890842807 IN IP4 as.example.com o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl s=MediaCtrl
c=IN IP4 as.example.com c=IN IP4 as.example.com
t=0 0 t=0 0
m=application 48035 TCP cfw m=application 48035 TCP cfw
a=connection:new a=connection:new
a=setup:active a=setup:active
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
5. MRB <- MS (200 OK sdp) 5. MRB <- MS (200 OK sdp)
------------------------- -------------------------
[..] [..]
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl s=MediaCtrl
c=IN IP4 ms.example.net c=IN IP4 ms.example.net
t=0 0 t=0 0
m=application 7575 TCP cfw m=application 7575 TCP cfw
a=connection:new a=connection:new
a=setup:passive a=setup:passive
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0 a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0 a=ctrl-package:msc-example-pkg/1.0
7. AS <- MRB (200 OK multipart/mixed) 7. AS <- MRB (200 OK multipart/mixed)
------------------------------------- -------------------------------------
[..] [..]
Content-Type: multipart/mixed;boundary="=_Part" Content-Type: multipart/mixed;boundary="=_Part"
=_Part =_Part
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl s=MediaCtrl
c=IN IP4 ms.example.net c=IN IP4 ms.example.net
t=0 0 t=0 0
m=application 7575 TCP cfw m=application 7575 TCP cfw
a=connection:new a=connection:new
a=setup:passive a=setup:passive
a=cfw-id:vF0zD4xzUAW9 a=cfw-id:vF0zD4xzUAW9
a=ctrl-package:msc-mixer/1.0 a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0 a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0 a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0 a=ctrl-package:msc-example-pkg/1.0
=_Part =_Part
Content-Type: application/mrb-consumer+xml Content-Type: application/mrb-consumer+xml
<mrbconsumer version="1.0" \ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address \
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
<mediaResourceResponse reason="Resource found" status="200"> =_Part
<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 As it can be evinced from the dumps, the only difference in the
response the MRB provides the AS with is in the 'connection-id'
attribute that is added to the first allocated MS instance: this
allows the AS to understand the MRB has sent the CFW channel
negotiation to that specific MS, and that the connection-id to be
used (should the SIP control dialog also include media-related SDP
later on) is the one provided. This will be more carefully described
in the next section, for the call leg-based approach.
The continuation of the scenario (the AS connecting to the MS to The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for start the Control Channel, the SYNC message, etc.) are omitted for
brevity. brevity.
7. Media Service Resource Publisher Interface XML Schema 9.2.2.2. IAMM Example: Call leg-based approach
The following example assumes the interested AS already knows the SIP
URI where an MRB is listening as an UAS.
Figure 12 shows the second approach, i.e. SIP-based transactions
related to a UAC call leg the AS wants to attach to a MS, the MRB and
the MS that will be chosen eventually. The interaction is basically
the same as before (e.g. for what concerns the multipart body) but
considering a new party is involved in the communication, the diagram
is slightly more complex than before. As before, the MRB acts as a
B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the AS,
since it is interested to its services (1.). The AS sends a
provisional response (2.) and, since it doesn't have the resources
yet, sends to the MRB a new SIP INVITE (3.), containing both the UAC
media-related SDP and a Consumer request (multipart body). The MRB
sends a provisional response to the AS (4.) 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 have
been chosen, the MRB sends a new SIP INVITE to one of the MS by just
including the SDP part of the original request (5.). The MS
negotiates this INVITE as specified in
[I-D.ietf-mediactrl-sip-control-framework] (6., 7., 8.) to allocate
the needed media resources to handle the new call leg, eventually
providing the MRB with its own media-related SDP. The MRB replies to
the original AS INVITE preparing a SIP 200 OK with another multipart
body (9.): this multipart body includes the Consumer response used by
the MRB to determine the right MS and the SDP returned by the MS in
7. The AS finally acknowledges the 200 OK (10.), and ends the
scenario by eventually providing the UAC with the SDP it needs to
setup the RTP channels with the chosen MS: a separate direct SIP
control dialog may be initiated by the AS to the same MS in order to
set up a control channel to manipulate the call leg media.
Please note that, to ease the reading of the protocol contents, a
simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
payload is provided, instead of the actual boundary that would be
inserted in the SIP messages.
UAC AS MRB MS
| | | |
| 1. INVITE | | |
| (media SDP) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed) | |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (only copy SDP from 3.) |
| | |-------------------------->|
| | | 6. 100 (Trying) |
| | |<--------------------------|
| | | +--|
| | | Handle call leg | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | |<--------------------------|
| | | 8. ACK |
| | |-------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed) | |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Cons. reply | |
| | | and send SDP | |
| |<-+ back to UAC | |
| 11. 200 OK | | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
|<<*************************** RTP *******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| |<<############## TCP CONNECTION #################>>|
| | |
| | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
Figure 12: Consumer Example (IAMM-CallLeg): 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, From/To and
multipart-related information). Specifically:
1. the original INVITE (1), containing the media-related SDP sent by
a UAC;
2. the original INVITE (3), containing both the media-related SDP
and a Consumer <mediaResourceRequest>;
3. the INVITE sent by the MRB to the MS as a B2BUA (5.), containing
only the media-related SDP from the original INVITE;
4. the 200 OK sent by the MS back to the MRB (7.), to complete the
media-related negotiation (SDP only);
5. the 200 OK sent by the MRB back to the AS in response to the
original INVITE (9.), containing both the media-related
information sent by the MS and a Consumer <mediaResourceRequest>
documenting the MRB's decision to use that MS;
6. the 200 OK sent by the AS back to the UAC to have it setup the
RTP channel(s) with the MS (11.).
1. UAC -> AS (INVITE with media SDP)
------------------------------------
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
3. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
=_Part
Content-Type: application/mrb-consumer+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" \
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest>
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</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
5. MRB -> MS (INVITE sdp only)
------------------------------
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
7. MRB <- MS (200 OK sdp)
-------------------------
[..]
From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
9. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
[..]
From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
To: <sip:Mrb@mrb.example.org>;tag=117652221
[..]
Content-Type: multipart/mixed;boundary="=_Part"
=_Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
=_Part
Content-Type: application/mrb-consumer+xml
<?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>z1skKYZQ3eFu</session-id>
<seq>1</seq>
<expires>3600</expires>
<media-server-address \
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address \
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
=_Part
11. UAC <- AS (200 OK sdp)
--------------------------
[..]
From: <sip:lminiero@users.example.com>;tag=1153573888
To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
[..]
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 1.2.3.4
s=MediaCtrl
c=IN IP4 1.2.3.4
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
As it can be evinced from the dumps, as in the IAMM-CFW example the
MRB provides the AS with a 'connection-id' attribute in the consumer
response: this connection-id allows the AS to understand the MRB has
sent the SDP media negotiation to that specific MS, and that the
connection-id to be used in CFW requests is the one provided. This
attribute is needed, since, according to the framework specification,
the AS should build this connection-id out of the From/To tags
extracted from the negotiation with the MS: since the MRB acts as a
B2BUA in this scenario, without that attribute the AS and the MS
would refer to different tags and, as a consequence, different
connection-ids, thus preventing the CFW protocol to work as expected.
The continuation of the scenario (the AS connecting to the MS to
start the Control Channel, the SYNC message, etc.) are omitted for
brevity.
10. Media Service Resource Publisher Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [W3C.REC-xmlschema-1-
20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/
mrb-publish+xml" format. mrb-publish+xml" format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all" elementFormDefault="qualified" blockDefault="#all"
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 87, line 48 skipping to change at page 101, line 48
<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 12 Figure 13
8. Media Service Resource Consumer Interface XML Schema 11. Media Service Resource Consumer Interface XML Schema
This section gives the XML Schema Definition [W3C.REC-xmlschema-1- This section gives the XML Schema Definition [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 91, line 6 skipping to change at page 105, line 6
##################################################### #####################################################
--> -->
<!-- generalInfo --> <!-- generalInfo -->
<xsd:complexType name="generalInfoType"> <xsd:complexType name="generalInfoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice>
<xsd:element ref="session-info" minOccurs="0" /> <xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" /> <xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</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="generalInfo" type="generalInfoType" /> <xsd:element name="generalInfo" type="generalInfoType" />
<!-- session-info --> <!-- session-info -->
<xsd:complexType name="session-infoType"> <xsd:complexType name="session-infoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/> <xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/> <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/> <xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</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="session-info" type="session-infoType" /> <xsd:element name="session-info" type="session-infoType" />
<!-- packages --> <!-- packages -->
skipping to change at page 92, line 27 skipping to change at page 106, line 23
##################################################### #####################################################
--> -->
<!-- ivrInfo --> <!-- ivrInfo -->
<xsd:complexType name="ivrInfoType"> <xsd:complexType name="ivrInfoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice> <xsd:element ref="ivr-sessions" minOccurs="0" />
<xsd:element ref="ivr-sessions" /> <xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="file-formats" /> <xsd:element ref="dtmf-type" minOccurs="0" />
<xsd:element ref="dtmf-type" /> <xsd:element ref="tones" minOccurs="0" />
<xsd:element ref="tones" /> <xsd:element ref="asr-tts" minOccurs="0" />
<xsd:element ref="asr-tts" /> <xsd:element ref="vxml" minOccurs="0" />
<xsd:element ref="vxml" /> <xsd:element ref="location" minOccurs="0" />
<xsd:element ref="location" /> <xsd:element ref="encryption" minOccurs="0" />
<xsd:element ref="encryption" /> <xsd:element ref="application-data" minOccurs="0" />
<xsd:element ref="application-data" /> <xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="max-prepared-duration" /> <xsd:element ref="streaming-modes" minOccurs="0" />
<xsd:element ref="streaming-modes" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</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="ivrInfo" type="ivrInfoType" /> <xsd:element name="ivrInfo" type="ivrInfoType" />
<!-- <!--
##################################################### #####################################################
skipping to change at page 93, line 10 skipping to change at page 107, line 4
<xsd:element name="ivrInfo" type="ivrInfoType" /> <xsd:element name="ivrInfo" type="ivrInfoType" />
<!-- <!--
##################################################### #####################################################
mixerInfo TYPE mixerInfo TYPE
##################################################### #####################################################
--> -->
<!-- mixerInfo --> <!-- mixerInfo -->
<xsd:complexType name="mixerInfoType"> <xsd:complexType name="mixerInfoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice> <xsd:element ref="mixers" minOccurs="0"/>
<xsd:element ref="mixers" /> <xsd:element ref="file-formats" minOccurs="0"/>
<xsd:element ref="file-formats" /> <xsd:element ref="dtmf-type" minOccurs="0"/>
<xsd:element ref="dtmf-type" /> <xsd:element ref="tones" minOccurs="0"/>
<xsd:element ref="tones" /> <xsd:element ref="mixing-modes" minOccurs="0"/>
<xsd:element ref="mixing-modes" /> <xsd:element ref="application-data" minOccurs="0"/>
<xsd:element ref="application-data" /> <xsd:element ref="location" minOccurs="0"/>
<xsd:element ref="location" /> <xsd:element ref="encryption" minOccurs="0"/>
<xsd:element ref="encryption" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</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="mixerInfo" type="mixerInfoType" /> <xsd:element name="mixerInfo" type="mixerInfoType" />
<!-- <!--
##################################################### #####################################################
skipping to change at page 94, line 33 skipping to change at page 108, line 25
#################################################### ####################################################
--> -->
<!-- session-info --> <!-- session-info -->
<xsd:complexType name="response-session-infoType"> <xsd:complexType name="response-session-infoType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:choice>
<xsd:element name="session-id" type="id.datatype"/> <xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/> <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/> <xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address" minOccurs="0" /> <xsd:element ref="media-server-address"
<xsd:any namespace="##other" minOccurs="0" minOccurs="0" maxOccurs="unbounded" />
maxOccurs="unbounded" processContents="lax" /> <xsd:any namespace="##other" minOccurs="0"
</xsd:choice> 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="response-session-info" <xsd:element name="response-session-info"
type="response-session-infoType" /> type="response-session-infoType" />
<!-- media-server-address --> <!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" /> <xsd:complexType name="media-server-addressTYPE">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="connection-id" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="ivr-sessions" minOccurs="0"/>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="uri" type="xsd:anyURI" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-address"
type="media-server-addressTYPE" />
<!-- ivr-sessions --> <!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType"> <xsd:complexType name="ivr-sessionsType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0" <xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
skipping to change at page 107, line 45 skipping to change at page 122, line 4
<xsd:enumeration value="Media" /> <xsd:enumeration value="Media" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="boolean.datatype"> <xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" /> <xsd:enumeration value="true" />
<xsd:enumeration value="false" /> <xsd:enumeration value="false" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="vxml.datatype"> <xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="RFC4240" /> <xsd:enumeration value="RFC4240" />
<xsd:enumeration value="RFC5552" /> <xsd:enumeration value="RFC5552" />
<xsd:enumeration value="IVR-Package" /> <xsd:enumeration value="IVR-Package" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="appdata.datatype"> <xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
Figure 13 Figure 14
9. Security Considerations 12. Security Considerations
The MRB network entity has two primary interfaces, Publish and The MRB network entity has two primary interfaces, Publish and
Consumer, that carry sensitive information and must therefore be Consumer, that carry sensitive information and must therefore be
appropriately protected and secured. appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1, The Publish interface, as defined in and described in Section 5.1,
uses the Media Control Channel Framework uses the Media Control Channel Framework
[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 110, line 5 skipping to change at page 124, line 5
use of the services provided by a MRB. Nevertheless, considering use of the services provided by a MRB. Nevertheless, considering
both the interfaces are transported in well-established protocols both the interfaces are transported in well-established protocols
(HTTP, SIP, CFW), support for such an functionality can be expressed (HTTP, SIP, CFW), support for such an functionality can be expressed
by means of the authentication mechanisms provided by the protocol by means of the authentication mechanisms provided by the protocol
themselves. Therefore, any MRB-aware entity (Application Servers, themselves. Therefore, any MRB-aware entity (Application Servers,
Media Servers, Media Resource Brokers themselves) MUST support the Media Servers, Media Resource Brokers themselves) MUST support the
HTTP and SIP Digest access authentication. That said, the usage of HTTP and SIP Digest access authentication. That said, the usage of
such Digest access authentications is recommended and not mandatory, such Digest access authentications is recommended and not mandatory,
which means MRB-aware entities MAY exploit it in deployment. which means MRB-aware entities MAY exploit it in deployment.
10. IANA Considerations 13. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
10.1. Control Package Registration 13.1. Control Package Registration
This section registers a new Media Control Channel Framework package, This section registers a new Media Control Channel Framework package,
per the instructions in Section 13.1 of per the instructions in Section 13.1 of
[I-D.ietf-mediactrl-sip-control-framework]. [I-D.ietf-mediactrl-sip-control-framework].
To: ietf-sip-control@iana.org To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package Subject: Registration of new Channel Framework package
Package Name: mrb-publish/1.0 [NOTE TO IANA/RFC-EDITOR: Please Package Name: mrb-publish/1.0 [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Published Specification(s): RFCXXXX Person and email address to Published Specification(s): RFCXXXX Person and email address to
contact for further information: IETF, MEDIACTRL working group, contact for further information: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
10.2. application/mrb-publish+xml MIME Type 13.2. application/mrb-publish+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-publish+xml MIME subtype name: mrb-publish+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023]. specified in RFC 3023 [RFC3023].
skipping to change at page 111, line 20 skipping to change at page 125, line 20
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton, Personal and email address for further information: Chris Boulton,
chris@ns-technologies.com chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
10.3. application/mrb-consumer+xml MIME Type 13.3. application/mrb-consumer+xml MIME Type
MIME media type name: application MIME media type name: application
MIME subtype name: mrb-consumer+xml MIME subtype name: mrb-consumer+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023]. specified in RFC 3023 [RFC3023].
skipping to change at page 112, line 13 skipping to change at page 126, line 13
File Extension: .xdf File Extension: .xdf
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton, Personal and email address for further information: Chris Boulton,
chris@ns-technologies.com chris@ns-technologies.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
10.4. URN Sub-Namespace Registration for mrb-publish 13.4. URN Sub-Namespace Registration for mrb-publish
Please register the URN name space Please register the URN name space
"urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish".
The template is in Section 7. The template is in Section 10.
10.5. URN Sub-Namespace Registration for mrb-consumer 13.5. URN Sub-Namespace Registration for mrb-consumer
Please register the URN name space Please register the URN name space
"urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer".
The template is in Section 8. The template is in Section 11.
10.6. XML Schema Registration for mrb-publish 13.6. XML Schema Registration for mrb-publish
Please register the schema for mrb-publish: Please register the schema for mrb-publish:
URI: urn:ietf:params:xml:ns:mrb-publish URI: urn:ietf:params:xml:ns:mrb-publish
ID: mrb-publish ID: mrb-publish
Filename: mbr-publish Filename: mbr-publish
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 7 of this document. Schema: The XML for the schema is in Section 10 of this document.
10.7. XML Schema Registration for mrb-consumer 13.7. XML Schema Registration for mrb-consumer
Please register the schema for mrb-consumer: Please register the schema for mrb-consumer:
URI: urn:ietf:params:xml:ns:mrb-consumer URI: urn:ietf:params:xml:ns:mrb-consumer
ID: mrb-consumer ID: mrb-consumer
Filename: mbr-consumer Filename: mbr-consumer
Registrant Contact: IETF, MEDIACTRL working group Registrant Contact: IETF, MEDIACTRL working group
(mediactrl@ietf.org) (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 8 of this document. Schema: The XML for the schema is in Section 11 of this document.
11. Changes 14. Changes
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
11.1. Changes from 06 Version 14.1. Changes from 07 Version
o Corrected some errors in the Consumer schema: a few elements were
not declared optional as they should have been, and some were
incorrectly defined as choices instead of sequences;
o Corrected examples after validation tests;
o Fixed a few typos in the text.
o Clarified language in various places.
o Added 'Multi-modal MRB Implementations' section.
o Added 'Relative Merits of Query Mode, IAMM, and IUMM' section.
o Clarifying text related to IAMM and IUMM.
o Expanded media-server-address for extra information and to allow
multiples.
o New B2BUA section.
o Updated Examples.
14.2. Changes from 06 Version
o Added the missing <encoding> and <decoding> elements to the <rtp- o Added the missing <encoding> and <decoding> elements to the <rtp-
codec> instances, where needed. codec> instances, where needed.
o Fixed a few typos in the text. o Fixed a few typos in the text.
11.2. Changes from 05 Version 14.3. Changes from 05 Version
o Clarifier that video layouts may refer to either XCON-defined o Clarifier that video layouts may refer to either XCON-defined
layouts or others. layouts or others.
o Added RFC4240 as an option for VXML support. o Added RFC4240 as an option for VXML support.
o Fixed a few typos in the text and in the schemas. o Fixed a few typos in the text and in the schemas.
11.3. Changes from 04 Version 14.4. Changes from 04 Version
o Corrected some typos and leftovers in both 'session-info' and o Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions. 'response-session-info' definitions.
o Clarified that 'response-session-info' is not only included in o Clarified that 'response-session-info' is not only included in
reply to updates, but also to new requests; besides, clarified reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any in successful responses (200), while not needed otherwise (any
error). error).
o Corrected the Query example flow which included a 'session'info' o Corrected the Query example flow which included a 'session'info'
in a new request. in a new request.
11.4. Changes from 03 Version 14.5. Changes from 03 Version
o Addressed comments per the Expert RAI Review by Ben Campbell. o Addressed comments per the Expert RAI Review by Ben Campbell.
o Several editorial changes (fixes, typos, nits). o Several editorial changes (fixes, typos, nits).
o Removed the 3xx class responses for the IAMM, per discussion in o Removed the 3xx class responses for the IAMM, per discussion in
Anaheim (feature had been added in the -02 version). Anaheim (feature had been added in the -02 version).
o Clarified that backslashes and XML indentation in the Examples are o Clarified that backslashes and XML indentation in the Examples are
only provided for readability. only provided for readability.
skipping to change at page 115, line 16 skipping to change at page 129, line 44
responses, in order to clarify when they are involved. responses, in order to clarify when they are involved.
o Added some text to better clarify the role of leasing in the o Added some text to better clarify the role of leasing in the
Consumer interface. Consumer interface.
o Added additional IANA considerations, that were missing in the o Added additional IANA considerations, that were missing in the
previous versions of the document. previous versions of the document.
o Added text to the security considerations. o Added text to the security considerations.
11.5. Changes from 02 Version 14.6. Changes from 02 Version
o Added examples in Section 6. o Added examples in Section 9.
o Fixed some nits in the schemas (encryption and required mixed=true o Fixed some nits in the schemas (encryption and required mixed=true
elements). elements).
o Completed review nit review comments from Gary Munson. o Completed review nit review comments from Gary Munson.
11.6. Changes from 01 Version 14.7. 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 115, line 47 skipping to change at page 130, line 27
o Removed announce-var element from doc. o Removed announce-var element from doc.
o Expanded Abstract. o Expanded Abstract.
o General scrub of text - input from Simon Romano. o General scrub of text - input from Simon Romano.
o Added IANA Considerations section. o Added IANA Considerations section.
o Added Security Considerations section. o Added Security Considerations section.
11.7. Changes from 00 Version 14.8. Changes from 00 Version
o Included In-line text based on strawman proposal. o Included In-line text based on strawman proposal.
o Included first attempt at publish interface based on design team o Included first attempt at publish interface based on design team
work. work.
12. Acknowledgments 15. 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 Adnan Saleem, Michael Trank, Victor
Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also
would also like to thank John Dally, Simon Romano, Henry Lum, like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
Christian Groves and Jonathan Lennox for input into this Christian Groves and Jonathan Lennox for input into this
specification. specification.
Ben Campbell carried out the RAI expert review on this specification Ben Campbell carried out the RAI expert review on this specification
and provided a great deal of invaluable input. and provided a great deal of invaluable input.
13. References 16. References
13.1. Normative References 16.1. Normative References
[ISO.3166-1] [ISO.3166-1]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries and their the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard 3166- subdivisions - Part 1: Country codes", ISO Standard 3166-
1:1997, 1997. 1:1997, 1997.
[ISO.639.1988] [ISO.639.1988]
International Organization for Standardization, "Code for International Organization for Standardization, "Code for
the representation of names of languages, 1st edition", the representation of names of languages, 1st edition",
skipping to change at page 118, line 5 skipping to change at page 133, line 5
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 4722,
November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Moreau, J., Mendelsohn, N., and H. Gudgin, M., Nielsen, H., Hadley, M., Moreau, J., and N.
Nielsen, "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]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Mendelsohn, N., Nielsen, H., Moreau, J., Hadley, M., and
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
13.2. Informative References 16.2. Informative References
[I-D.ietf-mediactrl-ivr-control-package] [I-D.ietf-mediactrl-ivr-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "An McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework", Media Control Channel Framework",
draft-ietf-mediactrl-ivr-control-package-08 (work in draft-ietf-mediactrl-ivr-control-package-11 (work in
progress), February 2010. progress), January 2011.
[I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-14 (work in
progress), January 2011.
[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-12 (work in draft-ietf-mediactrl-sip-control-framework-12 (work in
progress), September 2010. progress), September 2010.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
skipping to change at line 5257 skipping to change at page 135, line 19
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Via Carlo Poerio 89 Via Carlo Poerio 89
Napoli 80100 Napoli 80100
Italy Italy
Email: lorenzo@meetecho.com Email: lorenzo@meetecho.com
Gary Munson
AT&T
200 Laurel Avenue South
Middletown
New Jersey 07748
USA
Email: gamunson@att.com
 End of changes. 157 change blocks. 
414 lines changed or deleted 1056 lines changed or added

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