Internet Engineering Task Force                                   SIP WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-sip-serverfeatures-02.txt             dynamicsoft,Columbia U.
March 5, 2000
Expires: September, 2000


                        The SIP Supported Header

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

   The Session Initiation Protocol (SIP) provides a mechanism that
   allows a client to request that a particular protocol extension be
   used to process the request. The server declines the request if it
   does not support the extension. However, there is currently no way
   for a server to determine which extensions are supported by the
   client. Knowing about client-supported extensions allows the server
   to tailor its response accordingly. Furthermore, SIP does not define
   a way for a client to query a server about the extensions it
   supports. This document defines a SIP extension that allows clients
   to indicate, in a request, the set of extensions supported. We also
   define a mechanism that allows clients, through an OPTIONS request,
   to determine the extensions supported by a server.


1 Introduction



J.Rosenberg,H.Schulzrinne                                     [Page 1]


Internet Draft                 supported                   March 5, 2000


   The Session Initiation Protocol (SIP) [1] defines the Require and
   Proxy-Require request headers that indicate to the server that it
   should only process the request if it supports the features
   enumerated. These headers include option tags. A UAS or proxy,
   respectively, must understand the option tags in order to process a
   request.

   However, SIP provides no support for the reverse case. In this case,
   a server wants to use a extension to process a request, but must
   determine if the client supports it. In this scenario, the client
   does not ask for the given extension, but the server wants to use the
   extension in the response. As the response cannot be processed
   without understanding this extension, the server needs a way to
   determine which extensions are supported by the client. The server
   also needs a way to signal to the client which extensions have been
   applied in the response.

   Very much related to this, there is currently no way for a client to
   query a server to determine which extensions it supports. OPTIONS
   allows a client to query a server about capabilities, such as support
   for various methods and media types. However, the set of supported
   extensions is not among the information returned in an OPTIONS
   response.

   This document defines an extension to SIP that enables the ability
   for clients and servers to indicate support for extensions. This is
   done through a new header, called Supported. Supported, like the
   Unsupported header, contains a list of option tags supported by the
   entity sending the message. This extension also allows the Require
   header to appear in responses. It is used to indicate what options
   must be understood by the UAC in order to process the response.

   It is expected that this extension will be folded into the next
   revision of the SIP specification.

2 Extension Syntax

2.1 Supported Header

   This extension defines a new general header, Supported. The syntax
   for this header is:



        Supported  =  ( "Supported" | "k" ) ":" 0#option-tag


   The BNF for option-tag is given in RFC 2543 [1]. The Supported



J.Rosenberg,H.Schulzrinne                                     [Page 2]


Internet Draft                 supported                   March 5, 2000


   general-header field enumerates all the capabilities of the client or
   server. Clients that support any SIP extensions SHOULD include this
   header in all requests excepting ACK. It MUST be included in the
   response to OPTIONS requests, even if the UAS generating the response
   doesn't support any extensions beyond this one.

   Note that the BNF for the header explicitly allows for zero option
   tags to be present. This will occur when a server responds to an
   OPTIONS request, but it supports no extensions beyond this one
   itself. This is needed to enable backwards compatibility. If the
   response to OPTIONS contains no Supported header at all, it means the
   server may support some extensions, but does not understand the
   Supported header.

   The following defines the entry for the Supported in Table 4 of RFC
   2543. Table 4 lists the places where the Supported may appear:


                       where  enc.  e-e ACK BYE CAN INV OPT REG
            ___________________________________________________
            Supported    g     c     e   -   o   o   o   o   o



   A compact form for the Supported header is defined. This is the
   letter k, for "know".

2.2 Require Header

   This extension also allows for the Require header to appear in
   responses. It is used to indicate what options must be understood by
   the UAC in order to process the response.

   This implies that the row of Table 4 in RFC 2543 defining usage of
   the Require header should read:


                     Require  g   e  o  o  o  o  o  o



2.3 421 (Extension Required) Response

   This extension defines a new response status code - 421. The default
   reason phrase for this status code is "Extension Required". This
   response is used by a server when it needs a particular extension to
   process the request, but this extension is not listed in a Supported
   header in the request. Responses with this status code MUST contain a
   Require header listing the required extensions.


J.Rosenberg,H.Schulzrinne                                     [Page 3]


Internet Draft                 supported                   March 5, 2000


3 Usage in Requests

   All requests, excepting ACK, generated by UACs conformant to this
   specification SHOULD include the Supported header. This header MUST
   list all those extensions supported by the UAC which the UAC is
   willing to apply to the transaction.

   Any server (UAS, proxy, redirect or registrar) that wishes to apply
   some extension to the response, MUST only do so if support for that
   extension is indicated in the Supported header. If the extension is
   essential, and the server cannot send its desired response without
   it, the server MAY send a 421 (Extension Required) response. This
   response indicates that the proper response cannot be generated
   without support of a specific extension. The needed extension(s) MUST
   be included in a Require header in the response.

   If the extension the server wishes to apply to the response is
   supported, the server MUST include a Require header in the response
   listing those extensions it applied to the response.

4 Usage with OPTIONS

   User agent servers compliant to this specification MUST include a
   Supported header in responses to OPTIONS requests. This header MUST
   be present even if the server supports no extensions beyond the one
   specified here. This means that the Supported header may be empty in
   the response.

   Clients MUST NOT treat absence of the Supported header in an OPTIONS
   response to mean no extensions are supported. The presence of an
   empty Supported header implies no extensions are supported.

5 Example Usage

   This section gives an example call flow using this extension. UAC A
   sends a request to UAS B. UAS B wishes to apply extension foo to the
   response. Two cases are shown. In the first, foo is supported by A,
   and in the second, is not.

5.1 A supports foo

   The initial INVITE from A looks like (SDP omitted for clarity):



   A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         Supported: foo



J.Rosenberg,H.Schulzrinne                                     [Page 4]


Internet Draft                 supported                   March 5, 2000


         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE
         Subject: Venture Capital



   Since the desired extension is supported, B applies it to the
   response (in this case, a redirect), and includes a Require header
   indicating that the extension has been applied.



   B->A: SIP/2.0 300 Moved
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         Require: foo
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com;tag=443322
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE
         Foo: 9998h7asdh9



   and A sends an ACK:



   C->S: ACK sip:jtoto@dynamicsoft.com SIP/2.0
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com;tag=443322
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 ACK



   Note that the Supported header is not included in the ACK.

5.2 A doesn't support foo

   In this case, A doesn't support foo. It supports some other
   extension, bar. The server wishes to apply foo, and is not willing to
   proceed without it. So, it rejects the request.

   A doesn't support foo, so it resubmits the request with an
   Unsupported header included:



J.Rosenberg,H.Schulzrinne                                     [Page 5]


Internet Draft                 supported                   March 5, 2000


   A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         Supported: bar
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE
         Subject: Venture Capital





   B->A: SIP/2.0 421 Extension Required
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         Require: foo
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com;tag=98765
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE



   a sends an ACK:



   A->B: ACK sip:jtoto@dynamicsoft.com SIP/2.0
         Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com;tag=98765
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 ACK



6 Security Considerations

   This extension introduces no new security considerations beyond those
   discussed in RFC 2543 [1].

7 Author's Addresses



   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive



J.Rosenberg,H.Schulzrinne                                     [Page 6]


Internet Draft                 supported                   March 5, 2000


   Suite 120
   West Orange, NJ 07052
   email: jdrosen@dynamicsoft.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu




8 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments (Proposed
   Standard) 2543, Internet Engineering Task Force, Mar. 1999.
































J.Rosenberg,H.Schulzrinne                                     [Page 7]