Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne draft-ietf-sip-serverfeatures-05.txt dynamicsoft,Columbia U. July 20, 2001 Expires: February, 2002 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 To view the list Internet-Draft Shadow Directories, see 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 July 20, 2001 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 July 20, 2001 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. When used in a request, the option-tags listed MUST only refer to extensions defined in standards track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header in a request, since they too are often used to document vendor defined extensions. 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 J.Rosenberg,H.Schulzrinne [Page 3] Internet Draft supported July 20, 2001 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. In general, a server SHOULD NOT use this response when it wishes to apply an extension to a request. The end result will often be no service at all, and a break in interoperability. Rather, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client. 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 desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. To ensure that the SHOULD can be fulfilled, any specification of a new extension MUST include discussion of how to gracefully return to baseline SIP when the extension is not present. In rare circumstances, where the server cannot process the request without the extension, 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. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header in the request. As a result of this, the Require header in a response will only ever contain option tags defined in standards track RFCs. 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 J.Rosenberg,H.Schulzrinne [Page 4] Internet Draft supported July 20, 2001 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 Usage in Responses The Supported header MAY be included in responses to any request, not just OPTIONS. The semantics are identical to the case of an OPTIONS response - it indicates the extensions supported by the UAS. It is particularly useful in responses to INVITE, allowing the UAC what extensions can be used for the remainder to the call. It is effectively an optimization that avoids the need for the additional OPTIONS message. 6 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. 6.1 A supports foo The initial INVITE from A looks like (SDP omitted for clarity): A->B: INVITE sip:jtoto@example.com SIP/2.0 Via: SIP/2.0/UDP bigmachine.example.com Supported: foo From: sip:jdrosen@example.com;tag=78a669 To: sip:jtoto@example.com Call-ID: 70710@bigmachine.example.com Contact: sip:jdrosen@bigmachine.example.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. J.Rosenberg,H.Schulzrinne [Page 5] Internet Draft supported July 20, 2001 B->A: SIP/2.0 300 Moved Via: SIP/2.0/UDP bigmachine.example.com Require: foo From: sip:jdrosen@example.com;tag=78a669 To: sip:jtoto@example.com;tag=443322 Call-ID: 70710@bigmachine.example.com Contact: sip:jtoto@university.edu CSeq: 1 INVITE Foo: 9998h7asdh9 and A sends an ACK: C->S: ACK sip:jtoto@example.com SIP/2.0 Via: SIP/2.0/UDP bigmachine.example.com From: sip:jdrosen@example.com;tag=78a669 To: sip:jtoto@example.com;tag=443322 Call-ID: 70710@bigmachine.example.com CSeq: 1 ACK Note that the Supported header is not included in the ACK. 6.2 OPTIONS Usage In this case, the Supported header is included in the response to an OPTIONS request. The response also indicates that the UAS supports the INFO method [2], but not the REGISTER method, and understands sdp in addition to plain text. A->B: OPTIONS sip:jtoto@example.com SIP/2.0 Via: SIP/2.0/UDP bigmachine.example.com From: sip:jdrosen@example.com;tag=55a66b To: sip:jtoto@example.com Call-ID: 70710@bigmachine.example.com CSeq: 1 OPTIONS B->A: SIP/2.0 200 OK J.Rosenberg,H.Schulzrinne [Page 6] Internet Draft supported July 20, 2001 Via: SIP/2.0/UDP bigmachine.example.com From: sip:jdrosen@example.com;tag=55a66b To: sip:jtoto@example.com;tag=98765 Call-ID: 70710@bigmachine.example.com CSeq: 1 OPTIONS Supported: foo, bar Accept: application/sdp, text/plain Allow: INVITE, ACK, CANCEL, OPTIONS, INFO 7 Security Considerations This extension introduces no new security considerations beyond those discussed in RFC 2543 [1]. 8 IANA Requirements Extensions referred to by the Supported header make use of SIP option tags. IANA procedures for these tags are defined in Section 4.4.1 of RFC 2543 [1]. 9 Author's Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive 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 10 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. J.Rosenberg,H.Schulzrinne [Page 7] Internet Draft supported July 20, 2001 [2] S. Donovan, "The SIP INFO method," Request for Comments 2976, Internet Engineering Task Force, Oct. 2000. J.Rosenberg,H.Schulzrinne [Page 8]