MEDIACTRL WG D. Sisalem Internet-Draft V. Pascual Intended status: BCP Tekelec Expires: March 25, 2010 September 21, 2009 MRB-Media Server Interaction Mechanisms draft-sisalem-mediactrl-mrbctrl-00 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 25, 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. Abstract The MediaCtrl work group in the IETF is currently working on an architecture for controlling media services. As part of the MediaCtrl architecture the Media Resource Broker (MRB) was identified Sisalem & Pascual Expires March 25, 2010 [Page 1] Internet-Draft MRB Control September 2009 as the component needed for intelligent, application level media service selection based on non-static signaling properties. This document defines the mechanisms needed by the media servers to publish their capabilities and the mechanisms needed by the MRB to monitor the status of the media servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Publishing of Media Server Capabilities . . . . . . . . . . . . 4 3.1. Media Server Publish Request . . . . . . . . . . . . . . . 5 3.2. Media Server Publish Response . . . . . . . . . . . . . . . 5 4. Media Server Status Reporting . . . . . . . . . . . . . . . . . 6 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 Sisalem & Pascual Expires March 25, 2010 [Page 2] Internet-Draft MRB Control September 2009 1. Introduction The MediaCtrl work group examines the protocols used for the communication between media servers and their clients, e.g., application servers. The MediaCtrl Requirements [I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture [I-D.ietf-mediactrl-architecture] documents indicate that it should be possible to have a many-to-many relationship between Application Servers and Media Servers. To enable the Application Servers to find the appropriate Media Server required for offering a certain service, the Application Servers must have an overview of all the available Media Servers, the capabilities of these servers as well their status. To relieve the Application servers from having to Keep an up-to-date overview of Media Servers, the Media Resource Broker (MRB) is being discussed in the MediaCtrl work group. The MRB will be located between the Application Servers and the Media servers and will have the responsibility of receiving requests from the Application Servers for certain services and deciding which Media Server should be handling this request. The tasks of a Media Resource Broker (MRB) can be summarized as follows: - Receive and process requests for service from Application Servers. - Make a decision on which Media Server can best handle the requested service. This decision can be made by matching the capabilities of the Media Server with the requested service, status of the Media Servers in terms of load or availability and policies defined by the operator of the MRB related to costs, quality of service, subscriber identity or time of day for example - Reply to the Application Server with regard to the made choice (Query Mode), or forward the request to the chosen Media Server (Inline Mode), see [I-D.ietf-mediactrl-mrb] for more details on the Query and In-Line modes As the basis for making a decision about which Media Server should handle a certain request the MRB requires from the Media Servers two types of information: - List of capabilities: This includes information about the name and address of the Media Server, the types of supported services, the supported features and capacity for example. - Status: Status information describe the current state of a Media Server in terms of load and available capacity. Without this Sisalem & Pascual Expires March 25, 2010 [Page 3] Internet-Draft MRB Control September 2009 information, the MRB might decide to use an overloaded Media Server. For the MRB to collect this information, the interface between the MRB and the Media Servers must enable the Media servers to publish their capabilities and to exchange information about their status with the MRB. This draft addresses possible mechanisms for realizing both the publishing and status reporting processes. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. The other concepts and terminology used in this document are compatible with [RFC3261]. This document inherits terminology proposed in the MediaCtrl Requirements [I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture [I-D.ietf-mediactrl-architecture] documents as well as the terms defined in [I-D.ietf-mediactrl-mrb] which include: - 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. 3. Publishing of Media Server Capabilities In order for an MRB to use an MS it needs to know about the existence, address and the capabilities of the MS. The MS will publish its information only infrequently, namely after starting and after a change in configuration. To keep the interface between the MRB and MS simple it seems that using HTTP would be the most appropriate solution. Including the MS information as XML with HTTP results in a simple solution that uses common standards and tools Sisalem & Pascual Expires March 25, 2010 [Page 4] Internet-Draft MRB Control September 2009 that are already available. In the following sections the use of HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2818] as transport for publishing the MS capabilities is described. 3.1. Media Server Publish Request The MS includes the description of its capabilities in the body of an HTTP/HTTPS POST request. The MIME type contained in the HTTP/HTTPS request/reponse should be 'application/ms+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 'mediaServerPublishRequest' element. The 'mediaServerPublishRequest' element is the primary container of information related to a media server publish request. In general Media Server Publish Request can include information about: - Name and location: Information about the location of the server such as a URI or IP address - Services: What kind of services are supported such as conferencing, IVR, etc. - Features: What specific features the MS provides for the supported services. For example in the case the MS provides IVR services then the list of features might include support for VXML for IVR services, length of announcements, supported languages, etc. - Capacity: Number of supported parallel calls as well as the rate of accepted calls The details of the element are TBD. 3.2. Media Server Publish Response If an HTTP POST request containing the 'mediaRerverPublishRequest' can be processed successfully then the MRB MUST respond to the MS with a 200 OK HTTP/HTTPS response message. This indicates that the request was received and processed. If processing the request resulted in an error, mis-formatted content or unrecognizable content- the MRB MUST return an application level error by including a 'mediaServerPublishError' element in the 200 OK HTTP/HTTPS response. The details of this element are TBD. Note that the use of HTTP/HTTPS for carrying the Media Server 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 [RFC2818]. This signifies that the request was received, was valid and could be responded appropriately. Sisalem & Pascual Expires March 25, 2010 [Page 5] Internet-Draft MRB Control September 2009 4. Media Server Status Reporting To be able to load balance incoming requests between different Media Servers, the MRB will need information about the load and capacity of the available Media Servers. This is needed to ensure that an overloaded server does not receive even more requests and ends up dropping these requests while other servers still have idle capacity. In the context of overload control [I-D.hilt-sipping-overload] already describes two mechanisms that enable SIP entities to exchange information about their load status. These mechanisms are shortly described below: - SIP Response Header: Media Servers add an "oc" parameter to the topmost Via header field in responses sent to the MRB. The value of the "oc" parameter describes the load of the MS, see [I-D.hilt-sipping-overload] - SIP Event Package: With this approach the MRB subscribes to the load status of the MS and the MS notifies the MRB regularly about its load status. This information is then used to identify overloaded Media Servers and achieve better load distribution. 5. Summary A Media Resource Broker has to collect information about the capabilities of Media Servers as well as be able to monitor the status of these servers. This draft suggests using HTTP/HTTPS in order to enable the Media Servers to publish their capabilities. In order to monitor the status of the Media Servers we suggest using the mechanisms proposed for exchanging overload information. By using mechanisms that the MRB and the Media Servers are expected to be implementing anyway, the overall implementation complexity of communication protocols between the the MRB and the Media Servers is minimized. 6. Security Considerations The proposed mechanism for publishing the Media Server capabilities will be considered later. The proposed mechanisms for monitoring the load of Media Servers have the same security consideration as those reported in [I-D.hilt-sipping-overload] Sisalem & Pascual Expires March 25, 2010 [Page 6] Internet-Draft MRB Control September 2009 7. IANA Considerations TBD 8. Acknowledgments TBD 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [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. [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-architecture] Melanchuk, T., "An Architectural Framework for Media Server Control", draft-ietf-mediactrl- architecture-04 (work in progress), November 2008. [I-D.ietf-mediactrl-mrb] Boulton, C. and L. Miniero, "Media Resource Brokering", draft-ietf-mediactrl-mrb-00 (work in progress), May 2009. Sisalem & Pascual Expires March 25, 2010 [Page 7] Internet-Draft MRB Control September 2009 [I-D.hilt-sipping-overload] Hilt, V., Widjaja, I., and H. Schulzrinne, "Session Initiation Protocol (SIP) Overload Control", draft-hilt-sipping-overload-06 (work in progress), March 2009. Appendix A. Change Log New Document Authors' Addresses D. Sisalem Tekelec Am Borsigturm 11 Berlin Germany EMail: sisalem@iptel.org V. Pascual Tekelec Am Borsigturm 11 Berlin Germany EMail: victor@iptel.org Sisalem & Pascual Expires March 25, 2010 [Page 8]