Network Working Group C. Boulton Internet-Draft NS-Technologies Intended status: Standards Track L. Miniero Expires: March 29, 2010 University of Napoli September 25, 2009 Media Resource Brokering draft-ietf-mediactrl-mrb-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Boulton & Miniero Expires March 29, 2010 [Page 1] Internet-Draft Media Resource Brokering September 2009 Abstract The MediaCtrl work group in the IETF is currently proposing an architecture for controlling media services. The Session Initiation Protocol (SIP) will be used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:M combinations of Application Servers and Media Servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 13 5.1. Media Server Resource Publishing Interface . . . . . . . . 13 5.1.1. Control Package Definition . . . . . . . . . . . . . . 14 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16 5.1.3. <mrbrequest> . . . . . . . . . . . . . . . . . . . . . 16 5.1.4. <mrbnotification> . . . . . . . . . . . . . . . . . . 17 5.1.5. <mrbresponse> . . . . . . . . . . . . . . . . . . . . 24 5.2. Media Service Resource Consumer Interface . . . . . . . . 25 5.2.1. Media Service Resource Request . . . . . . . . . . . . 25 5.2.2. Media Service Resource Response . . . . . . . . . . . 26 5.3. In-Line MRB Interface . . . . . . . . . . . . . . . . . . 27 5.3.1. In-line Unaware MRB Mode . . . . . . . . . . . . . . . 27 5.3.2. In-line Aware MRB Mode . . . . . . . . . . . . . . . . 27 6. Media Service Resource Publisher Interface XML Schema . . . . 30 7. Media Service Resource Consumer Interface XML Schema . . . . . 47 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1. Changes from 01 Version . . . . . . . . . . . . . . . . . 51 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 12.2. Informative References . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Boulton & Miniero Expires March 29, 2010 [Page 2] Internet-Draft Media Resource Brokering September 2009 1. Introduction The topic of Media Resources has been in discussion for a number of years with varying proprietary solutions being used today. It is clear that, as we move towards a consistent architecture and protocol for Media Server Control, a standard mechanism is required for accurate media resource location. 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 work 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 you introduce a flexible level of deployment scenarios, as specified in the MediaCtrl Requirements [I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture [I-D.ietf-mediactrl-architecture] documents. 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. 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 that 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 that each media server possesses a different media capability set. Media servers may offer different media services as specified in the Mediactrl architecture document. A Media server may have similar media functionality but may have different capacity or media codec support. Boulton & Miniero Expires March 29, 2010 [Page 3] Internet-Draft Media Resource Brokering September 2009 +---+-----+---+ | 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 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 The final deployment view is the most complex. In this model (M:M) there exists any number of Application Servers and any number of Media Servers. It is again possible in this model that media servers might not be homogenous and have different capability sets and Boulton & Miniero Expires March 29, 2010 [Page 4] Internet-Draft Media Resource Brokering September 2009 capacity. +---+-----+---+ +---+-----+---+ | Application | | Media | | Server |<-----+ +---->| Server | +-------------+ | | +-------------+ | | +---+-----+---+ | | +---+-----+---+ | Application | | | | Media | | Server |<-----+-MS Control-+---->| Server | +-------------+ | | +-------------+ | | +---+-----+---+ | | +---+-----+---+ | Application | | +---->| Media | | Server |<-----+ | Server | +-------------+ +---+-----+---+ Figure 4: Basic Architecture This document will take a look at the specific problem areas related to such deployment architectures. It is recognised that the solutions proposed in this document should be equally adaptable to all of the previously described deployment models. It is also recognised 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 & Miniero Expires March 29, 2010 [Page 5] Internet-Draft Media Resource Brokering September 2009 2. Conventions and Terminology In this document, BCP 14/RFC 2119 [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In addition, BCP 15 indicates requirement levels for compliant implementations. This document inherits terminology proposed in the MediaCtrl Architecture [I-D.ietf-mediactrl-architecture] and Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] documents. In addition, the following terms are defined for use in this document and for use in the context of the MediaCtrl Work 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 supplying of appropriate MS information to consuming entities. Query MRB An instantiation of an MRB (See previous definition) that provides an interface for an Application Server to retrieve the location 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 definition) that directly receives requests on the signalling path. The decision making process is totally delegated to the MRB. Boulton & Miniero Expires March 29, 2010 [Page 6] Internet-Draft Media Resource Brokering September 2009 3. Problem Discussion It is clear from Section 1 that the MediaCtrl group will be producing a solution that must service a wide variety of deployment architectures. These range from the simplest 1:1 relationship between Media Servers and Application Servers to potentially linearly scaling 1:M, M:1 and M:M deployments. This still does not seem like a major issue for the proposed solution until you add a number of additional factors into the equation that increase complexity. 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 tool set 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 unavailability can be handled using the appropriate underlying signalling 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 tools provided 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 after a request has taken place should be handled by the underlying protocol. Please note that, while the MRB is supposed to provided ASs with as much relevant information as possible, there are information pieces that ASs may be interested to which are out of scope in this document, as for instance reservation requests, MS resource allocation rules, planned or unplanned downtime of MS resources, the planned addition of future MS resources and the like. Boulton & Miniero Expires March 29, 2010 [Page 7] Internet-Draft Media Resource Brokering September 2009 4. Deployment Scenario Options On researching Media Resource Brokering it became clear that a couple of high level models exist. The general principles of "in-line" and "query" MRB concepts are discussed in the rest of this section. 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 Publishing 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 an increased accuracy in its response. This particular interface is discussed in "Media Resource Consumer Interface" in Section 5.2. The Application Server is then able to direct control commands (for example create conference) and Media Dialogs to the Boulton & Miniero Expires March 29, 2010 [Page 8] Internet-Draft Media Resource Brokering September 2009 appropriate Media Server, as shown by (3) in Figure 5. 4.1.1. Hybrid Query MRB As mentioned previously, it is the intention that a tool kit 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 - AS 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 Publishing 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. In a similar manner, the Media Server could also act as a hybrid for the deployment cluster, as illustrated in Figure 7. Boulton & Miniero Expires March 29, 2010 [Page 9] Internet-Draft Media Resource Brokering September 2009 (1) +---+-----+---+ +---+---+------------->---------------->----------->| MRB | | | | +---+--+--+---+ +---+-----+---+ | | +-<-| Application | | Media | | | | Server |<--+-MS Control-+------->| Server | | | +-------------+ | +-------------+ | | | | | +---+--+--+---+ | | +---<---| Application | | | | Server |<--+-MS Control-+--+ | +-------------+ | | | | +---+--+--+---+ | +---<-------| Application | | | Server |<--+-MS Control-+--+ +-------------+ Figure 7: Hybrid Query MRB - MS Hosted This time 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. This time the "Media Server Publishing 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 Publishing Interface" could then be offered from the hybrid if required. A typical use case scenario for such a topology would be a single MS representing a pool of MSs in a cluster. In that case, the MRB would actually be handling a cluster of MSs, rather than one. 4.2. In-Line MRB The "In-line" MRB is architecturally different from the "Query" model that was discussed in the previous section. The Concept of a "Media Server Consumer Interface" disappears. The client of the MRB simply uses the signalling to offload the decision making process - this applies to both media server Control and Media dialogs. This type of deployment is illustrated in Figure 8. Boulton & Miniero Expires March 29, 2010 [Page 10] Internet-Draft Media Resource Brokering September 2009 +-------<----------+----<-------+---+ | | (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 Publishing Interface' to convey capabilities and resources to the MRB - as illustrated by (1). The media server Control and Media dialogs are sent to the MRB (2) which then selects an appropriate Media Server (3). The result of such an architecture is that the signalling decision is left entirely to the MRB and the Application Server has no choice in the final selection process. This is the opposite to the "Query" model which provided information that would help influence the Media Server decision making process on the application server and resulted in it directly contacting an appropriate Media Server instance. As a by- product of this decision shift, a lot more emphasis is placed on the intelligence of the MRB to interpret the required capabilities of the request. The MRB will actually have to inspect both the SIP signalling and the media server control protocol PDUs for the purpose of Media Server selection. This includes, for example, looking for explicit capabilities in the signalling and session details such as media types, codecs and bandwidth requirements. Ultimately the decision making and policy enforcement is removed from the Application Server and shifted to the MRB logical entity. In-line MRB can be split into two distinct logical roles which can be 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. Boulton & Miniero Expires March 29, 2010 [Page 11] Internet-Draft Media Resource Brokering September 2009 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. The two modes are discussed in more detail in Section 5.3. Boulton & Miniero Expires March 29, 2010 [Page 12] Internet-Draft Media Resource Brokering September 2009 5. MRB Interface Definitions As discussed in previous sections in this document, the intention is to provide a toolkit for a variety of deployment architectures where media resource brokering can take place. As a result, 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 Publishing' and 'Media Server Resource Consumer' interfaces. These two interfaces have extremely differing responsibilities and usages which is reflected in the choice of solutions. It is beyond the scope of this document to define exactly how to construct an MRB. This includes interpreting the data for the Media Service Consumer interface supplied by the Media Server Publishing interface. It is, however, important that the two interfaces are complimentary so that development of appropriate MRB functionality is supported. 5.1. Media Server Resource Publishing Interface The Media Server Resource Publishing interface is responsible for providing an MRB with appropriate Media Server resource information. It is generally accepted that this interface provides 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 fulfil this interface requirement. It provides the perfect establishment and monitoring mechanism to enable a Media Server to report appropriate statistics to an MRB. The Publish interface is used with both Query and In-line modes of MRB operation. As already anticipated in the introduction, the information provided by the Media Server is to be considered a best effort. This means that while the information is assumed to be as exact as possible, it can only be considered a good approximation rather than the exact information. It is clear, in fact, that the accuracy of MRB resource availability will never be exact due to several reasons which include timing issues, computed as opposed to reserved resource consumption (e.g., DSP's with a fixed number of streams versus GPU's with CPU availability), and licensing (e.g., even if lots of CPU and memory are available, licensing or other configuration elements may restrict the number of stream types). This implies that the only way an Application Server can be sure a specific resource is available is to reserve it by establishing a session. For the same reason, the reporting of resources availability has no relation to predictive resource allocation. A typical example of that is a conference Boulton & Miniero Expires March 29, 2010 [Page 13] Internet-Draft Media Resource Brokering September 2009 bridge that allows for oversubscription. The oversubscription must be taken care of at the application layer in the Application Server, since requests to the Media Server must be for the actual number of streams requested. It is also worth noting that, while the scope of the MRB is definitely on providing interested Application Servers with the available resources, the MRB also allows for the retrieval of information about the currently occupied resources. While this is of course a relevant piece of information (e.g. for monitoring purposes), such a functionality inevitably raises security considerations, and implementations should take this into account. See Section 8 for more details. The MRB Publish interface uses the Media Control Channel Framework ([I-D.ietf-mediactrl-sip-control-framework]) 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 which 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 fulfils the mandatory requirement for information that MUST be specified during the definition of a Control Framework Package, as detailed in Section 8 of [I-D.ietf-mediactrl-sip-control-framework]. 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 publishing 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 6. The XML elements in this package are split into requests, responses and event notifications. Requests are carried in CONTROL message bodies; <mrbrequest> element is defined as a package request. Event notifications are also carried in CONTROL message bodies; the Boulton & Miniero Expires March 29, 2010 [Page 14] Internet-Draft Media Resource Brokering September 2009 <mrbnotification> element is defined for package event notifications. Responses are carried either in REPORT message or Control Framework 200 response bodies; the <mrbresponse> element is defined as a package level response. Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of [I-D.ietf-mediactrl-sip-control-framework]) 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.5. 5.1.1.3. Common XML Support The Control Framework requires a Control Package definition to specify if the attributes for media dialog or conference references are required. [Editors Note: *TODO*.] 5.1.1.4. CONTROL Message Body A valid CONTROL body message MUST conform to the schema defined in Section 6 and described in Section 5.1.2. XML messages appearing in CONTROL messages MUST contain either a <mrbrequest> or <mrbnotification> element. 5.1.1.5. REPORT Message Body A valid REPORT body MUST conform to the schema defined in Section 6 and described in Section 5.1.2. XML messages appearing in REPORT messages MUST contain a <mrbresponse> element. 5.1.1.6. Audit *TODO*. [Editors Note: do we really need an Audit section for this package? Auditing is not a mandatory operation in a package, but the framework encourages its use. If we add this here, are we saying that there are things a MRB may or may not do, and auditing tells you about it? Or could it be used as a monitoring entity?] 5.1.1.7. Examples [Editors Note: TODO]. Boulton & Miniero Expires March 29, 2010 [Page 15] Internet-Draft Media Resource Brokering September 2009 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 6. The root element is <mrbpublish>. All other XML elements (requests, responses, notifications) are contained within it. The MRB Publish interface request element is detailed in Section 5.1.3. The MRB Publish interface notification element is detailed in Section 5.1.4. MRB Publish interface response element is contained in Section 5.1.5. The <mrbpublish> element has the following attributes: Version) a token specifying the mrb-publish package version. The value is fixed as '1.0' for this version of the package. The attribute is mandatory. The <mrbpublish> elements has the following child elements, only one of which is allowed to occur. <mrbrequest> for sending an MRB request. See Section 5.1.3. <mrbresponse> for sending an MRB response. See Section 5.1.5. <mrbnotification> for sending an MRB notification. See Section 5.1.4. 5.1.3. <mrbrequest> This section defines the <mrbrequest> element used to initiate requests from an MRB to a Media Server. The element is a container for information relevant for the interrogation of a media server. The <mrbrequest> element has no defined attributes. The <mrbrequest> element has the following sub-elements which are defined in the remainder of this section: <subscription> for initiating a subscription to a Media Server from an MRB. See Section 5.1.3.1. 5.1.3.1. <subscription> The <subscription> element is included in a request from an MRB to a Media Server to provide the details relating to the configuration of updates. The MRB will inform the Media Server how long it wishes to Boulton & Miniero Expires March 29, 2010 [Page 16] Internet-Draft Media Resource Brokering September 2009 receive updates for and the frequency that updates should be sent. Updates are sent using the <mrbnotification> element. [Editors Note: Include more detail on subscription mechanism including responses/reject from MS + polling (not including expires and frequency elements constitutes a poll of the Media Server using a different 'id')]. The <subscription> element has the following attributes: id: indicates a unique token representing the session between the MRB and the Media Server. The attribute is mandatory. seqnumber: indicates a sequence number to be used in conjunction with the session id to identify a specific subscription command. The attribute is mandatory The <subscription> element has the following child elements: expires: Provides the amount of time in seconds that a subscription should be installed for notifications at the Media Server. The element is optional. frequency: Provides the frequency in seconds that the MRB wishes to receive notifications from the MRB. The element is optional. [Editors Note: Next version of the document will have exclude/include lists in MRB requests; the default behaviour is "subscribe me to everything you have", and the MRB package will trigger events saying everything it knows; we could envisage more drill-down requests like: 1) tell me everything (default) 2) tell me everything except... (exclude list) 3) tell me only... (include list) this would only require a change in 'subscriptionType' and optional occurrences in 'mrbnotificationType' for the reported elements; this could allow for more lightweight notifications for entities only interested in a subset of info, or for entities which want different transactions for different info (e.g. "I only need to know about RTP stuff, I don't care about the rest");]. 5.1.4. <mrbnotification> The <mrbnotification> element is included in a request from a Media Server to an MRB to provide the details relating current status. The Media Server will inform the MRB of its current status as defined by the information in the <subscription> element. Updates are sent using the <mrbnotification> element contained in an <mrbrequest> element. Boulton & Miniero Expires March 29, 2010 [Page 17] Internet-Draft Media Resource Brokering September 2009 The <mrbnotification> element has the following attributes: id: indicates a unique token representing the session between the MRB and the Media Server and is the same as the one appearing in the <subscription> element. The attribute is mandatory. seqnumber: indicates a sequence number to be used in conjunction with the session id to identify a specific notification update. The attribute is mandatory The following subsections provide details on the child elements that are contained within an <mrbnotification> element. [Editors Note: What is mandatory to support by Media Servers? Do we want to specify that MS MUST support all elements in the mrbrequest OR should we specify a minumum number of elements]. 5.1.4.1. <media-server-id> The <media-server-id> element provides a unique system wide identifier for a Media Server instance. The element is mandatory. [Editors Note: Need to talk more about unique property.] 5.1.4.2. <active-rtp-sessions> The <active-rtp-sessions> element provides information detailing the current active Real-time Transport Protocol(RTP) sessions. The element is optional. The <active-rtp-sessions> element has no attributes. The <active-rtp-sessions> element has the following child elements: rtp-codec: Is a container which representing a supported codec and the active sessions. The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec being represented. The <rtp-codec> element has two child elements. The child element, <decoding>, represents the number of RTP sessions for the specified codec being decoded. The child element, <encoding>, represents the number of RTP sessions for the specified codec being encoded. 5.1.4.3. <active-mixer-sessions> The <active-mixer-sessions> element provides information detailing the current active mixed RTP sessions. The element is optional. Boulton & Miniero Expires March 29, 2010 [Page 18] Internet-Draft Media Resource Brokering September 2009 The <active-rtp-sessions> element has no attributes. The <active-mixer-sessions> element has the following child elements: active-mix: Is a container which representing a mixed active RTP session. The <active-mix> element has one attribute. The attribute 'conferenceid' represents the name of the mix being represented. The <active-mix> element has one child elements. The child element, <rtp-codec>, contains the same information relating to RTP sessions as defined in Section 5.1.4.2. The element is optional. 5.1.4.4. <non-active-rtp-sessions> The <non-active-rtp-sessions> element provides information detailing the currently available inactive RTP sessions. The element is optional. The <non-active-rtp-sessions> element has no attributes. The <non-active-rtp-sessions> element has the following child elements: rtp-codec: Is a container which representing a supported codec and the inactive sessions. The <rtp-codec> element has one attribute. The attribute 'name' represents the name of the codec being represented. The <rtp-codec> element has two child elements. The first child element, <decoding>, represents the number of available RTP session for the specified codec being decoded. The second child element, <encoding>, represents the number of available RTP sessions for the specified codec being encoded. The element is optional. 5.1.4.5. <non-active-mixer-sessions> The <non-active-mixer-sessions> element provides information detailing the current inactive mixed RTP sessions. The element is optional. The <non-active-rtp-sessions> element has no attributes. The <non-active-mixer-sessions> element has the following child elements: non-active-mix: Is a container which representing an available mixed RTP session. The <non-active-mix> element has one attribute. The attribute 'available' represents the number of mixes that could be used using that profile. The <non-active-mix> Boulton & Miniero Expires March 29, 2010 [Page 19] Internet-Draft Media Resource Brokering September 2009 element has one child elements. The child element, <rtp-codec>, contains the same information relating to RTP sessions as defined in Section 5.1.4.4. The element is optional. 5.1.4.6. <media-server-status> The <media-server-status> element provides information detailing the current status of the media server. The element is mandatory. It can return one of the following values: active: Indicating that the Media Server is available for service. deactivated: Indicating that the Media Server has been withdrawn from service. unavailable: Indicating that the Media Server can not process new requests. The <media-server-status> element has no attributes. The <media-server-status> element has no child elements. [Editors Note: Need to think about status messages and meanings.] The <media-server-status> element has no attributes. The <media-server-status> element has no child elements. 5.1.4.7. <supported-codecs> The <supported-codecs> element provides information detailing the current codecs supported by a media server and associated actions. The element is optional. The <supported-codecs> element has no attributes. The <supported-codecs> element has the following child elements: supported-codec: has a single attribute, 'name', which provides the name of the codec providing information. The <supported-codec> element then has a further child element, <supported-codec- package>. The <supported-codec-package> element has a single attribute, 'name', which provides the name of the Media Control Channel Framework package for which the codec support applies. The <supported-codec-package> element has one further child element, <supported-actions>, which provide the actions that an Media Server can apply to this codec (decode, encode, passthrough). Boulton & Miniero Expires March 29, 2010 [Page 20] Internet-Draft Media Resource Brokering September 2009 5.1.4.8. <application-data> The <application-data> element provides application level data. The element is optional. The <application-data> element has no attributes. The <application-data> element has no child elements. 5.1.4.9. <file-formats> The <file-formats> element provides a list of file formats supported for the purpose of making announcements. The element is optional. The <file-formats> element has no attributes. The <file-formats> element has the following child elements: supported-format: has a single attribute, 'name', which provides the type of file format that is supported. The <supported-format> element then has a further child element, <supported-file- package>. The <supported-file-package> element provides the name of the Media Control Channel Framework package for which the codec support applies. 5.1.4.10. <max-prepared-duration> The <max-prepared-duration> element provides the amount of time a media dialog cane be prepared in the system before it is executed. The element is optional. The <max-prepared-duration> element has no attributes. The <max-prepared-duration> element has the following child elements: max-time: has a single attribute, 'max-time-seconds', which provides the amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has a further child element, <max-time-package>. The <max-time-package> element provides the name of the Media Control Channel Framework package for which the time period applies. 5.1.4.11. <announce-var> The <announce-var> element supplies the supported substitution variables for variable announcements, including digits, dates, costs, etc. The element is optional. Boulton & Miniero Expires March 29, 2010 [Page 21] Internet-Draft Media Resource Brokering September 2009 The <announce-var> element has no attributes. The <announce-var> element has the following child elements: param: has a two attributes, 'name' and 'package'. The 'name' attribute provides the name of the parameter. The 'package' attribute provides the name of the Media Control Channel Framework package for which the parameter applies. The <param> element then has a further child element, <param-value>. The <param-value> element provides the value associated with the parameter. [Editors Note: TODO - the structure of this needs to change to reflect top level of package and the params underneath as a child]. 5.1.4.12. <dtmf-support> The <dtmf-support> element supplies the supported methods to detect DTMF tones and to generate them. The element is optional. The <dtmf-support> element has no attributes. The <dtmf-support> element has the following child elements: detect: has no attributes. The <detect> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes, 'name' and 'package. The 'name' attribute provides the type of DTMF being used. The 'package' attribute provides the name of the Media Control Channel Framework package for which the DTMF type applies. generate: has no attributes. The <generate> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes, 'name' and 'package. The 'name' attribute provides the type of DTMF being used. The 'package' attribute provides the name of the Media Control Channel Framework package for which the DTMF type applies. passthrough: has no attributes. The <passthrough> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes, 'name' and 'package. The 'name' attribute provides the type of DTMF being used. The 'package' attribute provides the name of the Media Control Channel Framework package for which the DTMF type applies. Boulton & Miniero Expires March 29, 2010 [Page 22] Internet-Draft Media Resource Brokering September 2009 5.1.4.13. <mixing-modes> [Editors Note: TODO after further group discussion]. 5.1.4.14. <supported-tones> [Editors Note: TODO after further group discussion]. 5.1.4.15. <streaming-modes> The <streaming-modes> element allows the Media Server to specify which protocols are supported for streaming to a Media Server for each Media Control Channel Framework package type. For example does the Media Server supports audio streaming via RTSP, HTTP, NFS, etc protocols. The element is optional. The <streaming-modes> element has no attributes. The <streaming-modes> element has the following child elements: stream-mode: has a two attributes, 'name' and 'package'. The 'name' attribute provides the type of protocol that can be used for streaming. The 'package' attribute provides the name of the Media Control Channel Framework package for which the streaming protocol applies. 5.1.4.16. <asr-tts-support> [Editors Note: TODO after further group discussion]. 5.1.4.17. <vxml-support> The <vxml-support> element specifies if the Media Server supports VoiceXML and if it does which protocols the support is exposed through (eg via the control framework, or RFC5552). The element is optional. The <vxml-support> element has a single attribute 'support'. The 'support' attribute is of type boolean with a value of 'true' indicating that the media server does support VXML, and a value of 'false' indicating it does not support VXML. The default value is 'false'. The <vxml-support> element has the following child elements: Boulton & Miniero Expires March 29, 2010 [Page 23] Internet-Draft Media Resource Brokering September 2009 vxml-mode: has a two attributes, 'package' and 'support'. The 'package' attribute provides the name of the Media Control Channel Framework package for which the streaming protocol applies. The 'support' attribute provides the type of VXML support provided by the Media Server (RFC5552 or msc-ivr/1.0). 5.1.4.18. <media-server-location> [Editors Note: TODO after further group discussion]. 5.1.4.19. <label> The <label> element allows a Media Server to declare a piece of information that will be understood by the MRB. For example, the Media Server can declare if its a blue or green. Its a string to allow arbitrary values to be returned to allow arbitrary classification. Its arbitrary as opposed to doing it purely on features. The element is optional. The <application-data> element has no attributes. The <application-data> element has no child elements. 5.1.4.20. <media-server-address> The <media-server-address> element allows a Media Server to provide a direct URI address. The <application-data> element has no attributes. The <application-data> element has no child elements. 5.1.4.21. <encryption> [Editors Note: TODO after further group discussion]. 5.1.5. <mrbresponse> Responses to requests are indicated by a <response> element from Section 6. The <response> element has following attributes: status: numeric code indicating the response status. The attribute is mandatory. The following status codes are defined: Boulton & Miniero Expires March 29, 2010 [Page 24] Internet-Draft Media Resource Brokering September 2009 +-----------+-------------------------------------------------------+ | code | description | +-----------+-------------------------------------------------------+ | 200 | OK | +-----------+-------------------------------------------------------+ Table 1: <response> status codes [Editors Note: more status codes to be added + an example.] 5.2. Media Service Resource Consumer Interface The Media Server Consumer interface provides the ability for clients of an MRB, such as Application Servers, to request an appropriate Media Server to satisfy specific criteria. The interface allows a client to pass detailed meta-information to the MRB to help select an appropriate Media Server. The MRB is then able to make and informed decision and provide the client with an appropriate media server resource. It appears the most appropriate interface for such a 'query' style interface is in fact a HTTP usage. Using HTTP and XML combined reduces complexity and encourages use of common tools that are widely available in the industry today. The following subsections explain the main operations required to request and then receive information from an MRB. The following description will describe the use of HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for a query for media resource and the appropriate response. Examples of the interface can be seen in section [ref examples section]. [Editors Note: Need to discuss the updating of a request and proposal of having the client supply updates on resources. For example, releasing resources.] 5.2.1. Media Service Resource Request The media resource query is carried in the body of an HTTP/HTTPS POST request. The MIME type contained in the HTTP/HTTPS request/response should be 'application/mrb-consumer+xml'. This value MUST be reflected in the appropriate HTTP headers like 'Content-Type' and 'Accept'. The body of the POST request MUST only contain the 'mediaResourceRequest' element as defined in Section 7. The 'mediaResourceRequest' element is the primary container of information related to a media resource request and has the following child elements which specify the request parameters: Boulton & Miniero Expires March 29, 2010 [Page 25] Internet-Draft Media Resource Brokering September 2009 5.2.1.1. <mediaResourceRequest> element The <mediaResourceRequest> element provides a container for clients wishing to query an external MRB entity. The <mediaResourceRequest> element has the following child elements that are used to provide appropriate contextual information relating to the request: [Editors Note: Convert groups input into appropriate XML schema.] o RTP requirements - including media/codec type, codec priority. o Conference requirements - number of users. 5.2.2. Media Service Resource Response The use of HTTP/HTTPS for carrying the media service resource information has no impact on the protocol. If protocol level operations and errors occur then they should be signalled as specified in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119]. A successful response to a HTTP POST request containing the 'mediaResourceRequest' MUST be responded to with a 200 OK HTTP/HTTPS response message. This signifies that the request was received, was valid and could be responded to appropriately. If the receiving MRB wishes to generate information for the requesting entity it MUST include a 'mediaResourceResponse' element in the 200 OK HTTP/HTTPS response (as discussed later in this section). An MRB can alternatively return an application level error by including a 'mediaResourceError' element in the 200 OK HTTP/HTTPS response (as discussed later in this section). 5.2.2.1. <mediaResourceResponse> element The <mediaResourceResponse> element provides a container for the MRB to generate a response to a previous query. The <mediaResourceResponse> element has the following child elements that are used to provide appropriate contextual information relating to the request: [Editors Note: Convert groups input into appropriate XML schema.] o list of appropriate media server resources (include individual capabilities). 5.2.2.2. <mediaResourceError> element The <mediaResourceError> element provides a container for the MRB to generate an error response to a previous query. The <mediaResourceError> has element the following child elements that are used to provide appropriate contextual information relating to the request: [Editors Note: Convert groups input into appropriate XML Boulton & Miniero Expires March 29, 2010 [Page 26] Internet-Draft Media Resource Brokering September 2009 schema.] o list of appropriate error response codes. 5.3. In-Line MRB Interface An entity acting as an In-Line MRB can act in one of two roles for a request, as introduced in Section 4.2. The following sub sections provide details for using In-Line Unaware MRB Mode (IUAMM) of operation and In-Line Aware MRB Mode (IAMM) of operation. 5.3.1. In-line Unaware MRB Mode It should be noted that the introduction of an MRB entity into the network, as specified in this document, requires interfaces to be implemented by those requesting media server resources (for example an application server). This applies when using both the Consumer interface as discussed in Section 5.2 and IAMM. It is for this reason that an MRB is able to act in a client unaware mode when it is deployed into the network. This allows any SIP compliant client entity, as defined by RFC 3261 [RFC3261] and its extensions, to send requests to an MRB and it will select an appropriate media server based on knowledge of media server resources it currently has available. Mechanisms used to connect to media servers are detailed in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. Using an MRB in this mode allows for easy migration of current applications and services that are unaware of the MRB concept and would simply require a configuration change resulting in the MRB being set as a SIP outbound proxy for clients requiring media services. Any client of media services wishing to take advantage of the advanced techniques detailed in this document when using In-line mode would implement IAMM which is covered in Section 5.3.2. The techniques used for selecting an appropriate Media Server by an MRB acting in IUMM is outside the scope of this document. 5.3.2. In-line Aware MRB Mode An In-Line Aware Mode MRB (IAMM) is one that complies to the extended functionality provided in this section. A client entity, such as an application server, wishing to use advanced MRB functionality can provide additional contextual information to an MRB. This information is identical to that used in the Consumer interface in Section 5.2 with the only difference being the underlying transport mechanism of the contextual information, as specified by the 'application/mrb-consumer+xml' payload in Section 7. A client of an IAMM uses SIP signalling to convey the 'application/mrb-consumer+xml' payload to the IAMM. The Consumer interface, as specified in Boulton & Miniero Expires March 29, 2010 [Page 27] Internet-Draft Media Resource Brokering September 2009 Section 5.2 , uses HTTP. A client of an IAMM requiring media services, as well as creating a standard SIP complaint request, MUST use the following steps to ensure that the request is dealt with appropriately: o The client of the IAMM constructs a SIP INVITE request to connect to a Media Server as detailed in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework] with one exception. o The client of the IAMM includes a MIME content type of multipart/ mixed as defined in RFC 2046 [RFC2046]. As part of this mixed payload, the client MUST at least include a content-type of type 'application/sdp' and a content type of type 'application/ mrb-consumer+xml'. The part of type application/sdp represents the media server connection details and MUST adhere to the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. The part of type 'application/mrb-consumer+xml' represents the IAMM contextual information and MUST adhere to the schema defined in Section 7. o Once the SIP INVITE request is constructed, it is sent to the recipient as per RFC 3261 [RFC3261]. [EDITORS NOTE: Include example of valid IAMM payload.] On receiving a SIP INVITE request containing the multipart mixed payload as specified previously, the IAMM will complete a number of steps to fulfil the request. It will: o Extract the multipart MIME payload from the SIP INVITE request. It will then use the contextual information provided by the client in the 'application/mrb-consumer+xml' part to determine which media server should be selected to service the request. o Extract the 'application/sdp' part from the payload and use it to populate a new SIP INVITE request for connecting the client to the selected media server, as defined in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. The IAMM acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/ mrb-consumer+xml' information from the SIP INVITE request and then forwards to the selected Media Server. [Editors Note: Consumer interface has a proposal to update a request for media services based on HTTP. There are times when an application server might want to override the MS view of resources. For example, a conference where participants leave and can rejoin. Need to decide if this use of consumer XML should also allow for Boulton & Miniero Expires March 29, 2010 [Page 28] Internet-Draft Media Resource Brokering September 2009 updates using SIP reINVITE and UPDATE.] Boulton & Miniero Expires March 29, 2010 [Page 29] Internet-Draft Media Resource Brokering September 2009 6. Media Service Resource Publisher Interface XML Schema This section gives the XML Schema Definition [W3C.REC-xmlschema-1- 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ mrb-publish+xml" format. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish" elementFormDefault="qualified" blockDefault="#all" xmlns="urn:ietf:params:xml:ns:mrb-publish" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation> IETF MediaCtrl MRB 1.0 This is the schema of the IETF MediaCtrl MRB package. The schema namespace is urn:ietf:params:xml:ns:mrb-publish </xsd:documentation> </xsd:annotation> <!-- ############################################################# SCHEMA IMPORTS ############################################################# --> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xsd:annotation> <xsd:documentation> This import brings in the XML attributes for xml:base, xml:lang, etc </xsd:documentation> </xsd:annotation> </xsd:import> <xsd:import namespace="urn:ietf:params:xml:ns:control:framework-attributes" schemaLocation="framework.xsd"> <xsd:annotation> Boulton & Miniero Expires March 29, 2010 [Page 30] Internet-Draft Media Resource Brokering September 2009 <xsd:documentation> This import brings in the framework attributes for conferenceid and connectionid. </xsd:documentation> </xsd:annotation> </xsd:import> <!-- ##################################################### Extensible core type ##################################################### --> <xsd:complexType name="Tcore"> <xsd:annotation> <xsd:documentation> This type is extended by other (non-mixed) component types to allow attributes from other namespaces. </xsd:documentation> </xsd:annotation> <xsd:sequence/> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> <!-- ##################################################### TOP LEVEL ELEMENT: mrbpublish ##################################################### --> <xsd:complexType name="mrbpublishType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:choice> <xsd:element ref="mrbrequest" /> <xsd:element ref="mrbresponse" /> <xsd:element ref="mrbnotification" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:choice> </xsd:sequence> Boulton & Miniero Expires March 29, 2010 [Page 31] Internet-Draft Media Resource Brokering September 2009 <xsd:attribute name="version" type="version.datatype" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="mrbpublish" type="mrbpublishType" /> <!-- ##################################################### mrbrequest TYPE ##################################################### --> <!-- mrbrequest --> <xsd:complexType name="mrbrequestType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="subscription" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="mrbrequest" type="mrbrequestType" /> <!-- subscription --> <xsd:complexType name="subscriptionType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="expires" type="xsd:nonNegativeInteger" minOccurs="0" maxOccurs="1" /> <xsd:element name="frequency" type="xsd:nonNegativeInteger" minOccurs="0" maxOccurs="1" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="id" type="id.datatype" use="required" /> Boulton & Miniero Expires March 29, 2010 [Page 32] Internet-Draft Media Resource Brokering September 2009 <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="subscription" type="subscriptionType" /> <!-- ##################################################### mrbresponse TYPE ##################################################### --> <!-- mrbresponse --> <xsd:complexType name="mrbresponseType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="status" type="status.datatype" use="required" /> <xsd:attribute name="reason" type="xsd:string" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="mrbresponse" type="mrbresponseType" /> <!-- ##################################################### mrbnotification TYPE ##################################################### --> <!-- mrbnotification --> Boulton & Miniero Expires March 29, 2010 [Page 33] Internet-Draft Media Resource Brokering September 2009 <xsd:complexType name="mrbnotificationType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence <xsd:element ref="media-server-id" type="subscriptionid.datatype"/> <xsd:element ref="active-rtp-sessions" minOccurs="0" /> <xsd:element ref="active-mixer-sessions" minOccurs="0" /> <xsd:element ref="non-active-rtp-sessions" minOccurs="0" /> <xsd:element ref="non-active-mixer-sessions" minOccurs="0" /> <xsd:element ref="media-server-status" minOccurs="0" /> <xsd:element ref="supported-codecs" minOccurs="0" /> <xsd:element ref="application-data" minOccurs="0" maxOccurs="unbounded" /> <xsd:element ref="file-formats" minOccurs="0" /> <xsd:element ref="max-prepared-duration" minOccurs="0" /> <xsd:element ref="announce-var" minOccurs="0" /> <xsd:element ref="dtmf-support" minOccurs="0" /> <xsd:element ref="mixing-modes" minOccurs="0" /> <xsd:element ref="supported-tones" minOccurs="0" /> <xsd:element ref="streaming-modes" minOccurs="0" /> <xsd:element ref="asr-tts-support" minOccurs="0" /> <xsd:element ref="vxml-support" minOccurs="0" /> <xsd:element ref="media-server-location" minOccurs="0" /> <xsd:element ref="label" minOccurs="0" /> <xsd:element ref="media-server-address" minOccurs="0" /> <xsd:element ref="encryption" minOccurs="0" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="id" type="subscriptionid.datatype" use="required" /> <xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="mrbnotification" type="mrbnotificationType" /> <!-- active-rtp-sessions --> <xsd:complexType name="active-rtp-sessionsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="rtp-codec" minOccurs="0" maxOccurs="unbounded" /> Boulton & Miniero Expires March 29, 2010 [Page 34] Internet-Draft Media Resource Brokering September 2009 <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/> <xsd:complexType name="rtp-codecType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="decoding" type="xsd:nonNegativeInteger" /> <xsd:element name="encoding" type="xsd:nonNegativeInteger" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="rtp-codec" type="rtp-codecType" /> <!-- active-mixer-sessions --> <xsd:complexType name="active-mixer-sessionsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="active-mix" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="active-mixer-sessions" type="active-mixer-sessionsType" /> Boulton & Miniero Expires March 29, 2010 [Page 35] Internet-Draft Media Resource Brokering September 2009 <xsd:complexType name="active-mixType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="rtp-codec" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attributeGroup ref="fw:framework-attributes" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="active-mix" type="active-mixType" /> <!-- non-active-rtp-sessions --> <xsd:complexType name="non-active-rtp-sessionsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="rtp-codec" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="non-active-rtp-sessions" type="non-active-rtp-sessionsType" /> <!-- non-active-mixer-sessions --> <xsd:complexType name="non-active-mixer-sessionsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="non-active-mix" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> Boulton & Miniero Expires March 29, 2010 [Page 36] Internet-Draft Media Resource Brokering September 2009 <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="non-active-mixer-sessions" type="non-active-mixer-sessionsType" /> <xsd:complexType name="non-active-mixType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="rtp-codec" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="available" type="xsd:nonNegativeInteger" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="non-active-mix" type="non-active-mixType" /> <!-- media-server-status --> <xsd:element name="status" type="msstatus.datatype" /> <!-- supported-codecs --> <xsd:complexType name="supported-codecsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="supported-codec" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="supported-codecs" type="supported-codecsType" /> <xsd:complexType name="supported-codecType"> Boulton & Miniero Expires March 29, 2010 [Page 37] Internet-Draft Media Resource Brokering September 2009 <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="supported-codec-package" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="supported-codec" type="supported-codecType" /> <xsd:complexType name="supported-codec-packageType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="supported-actions" type="actions.datatype" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="supported-codec-package" type="supported-codec-packageType" /> <!-- application-data --> <xsd:element name="application-data" type="appdata.datatype" /> <!-- file-formats --> <xsd:complexType name="file-formatsType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="supported-format" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" Boulton & Miniero Expires March 29, 2010 [Page 38] Internet-Draft Media Resource Brokering September 2009 maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="file-formats" type="file-formatsType" /> <xsd:complexType name="supported-formatType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="supported-file-package" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="supported-format" type="supported-formatType" /> <xsd:complexType name="supported-file-packageType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="supported-file-package-name" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="supported-file-package" type="supported-file-packageType" /> <!-- max-prepared-duration --> <xsd:complexType name="max-prepared-durationType"> <xsd:complexContent> <xsd:extension base="Tcore"> Boulton & Miniero Expires March 29, 2010 [Page 39] Internet-Draft Media Resource Brokering September 2009 <xsd:sequence> <xsd:element ref="max-time" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="max-prepared-duration" type="max-prepared-durationType" /> <xsd:complexType name="max-timeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="max-time-package" type="xsd:string" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="max-time" type="max-timeType" /> <!-- announce-var --> <xsd:complexType name="announce-varType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="param" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="announce-var" type="announce-varType" /> Boulton & Miniero Expires March 29, 2010 [Page 40] Internet-Draft Media Resource Brokering September 2009 <xsd:complexType name="paramType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element name="param-value" type="xsd:NMTOKEN" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="param" type="paramType" /> <!-- dtmf-support --> <xsd:complexType name="dtmf-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="detect" /> <xsd:element ref="generate" /> <xsd:element ref="passthrough" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="dtmf-support" type="dtmf-supportType" /> <xsd:complexType name="detectType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> Boulton & Miniero Expires March 29, 2010 [Page 41] Internet-Draft Media Resource Brokering September 2009 </xsd:complexContent> </xsd:complexType> <xsd:element name="detect" type="detectType" /> <xsd:complexType name="generateType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="generate" type="generateType" /> <xsd:complexType name="passthroughType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="dtmf-type" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="passthrough" type="passthroughType" /> <xsd:complexType name="dtmf-typeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="dtmf.datatype" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> Boulton & Miniero Expires March 29, 2010 [Page 42] Internet-Draft Media Resource Brokering September 2009 </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="dtmf-type" type="dtmf-typeType" /> <!-- mixing-modes --> <!-- **** TODO **** --> <!-- supported-tones --> <!-- **** TODO **** --> <!-- streaming-modes --> <xsd:complexType name="stream-modesType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="stream-mode" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="stream-modes" type="stream-modesType" /> <xsd:complexType name="stream-modeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="name" type="streammode.datatype" use="required" /> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> Boulton & Miniero Expires March 29, 2010 [Page 43] Internet-Draft Media Resource Brokering September 2009 <xsd:element name="stream-mode" type="stream-modeType" /> <!-- asr-tts-support --> <!-- **** TODO **** --> <!-- vxml-support --> <xsd:complexType name="vxml-supportType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:element ref="vxml-mode" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="support" type="boolean.datatype" default="false" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="vxml-support" type="vxml-supportType" /> <xsd:complexType name="vxml-modeType"> <xsd:complexContent> <xsd:extension base="Tcore"> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:attribute name="package" type="xsd:string" use="required" /> <xsd:attribute name="support" type="vxml.datatype" use="required" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="vxml-mode" type="vxml-modeType" /> <!-- media-server-location --> <!-- **** TODO **** --> <!-- label --> Boulton & Miniero Expires March 29, 2010 [Page 44] Internet-Draft Media Resource Brokering September 2009 <xsd:element name="label" type="label.datatype" /> <!-- media-server-address --> <xsd:element name="ms-address" type="xsd:anyURI" /> <!-- encryption --> <!-- **** TODO **** --> <!-- #################################################### DATATYPES #################################################### --> <xsd:simpleType name="version.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="1.0" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="id.datatype"> <xsd:restriction base="xsd:NMTOKEN" /> </xsd:simpleType> <xsd:simpleType name="status.datatype"> <xsd:restriction base="xsd:positiveInteger"> <xsd:pattern value="[0-9][0-9][0-9]" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="msstatus.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="active" /> <xsd:enumeration value="deactivated" /> <xsd:enumeration value="unavailable" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="actions.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="encoding" /> <xsd:enumeration value="decoding" /> Boulton & Miniero Expires March 29, 2010 [Page 45] Internet-Draft Media Resource Brokering September 2009 <xsd:enumeration value="passthrough" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="appdata.datatype"> <xsd:restriction base="xsd:NMTOKEN" /> </xsd:simpleType> <xsd:simpleType name="dtmf.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="INFO" /> <xsd:enumeration value="RFC4733" /> <xsd:enumeration value="Media" /> </xsd:restriction> </xsd:simpleType> <!-- *** TODO-Look at values **** --> <xsd:simpleType name="streammode.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="RTSP" /> <xsd:enumeration value="HTTP" /> <xsd:enumeration value="NFS" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="boolean.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="true" /> <xsd:enumeration value="false" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="vxml.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="RFC5552" /> <xsd:enumeration value="IVR-Package" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="label.datatype"> <xsd:restriction base="xsd:NMTOKEN" /> </xsd:simpleType> </xsd:schema> Figure 9 Boulton & Miniero Expires March 29, 2010 [Page 46] Internet-Draft Media Resource Brokering September 2009 7. Media Service Resource Consumer Interface XML Schema This section gives the XML Schema Definition [W3C.REC-xmlschema-1- 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ mrb-consumer+xml" format. <?xml version="1.0"?> <xsd:schema targetNamespace="urn:ietf:params:xml:ns:mediactrl:mrb" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:mrb="urn:ietf:params:xml:ns:mediactrl:mrb" xmlns:xml="http://www.w3.org/XML/1998/namespace" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xsd:element name="mrb-message" type="mrb-message-type" /> <xsd:complexType name="mrb-message-type"> <xsd:sequence> <xsd:choice> <xsd:element name="mediaResourceRequest" type="mrb:mediaResourceRequestType"/> <xsd:element name="mediaResourceResponse" type="mrb:mediaResourceResponseType"/> <xsd:element name="mediaResourceError" type="mrb:mediaResourceErrorType"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:choice> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> <xsd:complexType name="mediaResourceRequestType"> <xsd:complexContent> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexContent> </xsd:complexType> Boulton & Miniero Expires March 29, 2010 [Page 47] Internet-Draft Media Resource Brokering September 2009 <xsd:complexType name="mediaResourceResponseType"> <xsd:complexContent> <xsd:sequence> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="mediaResourceErrorType"> <xsd:complexContent> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:any namespace="##other" processContents="strict"/> </xsd:choice> <xsd:attribute name="status" type="status.datatype" use="required"/> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexContent> </xsd:complexType> <!-- DATATYPES --> <xsd:simpleType name="status.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:pattern value="[0-9][0-9][0-9]"/> </xsd:restriction> </xsd:simpleType> </xsd:complexContent> </xsd:complexType> </xsd:schema> Figure 10 Boulton & Miniero Expires March 29, 2010 [Page 48] Internet-Draft Media Resource Brokering September 2009 8. Security Considerations Security Considerations to be included in later versions of this document. Boulton & Miniero Expires March 29, 2010 [Page 49] Internet-Draft Media Resource Brokering September 2009 9. IANA Considerations IANA Considerations to be included in later versions of this document. Boulton & Miniero Expires March 29, 2010 [Page 50] Internet-Draft Media Resource Brokering September 2009 10. Changes Note to RFC Editor: Please remove this whole section. 10.1. Changes from 01 Version o Included In-line text based on strawman proposal. o Included first attempt at publish interface based on design team work. Boulton & Miniero Expires March 29, 2010 [Page 51] Internet-Draft Media Resource Brokering September 2009 11. Acknowledgments The authors would like to thank the members of the Publish Interface design team who provided valuable input into this document. The design team consisted of Gary Munson, Adnan Saleem, Michael Trank, Victor Paulsamy, Martin Dolly, and Scott McGlashan. Boulton & Miniero Expires March 29, 2010 [Page 52] Internet-Draft Media Resource Brokering September 2009 12. References 12.1. Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [W3C.CR-wsdl20-20051215] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", W3C CR CR-wsdl20-20051215, December 2005. [W3C.REC-soap12-part1-20030624] Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1- Boulton & Miniero Expires March 29, 2010 [Page 53] Internet-Draft Media Resource Brokering September 2009 20030624, June 2003, <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. [W3C.REC-soap12-part2-20030624] Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium FirstEdition REC-soap12-part2-20030624, June 2003, <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. 12.2. Informative References [I-D.ietf-mediactrl-architecture] Melanchuk, T., "An Architectural Framework for Media Server Control", draft-ietf-mediactrl-architecture-04 (work in progress), November 2008. [I-D.ietf-mediactrl-requirements] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", draft-ietf-mediactrl-requirements-04 (work in progress), February 2008. [I-D.ietf-mediactrl-sip-control-framework] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", draft-ietf-mediactrl-sip-control-framework-10 (work in progress), February 2009. Boulton & Miniero Expires March 29, 2010 [Page 54] Internet-Draft Media Resource Brokering September 2009 Authors' Addresses Chris Boulton NS-Technologies Email: chris@ns-technologies.com Lorenzo Miniero University of Napoli Email: lorenzo.miniero@unina.it Boulton & Miniero Expires March 29, 2010 [Page 55]