[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Internet Engineering Task Force                                   SIP WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-sip-serverfeatures-01.txt             dynamicsoft,Columbia U.
February 28, 2000
Expires: August, 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) defines mechanims that allow a
   client to mandate that a server support specific extensions in order
   to process a request. However, there is currently no way for a server
   to determine what features are supported in a client, in order to use
   those features to process the request. This capability is needed for
   numerous extensions currently under development, such as provisional
   response reliability and the session progress message. We also note
   that there is currently no way for a client to query a server about
   the features it supports. This document defines a SIP extension that
   allows clients to indicate, in a request, the set of features
   supported. We also define a mechanism that allows clients, through an
   OPTIONS request, to determine the features supported by a server.


1 Introduction



J.Rosenberg,H.Schulzrinne                                     [Page 1]


Internet Draft                 supported               February 28, 2000


   The Session Initiation Protocol (SIP) [1] defines mechanims that
   allow a client to mandate that a server support specific extensions
   in order to process a request. This is accomplished through the
   Require and Proxy-Require headers. 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 feature to process a request, but must
   determine if the client supports it. In this scenario, the client
   does not ask for the given feature, but the server wants to use the
   feature in the response. As the response cannot be processed without
   understanding this feature, the server needs a way to determine which
   features are supported by the client. The server also needs a way to
   signal to the client which features 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 features 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
   features 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 features. 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 Header 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               February 28, 2000


   general-header field enumerates all the capabilities of the client or
   server. This header field SHOULD be included in all requests (except
   ACK) generated by clients conforming to this specification, if those
   clients support any extensions. 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

   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



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 features supported by the UAC which the UAC is willing
   to apply to the transaction.



J.Rosenberg,H.Schulzrinne                                     [Page 3]


Internet Draft                 supported               February 28, 2000


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

   If the feature the server wishes to apply to the response is
   supported, the server MUST include a Require header in the response
   listing those features 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 features/extensions beyond
   the one specificed 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 feature 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
         From: sip:jdrosen@dynamicsoft.com
         To: sip:jtoto@dynamicsoft.com
         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE
         Subject: Venture Capital





J.Rosenberg,H.Schulzrinne                                     [Page 4]


Internet Draft                 supported               February 28, 2000


   Since the desired feature is supported, B applies it to the response
   (in this case, a redirect), and includes a Require header indicating
   that the feature 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 feature,
   bar. The server wishes to apply foo, and is not willing to proceed
   without it. So, it rejects the request.

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



   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



J.Rosenberg,H.Schulzrinne                                     [Page 5]


Internet Draft                 supported               February 28, 2000


         Call-ID: 70710@bigmachine.dynamicsoft.com
         CSeq: 1 INVITE
         Subject: Venture Capital





   B->A: SIP/2.0 421 Feature 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
   Suite 120
   West Orange, NJ 07052
   email: jdrosen@dynamicsoft.com

   Henning Schulzrinne



J.Rosenberg,H.Schulzrinne                                     [Page 6]


Internet Draft                 supported               February 28, 2000


   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]