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]
