summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6917.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6917.txt')
-rw-r--r--doc/rfc/rfc6917.txt7619
1 files changed, 7619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6917.txt b/doc/rfc/rfc6917.txt
new file mode 100644
index 0000000..1752a0a
--- /dev/null
+++ b/doc/rfc/rfc6917.txt
@@ -0,0 +1,7619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Boulton
+Request for Comments: 6917 NS-Technologies
+Category: Standards Track L. Miniero
+ISSN: 2070-1721 Meetecho
+ G. Munson
+ AT&T
+ April 2013
+
+
+ Media Resource Brokering
+
+Abstract
+
+ The MediaCtrl working group in the IETF has proposed an architecture
+ for controlling media services. The Session Initiation Protocol
+ (SIP) is used as the signaling protocol that provides many inherent
+ capabilities for message routing. In addition to such signaling
+ properties, a need exists for intelligent, application-level media
+ service selection based on non-static signaling properties. This is
+ especially true when considered in conjunction with deployment
+ architectures that include 1:M and M:N combinations of Application
+ Servers and Media Servers. This document introduces a Media Resource
+ Broker (MRB) entity, which manages the availability of Media Servers
+ and the media resource demands of Application Servers. The document
+ includes potential deployment options for an MRB and appropriate
+ interfaces to Application Servers and Media Servers.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6917.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 1]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions and Terminology .....................................6
+ 3. Problem Discussion ..............................................6
+ 4. Deployment Scenario Options .....................................7
+ 4.1. Query MRB ..................................................8
+ 4.1.1. Hybrid Query MRB ....................................9
+ 4.2. In-Line MRB ...............................................11
+ 5. MRB Interface Definitions ......................................12
+ 5.1. Media Server Resource Publish Interface ...................12
+ 5.1.1. Control Package Definition .........................13
+ 5.1.2. Element Definitions ................................15
+ 5.1.3. <mrbrequest> .......................................15
+ 5.1.4. <mrbresponse> ......................................17
+ 5.1.5. <mrbnotification> ..................................19
+ 5.2. Media Service Resource Consumer Interface .................30
+ 5.2.1. Query Mode/HTTP Consumer Interface Usage ...........31
+ 5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage ....32
+ 5.2.3. Consumer Interface Lease Mechanism .................35
+ 5.2.4. <mrbconsumer> ......................................38
+ 5.2.5. Media Service Resource Request .....................39
+ 5.2.6. Media Service Resource Response ....................51
+ 5.3. In-Line Unaware MRB Interface .............................54
+ 6. MRB Acting as a B2BUA ..........................................54
+ 7. Multimodal MRB Implementations .................................55
+ 8. Relative Merits of Query Mode, IAMM, and IUMM ..................56
+ 9. Examples .......................................................58
+ 9.1. Publish Example ...........................................58
+ 9.2. Consumer Examples .........................................64
+ 9.2.1. Query Example ......................................64
+ 9.2.2. IAMM Examples ......................................68
+ 10. Media Service Resource Publisher Interface XML Schema .........83
+
+
+
+Boulton, et al. Standards Track [Page 2]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 11. Media Service Resource Consumer Interface XML Schema .........106
+ 12. Security Considerations ......................................127
+ 13. IANA Considerations ..........................................130
+ 13.1. Media Control Channel Framework Package Registration ....130
+ 13.2. application/mrb-publish+xml Media Type ..................130
+ 13.3. application/mrb-consumer+xml Media Type .................131
+ 13.4. URN Sub-Namespace Registration for mrb-publish ..........132
+ 13.5. URN Sub-Namespace Registration for mrb-consumer .........132
+ 13.6. XML Schema Registration for mrb-publish .................132
+ 13.7. XML Schema Registration for mrb-consumer ................133
+ 14. Acknowledgements .............................................133
+ 15. References ...................................................133
+ 15.1. Normative References ....................................133
+ 15.2. Informative References ..................................135
+
+1. Introduction
+
+ As IP-based multimedia infrastructures mature, the complexity and
+ demands from deployments increase. Such complexity will result in a
+ wide variety of capabilities from a range of vendors that should all
+ be interoperable using the architecture and protocols produced by the
+ MediaCtrl working group. It should be possible for a controlling
+ entity to be assisted in Media Server selection so that the most
+ appropriate resource is selected for a particular operation. The
+ importance increases when one introduces a flexible level of
+ deployment scenarios, as specified in RFC 5167 [RFC5167] and RFC 5567
+ [RFC5567]. These documents make statements like "it should be
+ possible to have a many-to-many relationship between Application
+ Servers and Media Servers that use this protocol". This leads to the
+ following deployment architectures being possible when considering
+ media resources, to provide what can be effectively described as
+ media resource brokering.
+
+ The simplest deployment view is illustrated in Figure 1.
+
+ +---+-----+---+ +---+-----+---+
+ | Application | | Media |
+ | Server |<-------MS Control------>| Server |
+ +-------------+ +-------------+
+
+ Figure 1: Basic Architecture
+
+ This simply involves a single Application Server and Media Server.
+ Expanding on this view, it is also possible for an Application Server
+ to control multiple (greater than 1) Media Server instances at any
+ one time. This deployment view is illustrated in Figure 2.
+ Typically, such architectures are associated with application logic
+ that requires high-demand media services. It is more than possible
+
+
+
+Boulton, et al. Standards Track [Page 3]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ that each Media Server possesses a different media capability set.
+ Media Servers may offer different media services as specified in the
+ MediaCtrl architecture document [RFC5567]. A Media Server may have
+ similar media functionality but may have different capacity or media
+ codec support.
+
+ +---+-----+---+
+ | Media |
+ +----->| Server |
+ | +-------------+
+ |
+ +---+-----+---+ | +---+-----+---+
+ | Application | | | Media |
+ | Server |<--MS Control-----+----->| Server |
+ +-------------+ | +-------------+
+ |
+ | +---+-----+---+
+ +----->| Media |
+ | Server |
+ +-------------+
+
+ Figure 2: Multiple Media Servers
+
+ Figure 3 conveys the opposite view to that in Figure 2. In this
+ model, there are a number of (greater than 1) Application Servers,
+ possibly supporting dissimilar applications, controlling a single
+ Media Server. Typically, such architectures are associated with
+ application logic that requires low-demand media services.
+
+ +---+-----+---+
+ | Application |
+ | Server |<-----+
+ +-------------+ |
+ |
+ +---+-----+---+ | +---+-----+---+
+ | Application | | | Media |
+ | Server |<-----+-----MS Control-->| Server |
+ +-------------+ | +-------------+
+ |
+ +---+-----+---+ |
+ | Application | |
+ | Server |<-----+
+ +-------------+
+
+ Figure 3: Multiple Application Servers
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 4]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The final deployment view is the most complex (Figure 4). In this
+ model (M:N), there exist any number of Application Servers and any
+ number of Media Servers. It is again possible in this model that
+ Media Servers might not be homogeneous, and they might have different
+ capability sets and capacities.
+
+ +---+-----+---+ +---+-----+---+
+ | Application | | Media |
+ | Server |<-----+ +---->| Server |
+ +-------------+ | | +-------------+
+ | |
+ +---+-----+---+ | | +---+-----+---+
+ | Application | | | | Media |
+ | Server |<-----+-MS Control-+---->| Server |
+ +-------------+ | | +-------------+
+ | |
+ +---+-----+---+ | | +---+-----+---+
+ | Application | | +---->| Media |
+ | Server |<-----+ | Server |
+ +-------------+ +---+-----+---+
+
+ Figure 4: Many-to-Many Architecture
+
+ The remaining sections in this specification will focus on a new
+ entity called a Media Resource Broker (MRB), which can be utilized in
+ the deployment architectures described previously in this section.
+ The MRB entity provides the ability to obtain media resource
+ information and appropriately allocate (broker) on behalf of client
+ applications.
+
+ The high-level deployment options discussed in this section rely on
+ network architecture and policy to prohibit inappropriate use. Such
+ policies are out of scope for this document.
+
+ This document will take a look at the specific problem areas related
+ to such deployment architectures. It is recognized that the
+ solutions proposed in this document should be equally adaptable to
+ all of the previously described deployment models. It is also
+ recognized that the solution is far more relevant to some of the
+ previously discussed deployment models and can almost be viewed as
+ redundant on others.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 5]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+2. Conventions and Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ This document inherits terminology proposed in RFC 5567 [RFC5567] and
+ in "Media Control Channel Framework" [RFC6230]. In addition, the
+ following terms are defined for use in this document and for use in
+ the context of the MediaCtrl working group in the IETF:
+
+ Media Resource Broker (MRB): A logical entity that is responsible
+ for both collection of appropriate published Media Server (MS)
+ information and selecting appropriate Media Server resources on
+ behalf of consuming entities.
+
+ Query MRB: An instantiation of an MRB (see previous definition) that
+ provides an interface for an Application Server to retrieve the
+ address of an appropriate Media Server. The result returned to
+ the Application Server can be influenced by information contained
+ in the query request.
+
+ In-line MRB: An instantiation of an MRB (see previous definition)
+ that directly receives requests on the signaling path. There is
+ no separate query.
+
+ CFW: Media Control Channel Framework, as specified in [RFC6230].
+
+ Within the context of In-line MRBs, additional terms are defined:
+
+ In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1.
+
+ In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
+
+ The document will often specify when a specific identifier in a
+ protocol message needs to be unique. Unless stated otherwise, such
+ uniqueness will always be within the scope of the Media Servers
+ controlled by the same MRB. The interaction between different MRB
+ instances, e.g., the partitioning of a logical MRB, is out of scope
+ for this document.
+
+3. Problem Discussion
+
+ As discussed in Section 1, a goal of the MediaCtrl working group is
+ to produce a solution that will service a wide variety of deployment
+ architectures. Such architectures range from the simplest 1:1
+ relationship between Media Servers and Application Servers to
+ potentially linearly scaling 1:M, M:1, and M:N deployments.
+
+
+
+Boulton, et al. Standards Track [Page 6]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Managing such deployments is itself non-trivial for the proposed
+ solution until an additional number of factors that increase
+ complexity are included in the equation. As Media Servers evolve, it
+ must be taken into consideration that, where many can exist in a
+ deployment, they may not have been produced by the same vendor and
+ may not have the same capability set. It should be possible for an
+ Application Server that exists in a deployment to select a media
+ service based on a common, appropriate capability set. In
+ conjunction with capabilities, it is also important to take available
+ resources into consideration. The ability to select an appropriate
+ media service function is an extremely useful feature but becomes
+ even more powerful when considered with available resources for
+ servicing a request.
+
+ In conclusion, the intention is to create a toolkit that allows
+ MediaCtrl deployments to effectively utilize the available media
+ resources. It should be noted that in the simplest deployments where
+ only a single Media Server exists, an MRB function is probably not
+ required. Only a single capability set exists, and resource
+ availability can be handled using the appropriate underlying
+ signaling, e.g., SIP response. This document does not prohibit such
+ uses of an MRB; it simply provides the tools for various entities to
+ interact where appropriate. It is also worth noting that the
+ functions specified in this document aim to provide a 'best effort'
+ view of media resources at the time of request for initial Media
+ Server routing decisions. Any dramatic change in media capabilities
+ or capacity after a request has taken place should be handled by the
+ underlying protocol.
+
+ It should be noted that there may be additional information that is
+ desirable for the MRB to have for purposes of selecting a Media
+ Server resource, such as resource allocation rules across different
+ applications, planned or unplanned downtime of Media Server
+ resources, the planned addition of future Media Server resources, or
+ Media Server resource capacity models. How the MRB acquires such
+ information is outside the scope of this document. The specific
+ techniques used for selecting an appropriate media resource by an MRB
+ is also outside the scope of this document.
+
+4. Deployment Scenario Options
+
+ Research into media resource brokering concluded that a couple of
+ high-level models provided an appropriate level of flexibility. The
+ general principles of "in-line" and "query" MRB concepts are
+ discussed in the rest of this section. It should be noted that while
+ the interfaces are different, they both use common underlying
+ mechanisms defined in this specification.
+
+
+
+
+Boulton, et al. Standards Track [Page 7]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+4.1. Query MRB
+
+ The "Query" model for MRB interactions provides the ability for a
+ client of media services (for example, an Application Server) to
+ "ask" an MRB for an appropriate Media Server, as illustrated in
+ Figure 5.
+
+ +---+-----+---+
+ +------------>| MRB |<----------+----<-----+---+
+ | +-------------+ (1)| | |
+ | | | |
+ |(2) +---+--+--+---+ | |
+ | | Media | | |
+ | +---->| Server | | |
+ | | +-------------+ | |
+ | | (1)| |
+ +---+--+--+---+ | +---+-----+---+ | |
+ | Application | | | Media | | |
+ | Server |<-----+-MS Control-+---->| Server |->-+ |
+ +-------------+ (3) | +-------------+ |
+ | |
+ | +---+-----+---+ (1)|
+ +---->| Media | |
+ | Server |--->---+
+ +---+-----+---+
+
+ Figure 5: Query MRB
+
+ In this deployment, the Media Servers use the Media Server Resource
+ Publish interface, as discussed in Section 5.1, to convey capability
+ sets as well as resource information. This is depicted by (1) in
+ Figure 5. It is then the MRB's responsibility to accumulate all
+ appropriate information relating to media services in the logical
+ deployment cluster. The Application Server (or other media services
+ client) is then able to query the MRB for an appropriate resource (as
+ identified by (2) in Figure 5). Such a query would carry specific
+ information related to the media service required and enable the MRB
+ to provide increased accuracy in its response. This particular
+ interface is discussed in "Media Service Resource Consumer Interface"
+ (Section 5.2). The Application Server is then able to direct control
+ commands (for example, create a conference) and media dialogs to the
+ appropriate Media Server, as shown by (3) in Figure 5. Additionally,
+ with Query mode, the MRB is not directly in the signaling path
+ between the Application Server and the selected Media Server
+ resource.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 8]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+4.1.1. Hybrid Query MRB
+
+ As mentioned previously, it is the intention that a toolkit is
+ provided for MRB functionality within a MediaCtrl architecture. It
+ is expected that in specific deployment scenarios the role of the MRB
+ might be co-hosted as a hybrid logical entity with an Application
+ Server, as shown in Figure 6.
+
+ +------------<----------------<---------+----<-----+---+
+ | (1) | | |
+ | | | |
+ | +---+--+--+---+ | |
+ | | Media | | |
+ V +---->| Server | | |
+ +------+------+ | +-------------+ | |
+ | MRB | | | |
+ +---+--+--+---+ | +---+-----+---+ | |
+ | Application | | | Media | | |
+ | Server |<-----+-MS Control-+---->| Server |->-+ |
+ +-------------+ | +-------------+ |
+ | |
+ | +---+-----+---+ |
+ +---->| Media | |
+ | Server |--->---+
+ +---+-----+---+
+
+ Figure 6: Hybrid Query MRB - Application Server Hosted
+
+ This diagram is identical to that in Figure 5 with the exception that
+ the MRB is now hosted on the Application Server. The Media Server
+ Publish interface is still being used to accumulate resource
+ information at the MRB, but as it is co-hosted on the Application
+ Server, the Media Server Consumer interface has collapsed. It might
+ still exist within the Application Server/MRB interaction, but this
+ is an implementation issue. This type of deployment suits a single
+ Application Server environment, but it should be noted that a Media
+ Server Consumer interface could then be offered from the hybrid if
+ required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 9]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ In a similar manner, the Media Server could also act as a hybrid for
+ the deployment cluster, as illustrated in Figure 7.
+
+ (1) +---+-----+---+
+ +---+---+------------->---------------->----------->| MRB |
+ | | | +---+--+--+---+ +---+-----+---+
+ | | +-<-| Application | | Media |
+ | | | Server |<--+-MS Control-+------->| Server |
+ | | +-------------+ | +-------------+
+ | | |
+ | | +---+--+--+---+ |
+ | +---<---| Application | |
+ | | Server |<--+-MS Control-+--+
+ | +-------------+ |
+ | |
+ | +---+--+--+---+ |
+ +---<-------| Application | |
+ | Server |<--+-MS Control-+--+
+ +-------------+
+
+ Figure 7: Hybrid Query MRB - MS Hosted
+
+ In this example, the MRB has collapsed and is co-hosted by the Media
+ Server. The Media Server Consumer interface is still available to
+ the Application Servers (1) to query Media Server resources. The
+ Media Server Publish interface has collapsed onto the Media Server.
+ It might still exist within the Media Server/MRB interaction, but
+ this is an implementation issue. This type of deployment suits a
+ single Media Server environment, but it should be noted that a Media
+ Server Publish interface could then be offered from the hybrid if
+ required. A typical use case scenario for such a topology would be a
+ single Media Server representing a pool of MSs in a cluster. In this
+ case, the MRB would actually be handling a cluster of Media Servers,
+ rather than one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 10]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+4.2. In-Line MRB
+
+ The "In-line" MRB is architecturally different from the "Query" model
+ discussed in the previous section. The concept of a separate query
+ disappears. The client of the MRB simply uses the media resource
+ control and media dialog signaling to involve the MRB. This type of
+ deployment is illustrated in Figure 8.
+
+ +-------<----------+----<-------+---+
+ | | (1) | |
+ | | | |
+ | +---+--+--+---+ | |
+ | | Media | | |
+ | +------>| Server | | |
+ | |(3) +-------------+ | |
+ | | (1)| |
+ +---+--+--+---+ | | +---+-----+---+ | |
+ | Application | (2) +---+--V--+---+ (3) | Media | | |
+ | Server |----->| MRB |----->| Server |->-+ |
+ +-------------+ +---+-----+---+ +-------------+ |
+ | |
+ | (3) +---+-----+---+ (1)|
+ +------>| Media | |
+ | Server |--->---+
+ +---+-----+---+
+
+ Figure 8: In-Line MRB
+
+ The Media Servers still use the Media Server Publish interface to
+ convey capabilities and resources to the MRB, as illustrated by (1).
+ The Media Server Control Channels (and media dialogs as well, if
+ required) are sent to the MRB (2), which then selects an appropriate
+ Media Server (3) and remains in the signaling path between the
+ Application Server and the Media Server resources.
+
+ The In-line MRB can be split into two distinct logical roles that can
+ be applied on a per-request basis. They are:
+
+ In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of
+ clients requiring media services who are not aware of an MRB or
+ its operation. In this case, the Application Server does not
+ provide explicit information on the kind of Media Server resource
+ it needs (as in Section 5.2), and the MRB is left to deduce it by
+ potentially inspecting other information in the request from the
+ Application Server (for example, Session Description Protocol
+ (SDP) content, or address of the requesting Application Server, or
+ additional Request-URI parameters as per RFC 4240 [RFC4240]).
+
+
+
+
+Boulton, et al. Standards Track [Page 11]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 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
+ operation. In particular, it allows the Application Server to
+ explicitly convey matching characteristics to those provided by
+ Media Servers, as does the Query MRB mode (as in Section 5.2).
+
+ In either of the previously described roles, signaling as specified
+ by the Media Control Channel Framework ([RFC6230]) would be involved,
+ and the MRB would deduce that the selected Media Server resources are
+ no longer needed when the Application Server or Media Server
+ terminates the corresponding SIP dialog. The two modes are discussed
+ in more detail in Section 5.3.
+
+5. MRB Interface Definitions
+
+ The intention of this specification is to provide a toolkit for a
+ variety of deployment architectures where media resource brokering
+ can take place. Two main interfaces are required to support the
+ differing requirements. The two interfaces are described in the
+ remainder of this section and have been named the Media Server
+ Resource Publish and Media Server Resource Consumer interfaces.
+
+ It is beyond the scope of this document to define exactly how to
+ construct an MRB using the interfaces described. It is, however,
+ important that the two interfaces are complimentary so that
+ development of appropriate MRB functionality is supported.
+
+5.1. Media Server Resource Publish Interface
+
+ The Media Server Resource Publish interface is responsible for
+ providing an MRB with appropriate Media Server resource information.
+ As such, this interface is assumed to provide both general and
+ specific details related to Media Server resources. This information
+ needs to be conveyed using an industry standard mechanism to provide
+ increased levels of adoption and interoperability. A Control Package
+ for the Media Control Channel Framework will be specified to fulfill
+ this interface requirement. It provides an establishment and
+ monitoring mechanism to enable a Media Server to report appropriate
+ statistics to an MRB. The Publish interface is used with both the
+ Query mode and In-line mode of MRB operation.
+
+ As already discussed in Section 1, the MRB view of Media Server
+ resource availability will in reality be approximate -- i.e., partial
+ and imperfect. The MRB Publish interface does not provide an
+ exhaustive view of current Media Server resource consumption; the
+ Media Server may in some cases provide a best-effort computed view of
+ resource consumption parameters conveyed in the Publish interface
+ (e.g., Digital Signal Processors (DSPs) with a fixed number of
+
+
+
+Boulton, et al. Standards Track [Page 12]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ streams versus Graphics Processing Units (GPUs) with CPU
+ availability). Media resource information may only be reported
+ periodically over the Publish interface to an MRB.
+
+ It is also worth noting that while the scope of the MRB is in
+ providing interested Application Servers with the available
+ resources, the MRB also allows for the retrieval of information about
+ consumed resources. While this is of course a relevant piece of
+ information (e.g., for monitoring purposes), such functionality
+ inevitably raises security considerations, and implementations should
+ take this into account. See Section 12 for more details.
+
+ The MRB Publish interface uses the Media Control Channel Framework
+ ([RFC6230]) as the basis for interaction between a Media Server and
+ an MRB. The Media Control Channel Framework uses an extension
+ mechanism to allow specific usages that are known as Control
+ Packages. Section 5.1.1 defines the Control Package that MUST be
+ implemented by any Media Server wanting to interact with an MRB
+ entity.
+
+5.1.1. Control Package Definition
+
+ This section fulfills the requirement for information that must be
+ specified during the definition of a Control Framework package, as
+ detailed in Section 8 of [RFC6230].
+
+5.1.1.1. Control Package Name
+
+ The Media Channel Control Framework requires a Control Package
+ definition to specify and register a unique name and version.
+
+ The name and version of this Control Package is "mrb-publish/1.0".
+
+5.1.1.2. Framework Message Usage
+
+ The MRB Publish interface allows a Media Server to convey available
+ capabilities and resources to an MRB entity.
+
+ This package defines XML elements in Section 5.1.2 and provides an
+ XML schema in Section 10.
+
+ The XML elements in this package are split into requests, responses,
+ and event notifications. Requests are carried in CONTROL message
+ bodies; the <mrbrequest> element is defined as a package request.
+ This request can be used for creating new subscriptions and updating/
+ removing existing subscriptions. Event notifications are also
+ carried in CONTROL message bodies; the <mrbnotification> element is
+
+
+
+
+Boulton, et al. Standards Track [Page 13]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ defined for package event notifications. Responses are carried
+ either in REPORT message or Control Framework 200 response bodies;
+ the <mrbresponse> element is defined as a package-level response.
+
+ Note that package responses are different from framework response
+ codes. Framework error response codes (see Section 7 of [RFC6230])
+ are used when the request or event notification is invalid; for
+ example, a request has invalid XML (400) or is not understood (500).
+ Package-level responses are carried in framework 200 response or
+ REPORT message bodies. This package's response codes are defined in
+ Section 5.1.4.
+
+5.1.1.3. Common XML Support
+
+ The Media Control Channel Framework [RFC6230] requires a Control
+ Package definition to specify if the attributes for media dialog or
+ conference references are required.
+
+ The Publish interface defined in Section 10 does import and make use
+ of the common XML schema defined in the Media Control Channel
+ Framework.
+
+ The Consumer interface defined in Section 11 does import and make use
+ of the common XML schema defined in the Media Control Channel
+ Framework.
+
+5.1.1.4. CONTROL Message Body
+
+ A valid CONTROL message body MUST conform to the schema defined in
+ Section 10 and described in Section 5.1.2. XML messages appearing in
+ CONTROL messages MUST contain either an <mrbrequest> or
+ <mrbnotification> element.
+
+5.1.1.5. REPORT Message Body
+
+ A valid REPORT message body MUST conform to the schema defined in
+ Section 10 and described in Section 5.1.2. XML messages appearing in
+ REPORT messages MUST contain an <mrbresponse> element.
+
+5.1.1.6. Audit
+
+ The 'mrb-publish/1.0' Media Control Channel Framework package does
+ not require any additional auditing capability.
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 14]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.2. Element Definitions
+
+ This section defines the XML elements for the Publish interface Media
+ Control Channel package defined in Section 5.1. The formal XML
+ schema definition for the Publish interface can be found in
+ Section 10.
+
+ The root element is <mrbpublish>. All other XML elements (requests,
+ responses, notifications) are contained within it. The MRB Publish
+ interface request element is detailed in Section 5.1.3. The MRB
+ Publish interface notification element is detailed in Section 5.1.5.
+ The MRB Publish interface response element is detailed in
+ Section 5.1.4.
+
+ The <mrbpublish> element has the following attributes:
+
+ version: a token specifying the mrb-publish package version. The
+ value is fixed as '1.0' for this version of the package. The
+ attribute MUST be present.
+
+ The <mrbpublish> element has the following child elements, and there
+ MUST NOT be more than one such child element in any <mrbpublish>
+ message:
+
+ <mrbrequest> for sending an MRB request. See Section 5.1.3.
+
+ <mrbresponse> for sending an MRB response. See Section 5.1.4.
+
+ <mrbnotification> for sending an MRB notification. See
+ Section 5.1.5.
+
+5.1.3. <mrbrequest>
+
+ This section defines the <mrbrequest> element used to initiate
+ requests from an MRB to a Media Server. The element describes
+ information relevant for the interrogation of a Media Server.
+
+ The <mrbrequest> element has no defined attributes.
+
+ The <mrbrequest> element has the following child element:
+
+ <subscription> for initiating a subscription to a Media Server
+ from an MRB. See Section 5.1.3.1.
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 15]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.3.1. <subscription>
+
+ The <subscription> element is included in a request from an MRB to a
+ Media Server to provide the details relating to the configuration of
+ updates (known as a subscription session). This element can be used
+ either to request a new subscription or to update an existing one
+ (e.g., to change the frequency of the updates), and to remove ongoing
+ subscriptions as well (e.g., to stop an indefinite update). The MRB
+ will inform the Media Server regarding how long it wishes to receive
+ updates and the frequency that updates should be sent. Updates
+ related to the subscription are sent using the <mrbnotification>
+ element.
+
+ The <subscription> element has the following attributes:
+
+ id: Indicates a unique token representing the subscription session
+ between the MRB and the Media Server. The attribute MUST be
+ present.
+
+ seqnumber: Indicates a sequence number to be used in conjunction
+ with the subscription session ID to identify a specific
+ subscription command. The first subscription MUST contain a
+ non-zero number 'seqnumber', and subsequent subscriptions MUST
+ contain a higher number than the previous 'seqnumber' value. If a
+ subsequent 'seqnumber' is not higher, a 405 response code is
+ generated as per Section 5.1.4. The attribute MUST be present.
+
+ action: Provides the operation that should be carried out on the
+ subscription:
+
+ * The value of 'create' instructs the Media Server to attempt to
+ set up a new subscription.
+
+ * The value of 'update' instructs the Media Server to attempt to
+ update an existing subscription.
+
+ * The value of 'remove' instructs the Media Server to attempt to
+ remove an existing subscription and consequently stop any
+ ongoing related notification.
+
+ The attribute MUST be present.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 16]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <subscription> element has zero or more of the following child
+ elements:
+
+ <expires>: Provides the amount of time in seconds that a
+ subscription should be installed for notifications at the Media
+ Server. Once the amount of time has passed, the subscription
+ expires, and the MRB has to subscribe again if it is still
+ interested in receiving notifications from the Media Server. The
+ element MAY be present.
+
+ <minfrequency>: Provides the minimum frequency in seconds that the
+ MRB wishes to receive notifications from the Media Server. The
+ element MAY be present.
+
+ <maxfrequency>: Provides the maximum frequency in seconds that the
+ MRB wishes to receive notifications from the Media Server. The
+ element MAY be present.
+
+ Please note that these three optional pieces of information provided
+ by the MRB only act as a suggestion: the Media Server MAY change the
+ proposed values if it considers the suggestions unacceptable (e.g.,
+ if the MRB has requested a notification frequency that is too high).
+ In such a case, the request would not fail, but the updated,
+ acceptable values would be reported in the <mrbresponse> accordingly.
+
+5.1.4. <mrbresponse>
+
+ Responses to requests are indicated by an <mrbresponse> element.
+
+ The <mrbresponse> element has the following attributes:
+
+ status: numeric code indicating the response status. The attribute
+ MUST be present.
+
+ reason: string specifying a reason for the response status. The
+ attribute MAY be present.
+
+ The <mrbresponse> element has a single child element:
+
+ <subscription> for providing details related to a subscription
+ requested by a Media Server (see below in this section).
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 17]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The following status codes are defined for 'status':
+
+ +-----------+-------------------------------------------------------+
+ | code | description |
+ +-----------+-------------------------------------------------------+
+ | 200 | OK |
+ | | |
+ | 400 | Syntax error |
+ | | |
+ | 401 | Unable to create Subscription |
+ | | |
+ | 402 | Unable to update Subscription |
+ | | |
+ | 403 | Unable to remove Subscription |
+ | | |
+ | 404 | Subscription does not exist |
+ | | |
+ | 405 | Wrong sequence number |
+ | | |
+ | 406 | Subscription already exists |
+ | | |
+ | 420 | Unsupported attribute or element |
+ +-----------+-------------------------------------------------------+
+
+ Table 1: <mrbresponse> Status Codes
+
+ If a new subscription request made by an MRB (action='create') has
+ been accepted, the Media Server MUST reply with an <mrbresponse> with
+ status code 200. The same rule applies whenever a request to update
+ (action='update') or remove (action='remove') an existing transaction
+ can be fulfilled by the Media Server.
+
+ A subscription request, nevertheless, may fail for several reasons.
+ In such a case, the status codes defined in Table 1 must be used
+ instead. Specifically, if the Media Server fails to handle a request
+ due to a syntax error in the request itself (e.g., incorrect XML,
+ violation of the schema constraints, or invalid values in any of the
+ attributes/elements), the Media Server MUST reply with an
+ <mrbresponse> with status code 400. If a syntactically correct
+ request fails because the request also includes any attribute/element
+ the Media Server doesn't understand, the Media Server MUST reply with
+ an <mrbresponse> with status code 420. If a syntactically correct
+ request fails because the MRB wants to create a new subscription, but
+ the provided unique 'id' for the subscription already exists, the
+ Media Server MUST reply with an <mrbresponse> with status code 406.
+ If a syntactically correct request fails because the MRB wants to
+ update/remove a subscription that doesn't exist, the Media Server
+ MUST reply with an <mrbresponse> with status code 404. If the Media
+
+
+
+Boulton, et al. Standards Track [Page 18]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Server is unable to accept a request for any other reason (e.g., the
+ MRB has no more resources to fulfill the request), the Media Server
+ MUST reply with an <mrbresponse> with status code 401/402/403,
+ depending on the action the MRB provided in its request:
+
+ o action='create' --> 401;
+
+ o action='update' --> 402;
+
+ o action='remove' --> 403;
+
+ A response to a subscription request that has a status code of 200
+ indicates that the request is successful. The response MAY also
+ contain a <subscription> child that describes the subscription. The
+ <subscription> child MAY contain 'expires', 'minfrequency', and
+ 'maxfrequency' values even if they were not contained in the request.
+
+ The Media Server can choose to change the suggested 'expires',
+ 'minfrequency', and 'maxfrequency' values provided by the MRB in its
+ <mrbrequest> if it considers them unacceptable (e.g., the requested
+ frequency range is too high). In such a case, the response MUST
+ contain a <subscription> element describing the subscription as the
+ Media Server accepted it, and the Media Server MUST include in the
+ <subscription> element all of those values that it modified relative
+ to the request, to inform the MRB about the change.
+
+5.1.5. <mrbnotification>
+
+ The <mrbnotification> element is included in a request from a Media
+ Server to an MRB to provide the details relating to current status.
+ The Media Server will inform the MRB of its current status as defined
+ by the information in the <subscription> element. Updates are sent
+ using the <mrbnotification> element.
+
+ The <mrbnotification> element has the following attributes:
+
+ id: indicates a unique token representing the session between the
+ MRB and the Media Server and is the same as the one appearing in
+ the <subscription> element. The attribute MUST be present.
+
+ seqnumber: indicates a sequence number to be used in conjunction
+ with the subscription session ID to identify a specific
+ notification update. The first notification update MUST contain a
+ non-zero number 'seqnumber', and subsequent notification updates
+ MUST contain a higher number than the previous 'seqnumber' value.
+ If a subsequent 'seqnumber' is not higher, the situation should be
+
+
+
+
+
+Boulton, et al. Standards Track [Page 19]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ considered an error by the entity receiving the notification
+ update. How the receiving entity deals with this situation is
+ implementation specific. The attribute MUST be present.
+
+ It's important to point out that the 'seqnumber' that appears in an
+ <mrbnotification> is not related to the 'seqnumber' appearing in a
+ <subscription>. In fact, the latter is associated with subscriptions
+ and would increase at every command issued by the MRB, while the
+ former is associated with the asynchronous notifications the Media
+ Server would trigger according to the subscription and as such would
+ increase at every notification message to enable the MRB to keep
+ track of them.
+
+ The following sub-sections provide details of the child elements that
+ make up the contents of the <mrbnotification> element.
+
+5.1.5.1. <media-server-id>
+
+ The <media-server-id> element provides a unique system-wide
+ identifier for a Media Server instance. The element MUST be present
+ and MUST be chosen such that it is extremely unlikely that two
+ different Media Servers would present the same id to a given MRB.
+
+5.1.5.2. <supported-packages>
+
+ The <supported-packages> element provides the list of Media Control
+ Channel packages supported by the Media Server. The element MAY be
+ present.
+
+ The <supported-packages> element has no attributes.
+
+ The <supported-packages> element has a single child element:
+
+ <package>: Gives the name of a package supported by the Media
+ Server. The <package> element has a single attribute, 'name',
+ which provides the name of the supported Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230].
+
+5.1.5.3. <active-rtp-sessions>
+
+ The <active-rtp-sessions> element provides information detailing the
+ current active Real-time Transport Protocol (RTP) sessions. The
+ element MAY be present.
+
+ The <active-rtp-sessions> element has no attributes.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 20]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <active-rtp-sessions> element has a single child element:
+
+ <rtp-codec>: Describes a supported codec and the number of active
+ sessions using that codec. The <rtp-codec> element has one
+ attribute. The value of the attribute, 'name', is a media type
+ (which can include parameters per [RFC6381]). The <rtp-codec>
+ element has two child elements. The child element <decoding> has
+ as content the decimal number of RTP sessions being decoded using
+ the specified codec, and the child element <encoding> has as
+ content the decimal number of RTP sessions being encoded using the
+ specified codec.
+
+5.1.5.4. <active-mixer-sessions>
+
+ The <active-mixer-sessions> element provides information detailing
+ the current active mixed RTP sessions. The element MAY be present.
+
+ The <active-mixer-sessions> element has no attributes.
+
+ The <active-mixer-sessions> element has a single child element:
+
+ <active-mix>: Describes a mixed active RTP session. The
+ <active-mix> element has one attribute. The value of the
+ attribute, 'conferenceid', is the name of the mix. The
+ <active-mix> element has one child element. The child element,
+ <rtp-codec>, contains the same information relating to RTP
+ sessions as that defined in Section 5.1.5.3. The element MAY be
+ present.
+
+5.1.5.5. <non-active-rtp-sessions>
+
+ The <non-active-rtp-sessions> element provides information detailing
+ the currently available inactive RTP sessions, that is, how many more
+ RTP streams this Media Server can support. The element MAY be
+ present.
+
+ The <non-active-rtp-sessions> element has no attributes.
+
+ The <non-active-rtp-sessions> element has a single child element:
+
+ <rtp-codec>: Describes a supported codec and the number of
+ non-active sessions for that codec. The <rtp-codec> element has
+ one attribute. The value of the attribute, 'name', is a media
+ type (which can include parameters per [RFC6381]). The
+ <rtp-codec> element has two child elements. The child element
+ <decoding> has as content the decimal number of RTP sessions
+
+
+
+
+
+Boulton, et al. Standards Track [Page 21]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ available for decoding using the specified codec, and the child
+ element <encoding> has as content the decimal number of RTP
+ sessions available for encoding using the specified codec.
+
+5.1.5.6. <non-active-mixer-sessions>
+
+ The <non-active-mixer-sessions> element provides information
+ detailing the current inactive mixed RTP sessions, that is, how many
+ more mixing sessions this Media Server can support. The element MAY
+ be present.
+
+ The <non-active-mixer-sessions> element has no attributes.
+
+ The <non-active-mixer-sessions> element has a single child element:
+
+ <non-active-mix>: Describes available mixed RTP sessions. The
+ <non-active-mix> element has one attribute. The value of the
+ attribute, 'available', is the number of mixes that could be used
+ using that profile. The <non-active-mix> element has one child
+ element. The child element, <rtp-codec>, contains the same
+ information relating to RTP sessions as that defined in
+ Section 5.1.5.5. The element MAY be present.
+
+5.1.5.7. <media-server-status>
+
+ The <media-server-status> element provides information detailing the
+ current status of the Media Server. The element MUST be present. It
+ can return one of the following values:
+
+ active: Indicates that the Media Server is available for service.
+
+ deactivated: Indicates that the Media Server has been withdrawn from
+ service, and as such requests should not be sent to it before it
+ becomes 'active' again.
+
+ unavailable: Indicates that the Media Server continues to process
+ past requests but cannot accept new requests, and as such should
+ not be contacted before it becomes 'active' again.
+
+ The <media-server-status> element has no attributes.
+
+ The <media-server-status> element has no child elements.
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 22]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.5.8. <supported-codecs>
+
+ The <supported-codecs> element provides information detailing the
+ current codecs supported by a Media Server and associated actions.
+ The element MAY be present.
+
+ The <supported-codecs> element has no attributes.
+
+ The <supported-codecs> element has a single child element:
+
+ <supported-codec>: Has a single attribute, 'name', which provides
+ the name of the codec about which this element provides
+ information. A valid value is a media type that, depending on its
+ definition, can include additional parameters (e.g., [RFC6381]).
+ The <supported-codec> element then has a further child element,
+ <supported-codec-package>. The <supported-codec-package> element
+ has a single attribute, 'name', which provides the name of the
+ Media Control Channel Framework package, compliant with
+ Section 13.1.1 of [RFC6230], for which the codec support applies.
+ The <supported-codec-package> element has zero or more
+ <supported-action> children, each one of which describes an action
+ that a Media Server can apply to this codec:
+
+ * 'decoding', meaning a decoder for this codec is available;
+
+ * 'encoding', meaning an encoder for this codec is available;
+
+ * 'passthrough', meaning the Media Server is able to pass a
+ stream encoded using that codec through, without re-encoding.
+
+5.1.5.9. <application-data>
+
+ The <application-data> element provides an arbitrary string of
+ characters as application-level data. This data is meant to only
+ have meaning at the application-level logic and as such is not
+ otherwise restricted by this specification. The set of allowed
+ characters is the same as those in XML (viz., tab, carriage return,
+ line feed, and the legal characters of Unicode and ISO/IEC 10646
+ [ISO.10646.2012] (see also Section 2.2 of
+ <http://www.w3.org/TR/xml/>)). The element MAY be present.
+
+ The <application-data> element has no attributes.
+
+ The <application-data> element has no child elements.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 23]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.5.10. <file-formats>
+
+ The <file-formats> element provides a list of file formats supported
+ for the purpose of playing media. The element MAY be present.
+
+ The <file-formats> element has no attributes.
+
+ The <file-formats> element has zero of more the following child
+ elements:
+
+ <supported-format>: Has a single attribute, 'name', which provides
+ the type of file format that is supported. A valid value is a
+ media type that, depending on its definition, can include
+ additional parameters (e.g., [RFC6381]). The <supported-format>
+ element then has a further child element,
+ <supported-file-package>. The <supported-file-package> element
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the file
+ format support applies.
+
+5.1.5.11. <max-prepared-duration>
+
+ The <max-prepared-duration> element provides the maximum amount of
+ time a media dialog will be kept in the prepared state before timing
+ out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231]. The element MAY be
+ present.
+
+ The <max-prepared-duration> element has no attributes.
+
+ The <max-prepared-duration> element has a single child element:
+
+ <max-time>: Has a single attribute, 'max-time-seconds', which
+ provides the amount of time in seconds that a media dialog can be
+ in the prepared state. The <max-time> element then has a further
+ child element, <max-time-package>. The <max-time-package> element
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the time
+ period applies.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 24]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.5.12. <dtmf-support>
+
+ The <dtmf-support> element specifies the supported methods to detect
+ Dual-Tone Multi-Frequency (DTMF) tones and to generate them. The
+ element MAY be present.
+
+ The <dtmf-support> element has no attributes.
+
+ The <dtmf-support> element has zero of more of the following child
+ elements:
+
+ <detect>: Indicates the support for DTMF detection. The <detect>
+ element has no attributes. The <detect> element then has a
+ further child element, <dtmf-type>. The <dtmf-type> element has
+ two attributes: 'name' and 'package'. The 'name' attribute
+ provides the type of DTMF being used, and it can only be a case-
+ insensitive string containing either 'RFC4733' [RFC4733] or
+ 'Media' (detecting tones as signals from the audio stream). The
+ 'package' attribute provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the DTMF type applies.
+
+ <generate>: Indicates the support for DTMF generation. The
+ <generate> element has no attributes. The <generate> element then
+ has a further child element, <dtmf-type>. The <dtmf-type> element
+ has two attributes: 'name' and 'package'. The 'name' attribute
+ provides the type of DTMF being used, and it can only be a case-
+ insensitive string containing either 'RFC4733' [RFC4733] or
+ 'Media' (generating tones as signals in the audio stream). The
+ 'package' attribute provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the DTMF type applies.
+
+ <passthrough>: Indicates the support for passing DTMF through
+ without re-encoding. The <passthrough> element has no attributes.
+ The <passthrough> element then has a further child element,
+ <dtmf-type>. The <dtmf-type> element has two attributes: 'name'
+ and 'package'. The 'name' attribute provides the type of DTMF
+ being used, and it can only be a case-insensitive string
+ containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as
+ signals through the audio stream). The 'package' attribute
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+ type applies.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 25]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.5.13. <mixing-modes>
+
+ The <mixing-modes> element provides information about the support for
+ audio and video mixing of a Media Server, specifically a list of
+ supported algorithms to mix audio and a list of supported video
+ presentation layouts. The element MAY be present.
+
+ The <mixing-modes> element has no attributes.
+
+ The <mixing-modes> element has zero or more of the following child
+ elements:
+
+ <audio-mixing-modes>: Describes the available algorithms for audio
+ mixing. The <audio-mixing-modes> element has no attributes. The
+ <audio-mixing-modes> element has one child element. The child
+ element, <audio-mixing-mode>, contains a specific available
+ algorithm. Valid values for the <audio-mixing-mode> element are
+ algorithm names, e.g., 'nbest' and 'controller' as defined in
+ [RFC6505]. The element has a single attribute, 'package'. The
+ attribute 'package' provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the algorithm support applies.
+
+ <video-mixing-modes>: Describes the available video presentation
+ layouts and the supported functionality related to video mixing.
+ The <video-mixing-modes> element has two attributes: 'vas' and
+ 'activespeakermix'. The 'vas' attribute is of type boolean with a
+ value of 'true' indicating that the Media Server supports
+ automatic Voice Activated Switching. The 'activespeakermix' is of
+ type boolean with a value of 'true' indicating that the Media
+ Server is able to prepare an additional video stream for the
+ loudest speaker participant without its contribution. The
+ <video-mixing-modes> element has one child element. The child
+ element, <video-mixing-mode>, contains the name of a specific
+ video presentation layout. The name may refer to one of the
+ predefined video layouts defined in the XCON conference
+ information data model [RFC6501], or to non-XCON layouts as well,
+ as long as they are properly prefixed according to the schema they
+ belong to. The <video-mixing-mode> element has a single
+ attribute, 'package'. The attribute 'package' provides the name
+ of the Media Control Channel Framework package, compliant with
+ Section 13.1.1 of [RFC6230], for which the algorithm support
+ applies.
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 26]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.1.5.14. <supported-tones>
+
+ The <supported-tones> element provides information about which tones
+ a Media Server is able to play and recognize. In particular, the
+ support is reported by referring to both support for country codes
+ (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T
+ Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
+
+ The <supported-tones> element has no attributes.
+
+ The <supported-tones> element has zero or more of the following child
+ elements:
+
+ <supported-country-codes>: Describes the supported country codes
+ with respect to tones. The <supported-country-codes> element has
+ no attributes. The <supported-country-codes> element has one
+ child element. The child element, <country-code>, reports support
+ for a specific country code, compliant with the ISO 3166-1
+ [ISO.3166-1] specification. The <country-code> element has a
+ single attribute, 'package'. The attribute 'package' provides the
+ name of the Media Control Channel Framework package, compliant
+ with Section 13.1.1 of [RFC6230], in which the tones from the
+ specified country code are supported.
+
+ <supported-h248-codes>: Describes the supported H.248 codes with
+ respect to tones. The <supported-h248-codes> element has no
+ attributes. The <supported-h248-codes> element has one child
+ element. The child element, <h248-code>, reports support for a
+ specific H.248 code, compliant with the ITU-T Recommendation
+ Q.1950 [ITU-T.Q.1950] specification. The codes can be either
+ specific (e.g., cg/dt to only report the Dial Tone from the Call
+ Progress Tones package) or generic (e.g., cg/* to report all the
+ tones from the Call Progress Tones package), using wildcards. The
+ <h248-code> element has a single attribute, 'package'. The
+ attribute 'package' provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], in
+ which the specified codes are supported.
+
+5.1.5.15. <file-transfer-modes>
+
+ The <file-transfer-modes> element allows the Media Server to specify
+ which scheme names are supported for transferring files to a Media
+ Server for each Media Control Channel Framework package type, for
+ example, whether the Media Server supports fetching resources via
+ HTTP, HTTPS, NFS, etc. The element MAY be present.
+
+ The <file-transfer-modes> element has no attributes.
+
+
+
+
+Boulton, et al. Standards Track [Page 27]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <file-transfer-modes> element has a single child element:
+
+ <file-transfer-mode>: Has two attributes: 'name' and 'package'. The
+ 'name' attribute provides the scheme name of the protocol that can
+ be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.); the
+ value of the attribute is case insensitive. The 'package'
+ attribute provides the name of the Media Control Channel Framework
+ package, compliant with the specification in the related IANA
+ registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.
+
+ It is important to point out that this element provides no
+ information about whether or not the Media Server supports any flavor
+ of live streaming: for instance, a value of "HTTP" for the IVR
+ (Interactive Voice Response) Package would only mean the 'http'
+ scheme makes sense to the Media Server within the context of that
+ package. Whether or not the Media Server can make use of HTTP to
+ only fetch resources, or also to attach an HTTP live stream to a
+ call, is to be considered implementation specific to the Media Server
+ and irrelevant to the Application Server and/or MRB. Besides, the
+ Media Server supporting a scheme does not imply that it also supports
+ the related secure versions: for instance, if the Media Server
+ supports both HTTP and HTTPS, both the schemes will appear in the
+ element. A lack of the "HTTPS" value would need to be interpreted as
+ a lack of support for the 'https' scheme.
+
+5.1.5.16. <asr-tts-support>
+
+ The <asr-tts-support> element provides information about the support
+ for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
+ functionality in a Media Server. The functionality is reported by
+ referring to the supported languages (using ISO 639-1 [ISO.639.2002]
+ codes) regarding both ASR and TTS. The element MAY be present.
+
+ The <asr-tts-support> element has no attributes.
+
+ The <asr-tts-support> element has zero or more of the following child
+ elements:
+
+ <asr-support>: Describes the available languages for ASR. The
+ <asr-support> element has no attributes. The <asr-support>
+ element has one child element. The child element, <language>,
+ reports that the Media Server supports ASR for a specific
+ language. The <language> element has a single attribute,
+ 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
+ [ISO.639.2002] code of the supported language.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 28]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <tts-support>: Describes the available languages for TTS. The
+ <tts-support> element has no attributes. The <tts-support>
+ element has one child element. The child element, <language>,
+ reports that the Media Server supports TTS for a specific
+ language. The <language> element has a single attribute,
+ 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
+ [ISO.639.2002] code of the supported language.
+
+5.1.5.17. <vxml-support>
+
+ The <vxml-support> element specifies if the Media Server supports
+ VoiceXML (VXML) and, if it does, through which protocols the support
+ is exposed (e.g., via the control framework, RFC 4240 [RFC4240], or
+ RFC 5552 [RFC5552]). The element MAY be present.
+
+ The <vxml-support> element has no attributes.
+
+ The <vxml-support> element has a single child element:
+
+ <vxml-mode>: Has two attributes: 'package' and 'support'. The
+ 'package' attribute provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the VXML support applies. The 'support' attribute provides
+ the type of VXML support provided by the Media Server (e.g.,
+ RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package
+ [RFC6231]), and valid values are case-insensitive RFC references
+ (e.g., "rfc6231" to specify that the Media Server supports
+ VoiceXML as provided by the IVR Package [RFC6231]).
+
+ The presence of at least one <vxml-mode> child element would indicate
+ that the Media Server does support VXML as specified by the child
+ element itself. An empty <vxml> element would otherwise indicate
+ that the Media Server does not support VXML at all.
+
+5.1.5.18. <media-server-location>
+
+ The <media-server-location> element provides information about the
+ civic location of a Media Server. Its description makes use of the
+ Civic Address Schema standardized in RFC 5139 [RFC5139]. The element
+ MAY be present. More precisely, this section is entirely optional,
+ and it's implementation specific to fill it with just the details
+ each implementer deems necessary for any optimization that may be
+ needed.
+
+ The <media-server-location> element has no attributes.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 29]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <media-server-location> element has a single child element:
+
+ <civicAddress>: Describes the civic address location of the Media
+ Server, whose representation refers to Section 4 of RFC 5139
+ [RFC5139].
+
+5.1.5.19. <label>
+
+ The <label> element allows a Media Server to declare a piece of
+ information that will be understood by the MRB. For example, the
+ Media Server can declare if it's a blue or green one. It's a string
+ to allow arbitrary values to be returned to allow arbitrary
+ classification. The element MAY be present.
+
+ The <label> element has no attributes.
+
+ The <label> element has no child elements.
+
+5.1.5.20. <media-server-address>
+
+ The <media-server-address> element allows a Media Server to provide a
+ direct SIP URI where it can be reached (e.g., the URI that the
+ Application Server would call in order to set up a Control Channel
+ and relay SIP media dialogs). The element MAY be present.
+
+ The <media-server-address> element has no attributes.
+
+ The <media-server-address> element has no child elements.
+
+5.1.5.21. <encryption>
+
+ The <encryption> element allows a Media Server to declare support for
+ encrypting RTP media streams using RFC 3711 [RFC3711]. The element
+ MAY be present. If the element is present, then the Media Server
+ supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP)
+ extension for Datagram Transport Layer Security (DTLS)) [RFC5763].
+
+ The <encryption> element has no attributes.
+
+ The <encryption> element has no child elements.
+
+5.2. Media Service Resource Consumer Interface
+
+ The Media Server Consumer interface provides the ability for clients
+ of an MRB, such as Application Servers, to request an appropriate
+ Media Server to satisfy specific criteria. This interface allows a
+ 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
+
+
+
+Boulton, et al. Standards Track [Page 30]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ decision and provide the client with an appropriate Media Server
+ resource. The MRB Consumer interface includes both 1) the In-line
+ Aware MRB Mode (IAMM), which uses the Session Initiation Protocol
+ (SIP) and 2) the Query mode, which uses the Hypertext Transfer
+ Protocol (HTTP) [RFC2616]. The MRB Consumer interface does not
+ include the In-line Unaware Mode (IUMM), which is further explained
+ in Section 5.3. The following sub-sections provide guidance on
+ using the Consumer interface, which is represented by the
+ 'application/mrb-consumer+xml' media type in Section 11, with HTTP
+ and SIP.
+
+5.2.1. Query Mode/HTTP Consumer Interface Usage
+
+ An appropriate interface for such a 'query' style interface is in
+ fact an HTTP usage. Using HTTP and XML combined reduces complexity
+ and encourages the use of common tools that are widely available in
+ the industry today. The following information explains the primary
+ operations required to request and then receive information from an
+ MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport
+ for a query for a media resource, and the appropriate response.
+
+ The media resource query, as defined by the <mediaResourceRequest>
+ element from Section 11, MUST be carried in the body of an HTTP/HTTPS
+ POST request. The media type contained in the HTTP/HTTPS request/
+ response MUST be 'application/mrb-consumer+xml'. This value MUST be
+ reflected in the appropriate HTTP headers, such as 'Content-Type' and
+ 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain
+ an <mrbconsumer> root element with only one child
+ <mediaResourceRequest> element as defined in Section 11.
+
+ The media resource response to a query, as defined by the
+ <mediaResourceResponse> element from Section 11, MUST be carried in
+ the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
+ POST request. The media type contained in the HTTP/HTTPS request/
+ response MUST be 'application/mrb-consumer+xml'. This value MUST be
+ reflected in the appropriate HTTP headers, such as 'Content-Type' and
+ 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
+ an <mrbconsumer> root element with only one child
+ <mediaResourceResponse> element as defined in Section 11.
+
+ When an Application Server wants to release previously awarded media
+ resources granted through a prior request/response exchange with an
+ MRB, it will send a new request with an <action> element with value
+ 'remove', as described in Section 5.2.3 ("Consumer Interface Lease
+ Mechanism").
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 31]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage
+
+ This document provides a complete toolkit for MRB deployment that
+ includes the ability to interact with an MRB using SIP for the
+ Consumer interface. The following information explains the primary
+ operations required to request and then receive information from an
+ MRB, by making use of SIP [RFC3261] as transport for a request for
+ media resources, and the appropriate response when using IAMM as the
+ mode of operation (as discussed in Section 5.2.2.1).
+
+ The use of IAMM, besides having the MRB select appropriate media
+ resources on behalf of a client application, includes setting up
+ either a Control Framework Control Channel between an Application
+ Server and one of the Media Servers (Section 5.2.2.1) or a media
+ dialog session between an Application Server and one of the Media
+ Servers (Section 5.2.2.2). Note that in either case the SIP URIs of
+ the selected Media Servers are made known to the requesting
+ Application Server in the SIP 200 OK response by means of one or more
+ <media-server-address> child elements in the <response-session-info>
+ element (Section 5.2.6).
+
+5.2.2.1. IAMM and Setting Up a Control Framework Control Channel
+
+ The media resource request information, as defined by the
+ <mediaResourceRequest> element from Section 11, is 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 [RFC6230]. It should be noted that this
+ specification does not exclude the use of an offerless INVITE as
+ defined in RFC 3261 [RFC3261]. Using offerless INVITE messages to an
+ MRB can potentially cause confusion when applying resource selection
+ algorithms, and an MRB, like any other SIP device, can choose to
+ reject with a 4xx response. For an offerless INVITE to be treated
+ appropriately, additional contextual information would need to be
+ provided with the request; this is out of scope for this document.
+ The following additional steps MUST be followed when using the
+ Consumer interface:
+
+ o The Consumer client will include a payload in the SIP INVITE
+ request of type 'multipart/mixed' [RFC2046]. One of the parts to
+ be included in the 'multipart/mixed' payload MUST be the
+ 'application/sdp' format, which is constructed as specified in the
+ Media Control Channel Framework [RFC6230].
+
+ o Another part of the 'multipart/mixed' payload MUST be of type
+ 'application/mrb-consumer+xml', as specified in this document and
+ defined in Section 11. The body part MUST be an XML document
+ without prolog and whose root element is <mediaResourceRequest>.
+
+
+
+Boulton, et al. Standards Track [Page 32]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ o The INVITE request will then be dispatched to the MRB, as defined
+ by [RFC6230].
+
+ On receiving a SIP INVITE request containing the multipart/mixed
+ 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 (or Media Servers, if more than one is deemed to be
+ needed) should be selected to service the request.
+
+ o Extract the 'application/sdp' part from the payload and use it as
+ the body of a new SIP INVITE request for connecting the client to
+ one of the selected Media Servers, as defined in the Media Channel
+ Control Framework [RFC6230]. The policy the MRB follows to pick a
+ specific Media Server out of the Media Servers it selects is
+ implementation specific and out of scope for this document. It is
+ important to configure the SIP elements between the MRB and the
+ Media Server in such a way that the INVITE will not fork. In the
+ case of a failure in reaching the chosen Media Server, the MRB
+ SHOULD proceed to the next one, if available.
+
+ If none of the available Media Servers can be reached, the MRB MUST
+ reply with a SIP 503 error message that includes a Retry-After header
+ with a non-zero value. The Application Server MUST NOT attempt to
+ set up a new session before the time that the MRB asked it to wait
+ has passed.
+
+ If at least one Media Server is reachable, the MRB acts as a Back-to-
+ Back User Agent (B2BUA) that extracts the 'application/
+ mrb-consumer+xml' information from the SIP INVITE request and then
+ sends a corresponding SIP INVITE request to the Media Server it has
+ selected, to negotiate a Control Channel as defined in the Media
+ Channel Control Framework [RFC6230].
+
+ In the case of a failure in negotiating the Control Channel with the
+ Media Server, the MRB SHOULD proceed to the next one, if available,
+ as explained above. If none of the available Media Servers can be
+ reached, or the negotiations of the Control Channel with all of them
+ fail, the MRB MUST reply with a SIP 503 error message that includes a
+ Retry-After header with a non-zero value. The Application Server
+ MUST NOT attempt to set up a new session before the time that the MRB
+ asked it to wait has expired.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 33]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 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 generated by an MRB to a request, as
+ defined by the <mediaResourceResponse> element from Section 11, MUST
+ be carried in the payload of a SIP 200 OK response to the original
+ SIP INVITE request. The SIP 200 OK response will be constructed as
+ it would have been to connect from a Media Server, as defined by the
+ Media Control Channel Framework [RFC6230]. The following additional
+ steps MUST be followed when using the Consumer interface:
+
+ o Include a payload in the SIP 200 response of type 'multipart/
+ mixed' as per RFC 2046 [RFC2046]. One of the parts to be included
+ in the 'multipart/mixed' payload MUST be the 'application/sdp'
+ format, which is constructed as specified in the Media Control
+ Channel Framework [RFC6230] and based on the incoming response
+ from the selected media resource.
+
+ o Another part of the 'multipart/mixed' payload MUST be of type
+ 'application/mrb-consumer+xml', as specified in this document and
+ defined in Section 11. Only the <mediaResourceResponse> and its
+ child elements can be included in the payload.
+
+ o The SIP 200 response will then be dispatched from the MRB.
+
+ o A SIP ACK to the 200 response will then be sent back to the MRB.
+
+ Considering that the use of SIP as a transport for Consumer
+ transactions may result in failure, the IAMM relies on a successful
+ INVITE transaction to address the previously discussed sequence
+ (using the 'seq' XML element) increment mechanism. This means that
+ if the INVITE is unsuccessful for any reason, the Application Server
+ MUST use the same 'seq' value as previously used for the next
+ Consumer request that it may want to send to the MRB for the same
+ session.
+
+ An MRB implementation may be programmed to conclude that the
+ 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 (Section 5.2.3)
+ interval expires.
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 34]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.2.2. IAMM and Setting Up a Media Dialog
+
+ This scenario is identical to the description in the previous section
+ for setting up a Control Framework Control Channel, with the
+ exception that the application/sdp payload conveys content
+ appropriate for setting up the media dialog to the media resource, as
+ per RFC 3261 [RFC3261], instead of setting up a Control Channel.
+
+5.2.3. Consumer Interface Lease Mechanism
+
+ The Consumer interface defined in Sections 5.2 and 11 allows a client
+ to request an appropriate media resource based on information
+ included in the request (either an HTTP POST or SIP INVITE message).
+ In the case of success, the response that is returned to the client
+ MUST contain a <response-session-info> element in either the SIP 200
+ or HTTP 200 response. The success response contains the description
+ of certain resources that have been reserved to a specific Consumer
+ client in a (new or revised) "resource session", which is identified
+ in the <response-session-info>. The resource session is a "lease",
+ in that the reservation is scheduled to expire at a particular time
+ in the future, releasing the resources to be assigned for other uses.
+ The lease may be extended or terminated earlier by future Consumer
+ client requests that identify and reference a specific resource
+ session.
+
+ Before delving into the details of such a lease mechanism, it is
+ worth clarifying its role within the context of the Consumer
+ interface. As explained in Section 5.1, the knowledge the MRB has of
+ the resources of all the Media Servers it is provisioned to manage is
+ not real-time. How an MRB actually manages such resources is
+ implementation specific -- for example, an implementation may choose
+ to have the MRB keeping track and state of the allocated resources,
+ or simply rely on the Media Servers themselves to provide the
+ information using the Publish interface. Further information may
+ also be inferred by the signaling, in the case where an MRB is in the
+ path of media dialogs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 35]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <mediaResourceResponse> element returned from the MRB contains a
+ <response-session-info> element if the request is successful. The
+ <response-session-info> element has zero or more of the following
+ child elements, which provide the appropriate resource session
+ information:
+
+ o <session-id> is a unique identifier that enables a Consumer client
+ and MRB to correlate future media resource requests related to an
+ initial media resource request. The <session-id> MUST be included
+ in all future related requests (see the <session-id> paragraph
+ later in this section, where constructing a subsequent request is
+ discussed).
+
+ o <seq> is a numeric value returned to the Consumer client. On
+ issuing any future requests related to the media resource session
+ (as determined by the <session-id> element), the Consumer client
+ MUST increment the value returned in the <seq> element and include
+ it in the request (see the <seq> paragraph later in this section,
+ where constructing a subsequent request is discussed). Its value
+ is a non-negative integer that MUST be limited within the
+ 0..2^31-1 range.
+
+ o <expires> provides a value indicating the number of seconds that
+ the request for media resources is deemed alive. The Consumer
+ client should issue a refresh of the request, as discussed later
+ in this section, if the expiry is due to fire and the media
+ resources are still required.
+
+ o <media-server-address> provides information representing an
+ assigned Media Server. More instances of this element may appear
+ should the MRB assign more Media Servers to a Consumer request.
+
+ The <mediaResourceRequest> element is used in subsequent Consumer
+ interface requests if the client wishes to manipulate the session.
+ The Consumer client MUST include the <session-info> element, which
+ enables the receiving MRB to determine an existing media resource
+ allocation session. The <session-info> element has the following
+ child elements, which provide the appropriate resource session
+ information to the MRB:
+
+ o <session-id> is a unique identifier that allows a Consumer client
+ to indicate the appropriate existing media resource session to be
+ manipulated by the MRB for this request. The value was provided
+ by the MRB in the initial request for media resources, as
+ discussed earlier in this section (<session-id> element included
+ as part of the <session-info> element in the initial
+ <mediaResourceResponse>).
+
+
+
+
+Boulton, et al. Standards Track [Page 36]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ o <seq> is a numeric value returned to the Consumer client in the
+ initial request for media resources, as discussed earlier in this
+ section (<seq> element included as part of the <session-info>
+ element in the initial <mediaResourceResponse>). On issuing any
+ future requests related to the specific media resource session (as
+ determined by the <session-id> element), the Consumer client MUST
+ increment the value returned in the <seq> element from the initial
+ response (contained in the <mediaResourceResponse>) for every new
+ request. The value of the <seq> element in requests acts as a
+ counter and when used in conjunction with the unique <session-id>
+ allows for unique identification of a request. As anticipated
+ before, the <seq> value is limited to the 0..2^31-1 range: in the
+ unlikely case that the counter increases to reach the highest
+ allowed value, the <seq> value MUST be set to 0. The first
+ numeric value for the <seq> element is not meant to be '1' but
+ SHOULD be generated randomly by the MRB: this is to reduce the
+ chances of a malicious MRB disrupting the session created by this
+ MRB, as explained in Section 12.
+
+ o <action> provides the operation to be carried out by the MRB on
+ receiving the request:
+
+ * The value of 'update' is a request by the Consumer client to
+ update the existing session on the MRB with alternate media
+ resource requirements. If the requested resource information
+ is identical to the existing MRB session, the MRB will attempt
+ a session refresh. If the information has changed, the MRB
+ will attempt to update the existing session with the new
+ information. If the operation is successful, the 200 status
+ code in the response is returned in the status attribute of the
+ <mediaResourceResponseType> element. If the operation is not
+ successful, a 409 status code in the response is returned in
+ the status attribute of the <mediaResourceResponseType>
+ element.
+
+ * The value of 'remove' is a request by the Consumer client to
+ remove the session on the MRB. This provides a mechanism for
+ Consumer clients to release unwanted resources before they
+ expire. If the operation is successful, a 200 status code in
+ the response is returned in the status attribute of the
+ <mediaResourceResponseType> element. If the operation is not
+ successful, a 410 status code in the response is returned in
+ the status attribute of the <mediaResourceResponseType>
+ element.
+
+ Omitting the 'action' attribute means requesting a new set of
+ resources.
+
+
+
+
+Boulton, et al. Standards Track [Page 37]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ When used with HTTP, the <session-info> element MUST be included in
+ an HTTP POST message (as defined in [RFC2616]). When used with SIP,
+ the <session-info> element MUST instead be included in either a SIP
+ INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP
+ UPDATE (as defined in [RFC3311]) request: in fact, any SIP dialog, be
+ it a new or an existing one, can be exploited to carry leasing
+ information, and as such new SIP INVITE messages can update other
+ leases as well as request a new one.
+
+ 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 media dialog. That BYE contains no Consumer interface
+ lease information.
+
+5.2.4. <mrbconsumer>
+
+ This section defines the XML elements for the Consumer interface.
+ The formal XML schema definition for the Consumer interface can be
+ found in Section 11.
+
+ The root element is <mrbconsumer>. All other XML elements (requests,
+ responses) are contained within it. The MRB Consumer interface
+ request element is detailed in Section 5.2.5.1. The MRB Consumer
+ interface response element is detailed in Section 5.2.6.1.
+
+ The <mrbconsumer> element has the following attributes:
+
+ version: a token specifying the mrb-consumer package version. The
+ value is fixed as '1.0' for this version of the package. The
+ attribute MUST be present.
+
+ The <mrbconsumer> element may have zero or more children of one of
+ the following child element types:
+
+ <mediaResourceRequest> for sending a Consumer request. See
+ Section 5.2.5.1.
+
+ <mediaResourceResponse> for sending a Consumer response. See
+ Section 5.2.6.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 38]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.5. Media Service Resource Request
+
+ This section provides the element definitions for use in Consumer
+ interface requests. The requests are carried in the
+ <mediaResourceRequest> element.
+
+5.2.5.1. <mediaResourceRequest>
+
+ The <mediaResourceRequest> element provides information for clients
+ wishing to query an external MRB entity. The <mediaResourceRequest>
+ element has a single mandatory attribute, 'id': this attribute
+ contains a random identifier, generated by the client, that will be
+ included in the response in order to map it to a specific request.
+ The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and
+ <mixerInfo> as child elements. These three elements are used to
+ describe the requirements of a client requesting a Media Server and
+ are covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3,
+ respectively.
+
+5.2.5.1.1. <generalInfo>
+
+ The <generalInfo> element provides general Consumer request
+ information that is neither IVR specific nor mixer specific. This
+ includes session information that can be used for subsequent requests
+ as part of the leasing mechanism described in Section 5.2.3. The
+ following sub-sections describe the <session-info> and <packages>
+ elements, as used by the <generalInfo> element.
+
+5.2.5.1.1.1. <session-info>
+
+ The <session-info> element is included in Consumer requests when an
+ update is being made to an existing media resource session. The
+ ability to change and remove an existing media resource session is
+ described in more detail in Section 5.2.3. The element MAY be
+ present.
+
+ The <session-info> element has no attributes.
+
+ The <session-info> element has zero or more of the following child
+ elements:
+
+ <session-id>: A unique identifier that explicitly references an
+ existing media resource session on the MRB. The identifier is
+ included to update the existing session and is described in more
+ detail in Section 5.2.3.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 39]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <seq>: Used in association with the <session-id> element in a
+ subsequent request to update an existing media resource session on
+ an MRB. The <seq> number is incremented from its original value
+ returned in response to the initial request for media resources.
+ Its value is a non-negative integer that MUST be limited within
+ the 0..2^31-1 range. In the unlikely case that the counter
+ increases to reach the highest allowed value, the <seq> value MUST
+ be set to 0. More information about its use is provided in
+ Section 5.2.3.
+
+ <action>: Provides the operation that should be carried out on an
+ existing media resource session on an MRB:
+
+ * The value of 'update' instructs the MRB to attempt to update
+ the existing media resource session with the information
+ contained in the <ivrInfo> and <mixerInfo> elements.
+
+ * The value of 'remove' instructs the MRB to attempt to remove
+ the existing media resource session. More information on its
+ use is provided in Section 5.2.3.
+
+5.2.5.1.1.2. <packages>
+
+ The <packages> element provides a list of Media Control Channel
+ Framework compliant packages that are required by the Consumer
+ client. The element MAY be present.
+
+ The <packages> element has no attributes.
+
+ The <packages> element has a single child element:
+
+ <package>: Contains a string representing the Media Control Channel
+ Framework package required by the Consumer client. The <package>
+ element can appear multiple times. A valid value is a Control
+ Package name compliant with Section 13.1.1 of [RFC6230].
+
+5.2.5.1.2. <ivrInfo>
+
+ The <ivrInfo> element provides information for general Consumer
+ request information that is IVR specific. The following sub-sections
+ describe the elements of the <ivrInfo> element: <ivr-sessions>,
+ <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>,
+ <encryption>, <application-data>, <max-prepared-duration>, and
+ <file-transfer-modes>.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 40]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.5.1.2.1. <ivr-sessions>
+
+ The <ivr-sessions> element indicates the number of IVR sessions that
+ a Consumer client requires from a media resource. The element MAY be
+ present.
+
+ The <ivr-sessions> element has no attributes.
+
+ The <ivr-sessions> element has a single child element:
+
+ <rtp-codec>: Describes a required codec and the number of sessions
+ using that codec. The <rtp-codec> element has one attribute. The
+ value of the attribute, 'name', is a media type (which can include
+ parameters per [RFC6381]). The <rtp-codec> element has two child
+ elements. The child element <decoding> contains the number of RTP
+ sessions required for decoding using the specified codec, and the
+ child element <encoding> contains the number of RTP sessions
+ required for encoding using the specified codec.
+
+5.2.5.1.2.2. <file-formats>
+
+ The <file-formats> element provides a list of file formats required
+ for the purpose of playing media. It should be noted that this
+ element describes media types and might better have been named
+ "media-formats", but due to existing implementations the name
+ "file-formats" is being used. The element MAY be present.
+
+ The <file-formats> element has no attributes.
+
+ The <file-formats> element has a single child element:
+
+ <required-format>: Has a single attribute, 'name', which provides
+ the type of file format that is required. A valid value is a
+ media type that, depending on its definition, can include
+ additional parameters (e.g., [RFC6381]). The <required-format>
+ element then has a further child element, <required-file-package>.
+ The <required-file-package> element has a single attribute,
+ 'required-file-package-name', which contains the name of the Media
+ Control Channel Framework package, compliant with Section 13.1.1
+ of [RFC6230], for which the file format support applies.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 41]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.5.1.2.3. <dtmf>
+
+ The <dtmf> element specifies the required methods to detect DTMF
+ tones and to generate them. The element MAY be present.
+
+ The <dtmf> element has no attributes.
+
+ The <dtmf> element has zero or more of the following child elements:
+
+ <detect>: Indicates the required support for DTMF detection. The
+ <detect> element has no attributes. The <detect> element has a
+ further child element, <dtmf-type>. The <dtmf-type> element has
+ two attributes: 'name' and 'package'. The 'name' attribute
+ provides the type of DTMF required and is a case-insensitive
+ string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
+ tones as signals from the audio stream). The 'package' attribute
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+ type applies.
+
+ <generate>: Indicates the required support for DTMF generation. The
+ <generate> element has no attributes. The <generate> element has
+ a single child element, <dtmf-type>. The <dtmf-type> element has
+ two attributes: 'name' and 'package'. The 'name' attribute
+ provides the type of DTMF required and is a case-insensitive
+ string containing either 'RFC4733' [RFC4733] or 'Media'
+ (generating tones as signals in the audio stream). The 'package'
+ attribute provides the name of the Media Control Channel Framework
+ package, compliant with Section 13.1.1 of [RFC6230], for which the
+ DTMF type applies.
+
+ <passthrough>: Indicates the required support for passing DTMF
+ through without re-encoding. The <passthrough> element has no
+ attributes. The <passthrough> element then has a further child
+ element, <dtmf-type>. The <dtmf-type> element has two attributes:
+ 'name' and 'package'. The 'name' attribute provides the type of
+ DTMF required and is a case-insensitive string containing either
+ 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
+ the audio stream). The 'package' attribute provides the name of
+ the Media Control Channel Framework package, compliant with
+ Section 13.1.1 of [RFC6230], for which the DTMF type applies.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 42]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.5.1.2.4. <tones>
+
+ The <tones> element provides requested tones that a Media Server must
+ support for IVR. In particular, the request refers to both support
+ for country codes (ISO 3166-1 [ISO.3166-1]) and requested
+ functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The
+ element MAY be present.
+
+ The <tones> element has no attributes.
+
+ The <tones> element has zero or more of the following child elements:
+
+ <country-codes>: Describes the requested country codes in relation
+ to tones. The <country-codes> element has no attributes. The
+ <country-codes> element has one child element. The child element,
+ <country-code>, requests a specific country code, compliant with
+ the ISO 3166-1 [ISO.3166-1] specification. The <country-code>
+ element has a single attribute, 'package'. The attribute
+ 'package' provides the name of the Media Control Channel Framework
+ package, compliant with Section 13.1.1 of [RFC6230], in which the
+ tones from the specified country code are requested.
+
+ <h248-codes>: Describes the requested H.248 codes in relation to
+ tones. The <h248-codes> element has no attributes. The
+ <h248-codes> element has one child element. The child element,
+ <h248-code>, requests a specific H.248 code, compliant with the
+ ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. The
+ codes can be either specific (e.g., cg/dt to only report the Dial
+ Tone from the Call Progress Tones package) or generic (e.g., cg/*
+ to report all the tones from the Call Progress Tones package),
+ using wildcards. The <h248-code> element has a single attribute,
+ 'package'. The attribute 'package' provides the name of the Media
+ Control Channel Framework package, compliant with Section 13.1.1
+ of [RFC6230], in which the specified codes are requested.
+
+5.2.5.1.2.5. <asr-tts>
+
+ The <asr-tts> element requests information about the support for
+ Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
+ functionality in a Media Server. The functionality is requested by
+ referring to the supported languages (using ISO 639-1 [ISO.639.2002]
+ codes) in relation to both ASR and TTS. The <asr-tts> element has no
+ attributes. The <asr-tts> element has zero or more of the following
+ child elements:
+
+ <asr-support>: Describes the available languages for ASR. The
+ <asr-support> element has no attributes. The <asr-support>
+ element has one child element. The child element, <language>,
+
+
+
+Boulton, et al. Standards Track [Page 43]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ requests that the Media Server supports ASR for a specific
+ language. The <language> element has a single attribute,
+ 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
+ [ISO.639.2002] code of the supported language.
+
+ <tts-support>: Describes the available languages for TTS. The
+ <tts-support> element has no attributes. The <tts-support>
+ element has one child element. The child element, <language>,
+ requests that the Media Server supports TTS for a specific
+ language. The <language> element has a single attribute,
+ 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1
+ [ISO.639.2002] code of the supported language.
+
+5.2.5.1.2.6. <vxml>
+
+ The <vxml> element specifies if the Consumer client requires VoiceXML
+ and, if so, which protocols are supported (e.g., via the control
+ framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]). The element
+ MAY be present.
+
+ The <vxml> element has a single child element:
+
+ <vxml-mode>: Has two attributes: 'package' and 'require'. The
+ 'package' attribute provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the VXML support applies. The 'require' attribute specifies
+ the type of VXML support required by the Consumer client (e.g.,
+ RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]),
+ and valid values are case-insensitive RFC references (e.g.,
+ "rfc6231" to specify that the client requests support for VoiceXML
+ as provided by the IVR Package [RFC6231]).
+
+ The presence of at least one <vxml> child element would indicate that
+ the Consumer client requires VXML support as specified by the child
+ element itself. An empty <vxml> element would otherwise indicate
+ that the Consumer client does not require VXML support.
+
+5.2.5.1.2.7. <location>
+
+ The <location> element requests a civic location for an IVR Media
+ Server. The request makes use of the Civic Address Schema
+ standardized in RFC 5139 [RFC5139]. The element MAY be present.
+ More precisely, this section is entirely optional and is
+ implementation specific in its level of population.
+
+ The <location> element has no attributes.
+
+
+
+
+
+Boulton, et al. Standards Track [Page 44]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <location> element has a single child element:
+
+ <civicAddress>: Describes the civic address location of the
+ requested Media Server, whose representation refers to Section 4
+ of RFC 5139 [RFC5139].
+
+5.2.5.1.2.8. <encryption>
+
+ The <encryption> element allows a Consumer client to request support
+ for encrypting RTP media streams using RFC 3711 [RFC3711]. The
+ element MAY be present. If the element is present, then the Media
+ Server supports DTLS-SRTP [RFC5763].
+
+ The <encryption> element has no attributes.
+
+ The <encryption> element has no child elements.
+
+5.2.5.1.2.9. <application-data>
+
+ The <application-data> element provides an arbitrary string of
+ characters as IVR application-level data. This data is meant to only
+ have meaning at the application-level logic and as such is not
+ otherwise restricted by this specification. The set of allowed
+ characters is the same as those in XML (viz., tab, carriage return,
+ line feed, and the legal characters of Unicode and ISO/IEC 10646
+ [ISO.10646.2012] (see also Section 2.2 of
+ <http://www.w3.org/TR/xml/>)). The element MAY be present.
+
+ The <application-data> element has no attributes.
+
+ The <application-data> element has no child elements.
+
+5.2.5.1.2.10. <max-prepared-duration>
+
+ The <max-prepared-duration> element indicates the amount of time
+ required by the Consumer client representing media dialog preparation
+ in the system before it is executed. The element MAY be present.
+
+ The <max-prepared-duration> element has no attributes.
+
+ The <max-prepared-duration> element has a single child element:
+
+ <max-time>: Has a single attribute, 'max-time-seconds', which
+ provides the amount of time in seconds that a media dialog can be
+ in the prepared state. The <max-time> element then has a further
+ child element, <max-time-package>. The <max-time-package> element
+
+
+
+
+
+Boulton, et al. Standards Track [Page 45]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the time
+ period applies.
+
+5.2.5.1.2.11. <file-transfer-modes>
+
+ The <file-transfer-modes> element allows the Consumer client to
+ specify which scheme names are required for file transfer to a Media
+ Server for each Media Control Channel Framework package type. For
+ example, does the Media Server support fetching media resources via
+ HTTP, HTTPS, NFS, etc.? The element MAY be present.
+
+ The <file-transfer-modes> element has no attributes.
+
+ The <file-transfer-modes> element has a single child element:
+
+ <file-transfer-mode>: Has two attributes: 'name' and 'package'. The
+ 'name' attribute provides the scheme name of the protocol required
+ for fetching resources: valid values are case-insensitive scheme
+ names (e.g., HTTP, HTTPS, NFS, etc.). The 'package' attribute
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the scheme
+ name applies.
+
+ The same considerations relating to file transfer and live streaming
+ are explained further in Section 5.1.5.15 and apply here as well.
+
+5.2.5.1.3. <mixerInfo>
+
+ The <mixerInfo> element provides information for general Consumer
+ request information that is mixer specific. The following
+ sub-sections describe the elements of the <mixerInfo> element:
+ <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>,
+ <application-data>, <location>, and <encryption>.
+
+5.2.5.1.3.1. <mixers>
+
+ The <mixers> element provides information detailing the required
+ mixed RTP sessions. The element MAY be present.
+
+ The <mixers> element has no attributes.
+
+ The <mixers> element has a single child element:
+
+ <mix>: Describes the required mixed RTP sessions. The <mix> element
+ has one attribute. The value of the attribute, 'users', is the
+ number of participants required in the mix. The <mix> element has
+
+
+
+
+Boulton, et al. Standards Track [Page 46]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ one child element. The child element, <rtp-codec>, contains the
+ same information relating to RTP sessions as that defined in
+ Section 5.1.5.3. The element MAY be present.
+
+5.2.5.1.3.2. <file-formats>
+
+ The <file-formats> element provides a list of file formats required
+ by the Consumer client for the purpose of playing media to a mix.
+ The element MAY be present.
+
+ The <file-formats> element has no attributes.
+
+ The <file-formats> element has a single child element:
+
+ <required-format>: Has a single attribute, 'name', which provides
+ the type of file format supported. A valid value is a media type
+ that, depending on its definition, can include additional
+ parameters (e.g., [RFC6381]). The <required-format> element has a
+ child element, <required-file-package>. The
+ <required-file-package> element contains a single attribute,
+ 'required-file-package-name', which contains the name of the Media
+ Control Channel Framework package, compliant with Section 13.1.1
+ of [RFC6230], for which the file format support applies.
+
+5.2.5.1.3.3. <dtmf>
+
+ The <dtmf> element specifies the required methods to detect DTMF
+ tones and to generate them in a mix. The element MAY be present.
+
+ The <dtmf> element has no attributes.
+
+ The <dtmf> element has zero or more of the following child elements:
+
+ <detect>: Indicates the required support for DTMF detection. The
+ <detect> element has no attributes. The <detect> element then has
+ a further child element, <dtmf-type>. The <dtmf-type> element has
+ two attributes: 'name' and 'package'. The 'name' attribute
+ provides the type of DTMF being used and is a case-insensitive
+ string containing either 'RFC4733' [RFC4733] or 'Media' (detecting
+ tones as signals from the audio stream). The 'package' attribute
+ provides the name of the Media Control Channel Framework package,
+ compliant with Section 13.1.1 of [RFC6230], for which the DTMF
+ type applies.
+
+ <generate>: Indicates the required support for DTMF generation. The
+ <generate> element has no attributes. The <generate> element has
+ a single child element, <dtmf-type>. The <dtmf-type> element has
+ two attributes: 'name' and 'package'. The 'name' attribute
+
+
+
+Boulton, et al. Standards Track [Page 47]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ provides the type of DTMF being used and is a case-insensitive
+ string containing either 'RFC4733' [RFC4733] or 'Media'
+ (generating tones as signals in the audio stream). The 'package'
+ attribute provides the name of the Media Control Channel Framework
+ package, compliant with Section 13.1.1 of [RFC6230], for which the
+ DTMF type applies.
+
+ <passthrough>: Indicates the required support for passing DTMF
+ through without re-encoding. The <passthrough> element has no
+ attributes. The <passthrough> element has a single child element,
+ <dtmf-type>. The <dtmf-type> element has two attributes: 'name'
+ and 'package'. The 'name' attribute provides the type of DTMF
+ being used and is a case-insensitive string containing either
+ 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through
+ the audio stream). The 'package' attribute provides the name of
+ the Media Control Channel Framework package, compliant with
+ Section 13.1.1 of [RFC6230], for which the DTMF type applies.
+
+5.2.5.1.3.4. <tones>
+
+ The <tones> element provides requested tones that a Media Server must
+ support for a mix. In particular, the request refers to both support
+ for country codes (ISO 3166-1 [ISO.3166-1]) and requested
+ functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The
+ element MAY be present.
+
+ The <tones> element has no attributes.
+
+ The <tones> element has zero or more of the following child elements:
+
+ <country-codes>: Describes the requested country codes in relation
+ to tones. The <country-codes> element has no attributes. The
+ <country-codes> element has a single child element. The child
+ element, <country-code>, requests a specific country code,
+ compliant with the ISO 3166-1 [ISO.3166-1] specification. The
+ <country-code> element has a single attribute, 'package'. The
+ attribute 'package' provides the name of the Media Control Channel
+ Framework package, compliant with the specification in the related
+ IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
+ specified country code are requested.
+
+ <h248-codes>: Describes the requested H.248 codes with respect to
+ tones. The <h248-codes> element has no attributes. The
+ <h248-codes> element has a single child element. The child
+ element, <h248-code>, requests a specific H.248 code, compliant
+ with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
+ The codes can be either specific (e.g., cg/dt to only report the
+ Dial Tone from the Call Progress Tones package) or generic (e.g.,
+
+
+
+Boulton, et al. Standards Track [Page 48]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ cg/* to report all the tones from the Call Progress Tones
+ package), using wildcards. The <h248-code> element has a single
+ attribute, 'package'. The attribute 'package' provides the name
+ of the Media Control Channel Framework package, compliant with
+ Section 13.1.1 of [RFC6230], in which the specified codes are
+ requested.
+
+5.2.5.1.3.5. <mixing-modes>
+
+ The <mixing-modes> element requests information relating to support
+ for audio and video mixing, more specifically a list of supported
+ algorithms to mix audio and a list of supported video presentation
+ layouts. The element MAY be present.
+
+ The <mixing-modes> element has no attributes.
+
+ The <mixing-modes> element has zero or more of the following child
+ elements:
+
+ <audio-mixing-modes>: Describes the requested algorithms for audio
+ mixing. The <audio-mixing-modes> element has no attributes. The
+ <audio-mixing-modes> element has one child element. The child
+ element, <audio-mixing-mode>, contains a requested mixing
+ algorithm. Valid values for the <audio-mixing-mode> element are
+ algorithm names, e.g., 'nbest' and 'controller' as defined in
+ [RFC6505]. The element has a single attribute, 'package'. The
+ attribute 'package' provides the name of the Media Control Channel
+ Framework package, compliant with Section 13.1.1 of [RFC6230], for
+ which the algorithm support is requested.
+
+ <video-mixing-modes>: Describes the requested video presentation
+ layouts for video mixing. The <video-mixing-modes> element has
+ two attributes: 'vas' and 'activespeakermix'. The 'vas' attribute
+ is of type boolean with a value of 'true' indicating that the
+ Consumer client requires automatic Voice Activated Switching. The
+ 'activespeakermix' attribute is of type boolean with a value of
+ 'true' indicating that the Consumer client requires an additional
+ video stream for the loudest speaker participant without its
+ contribution. The <video-mixing-modes> element has one child
+ element. The child element, <video-mixing-mode>, contains the
+ name of a specific video presentation layout. The name may refer
+ to one of the predefined video layouts defined in the XCON
+ conference information data model, or to non-XCON layouts as well,
+ as long as they are appropriately prefixed. The
+ <video-mixing-mode> element has a single attribute, 'package'.
+ The attribute 'package' provides the name of the Media Control
+ Channel Framework package, compliant with Section 13.1.1 of
+ [RFC6230], for which the algorithm support is requested.
+
+
+
+Boulton, et al. Standards Track [Page 49]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.5.1.3.6. <application-data>
+
+ The <application-data> element provides an arbitrary string of
+ characters as mixer application-level data. This data is meant to
+ only have meaning at the application-level logic and as such is not
+ otherwise restricted by this specification. The set of allowed
+ characters is the same as those in XML (viz., tab, carriage return,
+ line feed, and the legal characters of Unicode and ISO/IEC 10646
+ [ISO.10646.2012] (see also Section 2.2 of
+ <http://www.w3.org/TR/xml/>)). The element MAY be present.
+
+ The <application-data> element has no attributes.
+
+ The <application-data> element has no child elements.
+
+5.2.5.1.3.7. <location>
+
+ The <location> element requests a civic location for a mixer Media
+ Server. The request makes use of the Civic Address Schema
+ standardized in RFC 5139 [RFC5139]. The element MAY be present.
+ More precisely, this section is entirely optional, and it's
+ implementation specific to fill it with just the details each
+ implementer deems necessary for any optimization that may be needed.
+
+ The <location> element has no attributes.
+
+ The <location> element has a single child element:
+
+ <civicAddress>: Describes the civic address location of the
+ requested Media Server, whose representation refers to Section 4
+ of RFC 5139 [RFC5139].
+
+5.2.5.1.3.8. <encryption>
+
+ The <encryption> element allows a Consumer client to request support
+ for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. The
+ element MAY be present. If the element is present, then the Media
+ Server supports DTLS-SRTP [RFC5763].
+
+ The <encryption> element has no attributes.
+
+ The <encryption> element has no child elements.
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 50]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.2.6. Media Service Resource Response
+
+ This section provides the element definitions for use in Consumer
+ interface responses. The responses are carried in the
+ <mediaResourceResponse> element.
+
+5.2.6.1. <mediaResourceResponse>
+
+ The <mediaResourceResponse> element provides information for clients
+ receiving response information from an external MRB entity.
+
+ The <mediaResourceResponse> element has two mandatory attributes:
+ 'id' and 'status'. The 'id' attribute must contain the same value
+ that the client provided in the 'id' attribute in the
+ <mediaResourceRequest> to which the response is mapped. The 'status'
+ attribute indicates the status code of the operation. The following
+ status codes are defined for 'status':
+
+ +-----------+-------------------------------------------------------+
+ | code | description |
+ +-----------+-------------------------------------------------------+
+ | 200 | OK |
+ | | |
+ | 400 | Syntax error |
+ | | |
+ | 405 | Wrong sequence number |
+ | | |
+ | 408 | Unable to find Resource |
+ | | |
+ | 409 | Unable to update Resource |
+ | | |
+ | 410 | Unable to remove Resource |
+ | | |
+ | 420 | Unsupported attribute or element |
+ +-----------+-------------------------------------------------------+
+
+ Table 2: <mediaResourceResponse> Status Codes
+
+ If a new media resource request made by a client application has been
+ accepted, the MRB MUST reply with a <mediaResourceResponse> with
+ status code 200. The same rule applies whenever a request to update
+ (action='update') or remove (action='remove') an existing transaction
+ can be fulfilled by the MRB.
+
+ A media resource request, nevertheless, may fail for several reasons.
+ In such a case, the status codes defined in Table 2 must be used
+ instead. Specifically, if the MRB fails to handle a request due to a
+ syntax error in the request itself (e.g., incorrect XML, violation of
+
+
+
+Boulton, et al. Standards Track [Page 51]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ the schema constraints, or invalid values in any of the attributes/
+ elements), the MRB MUST reply with a <mediaResourceResponse> with
+ status code 400. If a syntactically correct request fails because
+ the request also includes any attribute/element the MRB doesn't
+ understand, the MRB MUST reply with a <mediaResourceResponse> with
+ status code 420. If a syntactically correct request fails because it
+ contains a wrong sequence number, that is, a 'seq' value not
+ consistent with the increment the MRB expects according to
+ Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with
+ status code 405. If a syntactically correct request fails because
+ the MRB couldn't find any Media Server able to fulfill the
+ requirements presented by the Application Server in its request, the
+ MRB MUST reply with a <mediaResourceResponse> with status code 408.
+ If a syntactically correct request fails because the MRB couldn't
+ update an existing request according to the new requirements
+ presented by the Application Server in its request, the MRB MUST
+ reply with a <mediaResourceResponse> with status code 409. If a
+ syntactically correct request fails because the MRB couldn't remove
+ an existing request and release the related resources as requested by
+ the Application Server, the MRB MUST reply with a
+ <mediaResourceResponse> with status code 410.
+
+ Further details on status codes 409 and 410 are included in
+ Section 5.2.3, where the leasing mechanism, along with its related
+ scenarios, is described in more detail.
+
+ The <mediaResourceResponse> element has <response-session-info> as a
+ child element. This element is used to describe the response of a
+ Consumer interface query and is covered in the following sub-section.
+
+5.2.6.1.1. <response-session-info>
+
+ The <response-session-info> element is included in Consumer
+ responses. This applies to responses to both requests for new
+ resources and requests to update an existing media resource session.
+ The ability to change and remove an existing media resource session
+ is described in more detail in Section 5.2.3. If the request was
+ successful, the <mediaResourceResponse> MUST have one
+ <response-session-info> child, which describes the media resource
+ session addressed by the request. If the request was not successful,
+ the <mediaResourceResponse> MUST NOT have a <response-session-info>
+ child.
+
+ The <response-session-info> element has no attributes.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 52]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The <response-session-info> element has zero or more of the following
+ child elements:
+
+ <session-id>: A unique identifier that explicitly references an
+ existing media resource session on the MRB. The identifier is
+ included to update the existing session and is described in more
+ detail in Section 5.2.3.
+
+ <seq>: Used in association with the <session-id> element in a
+ subsequent request to update an existing media resource session on
+ an MRB. The <seq> number is incremented from its original value
+ returned in response to the initial request for media resources.
+ More information on its use is provided in Section 5.2.3.
+
+ <expires>: Includes the number of seconds that the media resources
+ are reserved as part of this interaction. If the lease is not
+ refreshed before expiry, the MRB will reclaim the resources and
+ they will no longer be guaranteed. It is RECOMMENDED that a
+ minimum value of 300 seconds be used for the value of the
+ 'expires' attribute. It is also RECOMMENDED that a Consumer
+ 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
+ used. For example, if the timeout period is 300 seconds, the
+ Consumer client would refresh the transaction at 240 seconds.
+ More information on its use is provided in Section 5.2.3.
+
+ <media-server-address>: Provides information to reach the Media
+ Server handling the requested media resource. One or more
+ instances of these elements may appear. The
+ <media-server-address> element has a single attribute named 'uri',
+ which supplies a SIP URI that reaches the specified Media Server.
+ It also has three optional elements: <connection-id>,
+ <ivr-sessions>, and <mixers>. The <ivr-sessions> and <mixers>
+ elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1,
+ respectively, and have the same meaning but are applied to
+ individual Media Server instances as a subset of the overall
+ resources reported in the <connection-id> element. If multiple
+ Media Servers are assigned in an IAMM operation, exactly one
+ <media-server-address> element, more specifically the Media Server
+ that provided the media dialog or CFW response, will have a
+ <connection-id> element. Additional information relating to the
+ use of the <connection-id> element for media dialogs is included
+ in Section 6.
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 53]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+5.3. In-Line Unaware MRB Interface
+
+ 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 In-line Unaware MRB Mode
+ (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of
+ operation. This section further describes IUMM.
+
+ It should be noted that the introduction of an MRB entity into the
+ network, as specified in this document, requires interfaces to be
+ implemented by those requesting Media Server resources (for example,
+ an Application Server). This applies when using the Consumer
+ interface as discussed in Sections 5.2.1 (Query mode) and 5.2.2
+ (IAMM). An MRB entity can also act in a client-unaware mode when
+ deployed into the network. This allows any SIP-compliant client
+ entity, as defined by RFC 3261 [RFC3261] and its extensions, to send
+ requests to an MRB that in turn will select an appropriate Media
+ Server based on knowledge of Media Server resources it currently has
+ available transparently to the client entity. Using an MRB in this
+ mode allows for easy migration of current applications and services
+ that are unaware of the MRB concept and would simply require a
+ configuration change resulting in the MRB being set as a SIP outbound
+ proxy for clients requiring media services.
+
+ 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 the SIP dialog that initiated the request.
+
+ As with IAMM, in IUMM the SIP INVITE from the Application Server
+ could convey the application/sdp payload to either set up a media
+ dialog or a Control Framework Control Channel. In either case, in
+ order to permit the Application Server to associate a media dialog
+ with a Control Channel to the same Media Server, using the procedures
+ of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and
+ not a B2BUA). This allows the SIP URI of the targeted Media Server
+ to be transparently passed back to the Application Server in the SIP
+ response, resulting in a direct SIP dialog between the Application
+ Server and the Media Server.
+
+ While IUMM has the least impact on legacy Application Servers, it
+ also provides the least versatility. See Section 8.
+
+6. MRB Acting as a B2BUA
+
+ An MRB entity can act as a SIP Back-to-Back User Agent (B2BUA) or a
+ SIP Proxy Server as defined in RFC 3261 [RFC3261]. When an MRB acts
+ as a B2BUA, issues can arise when using Media Control Channel
+ packages such as the IVR [RFC6231] and mixer [RFC6505] packages.
+ Specifically, the framework attribute 'connectionid' as provided in
+
+
+
+Boulton, et al. Standards Track [Page 54]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Appendix A ("Common Package Components") of [RFC6230] 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' cannot be used as
+ intended due to this change. For this reason, when an MRB wishes to
+ act as a SIP B2BUA when handling a request from an Application Server
+ to set up a media dialog to a Media Server, it MUST include the
+ optional <connection-id> element in a Consumer interface response
+ with a value that provides 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 an HTTP
+ Consumer interface response.
+
+ It is important to point out that although more Media Server
+ instances may be returned in a Consumer response (i.e., the MRB has
+ assigned more than one Media Server to a Consumer request to fulfill
+ the Application Server requirements), in IAMM the MRB will only act
+ as a B2BUA with a single Media Server. In this case, exactly one
+ <media-server-address> element, describing the media dialog or CFW
+ response, will have a <connection-id> element that will not be
+ included in any additional <media-server-address> elements.
+
+7. Multimodal MRB Implementations
+
+ An MRB implementation may operate multimodally with a collection of
+ Application Server clients all sharing the same pool of media
+ resources. That is, an MRB may be simultaneously operating in Query
+ mode, IAMM, and IUMM. It knows in which mode to act on any
+ particular request from a client, depending on the context of the
+ request:
+
+ o If the received request is an HTTP POST message with application/
+ mrb-consumer+xml content, then the MRB processes it in Query mode.
+
+ o If the received request is a SIP INVITE with application/
+ mrb-consumer+xml content and application/sdp content, then the 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
+ the MRB processes it in IUMM.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 55]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+8. Relative Merits of Query Mode, IAMM, and IUMM
+
+ At a high level, the possible Application Server MRB interactions can
+ be distinguished by the following basic types:
+
+ a. Query mode - the client is requesting the assignment by the MRB
+ of suitable Media Server resources;
+
+ b. IAMM/media dialog - the client is requesting the assignment by
+ the MRB of suitable Media Server resources and the establishment
+ of a media dialog to one of the Media Servers;
+
+ c. IAMM/Control Channel - the client is requesting the assignment by
+ the MRB of suitable Media Server resources and the establishment
+ of a CFW Control Channel to one of the Media Servers;
+
+ d. IUMM/media dialog - the client is requesting the establishment of
+ a media dialog to a Media Server resource;
+
+ e. IUMM/Control Channel - the client is requesting the establishment
+ of a CFW Control Channel to a Media Server resource.
+
+ Each type of interaction has advantages and disadvantages, where such
+ considerations relate to the versatility of what the 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 provides a few observations on relative
+ merits but is not intended to be exhaustive. Some constraints of a
+ given interaction type may be subtle.
+
+ o Operation with other types of media control: Any of the types of
+ interactions work with the mechanisms described in RFC 4240
+ [RFC4240] and RFC 5552 [RFC5552] where initial control
+ instructions are conveyed in the SIP INVITE from the Application
+ Server for the media dialog to the Media Server and subsequent
+ instructions may be fetched using HTTP. Query mode (a), IAMM/
+ media dialog (b), and IUMM/media dialog (d) work with the Media
+ Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the
+ Media Server Control Markup Language (MSCML) as per RFC 5022
+ [RFC5022].
+
+ o As stated previously, IUMM has no interface impacts on an
+ Application Server. When using IUMM, the Application Server does
+ not specify the characteristics of the type of media resource it
+ requires, as the <mediaResourceRequest> element is not passed to
+
+
+
+Boulton, et al. Standards Track [Page 56]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ the MRB. For IUMM/media dialog (d), the MRB can deduce an
+ appropriate media resource on a best-effort basis using
+ information gleaned from examining information in the SIP INVITE.
+ This includes the SDP information for the media dialog, 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
+ media dialog to the Media Server should not be done using IUMM/
+ media dialog. That is, the SIP signaling to send the media dialog
+ to the selected Media Server must be directly between the
+ Application Server and that Media Server, and not through the MRB.
+ Unless resources can be confidentially identified, the MRB could
+ send the media dialog to a different Media Server. Likewise, if
+ using IUMM/media dialog (d), the subsequent establishment of a
+ Control Channel should not be done with IUMM/Control Channel (e)
+ unless definitive information is available.
+
+ o Query mode (a) and IAMM/Control Channel (c) lend themselves to
+ requesting a pool of media resources (e.g., a number of IVR or
+ conferencing ports) in advance of use and retaining use over a
+ period of time, independent of whether there are media dialogs to
+ those resources at any given moment, whereas the other types of
+ interactions do not. This also applies to 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 non-use 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 an 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 Application Server has a new request for an MRB for
+ media resources.
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 57]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+9. Examples
+
+ This section provides examples of both the Publish and Consumer
+ interfaces. Both the Query mode and In-line mode are addressed.
+
+ Note that due to RFC formatting conventions, this section often
+ splits HTTP, SIP/SDP, and CFW across lines whose content would exceed
+ 72 characters. A backslash character marks where this line folding
+ has taken place. This backslash, and its trailing CRLF and
+ whitespace, would not appear in the actual protocol contents. Also
+ note that the indentation of the XML content is only provided for
+ readability: actual messages will follow strict XML syntax, which
+ allows for but does not require indentation.
+
+9.1. Publish Example
+
+ The following example assumes that a Control Channel has been
+ established and synced as described in the Media Control Channel
+ Framework ([RFC6230]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 58]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Figure 9 shows the subscription/notification mechanism the Publish
+ interface is based on, as defined in Section 5.1. The MRB subscribes
+ for information at the Media Server (message A1.), and the Media
+ Server accepts the subscription (A2.). Notifications are triggered
+ by the Media Server (B1.) and acknowledged by the MRB (B2.).
+
+ MRB MS
+ | |
+ | A1. CONTROL (MRB subscription) |
+ |--------------------------------------------->|
+ | A2. 200 OK |
+ |<---------------------------------------------|
+ | |
+ . .
+ . .
+ | |
+ | |--+ collect
+ | | | up-to-date
+ | |<-+ info
+ | B1. CONTROL (MRB notification) |
+ |<---------------------------------------------|
+ | B2. 200 OK |
+ |--------------------------------------------->|
+ | |
+ . .
+ . .
+
+ Figure 9: Publish Example: Sequence Diagram
+
+ The rest of this section includes a full dump of the messages
+ associated with the previous sequence diagram, specifically:
+
+ 1. the subscription (A1.), in an <mrbrequest> (CFW CONTROL);
+
+ 2. the Media Server accepting the subscription (A2.), in an
+ <mrbresponse> (CFW 200);
+
+ 3. a notification (B1.), in an <mrbnotification> (CFW CONTROL);
+
+ 4. the ack to the notification (B2.), in a framework-level 200
+ message (CFW 200).
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 59]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+A1. MRB -> MS (CONTROL, publish request)
+----------------------------------------
+CFW lidc30BZObiC CONTROL
+Control-Package: mrb-publish/1.0
+Content-Type: application/mrb-publish+xml
+Content-Length: 337
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
+ <mrbrequest>
+ <subscription action="create" seqnumber="1" id="p0T65U">
+ <expires>600</expires>
+ <minfrequency>20</minfrequency>
+ <maxfrequency>20</maxfrequency>
+ </subscription>
+ </mrbrequest>
+</mrbpublish>
+
+
+A2. MRB <- MS (200 to CONTROL, request accepted)
+------------------------------------------------
+CFW lidc30BZObiC 200
+Timeout: 10
+Content-Type: application/mrb-publish+xml
+Content-Length: 139
+
+<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
+ <mrbresponse status="200" reason="OK: Request accepted"/>
+</mrbpublish>
+
+
+B1. MRB <- MS (CONTROL, event notification from MS)
+---------------------------------------------------
+CFW 03fff52e7b7a CONTROL
+Control-Package: mrb-publish/1.0
+Content-Type: application/mrb-publish+xml
+Content-Length: 4226
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <mrbpublish version="1.0"
+ xmlns="urn:ietf:params:xml:ns:mrb-publish">
+ <mrbnotification seqnumber="1" id="QQ6J3c">
+ <media-server-id>a1b2c3d4</media-server-id>
+ <supported-packages>
+ <package name="msc-ivr/1.0"/>
+ <package name="msc-mixer/1.0"/>
+
+
+
+
+
+Boulton, et al. Standards Track [Page 60]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <package name="mrb-publish/1.0"/>
+ <package name="msc-example-pkg/1.0"/>
+ </supported-packages>
+ <active-rtp-sessions>
+ <rtp-codec name="audio/basic">
+ <decoding>10</decoding>
+ <encoding>20</encoding>
+ </rtp-codec>
+ </active-rtp-sessions>
+ <active-mixer-sessions>
+ <active-mix conferenceid="7cfgs43">
+ <rtp-codec name="audio/basic">
+ <decoding>3</decoding>
+ <encoding>3</encoding>
+ </rtp-codec>
+ </active-mix>
+ </active-mixer-sessions>
+ <non-active-rtp-sessions>
+ <rtp-codec name="audio/basic">
+ <decoding>50</decoding>
+ <encoding>40</encoding>
+ </rtp-codec>
+ </non-active-rtp-sessions>
+ <non-active-mixer-sessions>
+ <non-active-mix available="15">
+ <rtp-codec name="audio/basic">
+ <decoding>15</decoding>
+ <encoding>15</encoding>
+ </rtp-codec>
+ </non-active-mix>
+ </non-active-mixer-sessions>
+ <media-server-status>active</media-server-status>
+ <supported-codecs>
+ <supported-codec name="audio/basic">
+ <supported-codec-package name="msc-ivr/1.0">
+ <supported-action>encoding</supported-action>
+ <supported-action>decoding</supported-action>
+ </supported-codec-package>
+ <supported-codec-package name="msc-mixer/1.0">
+ <supported-action>encoding</supported-action>
+ <supported-action>decoding</supported-action>
+ </supported-codec-package>
+ </supported-codec>
+ </supported-codecs>
+ <application-data>TestbedPrototype</application-data>
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 61]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <file-formats>
+ <supported-format name="audio/x-wav">
+ <supported-file-package>
+ msc-ivr/1.0
+ </supported-file-package>
+ </supported-format>
+ </file-formats>
+ <max-prepared-duration>
+ <max-time max-time-seconds="3600">
+ <max-time-package>msc-ivr/1.0</max-time-package>
+ </max-time>
+ </max-prepared-duration>
+ <dtmf-support>
+ <detect>
+ <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+ <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+ </detect>
+ <generate>
+ <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+ <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+ </generate>
+ <passthrough>
+ <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
+ <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
+ </passthrough>
+ </dtmf-support>
+ <mixing-modes>
+ <audio-mixing-modes>
+ <audio-mixing-mode package="msc-ivr/1.0">
+ nbest
+ </audio-mixing-mode>
+ </audio-mixing-modes>
+ <video-mixing-modes activespeakermix="true" vas="true">
+ <video-mixing-mode package="msc-mixer/1.0">
+ single-view
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ dual-view
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ dual-view-crop
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ dual-view-2x1
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ dual-view-2x1-crop
+ </video-mixing-mode>
+
+
+
+Boulton, et al. Standards Track [Page 62]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <video-mixing-mode package="msc-mixer/1.0">
+ quad-view
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ multiple-5x1
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ multiple-3x3
+ </video-mixing-mode>
+ <video-mixing-mode package="msc-mixer/1.0">
+ multiple-4x4
+ </video-mixing-mode>
+ </video-mixing-modes>
+ </mixing-modes>
+ <supported-tones>
+ <supported-country-codes>
+ <country-code package="msc-ivr/1.0">GB</country-code>
+ <country-code package="msc-ivr/1.0">IT</country-code>
+ <country-code package="msc-ivr/1.0">US</country-code>
+ </supported-country-codes>
+ <supported-h248-codes>
+ <h248-code package="msc-ivr/1.0">cg/*</h248-code>
+ <h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
+ <h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
+ <h248-code package="msc-mixer/1.0">conftn/*</h248-code>
+ </supported-h248-codes>
+ </supported-tones>
+ <file-transfer-modes>
+ <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+ </file-transfer-modes>
+ <asr-tts-support>
+ <asr-support>
+ <language xml:lang="en"/>
+ </asr-support>
+ <tts-support>
+ <language xml:lang="en"/>
+ </tts-support>
+ </asr-tts-support>
+ <vxml-support>
+ <vxml-mode package="msc-ivr/1.0" support="RFC6231"/>
+ </vxml-support>
+ <media-server-location>
+ <civicAddress xml:lang="it">
+ <country>IT</country>
+ <A1>Campania</A1>
+ <A3>Napoli</A3>
+ <A6>Via Claudio</A6>
+ <HNO>21</HNO>
+
+
+
+Boulton, et al. Standards Track [Page 63]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <LMK>University of Napoli Federico II</LMK>
+ <NAM>Dipartimento di Informatica e Sistemistica</NAM>
+ <PC>80210</PC>
+ </civicAddress>
+ </media-server-location>
+ <label>TestbedPrototype-01</label>
+ <media-server-address>sip:MS1@ms.example.net</media-server-address>
+ <encryption/>
+ </mrbnotification>
+ </mrbpublish>
+
+
+B2. MRB -> MS (200 to CONTROL)
+------------------------------
+CFW 03fff52e7b7a 200
+
+9.2. Consumer Examples
+
+ As specified in Section 5.2, the Consumer interface can be involved
+ in two different modes: Query and In-line aware. When in Query mode,
+ Consumer messages are transported in HTTP messages: an example of
+ such an approach is presented in Section 9.2.1. When in In-line
+ aware mode, messages are instead transported as part of SIP
+ negotiations: considering that SIP negotiations may be related to
+ either the creation of a Control Channel or to a User Agent Client
+ (UAC) media dialog, two separate examples of such an approach are
+ presented in Section 9.2.2.
+
+9.2.1. Query Example
+
+ The following example assumes that the interested Application Server
+ already knows the HTTP URL where an MRB is listening for Consumer
+ messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 64]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Figure 10 shows the HTTP-based transaction between the Application
+ Server (AS, as shown in the figure) and the MRB. The Application
+ Server sends a Consumer request as payload of an HTTP POST message
+ (1.), and the MRB provides an answer in an HTTP 200 OK message (2.).
+ Specifically, as will be shown in the examples, the Application
+ Server is interested in 100 IVR ports: the MRB finds two Media
+ Servers that can satisfy the request (one providing 60 ports and the
+ other providing 40 ports) and reports them to the Application Server.
+
+ AS MRB
+ | |
+ | 1. HTTP POST (Consumer request) |
+ |--------------------------------------------->|
+ | |
+ | |
+ | |--+ Parse request
+ | | | and see if any
+ | |<-+ MS applies
+ | |
+ | 2. 200 OK (Consumer response) |
+ |<---------------------------------------------|
+ | |
+ |--+ Parse response and |
+ | | start session (SIP/COMEDIA/CFW) |
+ |<-+ with first MS reported by MRB |
+ | |
+ . .
+ . .
+
+ Figure 10: Consumer Example (Query): Sequence Diagram
+
+ The rest of this section includes a full dump of the messages
+ associated with the previous sequence diagram, specifically:
+
+ 1. the Consumer request (1.), in a <mediaResourceRequest> (HTTP
+ POST, Content-Type 'application/mrb-consumer+xml');
+
+ 2. the Consumer response (2.), in a <mediaResourceResponse> (HTTP
+ 200 OK, Content-Type 'application/mrb-consumer+xml').
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 65]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+1. AS -> MRB (HTTP POST, Consumer request)
+------------------------------------------
+POST /Mrb/Consumer HTTP/1.1
+Content-Length: 893
+Content-Type: application/mrb-consumer+xml
+Host: mrb.example.net:8080
+Connection: Keep-Alive
+User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
+ <mediaResourceRequest id="gh11x23v">
+ <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>
+ <file-transfer-modes>
+ <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+ </file-transfer-modes>
+ </ivrInfo>
+ </mediaResourceRequest>
+</mrbconsumer>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 66]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+2. AS <- MRB (200 to POST, Consumer response)
+---------------------------------------------
+HTTP/1.1 200 OK
+X-Powered-By: Servlet/2.5
+Server: Sun GlassFish Communications Server 1.5
+Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
+Content-Length: 1133
+Date: Mon, 12 Apr 2011 14:59:26 GMT
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
+ <mediaResourceResponse reason="Resource found" status="200"
+ id="gh11x23v">
+ <response-session-info>
+ <session-id>5t3Y4IQ84gY1</session-id>
+ <seq>9</seq>
+ <expires>3600</expires>
+ <media-server-address
+ 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>
+ </response-session-info>
+ </mediaResourceResponse>
+</mrbconsumer>
+
+ As the example shows, the request and response are associated by
+ means of the 'id' attribute (id="gh11x23v"). The MRB has picked '9'
+ as the random sequence number that needs to be incremented by the
+ Application Server for the subsequent request associated with the
+ same session.
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 67]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The rest of the scenario is omitted for brevity. After having
+ received the 'mediaResourceResponse', the Application Server has the
+ URIs of two Media Servers able to fulfill its media requirements and
+ can start a control dialog with one or both of them.
+
+9.2.2. IAMM Examples
+
+ Two separate examples are presented for the IAMM case: in fact, IAMM
+ 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 media
+ dialog to attach to a Media Server. 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 behavior of the
+ involved parties may differ.
+
+9.2.2.1. IAMM Example: CFW-Based Approach
+
+ The following example assumes that the interested Application Server
+ already knows the SIP URI of an MRB.
+
+ Figure 11 shows the first approach, i.e., SIP-based transactions
+ between the Application Server, the MRB, and one Media Server that
+ the MRB chooses from the two that are allocated to fulfill the
+ request. The diagram is more complex than before. This is basically
+ a scenario envisaging the MRB as a B2BUA. The Application Server
+ sends a SIP INVITE (1.) containing both a CFW-related SDP and a
+ Consumer request (multipart body). The MRB sends a provisional
+ response to the Application Server (2.) and starts working on the
+ request. First of all, it makes use of the Consumer request from the
+ Application Server to determine which Media Servers should be
+ exploited. Once the right Media Servers have been chosen (MS1 and
+ MS2 in the example), the MRB sends a new SIP INVITE (3.) to one of
+ the Media Servers (MS1 in the example) by just including the SDP part
+ of the original request. That Media Server negotiates this INVITE as
+ specified in [RFC6230] (4., 5., 6.), providing the MRB with its own
+ CFW-related SDP. The MRB replies to the original Application Server
+ INVITE preparing a SIP 200 OK with another multipart body (7.): this
+ multipart body includes the Consumer response used by the MRB to
+ determine the right Media Servers and the SDP returned by the Media
+ Server (MS1) in (5.). The Application Server finally acknowledges
+ the 200 OK (8.), and can start a CFW connection towards that Media
+ Server (MS1). Since the MRB provided the Application Server with two
+ Media Server instances to fulfill its requirements, the Application
+ Server can use the URI in the <media-server-address> element in the
+ <mediaResourceResponse> that describes the other Media Server to
+ establish a CFW channel with that Media Server (MS2) as well.
+
+
+
+
+Boulton, et al. Standards Track [Page 68]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 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.
+
+ AS MRB MS1 MS2
+ | | | |
+ | 1. INVITE | | |
+ | (multipart/mixed) | | |
+ |---------------------->| | |
+ | 2. 100 (Trying) | | |
+ |<----------------------| | |
+ | |--+ Extract SDP and | |
+ | | | MRB payloads; handle | |
+ | |<-+ Consumer request to | |
+ | | pick MSs (MS1 and MS2) | |
+ | | | |
+ | | 3. INVITE | |
+ | | (only copy SDP from 1.) | |
+ | |-------------------------->| |
+ | | 4. 100 (Trying) | |
+ | |<--------------------------| |
+ | | |--+ Negotiate |
+ | | | | CFW Control |
+ | | |<-+ Channel |
+ | | 5. 200 OK | |
+ | |<--------------------------| |
+ | | 6. ACK | |
+ | |-------------------------->| |
+ | Prepare new +--| | |
+ | payload with | | | |
+ | SDP from MS and +->| | |
+ | Consumer reply | | |
+ | | | |
+ | 7. 200 OK | | |
+ | (multipart/mixed) | | |
+ |<----------------------| | |
+ | 8. ACK | | |
+ |---------------------->| | |
+ | | | |
+ |--+ Read Cons. reply | | |
+ | | and use SDP to | | |
+ |<-+ create CFW Chn. | | |
+ | | | |
+ | | |
+ | Create TCP CFW channel towards MS1 (if needed) | |
+ |-------------------------------------------------->| |
+ | | |
+
+
+
+Boulton, et al. Standards Track [Page 69]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ |<<############## TCP CONNECTION #################>>| |
+ | | |
+ | CFW SYNC | |
+ |++++++++++++++++++++++++++++++++++++++++++++++++++>| |
+ | | |
+ . . . .
+ . . . .
+ | | |
+ | Negotiate SIP control dialog with MS2 |
+ |<------------------------------------------------------------------>|
+ | Create TCP CFW channel towards MS2 as well (if needed) |
+ |------------------------------------------------------------------->|
+ | |
+ |<<######################## TCP CONNECTION ########################>>|
+ | |
+ | CFW SYNC |
+ |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
+ | |
+ | | | |
+ . . . .
+ . . . .
+
+ Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram
+
+ The rest of this section includes an almost full trace of the
+ messages associated with the previous sequence diagram. Only the
+ relevant SIP messages are shown (both the INVITEs and the 200 OKs),
+ and only the relevant headers are preserved for brevity (Content-Type
+ and multipart-related information). Specifically:
+
+ 1. the original INVITE (1.) containing both a CFW-related SDP
+ (Connection-Oriented Media (COMEDIA) information to negotiate a
+ new Control Channel) and a Consumer <mediaResourceRequest>;
+
+ 2. the INVITE sent by the MRB (acting as a B2BUA) to the Media
+ Server (3.), containing only the CFW-related SDP from the
+ original INVITE;
+
+ 3. the 200 OK sent by the Media Server back to the MRB (5.) to
+ complete the CFW-related negotiation (SDP only);
+
+ 4. the 200 OK sent by the MRB back to the Application Server in
+ response to the original INVITE (7.), containing both the
+ CFW-related information sent by the Media Server and a Consumer
+ <mediaResourceRequest> documenting the MRB's decision to use that
+ Media Server.
+
+
+
+
+
+Boulton, et al. Standards Track [Page 70]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+1. AS -> MRB (INVITE multipart/mixed)
+-------------------------------------
+ [..]
+ Content-Type: multipart/mixed;boundary="=_Part"
+
+ =_Part
+ Content-Type: application/sdp
+
+ v=0
+ o=- 2890844526 2890842807 IN IP4 as.example.com
+ s=MediaCtrl
+ c=IN IP4 as.example.com
+ t=0 0
+ m=application 48035 TCP cfw
+ a=connection:new
+ a=setup:active
+ a=cfw-id:vF0zD4xzUAW9
+ a=ctrl-package:msc-mixer/1.0
+ a=ctrl-package:msc-ivr/1.0
+
+ =_Part
+ 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 id="pz78hnq1">
+ <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>
+ <file-transfer-modes>
+ <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+ </file-transfer-modes>
+ </ivrInfo>
+ </mediaResourceRequest>
+
+
+
+Boulton, et al. Standards Track [Page 71]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </mrbconsumer>
+
+ =_Part
+
+
+3. MRB -> MS (INVITE sdp only)
+------------------------------
+ [..]
+ Content-Type: application/sdp
+
+ v=0
+ o=- 2890844526 2890842807 IN IP4 as.example.com
+ s=MediaCtrl
+ c=IN IP4 as.example.com
+ t=0 0
+ m=application 48035 TCP cfw
+ a=connection:new
+ a=setup:active
+ a=cfw-id:vF0zD4xzUAW9
+ a=ctrl-package:msc-mixer/1.0
+ a=ctrl-package:msc-ivr/1.0
+
+
+5. MRB <- MS (200 OK sdp)
+-------------------------
+ [..]
+ Content-Type: application/sdp
+
+ v=0
+ o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
+ s=MediaCtrl
+ c=IN IP4 ms.example.net
+ t=0 0
+ m=application 7575 TCP cfw
+ a=connection:new
+ a=setup:passive
+ a=cfw-id:vF0zD4xzUAW9
+ a=ctrl-package:msc-mixer/1.0
+ a=ctrl-package:msc-ivr/1.0
+ a=ctrl-package:mrb-publish/1.0
+ a=ctrl-package:msc-example-pkg/1.0
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 72]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+7. AS <- MRB (200 OK multipart/mixed)
+-------------------------------------
+ [..]
+ Content-Type: multipart/mixed;boundary="=_Part"
+
+ =_Part
+ Content-Type: application/sdp
+
+ v=0
+ o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
+ s=MediaCtrl
+ c=IN IP4 ms.example.net
+ t=0 0
+ m=application 7575 TCP cfw
+ a=connection:new
+ a=setup:passive
+ a=cfw-id:vF0zD4xzUAW9
+ a=ctrl-package:msc-mixer/1.0
+ a=ctrl-package:msc-ivr/1.0
+ a=ctrl-package:mrb-publish/1.0
+ a=ctrl-package:msc-example-pkg/1.0
+
+ =_Part
+ 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"
+ id="pz78hnq1">
+ <response-session-info>
+ <session-id>z1skKYZQ3eFu</session-id>
+ <seq>9</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">
+
+
+
+Boulton, et al. Standards Track [Page 73]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <decoding>40</decoding>
+ <encoding>40</encoding>
+ </rtp-codec>
+ </ivr-sessions>
+ </media-server-address>
+ </response-session-info>
+ </mediaResourceResponse>
+ </mrbconsumer>
+
+ =_Part
+
+ As the previous example illustrates, the only difference in the
+ response that the MRB provides to the Application Server is in the
+ 'connection-id' attribute that is added to the first allocated Media
+ Server instance: this allows the Application Server to understand
+ that the MRB has sent the CFW channel negotiation to that specific
+ Media Server and that the connection-id to be used is the one
+ provided. This will be described in more detail in the following
+ section for the media dialog-based approach.
+
+ The continuation of the scenario (the Application Server connecting
+ to MS1 to start the Control Channel and the related SYNC message, the
+ Application Server connecting to MS2 as well later on, all the media
+ dialogs being attached to either Media Server) is omitted for
+ brevity.
+
+9.2.2.2. IAMM Example: Media Dialog-Based Approach
+
+ The following example assumes that the interested Application Server
+ already knows the SIP URI of an MRB.
+
+ Figure 12 shows the second approach, i.e., SIP-based transactions
+ between a SIP client, the Application Server, the MRB, and the Media
+ Server that the MRB chooses. The interaction is basically the same
+ as previous examples (e.g., contents of the multipart body), but
+ considering that 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 Application Server, since it is interested to its services (1.).
+ The Application Server sends a provisional response (2.) and, since
+ it doesn't have the resources yet, sends to the MRB a new SIP INVITE
+ (3.) containing both the UAC media-related SDP and a Consumer request
+ (multipart body). The MRB sends a provisional response to the
+ Application Server (4.) and starts working on the request. First of
+ all, it makes use of the Consumer request from the Application Server
+ to determine which Media Servers should be chosen. Once the Media
+ Server has been chosen, the MRB sends a new SIP INVITE to one of the
+ Media Servers by including the SDP part of the original request (5.).
+
+
+
+Boulton, et al. Standards Track [Page 74]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ The Media Server negotiates this INVITE as specified in [RFC6230]
+ (6., 7., 8.) to allocate the needed media resources to handle the new
+ media dialog, eventually providing the MRB with its own media-related
+ SDP. The MRB replies to the original Application Server INVITE
+ preparing a SIP 200 OK with a multipart body (9.): this multipart
+ body includes the Consumer response from the MRB indicating the
+ chosen Media Servers and the SDP returned by the Media Server in
+ (7.). The Application Server finally acknowledges the 200 OK (10.)
+ and ends the scenario by eventually providing the UAC with the SDP it
+ needs to set up the RTP channels with the chosen Media Server: a
+ separate direct SIP control dialog may be initiated by the
+ Application Server to the same Media Server in order to set up a
+ Control Channel to manipulate the media dialog.
+
+ As with the IAMM/Control Channel example in the prior section, this
+ example has the MRB selecting Media Server resources across two Media
+ Server instances. The convention could be that the MRB sent the SIP
+ INVITE to the first Media Server in the list provided to the
+ Application Server in the Consumer response information. For the
+ sake of brevity, considerations related to connecting to the other
+ Media Servers as well are omitted, since they have already been
+ addressed in the previous section.
+
+ Please note that to ease the reading of the protocol contents, a
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 75]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 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 media dialog | |
+ | | | (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 | | |
+ |-------------->| | |
+
+
+
+Boulton, et al. Standards Track [Page 76]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ | | | |
+ |<<*************************** RTP *******************************>>|
+ | | | |
+ | |--+ Negotiate | |
+ | | | CFW channel | |
+ | |<-+ towards MS | |
+ | | (if needed) | |
+ . . . .
+ . . . .
+ | | | |
+ | | |
+ | | Create TCP CFW channel towards MS (if needed) |
+ | |-------------------------------------------------->|
+ | | |
+ | |<<############## TCP CONNECTION #################>>|
+ | | |
+ | | CFW SYNC |
+ | |++++++++++++++++++++++++++++++++++++++++++++++++++>|
+ | | |
+ . . . .
+ . . . .
+
+ Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram
+
+ The rest of this section includes a trace 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 INVITE sent by the AS to the MRB (3.), containing both the
+ media-related SDP and a Consumer <mediaResourceRequest>;
+
+ 3. the INVITE sent by the MRB (acting as a B2BUA) to the Media
+ Server (5.), containing only the media-related SDP from the
+ original INVITE;
+
+ 4. the 200 OK sent by the Media Server back to the MRB (7.) to
+ complete the media-related negotiation (SDP only);
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 77]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 5. the 200 OK sent by the MRB back to the Application Server in
+ response to the original INVITE (9.), containing both the
+ media-related information sent by the Media Server and a Consumer
+ <mediaResourceRequest> documenting the MRB's decision to use that
+ Media Server;
+
+ 6. the 200 OK sent by the Application Server back to the UAC to have
+ it set up the RTP channel(s) with the Media Server (11.).
+
+
+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 203.0.113.2
+ s=A conversation
+ c=IN IP4 203.0.113.2
+ 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 203.0.113.2
+ s=A conversation
+ c=IN IP4 203.0.113.2
+ t=0 0
+
+
+
+Boulton, et al. Standards Track [Page 78]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ 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 id="ns56g1x0">
+ <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>
+ <file-transfer-modes>
+ <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
+ </file-transfer-modes>
+ </ivrInfo>
+ </mediaResourceRequest>
+ </mrbconsumer>
+
+ =_Part
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 79]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+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 203.0.113.2
+ s=A conversation
+ c=IN IP4 203.0.113.2
+ 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 203.0.113.1
+ s=MediaCtrl
+ c=IN IP4 203.0.113.1
+ 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
+
+
+
+
+Boulton, et al. Standards Track [Page 80]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+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 203.0.113.1
+ s=MediaCtrl
+ c=IN IP4 203.0.113.1
+ 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"
+ id="ns56g1x0">
+ <response-session-info>
+ <session-id>z1skKYZQ3eFu</session-id>
+ <seq>9</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>
+
+
+
+Boulton, et al. Standards Track [Page 81]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </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 203.0.113.1
+ s=MediaCtrl
+ c=IN IP4 203.0.113.1
+ 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 the examples illustrate, as in the IAMM/Control Channel example,
+ the MRB provides the Application Server with a <media-server-address>
+ element in the Consumer response: the 'uri' attribute identifies the
+
+
+
+Boulton, et al. Standards Track [Page 82]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ specific Media Server to which the MRB has sent the SDP media
+ negotiation, and the 'connection-id' enables the Application Server
+ to identify to the Media Server the dialog between the MRB and Media
+ Server. This attribute is needed, since according to the framework
+ specification [RFC6230] the connection-id is built out of the From/To
+ tags of the dialog between the MRB and Media Server; since the MRB
+ acts as a B2BUA in this scenario, without that attribute the
+ Application Server does not know the relevant tags, thus preventing
+ the CFW protocol from working as expected.
+
+ The continuation of the scenario (the Application Server connecting
+ to the Media Server to start the Control Channel, the SYNC message,
+ etc.) is omitted for brevity.
+
+10. Media Service Resource Publisher Interface XML Schema
+
+ This section gives the XML Schema Definition
+ [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
+ "application/mrb-publish+xml" format.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
+ elementFormDefault="qualified" blockDefault="#all"
+ xmlns="urn:ietf:params:xml:ns:mrb-publish"
+ xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
+ xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+
+ <xsd:annotation>
+ <xsd:documentation>
+ IETF MediaCtrl MRB 1.0
+
+ This is the schema of the IETF MediaCtrl MRB package.
+
+ The schema namespace is urn:ietf:params:xml:ns:mrb-publish
+
+ </xsd:documentation>
+ </xsd:annotation>
+
+
+ <!--
+ #############################################################
+
+ SCHEMA IMPORTS
+
+ #############################################################
+ -->
+
+
+
+
+Boulton, et al. Standards Track [Page 83]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd">
+ <xsd:annotation>
+ <xsd:documentation>
+ This import brings in the XML attributes for
+ xml:base, xml:lang, etc.
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+ namespace="urn:ietf:params:xml:ns:control:framework-attributes"
+ schemaLocation="framework.xsd">
+ <xsd:annotation>
+ <xsd:documentation>
+ This import brings in the framework attributes for
+ conferenceid and connectionid.
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+ namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ schemaLocation="civicAddress.xsd">
+ <xsd:annotation>
+ <xsd:documentation>
+ This import brings in the civicAddress specification
+ from RFC 5139.
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:import>
+
+<!--
+ #####################################################
+
+ Extensible core type
+
+ #####################################################
+ -->
+
+ <xsd:complexType name="Tcore">
+ <xsd:annotation>
+ <xsd:documentation>
+ This type is extended by other (non-mixed) component types to
+ allow attributes from other namespaces.
+ </xsd:documentation>
+ </xsd:annotation>
+
+
+
+
+Boulton, et al. Standards Track [Page 84]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:sequence/>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:complexType>
+
+
+<!--
+ #####################################################
+
+ TOP-LEVEL ELEMENT: mrbpublish
+
+ #####################################################
+ -->
+
+<xsd:complexType name="mrbpublishType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:choice>
+ <xsd:element ref="mrbrequest" />
+ <xsd:element ref="mrbresponse" />
+ <xsd:element ref="mrbnotification" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:choice>
+ </xsd:sequence>
+ <xsd:attribute name="version" type="version.datatype"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mrbpublish" type="mrbpublishType" />
+
+<!--
+ #####################################################
+
+ mrbrequest TYPE
+
+ #####################################################
+ -->
+
+<!-- mrbrequest -->
+
+ <xsd:complexType name="mrbrequestType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+
+
+
+Boulton, et al. Standards Track [Page 85]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:element ref="subscription" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mrbrequest" type="mrbrequestType" />
+
+<!-- subscription -->
+
+<xsd:complexType name="subscriptionType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="expires" type="xsd:nonNegativeInteger"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element name="minfrequency" type="xsd:nonNegativeInteger"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element name="maxfrequency" type="xsd:nonNegativeInteger"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="id" type="id.datatype" use="required" />
+ <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
+ use="required" />
+ <xsd:attribute name="action" type="action.datatype"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="subscription" type="subscriptionType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 86]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!--
+ #####################################################
+
+ mrbresponse TYPE
+
+ #####################################################
+ -->
+
+<!-- mrbresponse -->
+
+ <xsd:complexType name="mrbresponseType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="status" type="status.datatype"
+ use="required" />
+ <xsd:attribute name="reason" type="xsd:string" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+
+ <xsd:element name="mrbresponse" type="mrbresponseType" />
+
+<!--
+ #####################################################
+
+ mrbnotification TYPE
+
+ #####################################################
+ -->
+
+<!-- mrbnotification -->
+
+<xsd:complexType name="mrbnotificationType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="media-server-id"
+ type="subscriptionid.datatype"/>
+ <xsd:element ref="supported-packages" minOccurs="0" />
+ <xsd:element ref="active-rtp-sessions" minOccurs="0" />
+ <xsd:element ref="active-mixer-sessions" minOccurs="0" />
+
+
+
+Boulton, et al. Standards Track [Page 87]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
+ <xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
+ <xsd:element ref="media-server-status" minOccurs="0" />
+ <xsd:element ref="supported-codecs" minOccurs="0" />
+ <xsd:element ref="application-data" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:element ref="file-formats" minOccurs="0" />
+ <xsd:element ref="max-prepared-duration" minOccurs="0" />
+ <xsd:element ref="dtmf-support" minOccurs="0" />
+ <xsd:element ref="mixing-modes" minOccurs="0" />
+ <xsd:element ref="supported-tones" minOccurs="0" />
+ <xsd:element ref="file-transfer-modes" minOccurs="0" />
+ <xsd:element ref="asr-tts-support" minOccurs="0" />
+ <xsd:element ref="vxml-support" minOccurs="0" />
+ <xsd:element ref="media-server-location" minOccurs="0" />
+ <xsd:element ref="label" minOccurs="0" />
+ <xsd:element ref="media-server-address" minOccurs="0" />
+ <xsd:element ref="encryption" minOccurs="0" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="id" type="subscriptionid.datatype"
+ use="required" />
+ <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mrbnotification" type="mrbnotificationType" />
+
+
+<!-- supported-packages -->
+
+ <xsd:complexType name="supported-packagesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="package" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+
+
+Boulton, et al. Standards Track [Page 88]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<xsd:element name="supported-packages" type="supported-packagesType"/>
+
+
+ <xsd:complexType name="packageType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="package" type="packageType" />
+
+
+<!-- active-rtp-sessions -->
+
+ <xsd:complexType name="active-rtp-sessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
+
+
+ <xsd:complexType name="rtp-codecType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
+ <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+
+
+
+Boulton, et al. Standards Track [Page 89]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="rtp-codec" type="rtp-codecType" />
+
+
+<!-- active-mixer-sessions -->
+
+<xsd:complexType name="active-mixer-sessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="active-mix" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="active-mixer-sessions"
+ type="active-mixer-sessionsType" />
+
+
+<xsd:complexType name="active-mixType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attributeGroup ref="fw:framework-attributes" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="active-mix" type="active-mixType" />
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 90]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!-- non-active-rtp-sessions -->
+
+<xsd:complexType name="non-active-rtp-sessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="non-active-rtp-sessions"
+ type="non-active-rtp-sessionsType" />
+
+<!-- non-active-mixer-sessions -->
+
+<xsd:complexType name="non-active-mixer-sessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="non-active-mix" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="non-active-mixer-sessions"
+ type="non-active-mixer-sessionsType" />
+
+ <xsd:complexType name="non-active-mixType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="available" type="xsd:nonNegativeInteger"
+ use="required" />
+
+
+
+Boulton, et al. Standards Track [Page 91]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="non-active-mix" type="non-active-mixType" />
+
+<!-- media-server-status -->
+
+ <xsd:element name="media-server-status" type="msstatus.datatype" />
+
+<!-- supported-codecs -->
+
+<xsd:complexType name="supported-codecsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="supported-codec"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-codecs" type="supported-codecsType" />
+
+ <xsd:complexType name="supported-codecType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="supported-codec-package"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-codec" type="supported-codecType" />
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 92]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:complexType name="supported-codec-packageType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="supported-action" type="actions.datatype"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-codec-package"
+ type="supported-codec-packageType" />
+
+
+<!-- application-data -->
+
+<xsd:element name="application-data" type="appdata.datatype" />
+
+<!-- file-formats -->
+
+<xsd:complexType name="file-formatsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="supported-format"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="file-formats" type="file-formatsType" />
+
+ <xsd:complexType name="supported-formatType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="supported-file-package"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+
+
+
+Boulton, et al. Standards Track [Page 93]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="supported-format" type="supported-formatType" />
+
+ <xsd:element name="supported-file-package"
+ type="xsd:string" />
+
+<!-- max-prepared-duration -->
+
+<xsd:complexType name="max-prepared-durationType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="max-time" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="max-prepared-duration"
+ type="max-prepared-durationType" />
+
+
+ <xsd:complexType name="max-timeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="max-time-package" type="xsd:string" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="max-time" type="max-timeType" />
+
+
+
+Boulton, et al. Standards Track [Page 94]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!-- dtmf-support -->
+
+<xsd:complexType name="dtmf-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="detect" />
+ <xsd:element ref="generate" />
+ <xsd:element ref="passthrough" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="dtmf-support" type="dtmf-supportType" />
+
+ <xsd:complexType name="detectType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="detect" type="detectType" />
+
+ <xsd:complexType name="generateType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+
+
+Boulton, et al. Standards Track [Page 95]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:element name="generate" type="generateType" />
+
+ <xsd:complexType name="passthroughType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="passthrough" type="passthroughType" />
+
+
+ <xsd:complexType name="dtmf-typeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="dtmf.datatype" use="required" />
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="dtmf-type" type="dtmf-typeType" />
+
+
+<!-- mixing-modes -->
+
+<xsd:complexType name="mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="audio-mixing-modes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="video-mixing-modes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 96]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixing-modes" type="mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="audio-mixing-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
+
+<xsd:complexType name="video-mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="video-mixing-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="vas" type="boolean.datatype"
+ default="false" />
+ <xsd:attribute name="activespeakermix" type="boolean.datatype"
+ default="false" />
+
+
+
+Boulton, et al. Standards Track [Page 97]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
+
+<xsd:complexType name="video-mixing-modeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
+
+
+<!-- supported-tones -->
+
+<xsd:complexType name="supported-tonesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="supported-country-codes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="supported-h248-codes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-tones" type="supported-tonesType" />
+
+<xsd:complexType name="supported-country-codesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="country-code"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+
+
+
+Boulton, et al. Standards Track [Page 98]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-country-codes"
+ type="supported-country-codesType" />
+
+<xsd:complexType name="country-codeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="country-code" type="country-codeType" />
+
+<xsd:complexType name="supported-h248-codesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="h248-code"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="supported-h248-codes"
+ type="supported-h248-codesType" />
+
+<xsd:complexType name="h248-codeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="h248-code" type="h248-codeType" />
+
+
+
+
+
+Boulton, et al. Standards Track [Page 99]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!-- file-transfer-modes -->
+
+ <xsd:complexType name="file-transfer-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="file-transfer-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="file-transfer-modes"
+ type="file-transfer-modesType" />
+
+ <xsd:complexType name="file-transfer-modeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="transfermode.datatype"
+ use="required" />
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+ <xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
+
+
+<!-- asr-tts-support -->
+
+<xsd:complexType name="asr-tts-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="asr-support"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="tts-support"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 100]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
+
+<xsd:complexType name="asr-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="language"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-support" type="asr-supportType" />
+
+<xsd:complexType name="tts-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="language"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tts-support" type="tts-supportType" />
+
+<xsd:complexType name="languageType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute ref="xml:lang" />
+
+
+
+Boulton, et al. Standards Track [Page 101]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="language" type="languageType" />
+
+
+<!-- media-server-location -->
+
+<xsd:complexType name="media-server-locationType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="civicAddress" type="ca:civicAddress"
+ minOccurs="1" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="media-server-location"
+ type="media-server-locationType" />
+
+
+<!-- vxml-support -->
+
+ <xsd:complexType name="vxml-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="vxml-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="vxml-support" type="vxml-supportType" />
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 102]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:complexType name="vxml-modeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:attribute name="support" type="vxml.datatype" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="vxml-mode" type="vxml-modeType" />
+
+
+<!-- label -->
+
+ <xsd:element name="label" type="label.datatype" />
+
+
+<!-- media-server-address -->
+
+ <xsd:element name="media-server-address" type="xsd:anyURI" />
+
+<!-- encryption -->
+
+ <xsd:complexType name="encryptionType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="encryption" type="encryptionType" />
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 103]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!--
+ ####################################################
+
+ DATATYPES
+
+ ####################################################
+ -->
+
+ <xsd:simpleType name="version.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="1.0" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+<xsd:simpleType name="id.datatype">
+ <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="status.datatype">
+ <xsd:restriction base="xsd:positiveInteger">
+ <xsd:pattern value="[0-9][0-9][0-9]" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="msstatus.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="active" />
+ <xsd:enumeration value="deactivated" />
+ <xsd:enumeration value="unavailable" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="action.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="create" />
+ <xsd:enumeration value="update" />
+ <xsd:enumeration value="remove" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="actions.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="encoding" />
+ <xsd:enumeration value="decoding" />
+ <xsd:enumeration value="passthrough" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+
+
+
+Boulton, et al. Standards Track [Page 104]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:simpleType name="appdata.datatype">
+ <xsd:restriction base="xsd:string" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="dtmf.datatype">
+ <xsd:restriction base="xsd:NMTOKEN"/>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="transfermode.datatype">
+ <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="boolean.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="true" />
+ <xsd:enumeration value="false" />
+ </xsd:restriction>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="vxml.datatype">
+ <xsd:restriction base="xsd:NMTOKEN"/>
+ </xsd:simpleType>
+
+ <xsd:simpleType name="label.datatype">
+ <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+ <xsd:simpleType name="subscriptionid.datatype">
+ <xsd:restriction base="xsd:NMTOKEN" />
+ </xsd:simpleType>
+
+</xsd:schema>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 105]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+11. Media Service Resource Consumer Interface XML Schema
+
+ This section gives the XML Schema Definition
+ [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
+ "application/mrb-consumer+xml" format.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
+ elementFormDefault="qualified" blockDefault="#all"
+ xmlns="urn:ietf:params:xml:ns:mrb-consumer"
+ xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+
+ <xsd:annotation>
+ <xsd:documentation>
+ IETF MediaCtrl MRB 1.0
+
+ This is the schema of the IETF MediaCtrl MRB Consumer interface.
+
+ The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
+
+ </xsd:documentation>
+ </xsd:annotation>
+
+
+ <!--
+ #############################################################
+
+ SCHEMA IMPORTS
+
+ #############################################################
+ -->
+
+ <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd">
+ <xsd:annotation>
+ <xsd:documentation>
+ This import brings in the XML attributes for
+ xml:base, xml:lang, etc.
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:import>
+
+ <xsd:import
+ namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+ schemaLocation="civicAddress.xsd">
+ <xsd:annotation>
+ <xsd:documentation>
+
+
+
+Boulton, et al. Standards Track [Page 106]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ This import brings in the civicAddress specification
+ from RFC 5139.
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:import>
+
+<!--
+ #####################################################
+
+ Extensible core type
+
+ #####################################################
+ -->
+
+ <xsd:complexType name="Tcore">
+ <xsd:annotation>
+ <xsd:documentation>
+ This type is extended by other (non-mixed) component types to
+ allow attributes from other namespaces.
+ </xsd:documentation>
+ </xsd:annotation>
+ <xsd:sequence/>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:complexType>
+
+
+<!--
+ #####################################################
+
+ TOP-LEVEL ELEMENT: mrbconsumer
+
+ #####################################################
+ -->
+
+<xsd:complexType name="mrbconsumerType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:choice>
+ <xsd:element ref="mediaResourceRequest" />
+ <xsd:element ref="mediaResourceResponse" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:choice>
+ </xsd:sequence>
+ <xsd:attribute name="version" type="version.datatype"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 107]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+ <xsd:element name="mrbconsumer" type="mrbconsumerType" />
+
+
+<!--
+ #####################################################
+
+ mediaResourceRequest TYPE
+
+ #####################################################
+ -->
+
+<!-- mediaResourceRequest -->
+
+ <xsd:complexType name="mediaResourceRequestType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="generalInfo" minOccurs="0" />
+ <xsd:element ref="ivrInfo" minOccurs="0" />
+ <xsd:element ref="mixerInfo" minOccurs="0" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="id" type="xsd:string"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mediaResourceRequest"
+ type="mediaResourceRequestType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 108]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!--
+ #####################################################
+
+ generalInfo TYPE
+
+ #####################################################
+-->
+
+<!-- generalInfo -->
+
+<xsd:complexType name="generalInfoType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="session-info" minOccurs="0" />
+ <xsd:element ref="packages" minOccurs="0" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="generalInfo" type="generalInfoType" />
+
+
+<!-- session-info -->
+
+<xsd:complexType name="session-infoType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="session-id" type="id.datatype"/>
+ <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
+ <xsd:element name="action" type="action.datatype"/>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="session-info" type="session-infoType" />
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 109]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!-- packages -->
+
+<xsd:complexType name="packagesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="package" type="xsd:string" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="packages" type="packagesType"/>
+
+
+<!--
+ #####################################################
+
+ ivrInfo TYPE
+
+ #####################################################
+-->
+
+<!-- ivrInfo -->
+
+<xsd:complexType name="ivrInfoType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="ivr-sessions" minOccurs="0" />
+ <xsd:element ref="file-formats" minOccurs="0" />
+ <xsd:element ref="dtmf-type" minOccurs="0" />
+ <xsd:element ref="tones" minOccurs="0" />
+ <xsd:element ref="asr-tts" minOccurs="0" />
+ <xsd:element ref="vxml" minOccurs="0" />
+ <xsd:element ref="location" minOccurs="0" />
+ <xsd:element ref="encryption" minOccurs="0" />
+ <xsd:element ref="application-data" minOccurs="0" />
+ <xsd:element ref="max-prepared-duration" minOccurs="0" />
+ <xsd:element ref="file-transfer-modes" minOccurs="0" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 110]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="ivrInfo" type="ivrInfoType" />
+
+
+<!--
+ #####################################################
+
+ mixerInfo TYPE
+
+ #####################################################
+-->
+
+<!-- mixerInfo -->
+
+<xsd:complexType name="mixerInfoType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="mixers" minOccurs="0"/>
+ <xsd:element ref="file-formats" minOccurs="0"/>
+ <xsd:element ref="dtmf-type" minOccurs="0"/>
+ <xsd:element ref="tones" minOccurs="0"/>
+ <xsd:element ref="mixing-modes" minOccurs="0"/>
+ <xsd:element ref="application-data" minOccurs="0"/>
+ <xsd:element ref="location" minOccurs="0"/>
+ <xsd:element ref="encryption" minOccurs="0"/>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="mixerInfo" type="mixerInfoType" />
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 111]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!--
+ #####################################################
+
+ mediaResourceResponse TYPE
+
+ #####################################################
+ -->
+
+<!-- mediaResourceResponse -->
+
+ <xsd:complexType name="mediaResourceResponseType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="response-session-info" minOccurs="0" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="id" type="xsd:string"
+ use="required" />
+ <xsd:attribute name="status" type="status.datatype"
+ use="required" />
+ <xsd:attribute name="reason" type="xsd:string" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="mediaResourceResponse"
+ type="mediaResourceResponseType" />
+
+
+<!--
+ ####################################################
+
+ ELEMENTS
+
+ ####################################################
+ -->
+
+<!-- response-session-info -->
+
+<xsd:complexType name="response-session-infoType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="session-id" type="id.datatype"/>
+ <xsd:element name="seq" type="xsd:nonNegativeInteger"/>
+
+
+
+Boulton, et al. Standards Track [Page 112]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:element name="expires" type="xsd:nonNegativeInteger"/>
+ <xsd:element ref="media-server-address"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="response-session-info"
+ type="response-session-infoType" />
+
+<!-- media-server-address -->
+
+<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 -->
+
+<xsd:complexType name="ivr-sessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 113]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
+
+<xsd:complexType name="rtp-codecType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="decoding" type="xsd:nonNegativeInteger" />
+ <xsd:element name="encoding" type="xsd:nonNegativeInteger" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="rtp-codec" type="rtp-codecType" />
+
+
+<!-- file-formats -->
+
+<xsd:complexType name="file-formatsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="required-format"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="file-formats" type="file-formatsType" />
+
+<xsd:complexType name="required-formatType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="required-file-package"
+ minOccurs="0" maxOccurs="unbounded" />
+
+
+
+Boulton, et al. Standards Track [Page 114]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="required-format" type="required-formatType" />
+
+<xsd:complexType name="required-file-packageType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="required-file-package-name" type="xsd:string"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="required-file-package"
+ type="required-file-packageType" />
+
+<!-- dtmf-type -->
+
+<xsd:complexType name="dtmfType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="detect" />
+ <xsd:element ref="generate" />
+ <xsd:element ref="passthrough" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="dtmf" type="dtmfType" />
+
+<xsd:complexType name="detectType">
+
+
+
+Boulton, et al. Standards Track [Page 115]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="detect" type="detectType" />
+
+<xsd:complexType name="generateType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="generate" type="generateType" />
+
+<xsd:complexType name="passthroughType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="dtmf-type"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="passthrough" type="passthroughType" />
+
+<xsd:complexType name="dtmf-typeType">
+
+
+
+Boulton, et al. Standards Track [Page 116]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="dtmf.datatype" use="required" />
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="dtmf-type" type="dtmf-typeType" />
+
+<!-- tones -->
+
+<xsd:complexType name="required-tonesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="country-codes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="h248-codes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tones" type="required-tonesType" />
+
+<xsd:complexType name="required-country-codesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="country-code"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+
+
+Boulton, et al. Standards Track [Page 117]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<xsd:element name="country-codes"
+ type="required-country-codesType" />
+
+<xsd:complexType name="country-codeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="country-code" type="country-codeType" />
+
+<xsd:complexType name="required-h248-codesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="h248-code"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="h248-codes"
+ type="required-h248-codesType" />
+
+<xsd:complexType name="h248-codeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="h248-code" type="h248-codeType" />
+
+<!-- asr-tts -->
+
+<xsd:complexType name="asr-ttsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+
+
+
+Boulton, et al. Standards Track [Page 118]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:element ref="asr-support"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="tts-support"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-tts" type="asr-ttsType" />
+
+<xsd:complexType name="asr-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="language"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="asr-support" type="asr-supportType" />
+
+<xsd:complexType name="tts-supportType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="language"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="tts-support" type="tts-supportType" />
+
+<xsd:complexType name="languageType">
+ <xsd:complexContent>
+
+
+
+Boulton, et al. Standards Track [Page 119]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute ref="xml:lang" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="language" type="languageType" />
+
+
+<!-- vxml -->
+
+<xsd:complexType name="vxmlType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="vxml-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="vxml" type="vxmlType" />
+
+<xsd:complexType name="vxml-modeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:attribute name="require" type="vxml.datatype" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="vxml-mode" type="vxml-modeType" />
+
+
+
+
+Boulton, et al. Standards Track [Page 120]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<!-- location -->
+
+<xsd:complexType name="locationType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="ca:civicAddress"
+ minOccurs="1" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+<xsd:element name="location" type="locationType" />
+
+
+<!-- encryption -->
+
+ <xsd:complexType name="encryptionType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+ </xsd:complexType>
+
+ <xsd:element name="encryption" type="encryptionType" />
+
+<!-- application-data -->
+
+<xsd:element name="application-data" type="appdata.datatype" />
+
+<!-- max-prepared-duration -->
+
+<xsd:complexType name="max-prepared-durationType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="max-time" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+
+
+
+Boulton, et al. Standards Track [Page 121]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="max-prepared-duration"
+ type="max-prepared-durationType" />
+
+
+<xsd:complexType name="max-timeType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element name="max-time-package" type="xsd:string" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="max-time" type="max-timeType" />
+
+
+<!-- file-transfer-modes -->
+
+<xsd:complexType name="file-transfer-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="file-transfer-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="file-transfer-modes"
+ type="file-transfer-modesType" />
+
+<xsd:complexType name="file-transfer-modeType">
+
+
+
+Boulton, et al. Standards Track [Page 122]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="transfermode.datatype"
+ use="required" />
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
+
+<!-- mixers -->
+
+<xsd:complexType name="mixerssessionsType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="mix" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixers" type="mixerssessionsType" />
+
+<xsd:complexType name="mixType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="rtp-codec" minOccurs="0"
+ maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="users" type="xsd:nonNegativeInteger"
+ use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+
+
+
+Boulton, et al. Standards Track [Page 123]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+</xsd:complexType>
+
+<xsd:element name="mix" type="mixType" />
+
+<!-- mixing-modes -->
+
+<xsd:complexType name="mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="audio-mixing-modes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:element ref="video-mixing-modes"
+ minOccurs="0" maxOccurs="1" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="mixing-modes" type="mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="audio-mixing-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
+
+<xsd:complexType name="audio-mixing-modeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+
+
+Boulton, et al. Standards Track [Page 124]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
+
+<xsd:complexType name="video-mixing-modesType">
+ <xsd:complexContent>
+ <xsd:extension base="Tcore">
+ <xsd:sequence>
+ <xsd:element ref="video-mixing-mode"
+ minOccurs="0" maxOccurs="unbounded" />
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="vas" type="boolean.datatype"
+ default="false" />
+ <xsd:attribute name="activespeakermix" type="boolean.datatype"
+ default="false" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+ </xsd:extension>
+ </xsd:complexContent>
+</xsd:complexType>
+
+<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
+
+<xsd:complexType name="video-mixing-modeType" mixed="true">
+ <xsd:sequence>
+ <xsd:any namespace="##other" minOccurs="0"
+ maxOccurs="unbounded" processContents="lax" />
+ </xsd:sequence>
+ <xsd:attribute name="package" type="xsd:string" use="required" />
+ <xsd:anyAttribute namespace="##other" processContents="lax" />
+</xsd:complexType>
+
+<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
+
+
+<!--
+ ####################################################
+
+ DATATYPES
+
+ ####################################################
+ -->
+
+<xsd:simpleType name="version.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="1.0" />
+ </xsd:restriction>
+</xsd:simpleType>
+
+
+
+
+Boulton, et al. Standards Track [Page 125]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+<xsd:simpleType name="id.datatype">
+ <xsd:restriction base="xsd:NMTOKEN" />
+</xsd:simpleType>
+
+<xsd:simpleType name="status.datatype">
+ <xsd:restriction base="xsd:positiveInteger">
+ <xsd:pattern value="[0-9][0-9][0-9]" />
+ </xsd:restriction>
+</xsd:simpleType>
+
+<xsd:simpleType name="transfermode.datatype">
+ <xsd:restriction base="xsd:NMTOKEN"/>
+</xsd:simpleType>
+
+<xsd:simpleType name="action.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="remove" />
+ <xsd:enumeration value="update" />
+ </xsd:restriction>
+</xsd:simpleType>
+
+<xsd:simpleType name="dtmf.datatype">
+ <xsd:restriction base="xsd:NMTOKEN"/>
+</xsd:simpleType>
+
+<xsd:simpleType name="boolean.datatype">
+ <xsd:restriction base="xsd:NMTOKEN">
+ <xsd:enumeration value="true" />
+ <xsd:enumeration value="false" />
+ </xsd:restriction>
+</xsd:simpleType>
+
+<xsd:simpleType name="vxml.datatype">
+ <xsd:restriction base="xsd:NMTOKEN"/>
+</xsd:simpleType>
+
+<xsd:simpleType name="appdata.datatype">
+ <xsd:restriction base="xsd:string" />
+ </xsd:simpleType>
+
+</xsd:schema>
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 126]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+12. Security Considerations
+
+ The MRB network entity has two primary interfaces -- Publish and
+ Consumer -- that carry sensitive information and must therefore be
+ appropriately protected and secured.
+
+ The Publish interface, as defined in and described in Section 5.1,
+ uses the Media Control Channel Framework [RFC6230] as a mechanism to
+ connect an MRB to a Media Server. It is very important that the
+ communication between the MRB and the Media Server is secured: a
+ malicious entity may change or even delete subscriptions to a Media
+ Server, thus affecting the view the MRB has of the resources actually
+ available on a Media Server, leading it to incorrect selection when
+ media resources are being requested by an Application Server. A
+ malicious entity may even manipulate available resources on a Media
+ Server, for example, to make the MRB think no resources are available
+ at all. Considering that the Publish interface is a CFW Control
+ Package, the same security considerations included in the Media
+ Control Channel Framework specification apply here to protect
+ interactions between an MRB and a Media Server.
+
+ The Publish interface also allows a Media Server, as explained in
+ Section 5.1.5.18, to provide more or less accurate information about
+ its geographic location, should Application Servers be interested in
+ such details when looking for services at an MRB. While the usage of
+ this information is entirely optional and the level of detail to be
+ provided is implementation specific, it is important to draw
+ attention to the potential security issues that the disclosure of
+ such addresses may introduce. As such, it is important to make sure
+ MRB implementations don't disclose this information as is to
+ interested Application Servers but only exploit those addresses as
+ part of computation algorithms to pick the most adequate resources
+ Application Servers may be looking for.
+
+ The Consumer interface, as defined in and described in Section 5.2,
+ conceives transactions based on a session ID. These transactions may
+ be transported either by means of HTTP messages or SIP dialogs. This
+ means that malicious users could be able to disrupt or manipulate an
+ MRB session should they have access to the above-mentioned session ID
+ or replicate it somehow: for instance, a malicious entity could
+ modify an existing session between an Application Server and the MRB,
+ e.g., requesting less resources than originally requested to cause
+ media dialogs to be rejected by the Application Server, or requesting
+ many more resources instead to try and lock as many of (if not all)
+ the resources an MRB can provide, thus making them unavailable to
+ other legitimate Application Servers in subsequent requests. In
+ order to prevent this, it is strongly advised that MRB
+ implementations generate session identifiers that are very hard to
+
+
+
+Boulton, et al. Standards Track [Page 127]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ replicate, in order to minimize the chances that malicious users
+ could gain access to valid identifiers by just guessing or by means
+ of brute-force attacks. It is very important, of course, to also
+ secure the way that these identifiers are transported by the involved
+ parties, in both requests and responses, in order to prevent network
+ attackers from intercepting Consumer messages and having access to
+ session IDs. The Consumer interface uses either the Hypertext
+ Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) as
+ the mechanism for clients to connect to an MRB to request media
+ resources. In the case where HTTP is used, any binding using the
+ Consumer interface MUST be capable of being transacted over Transport
+ Layer Security (TLS), as described in RFC 2818 [RFC2818]. In the
+ case where SIP is used, the same security considerations included in
+ the Media Control Channel Framework specification apply here to
+ protect interactions between a client requesting media resources and
+ an MRB.
+
+ Should a valid session ID be compromised somehow (that is,
+ intercepted or just guessed by a malicious user), as a further means
+ to prevent disruption the Consumer interface also prescribes the use
+ of a sequence number in its transactions. This sequence number is to
+ be increased after each successful transaction, starting from a first
+ value randomly generated by the MRB when the session is first
+ created, and it must match in every request/response. While this
+ adds complexity to the protocol (implementations must pay attention
+ to those sequence numbers, since wrong values will cause "Wrong
+ sequence number" errors and the failure of the related requests), it
+ is an important added value for security. In fact, considering that
+ different transactions related to the same session could be
+ transported in different, unrelated HTTP messages (or SIP INVITEs in
+ cases where the In-line mode is being used), this sequence number
+ protection prevents the chances of session replication or disruption,
+ especially in cases where the session ID has been compromised: that
+ is, it should make it harder for malicious users to manipulate or
+ remove a session for which they have obtained the session ID. It is
+ strongly advised that the MRB doesn't choose 1 as the first sequence
+ number for a new session but rather picks a random value to start
+ from. The reaction to transactions that are out of sequence is left
+ to MRB implementations: a related error code is available, but
+ implementations may decide to enforce further limitations or actions
+ upon the receipt of too many failed attempts in a row or of what
+ looks like blatant attempts to guess what the current, valid sequence
+ number is.
+
+ It is also worth noting that in In-line mode (both IAMM and IUMM) the
+ MRB may act as a Back-to-Back User Agent (B2BUA). This means that
+ when acting as a B2BUA the MRB may modify SIP bodies: it is the case,
+ for instance, for the IAMM handling multipart/mixed payloads. This
+
+
+
+Boulton, et al. Standards Track [Page 128]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ impacts the ability to use any SIP security feature that protects the
+ body (e.g., RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as
+ a mediator for the security association. This should be taken into
+ account when implementing an MRB compliant with this specification.
+
+ Both the Publishing interface and Consumer interface may address the
+ location of a Media Server: the Publishing interface may be used to
+ inform the MRB where a Media Server is located (approximately or
+ precisely), and the Consumer interface may be used to ask for a Media
+ Server located somewhere in a particular region (e.g., a conference
+ bridge close to San Francisco). Both Media Server and MRB
+ implementers need to take this into account when deciding whether or
+ not to make this location information available, and if so how many
+ bits of information really need to be made available for brokering
+ purposes.
+
+ It is worthwhile to cover authorization issues related to this
+ specification. Neither the Publishing interface nor the Consumer
+ interface provides an explicit means for implementing authentication,
+ i.e., they do not contain specific protocol interactions to ensure
+ that authorized Application Servers can make use of the services
+ provided by an MRB instance. Considering that both interfaces are
+ transported using well-established protocols (HTTP, SIP, CFW),
+ support for such functionality can be expressed by means of the
+ authentication mechanisms provided by the protocols themselves.
+ Therefore, any MRB-aware entity (Application Servers, Media Servers,
+ MRBs themselves) MUST support HTTP and SIP Digest access
+ authentication. The usage of such Digest access authentications is
+ recommended and not mandatory, which means MRB-aware entities MAY
+ exploit it in deployment.
+
+ An MRB may want to enforce further constraints on the interactions
+ between an Application Server/Media Server and an MRB. For example,
+ it may choose to only accept requests associated with a specific
+ session ID from the IP address that originated the first request or
+ may just make use of pre-shared certificates to assess the identity
+ of legitimate Application Servers and/or Media Servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 129]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+13. IANA Considerations
+
+ There are several IANA considerations associated with this
+ specification.
+
+13.1. Media Control Channel Framework Package Registration
+
+ This section registers a new Media Control Channel Framework package,
+ per the instructions in Section 13.1 of [RFC6230].
+
+ Package Name: mrb-publish/1.0
+
+ Published Specification(s): RFC 6917
+
+ Person and email address to contact for further information: IETF
+ MediaCtrl working group (mediactrl@ietf.org), Chris Boulton
+ (chris@ns-technologies.com).
+
+13.2. application/mrb-publish+xml Media Type
+
+ To: application
+
+ Subject: Registration of media type application/mrb-publish+xml
+
+ Type name: application
+
+ Subtype name: mrb-publish+xml
+
+ Required parameters: none
+
+ Optional parameters: Same as charset parameter of application/xml as
+ specified in RFC 3023 [RFC3023].
+
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in RFC 3023 [RFC3023].
+
+ Security considerations: See Section 10 of RFC 3023 [RFC3023] and
+ Section 12 of RFC 6917.
+
+ Interoperability considerations: none.
+
+ Published specification: Section 10 of RFC 6917.
+
+ Applications that use this media type: This media type is used to
+ support a Media Resource Broker (MRB) entity.
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 130]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Additional Information:
+
+ Magic Number: None
+
+ File Extension: .xdf
+
+ Macintosh file type code: "TEXT"
+
+ Person and email address to contact for further information: Chris
+ Boulton (chris@ns-technologies.com).
+
+ Intended usage: COMMON
+
+ Author/Change controller: The IETF.
+
+13.3. application/mrb-consumer+xml Media Type
+
+ To: application
+
+ Subject: Registration of media type application/mrb-consumer+xml
+
+ Type name: application
+
+ Subtype name: mrb-consumer+xml
+
+ Mandatory parameters: none
+
+ Optional parameters: Same as charset parameter of application/xml as
+ specified in RFC 3023 [RFC3023].
+
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in RFC 3023 [RFC3023].
+
+ Security considerations: See Section 10 of RFC 3023 [RFC3023] and
+ Section 12 of RFC 6917.
+
+ Interoperability considerations: none.
+
+ Published specification: Section 11 of RFC 6917.
+
+ Applications that use this media type: This media type is used to
+ support a Media Resource Broker (MRB) entity.
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 131]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ Additional Information:
+
+ Magic Number: None
+
+ File Extension: .xdf
+
+ Macintosh file type code: "TEXT"
+
+ Person and email address to contact for further information: Chris
+ Boulton (chris@ns-technologies.com).
+
+ Intended usage: COMMON
+
+ Author/Change controller: The IETF.
+
+13.4. URN Sub-Namespace Registration for mrb-publish
+
+ IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish",
+ with the ID of "mrb-publish". The schema of the XML namespace named
+ urn:ietf:params:xml:ns:mrb-publish is in Section 10.
+
+13.5. URN Sub-Namespace Registration for mrb-consumer
+
+ IANA has registered the URN "urn:ietf:params:xml:ns:mrb-consumer",
+ with the ID of "mrb-consumer". The schema of the XML namespace named
+ urn:ietf:params:xml:ns:mrb-consumer is in Section 11.
+
+13.6. XML Schema Registration for mrb-publish
+
+ IANA has registered the schema for mrb-publish:
+
+ URI: urn:ietf:params:xml:schema:mrb-publish
+
+ ID: mrb-publish
+
+ Filename: mrb-publish
+
+ Registrant Contact: IETF MediaCtrl working group
+ (mediactrl@ietf.org)
+
+ Schema: The XML for the schema is in Section 10 of this document.
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 132]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+13.7. XML Schema Registration for mrb-consumer
+
+ Please register the schema for mrb-consumer:
+
+ URI: urn:ietf:params:xml:schema:mrb-consumer
+
+ ID: mrb-consumer
+
+ Filename: mrb-consumer
+
+ Registrant Contact: IETF MediaCtrl working group
+ (mediactrl@ietf.org)
+
+ Schema: The XML for the schema is in Section 11 of this document.
+
+14. Acknowledgements
+
+ The authors would like to thank the members of the Publish Interface
+ design team, who provided valuable input into this document. The
+ design team consisted of Adnan Saleem, Michael Trank, Victor
+ Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also
+ like to thank John Dally, Bob Epley, Simon Romano, Henry Lum,
+ Christian Groves, and Jonathan Lennox for input into this
+ specification.
+
+ Ben Campbell carried out the RAI expert review on an early version of
+ this specification and provided a great deal of invaluable input.
+
+15. References
+
+15.1. Normative References
+
+ [ISO.10646.2012]
+ International Organization for Standardization,
+ "Information technology -- Universal Coded Character Set
+ (UCS)", ISO Standard 10646, 2012.
+
+ [ISO.3166-1]
+ International Organization for Standardization, "Codes for
+ the representation of names of countries and their
+ subdivisions - Part 1: Country codes", ISO Standard
+ 3166-1:2006, 2006.
+
+ [ISO.639.2002]
+ International Organization for Standardization, "Codes for
+ the representation of names of languages -- Part 1:
+ Alpha-2 code", ISO Standard 639, 2002.
+
+
+
+
+Boulton, et al. Standards Track [Page 133]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ [ITU-T.Q.1950]
+ International Telecommunication Union, "Bearer independent
+ call bearer control protocol", ITU-T Recommendation
+ Q.1950, December 2002.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
+ UPDATE Method", RFC 3311, October 2002.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
+ Format for Presence Information Data Format Location
+ Object (PIDF-LO)", RFC 5139, February 2008.
+
+ [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
+ for Establishing a Secure Real-time Transport Protocol
+ (SRTP) Security Context Using Datagram Transport Layer
+ Security (DTLS)", RFC 5763, May 2010.
+
+ [W3C.REC-xmlschema-1-20041028]
+ Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
+ "XML Schema Part 1: Structures Second Edition", World Wide
+ Web Consortium Recommendation REC-xmlschema-1-20041028,
+ October 2004,
+ <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+
+
+
+
+Boulton, et al. Standards Track [Page 134]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ [W3C.REC-xmlschema-2-20041028]
+ Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
+ Second Edition", World Wide Web Consortium
+ Recommendation REC-xmlschema-2-20041028, October 2004,
+ <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+15.2. Informative References
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
+ Media Services with SIP", RFC 4240, December 2005.
+
+ [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
+ Authenticated Identity Management in the Session
+ Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+ [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+ Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+ December 2006.
+
+ [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
+ Control Markup Language (MSCML) and Protocol", RFC 5022,
+ September 2007.
+
+ [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
+ Requirements", RFC 5167, March 2008.
+
+ [RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
+ Services", RFC 5552, May 2009.
+
+ [RFC5567] Melanchuk, T., "An Architectural Framework for Media
+ Server Control", RFC 5567, June 2009.
+
+ [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
+ Language (MSML)", RFC 5707, February 2010.
+
+ [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
+ Control Channel Framework", RFC 6230, May 2011.
+
+ [RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An
+ Interactive Voice Response (IVR) Control Package for the
+ Media Control Channel Framework", RFC 6231, May 2011.
+
+ [RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and
+ 'Profiles' Parameters for "Bucket" Media Types", RFC 6381,
+ August 2011.
+
+
+
+
+Boulton, et al. Standards Track [Page 135]
+
+RFC 6917 Media Resource Brokering April 2013
+
+
+ [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+ "Conference Information Data Model for Centralized
+ Conferencing (XCON)", RFC 6501, March 2012.
+
+ [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
+ Control Package for the Media Control Channel Framework",
+ RFC 6505, March 2012.
+
+Authors' Addresses
+
+ Chris Boulton
+ NS-Technologies
+
+ EMail: chris@ns-technologies.com
+
+
+ Lorenzo Miniero
+ Meetecho
+ Via Carlo Poerio 89
+ Napoli 80100
+ Italy
+
+ EMail: lorenzo@meetecho.com
+
+
+ Gary Munson
+ AT&T
+ 200 Laurel Avenue South
+ Middletown, New Jersey 07748
+ USA
+
+ EMail: gamunson@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boulton, et al. Standards Track [Page 136]
+