From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6917.txt | 7619 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 7619 insertions(+) create mode 100644 doc/rfc/rfc6917.txt (limited to 'doc/rfc/rfc6917.txt') 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. .......................................15 + 5.1.4. ......................................17 + 5.1.5. ..................................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. ......................................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 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 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 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 or + 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 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 . 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 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 element has the following child elements, and there + MUST NOT be more than one such child element in any + message: + + for sending an MRB request. See Section 5.1.3. + + for sending an MRB response. See Section 5.1.4. + + for sending an MRB notification. See + Section 5.1.5. + +5.1.3. + + This section defines the 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 element has no defined attributes. + + The element has the following child element: + + 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. + + The 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 + element. + + The 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 element has zero or more of the following child + elements: + + : 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. + + : Provides the minimum frequency in seconds that the + MRB wishes to receive notifications from the Media Server. The + element MAY be present. + + : 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 accordingly. + +5.1.4. + + Responses to requests are indicated by an element. + + The 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 element has a single child element: + + 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: Status Codes + + If a new subscription request made by an MRB (action='create') has + been accepted, the Media Server MUST reply with an 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 + 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 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 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 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 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 child that describes the subscription. The + 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 + if it considers them unacceptable (e.g., the requested + frequency range is too high). In such a case, the response MUST + contain a element describing the subscription as the + Media Server accepted it, and the Media Server MUST include in the + element all of those values that it modified relative + to the request, to inform the MRB about the change. + +5.1.5. + + The 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 element. Updates are sent + using the element. + + The 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 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 + is not related to the 'seqnumber' appearing in a + . 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 element. + +5.1.5.1. + + The 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. + + The element provides the list of Media Control + Channel packages supported by the Media Server. The element MAY be + present. + + The element has no attributes. + + The element has a single child element: + + : Gives the name of a package supported by the Media + Server. The 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. + + The element provides information detailing the + current active Real-time Transport Protocol (RTP) sessions. The + element MAY be present. + + The element has no attributes. + + + + + + +Boulton, et al. Standards Track [Page 20] + +RFC 6917 Media Resource Brokering April 2013 + + + The element has a single child element: + + : Describes a supported codec and the number of active + sessions using that codec. The element has one + attribute. The value of the attribute, 'name', is a media type + (which can include parameters per [RFC6381]). The + element has two child elements. The child element has + as content the decimal number of RTP sessions being decoded using + the specified codec, and the child element has as + content the decimal number of RTP sessions being encoded using the + specified codec. + +5.1.5.4. + + The element provides information detailing + the current active mixed RTP sessions. The element MAY be present. + + The element has no attributes. + + The element has a single child element: + + : Describes a mixed active RTP session. The + element has one attribute. The value of the + attribute, 'conferenceid', is the name of the mix. The + element has one child element. The child element, + , 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. + + The 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 element has no attributes. + + The element has a single child element: + + : Describes a supported codec and the number of + non-active sessions for that codec. The element has + one attribute. The value of the attribute, 'name', is a media + type (which can include parameters per [RFC6381]). The + element has two child elements. The child element + 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 has as content the decimal number of RTP + sessions available for encoding using the specified codec. + +5.1.5.6. + + The 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 element has no attributes. + + The element has a single child element: + + : Describes available mixed RTP sessions. The + element has one attribute. The value of the + attribute, 'available', is the number of mixes that could be used + using that profile. The element has one child + element. The child element, , 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. + + The 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 element has no attributes. + + The element has no child elements. + + + + + + + + + +Boulton, et al. Standards Track [Page 22] + +RFC 6917 Media Resource Brokering April 2013 + + +5.1.5.8. + + The element provides information detailing the + current codecs supported by a Media Server and associated actions. + The element MAY be present. + + The element has no attributes. + + The element has a single child element: + + : 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 element then has a further child element, + . The 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 element has zero or more + 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. + + The 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 + )). The element MAY be present. + + The element has no attributes. + + The element has no child elements. + + + + + + + +Boulton, et al. Standards Track [Page 23] + +RFC 6917 Media Resource Brokering April 2013 + + +5.1.5.10. + + The element provides a list of file formats supported + for the purpose of playing media. The element MAY be present. + + The element has no attributes. + + The element has zero of more the following child + elements: + + : 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 + element then has a further child element, + . The 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. + + The 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 element has no attributes. + + The element has a single child element: + + : 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 element then has a further + child element, . The 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. + + The element specifies the supported methods to detect + Dual-Tone Multi-Frequency (DTMF) tones and to generate them. The + element MAY be present. + + The element has no attributes. + + The element has zero of more of the following child + elements: + + : Indicates the support for DTMF detection. The + element has no attributes. The element then has a + further child element, . The 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. + + : Indicates the support for DTMF generation. The + element has no attributes. The element then + has a further child element, . The 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. + + : Indicates the support for passing DTMF through + without re-encoding. The element has no attributes. + The element then has a further child element, + . The 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. + + The 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 element has no attributes. + + The element has zero or more of the following child + elements: + + : Describes the available algorithms for audio + mixing. The element has no attributes. The + element has one child element. The child + element, , contains a specific available + algorithm. Valid values for the 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. + + : Describes the available video presentation + layouts and the supported functionality related to video mixing. + The 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 + element has one child element. The child + element, , 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 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. + + The 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 element has no attributes. + + The element has zero or more of the following child + elements: + + : Describes the supported country codes + with respect to tones. The element has + no attributes. The element has one + child element. The child element, , reports support + for a specific country code, compliant with the ISO 3166-1 + [ISO.3166-1] specification. 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], in which the tones from the + specified country code are supported. + + : Describes the supported H.248 codes with + respect to tones. The element has no + attributes. The element has one child + element. The child element, , 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 + 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. + + The 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 element has no attributes. + + + + +Boulton, et al. Standards Track [Page 27] + +RFC 6917 Media Resource Brokering April 2013 + + + The element has a single child element: + + : 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. + + The 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 element has no attributes. + + The element has zero or more of the following child + elements: + + : Describes the available languages for ASR. The + element has no attributes. The + element has one child element. The child element, , + reports that the Media Server supports ASR for a specific + language. The 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 + + + : Describes the available languages for TTS. The + element has no attributes. The + element has one child element. The child element, , + reports that the Media Server supports TTS for a specific + language. The 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. + + The 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 element has no attributes. + + The element has a single child element: + + : 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 child element would indicate + that the Media Server does support VXML as specified by the child + element itself. An empty element would otherwise indicate + that the Media Server does not support VXML at all. + +5.1.5.18. + + The 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 element has no attributes. + + + + + + +Boulton, et al. Standards Track [Page 29] + +RFC 6917 Media Resource Brokering April 2013 + + + The element has a single child element: + + : Describes the civic address location of the Media + Server, whose representation refers to Section 4 of RFC 5139 + [RFC5139]. + +5.1.5.19.