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]