Network Working Group                                     J. Van Dyke 
Internet Draft                                              E. Burger 
Document: draft-burger-sipping-msuri-01.txt  SnowShore Networks, Inc. 
Category: Standards Track                           November 21, 2001 
Expires: May 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. 
    
   Discussion of this document is on the SIPPING discussion list.  The 
   SIPPING list is at <mailto:sipping-request@ietf.org>. 
    
 
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 5/21/02                      1 
                   SIP Media Server URI Conventions      November 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 Definition.................................................3 
5. Service Indicators and URI Signatures..............................3 
6. Operation..........................................................4 
7. Formal Syntax......................................................5 
8. Security Considerations............................................5 
9. IANA Considerations................................................5 
10. Examples..........................................................6 
10.1. Announcement....................................................6 
10.2. Conference......................................................7 
11. References........................................................7 
12. Changes Made in Version 01........................................8 
13. Acknowledgments...................................................8 
14. Author's Addresses................................................8 
    
    
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). 
    
   These services are of general utility to a wide array of SIP UA's 
   including application servers, softswitches and proxy servers.  In 
   addition, the behaviors and semantics of these services are well 
   understood.  For these reasons, it is both desirable and possible to 
   create standard SIP interfaces for these services. 
  
Van Dyke                  Expires 5/21/2002                         2 
                   SIP Media Server URI Conventions      November 2001 
 
 
    
    
4. Service Definition 
    
   A service is a set of related media processing features with a well-
   defined set of properties.  The defining properties of a service are 
   its SIP URI signature, the MIME types it accepts and any 
   SUBSCRIBE/NOTIFY [4] event packages it supports.  The SIP URI 
   signature consists of the service indicator, instance ID and any 
   associated URI parameters. 
    
   Services MUST have a unique SIP URI signature.  Services MAY offer 
   support for MIME types other than "application/sdp" and 
   SUBSCRIBE/NOTIFY event packages if required to implement service 
   features. 
    
   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 
   processing services may be thought of as user automatons that 
   participate in SIP sessions. It naturally follows that the user 
   address, or the left-hand-side of the URI, should be utilized as a 
   service indicator. 
    
   Media servers commonly offer multiple services at a single host 
   address.  Use of the user part as a service indicator enables 
   service consumers to direct their requests without ambiguity.  It 
   has the added benefit of enabling media services to register their 
   availability with SIP Registrars just as any "real" SIP user would.  
   This maintains consistency and provides enhanced flexibility in the 
   deployment of media services in the network. 
    
   For per-service security, the media server MAY use any of the 
   security protocols described in [2]. 
    
   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. 
 
    
5. Service Indicators and URI Signatures 
    
   The service indicator is the concatenation of the service name and 
   an optional service instance identifier, separated by an equal sign.  
   The service name MAY be modified by an optional service namespace.   
    
   There has been much discussion about the potential for confusion if 
   media services URIs are not readily distinguishable from other types 
   of SIP UA's.  The use of a service namespace provides a mechanism to 
   unambiguously identify standard interfaces while not constraining 
   the development of private or experimental services.  
  
Van Dyke                  Expires 5/21/2002                         3 
                   SIP Media Server URI Conventions      November 2001 
 
 
   It is proposed that standard services, such as the announcement and 
   conferencing services described here, be registered with IANA using 
   the "org.iana" service namespace. 
    
   Service developers MAY use a service namespace other than "org.iana" 
   for private or experimental services.  
    
   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. 
    
   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. 
    
    
6. Operation 
    
   The requesting client issues a SIP INVITE to the media server, 
   specifying the requested service and any appropriate parameters. 
    
   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, 606 is not 
   appropriate, as some other media server may be able to satisfy the 
   request.  [2] describes the 488 and 606 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 
  
Van Dyke                  Expires 5/21/2002                         4 
                   SIP Media Server URI Conventions      November 2001 
 
 
   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.  
     
    
7. Formal Syntax 
    
   The following syntax specification uses the augmented Backus-Naur 
   Form (BNF) as described in RFC-2234 [6]. 
 
   SERVICE-URL     = "sip:" [srvc-namespace] srvc-ind "@" hostport 
                          url-parameters [headers] 
    
   srvc-namespace  = ("org.iana" "." | 1*nmspc-part) 
    
   nmspc-part      = 1*(ALPHA | DIGIT) "." 
    
   srvc-ind        = srvc-name [ "=" instanceId ]  
    
   srvc-name       = "annc" | "conf" | token 
    
   instanceId      = token 
    
   Section 2 of [2] defines the elements hostport and token.  See the 
   IANA Considerations section for procedures for adding new service 
   indicators. 
    
    
8. Security Considerations 
 
   The security issues are the same as for SIP [2], as the media server 
   is simply a SIP User Agent. 
    
    
9. 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 [7], this repository is "Specification Required by RFC."  
   The documents [8] and [10] describe the initial values for the 
   repository.  For reference, the values are as follows. 
    
   NOTE: Drafts describing service indicators for conferencing, 
   transcoding and IVR are currently being developed. 
    
    
  
Van Dyke                  Expires 5/21/2002                         5 
                   SIP Media Server URI Conventions      November 2001 
 
 
   SIP Media Server Service Indicator Types 
   ======================================== 
    
   Value   Meaning                Reference 
   -----   --------------         --------- 
                   Parameter     Values 
                   -----------   ------ 
   annc    Announcement Service   draft-burger-sipping-netann-01.txt 
                   play=         URI or provisioned sequence identifier 
                   early=        ( "yes" | "no" ) 
                   repeat=        Integer, number of repetitions 
                   delay=         Integer, delay between repetitions 
                   duration=      Integer, max. prompt duration 
                   locale=       Language and country codes 
                   param[n]=      Variable values to be substituted in               
                   a sequence                            
 
   conf    Conference Service                      
                   <none> 
    
    
10. 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. 
    
    
10.1. Announcement 
    
   The document [8] 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 service has 
   several associated parameters that control the content and delivery 
   of the announcement. 
    
   In the following example, the media server at ms2.carrier.net 
   retrieves an audio file using HTTP [9] 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 
    
    
  
Van Dyke                  Expires 5/21/2002                         6 
                   SIP Media Server URI Conventions      November 2001 
 
 
10.2. Conference 
    
   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 
    
   NOTE: A draft describing the conference service in detail is in 
   progress. 
    
     
 
11. 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", draft-ietf-sip-rfc2543bis-03.txt, 
      May 2001, work in progress. 
    
   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997. 
 
   4  Roach, A., "SIP-Specific Event Notification, "draft-ietf-sip-
      events-01.txt, November 2001, work in progress. 
    
   6  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
      Specifications: ABNF", RFC 2234, November 1997. 
    
   7  Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA 
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
    
   8  O'Connor, W., Burger, E., "Network Announcements with SIP", 
      draft-burger-sipping-netann-01.txt, November 2001, work in 
      progress. 
    
   9  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. 
    
 
  
Van Dyke                  Expires 5/21/2002                         7 
12. Changes Made in Version 01 
     o Added additional explanatory text to explain motivations for 
        use of service indicators and benefits of the proposed format. 
     o Updated description of the announcement service to be 
        consistent with draft-burger-sipping-netann-01.txt. 
     o Proposed an option for implementing a namespace for service 
        indicators.   
    
 
13. Acknowledgments 
    
   We would like to offer our thanks to Jonathan Rosenberg of 
   dynamicsoft for his constructive comments. 
    
    
14. Author's Addresses 
    
   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               Draft û Expires 5/21/02                      8 
                   SIP Media Server URI Conventions      November 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 5/21/2002                         9