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.