Network Working Group J. Van Dyke Internet Draft E. Burger Document: draft-burger-sipping-msuri-00.txt SnowShore Networks, Inc. Category: Standards Track July 12, 2001 Expires: January 2002 SIP URI Conventions for Media Servers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 document is the result of a chartered SIPPING work group item. 1. Abstract Application Servers, SIP Proxies, and SoftSwitches (a.k.a. Media Gateway Controllers) act as SIP [2] User Agents to control the media processing capabilities of media servers. The SIP Request URI identifies the desired service and provides a context for the media server to interpret the SIP message. This document describes a standard SIP addressing mechanism to address specific services. Because of SIP's flexibility, the existing protocol accommodates these services. This document proposes a standard URI scheme for important media services such as announcements and conferencing. Van Dyke Draft û Expires 1/12/02 1 SIP Media Server URI Conventions July 2001 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. FORMATTING NOTE: Notes, such at this one, provide additional, nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. Table of Contents 1. Abstract...........................................................1 2. Conventions used in this document..................................2 3. Overview...........................................................2 4. Service Indicators.................................................3 5. Operation..........................................................3 6. Formal Syntax......................................................4 7. Security Considerations............................................4 8. IANA Considerations................................................5 9. Examples...........................................................5 9.1. Announcement.....................................................5 9.2. Conference.......................................................6 10. References........................................................6 11. Acknowledgments...................................................7 12. Author's Addresses................................................7 3. Overview Media servers are devices that perform media processing on real-time packet media. Examples of such processing are tone detection and generation, packet recording (usually with transcoding), packet playing (usually with transcoding û also known as prompting), and mixing (also known as conferencing). In the context of SIP control of media servers, we take advantage of the fact that the standard SIP URI has a user part [2]. Media servers do not have a concept of a user. Thus we use the user address, or the left-hand-side of the URI, as a service indicator. For per-service security, the media server MAY require a per-service password. If the media server does require a per-service password, the client encodes the password in the SIP URI as if it was a user Van Dyke Expires 1/12/2002 2 SIP Media Server URI Conventions July 2001 password. That is, the password is the right-hand side of the user address part (left-hand side) of the SIP URI, separated from the user address part by a colon. This can be particularly useful for password protecting service instances. Following [2], the media server MAY issue 401 challenges for authentication. The media server, upon receiving the INVITE, notes the service indicator. Depending on the service indicator, the media server will either honor the request or return a failure response code. 4. Service Indicators The service indicator is the concatenation of the service name and an optional service instance identifier, separated by an equal sign. Per [2], the service indicator is case insensitive. The service name MUST be from the set alphanumeric characters plus dash (US- ASCII %2C). The service name MUST NOT include an equal sign (US- ASCII %3C). The service name MAY have long- and short-forms, as SIP does for headers. This document reserves service names starting with "X-" or "x-" for experimental or non-standard services. Standard service indicators MUST NOT begin with "X-" or "x-". A given service indicator MAY have an associated set of parameters. Such parameters MUST follow the convention set out in [2] for SIP URI parameters. That is, a semi-colon separated list of keyword=values. Certain services may have an association with a unique service instance on the media server. For example, a given media server can host multiple, separate conference sessions. To identify unique service instances, a unique identifier modifies the service name. The unique identifier MUST meet the rules for a legal user part of a SIP URI as set out in [2]. An equal sign, US-ASCII %3D, MUST separate the service indicator from the unique identifier. Note that since the service indicator is case insensitive per [2], the service instance identifier is also case insensitive. 5. Operation The requesting client issues a SIP INVITE to the media server, specifying the requested service and any appropriate parameters. Van Dyke Expires 1/12/2002 3 SIP Media Server URI Conventions July 2001 If the media server can perform the requested service, it does so, following the processing steps described in the service definition document (see IANA Considerations, below). If the media server cannot perform the requested service or does not recognize the service indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to a problem with the user part of the URI. Moreover, 608 is not appropriate, as some other media server may be able to satisfy the request. [4] describes the 488 and 608 response codes. Some services require a unique identifier. Most services automatically create a service instance upon the first INVITE with the given identifier. However, if a service requires an existing service instance, and no such service instance exists on the media server, the media server MUST respond with the response code 404 NOT FOUND. This is appropriate as the service itself exists on the media server, but the particular service instance does not. It is as if the user was not home. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [5]. SERVICE-URL = "sip:" srvc-ind "@" hostport url-parameters [headers] srvc-ind = srvc [ ":" password ] srvc = srvc-name [ "=" instanceId ] srvc-name = "annc" | "conf" | token | x-token x-token = ( "X-" | "x-" ) token instanceId = token Section 2 of [2] defines the elements password, hostport, and token. See the IANA Considerations section for procedures for adding new service indicators. 7. Security Considerations The security issues are the same as for SIP [4], as the media server is simply a SIP User Agent. Van Dyke Expires 1/12/2002 4 SIP Media Server URI Conventions July 2001 8. IANA Considerations This document describes an extensible set of SIP Media Server Service Indicator types. To promote interoperability and coherent interpretations of different types, we need a central repository for well-known service indicator types. IANA will create a repository for service indicator types called "SIP Media Server Service Indicator Types". Following the policies outlined in [6], this repository is "Specification Required by RFC." The documents [7] and [9] describe the initial values for the repository. For reference, the values are as follows. NOTE: We already have another indicator type for transcoding, but the draft isn't baked yet. SIP Media Server Service Indicator Types ======================================== Value Meaning Reference ----- -------------- --------- Parameter Values ----------- ------ annc Announcement Service draft-ietf-sipping-netann-00.txt play= URI early= ( "yes" | "no" ) conf Conference Service draft-ietf-sipping-conference-00.txt 9. Examples These examples are informative. For the normative definitions of the given services, see the referenced documents. NOTE: The line wrapping (backslash, CRLF, and spacing before continued lines) in the examples is for readability purposes only. 9.1. Announcement The document [7] fully specifies the announcement service. In brief, the announcement service can play a prompt as early media or after the establishment of a connection. The announcement service indicator is "annc". The parameters are "play" which specifies an audio resource and "early" which specifies whether to play the announcement as early media or after connection establishment. Van Dyke Expires 1/12/2002 5 SIP Media Server URI Conventions July 2001 In the following example, the media server at ms2.carrier.net retrieves an audio file using HTTP [8] from the server prompts.carrier.net and plays it as early media. sip:annc@ms2.carrier.net; \ play=http://prompts.carrier.net/audio/allcircuitsbusy.g711; \ early=yes 9.2. Conference The document [9] fully specifies the conference service. In brief, the conference service creates a conference upon the first instance of a unique service instance identifier. The media server places subsequent requests with the same service instance identifier into a conference. The conference service indicator is "conf". There are no parameters for the conference service. In the following example, the media server at ms2.carrier.net creates (or places into conference) the stream associated with the SDP in the INVITE to the conference identified by the identifier "q4unfcqdscQS". sip:conf=q4unfcqdscQS@ms2.carrier.net 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: Session Initiation Protocol", RFC 2543, March 1999. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4 Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt, May 2001, work in progress. 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 6 Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Van Dyke Expires 1/12/2002 6 SIP Media Server URI Conventions July 2001 7 O'Connor, W., Burger, E., "Network Announcements with SIP", draft-ietf-sipping-netann-00.txt, July 2001, work in progress. 8 Fielding, R., Gettys, D., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 9 Van Dyke, J. and Burger, E., "Conference Bridging with SIP", draft-ietf-sipping-conference-00.txt, July 2001, work in progress. 11. Acknowledgments 12. Author's Addresses J. Jeff Van Dyke SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: +1 978/367-8405 Email: jvandyke@snowshore.com Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: +1 978/367-8403 Email: eburger@snowshore.com Van Dyke Expires 1/12/2002 7 SIP Media Server URI Conventions July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement The Internet Society currently provides funding for the RFC Editor function. Van Dyke Expires 1/12/2002 8