Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne draft-ietf-sip-serverfeatures-00.txt dynamicsoft,Columbia U. January 16, 2000 Expires: July, 2000 Mandating SIP Extension Support by Servers 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 ask for, and a client to indicate, what features a server might use in a response. This capability is needed for numerous extensions currently under development, such as provisional response reliability and the session progress message. This document defines a SIP extension that allows servers to mandate that clients understand certain features in order to process a response. 1 Introduction The Session Initiation Protocol (SIP) [1] defines mechanims that allow a client to mandate that a server support specific extensions J.Rosenberg,H.Schulzrinne [Page 1]
Internet Draft supported January 16, 2000 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, where a server wants to use a feature in a response. 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. This document defines an extension to SIP that enables this capability, which we call server side feature extensions. The extension is backwards compatible with existing SIP implementations. 2 Protocol Overview This extension defines a new request header, called Supported. The Supported header is similar to the Require header. It contains a list of option tags. However, these option tags are a list of those features that the user agent supports, not those which are needed to process the request. The SIP specification only allows the Unsupported header in responses. In this document, we propose to also allow it to appear in requests. When used in a request, it indicates features that the UAC is unable to understand or unwilling to process. Similarly, the SIP specification only allows the Require heder in requests. In this document, we propose to also allow it to appear in responses. When used in 421 responses, it indicates the feature needed by the server, and in all other responses, indicates the feature used. When a request arrives at a server, and the server wishes to use a feature in a response, the server checks the Supported header. If the Supported header is present, and indicates support for the feature, the server can go ahead and use it in the response. If the Unsupported header is present, and indicates that the feature is not supported, the server can reject the request or process it without the feature. If neither case is true (the feature is not listed in either header), but the client understands server side feature extensions (as indicated in the Supported header), the server rejects the request with a new response code, 421 Feature Required. The 421 response contains a Require header listing the features required by the server. If the client supports the feature that the server has asked for, it J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft supported January 16, 2000 adds the named feature to the Supported header, and resubmits the request with a higher CSeq number. If the client does not support the feature that the server has asked for, it adds the named feature to the Unsupported header, and resubmits the request with a higher CSeq number. 3 Protocol Syntax This extension defines a new general header, Supported. The syntax for this header is: Supported = ( "Supported" | k ) ":" 1#option-tag The BNF for option-tag is given in RFC 2543 [1]. The Supported header contains a list of features supported by a UAC. A compact form for the Supported header is defined. This is the letter k, for "know". This extension also allows the Unsupported header to be used as a request header in addition to a response header, and the Require header to be used as a response header in addition to a request header. The usage of these headers in their new roles is discussed in the sections below on UAC behavior. 4 Detailed Protocol Semantics This section overviews the detailed protocol semantics of this extension. 4.1 UAC Behavior UACs that support this extension MUST include the Supported header in every request they generate, with the exception of ACK and CANCEL. The Supported header MUST, at least, indicate the option tag org.ietf.sip.supported. This option tag indicates support for the extension defined in this document. We could treat the presence of the Supported header itself as an indication of support for this extension. However, some implementations may treat a header with no value as the same as if the header were not present. Furthermore, if the Supported is used for some other purpose, it would not be clear whether this extension was supported. On the other J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft supported January 16, 2000 hand, since Supported is a new header, we could specify that its presence with no value is not the same as its absence. Having the option tag org.ietf.sip.supported in every Supported header is wasteful. A UAC MAY include other option tags, indicating support for other features, in the Supported header of an initial request, at their discretion. These option tags SHOULD only be for features and extensions that require the server to place additional information in responses. An example of such an extension is reliability of provisional responses [2]. Typically, a UAC would insert option tags for the most commonly used features. If the option tag is present in an initial request, one round trip time of protocol messaging can be avoided. Advanced clients might keep track of features that are requested by servers, and dynamically decide on the top three, which are then inserted into all requests. As an alternative, the UAC might cache features that were requested for a particular request URI, and place those in subsequent requests for the same URI. An initial request MAY contain an Unsupported header, listing those features that the UAC does not support. A UAC may know apriori that it doesn't support a feature. Or, this information can be gleaned by caching option tags from error responses to previous requests. If the UAC receives a 421 response to the request, the UAC needs to resubmit the request. The resubmitted request MUST have a higher CSeq value. The UAC MUST follow the following procedure which may result in the insertion of Supported and Unsupported headers into the resubmitted request. The UAC checks for the presence of the Require header in the 421 response. The Require header contains a list of option tags. Call this list L. For each option tag in L, the UAC checks whether it knows the named feature or not. If the feature is known, the UAC MUST insert the option tag into a Supported header in the resubmitted request. If the feature is not known, the UAC MUST insert the option tag into the Unsupported header in the resubmitted request. If the resubmitted request is rejected once more with a 421, the process above repeats only if the set L in this response is not equal to, or not a subset of, the set L in a previous 421 response. For any other final response, the response will contain a Require header indicating which features are needed to process that final response. If the protocol mechanisms followed here are operating correctly, these features will only be among the set supported by the UAC. If that is not the case, the client SHOULD resubmit the request as if it were a 421 response. J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft supported January 16, 2000 4.2 Server Behavior The behavior of a server is independent of whether the server is a proxy, redirect server, or UAS. The reason is that this extension only applies to features needed to process a response; the type of server that generates the response is irrelevant. If a server receives a request, and wishes to apply some features in a response, and these features do not operate correctly if not understood by the client, the rules in this section apply. If the request does not contain a Supported header, or it contains a Supported header, but this header does not indicate support for the feature org.ietf.sip.supported, the server MUST NOT attempt to send a response with the desired features. If the request contains an Unsupported header, and this header lists the names of any of the desired features, the server MUST NOT attempt to send a response with the desired features. If the request contains a Supported header, and the header lists the names of all the desired features, the server MAY send a response using the desired features. This response MUST include a Require header indicating those features applied to the response which are mandatory in order to process it. If the Supported header is present in a request, and indicates support for the feature org.ietf.sip.supported, but the desired features are not indicated in either the Supported or Unsupported header, the server MAY reject the request with a 421 "Feature Required" response. This response MUST include a Require header, indicating the set of features that the server wishes to apply. Alternatively, the server MAY process the request and send a response without the desired features. 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 com.dynamicsoft.foo to the response. When it discovered that A doesn't support feature com.dynamicsoft.foo, it tries to provide feature com.dynamicsoft.bar. As com.dynamicsoft.bar is supported, B applies feature bar and sends a 300 response. 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: org.ietf.sip.supported J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft supported January 16, 2000 From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 1 INVITE Subject: Venture Capital B then sends a 421 response: B->A: SIP/2.0 421 Feature Required Via: SIP/2.0/UDP bigmachine.dynamicsoft.com Require: com.dynamicsoft.foo From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com;tag=443322 Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 1 INVITE 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 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: org.ietf.sip.supported Unsupported: com.dynamicsoft.foo From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 2 INVITE Subject: Venture Capital J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft supported January 16, 2000 B then decides to apply feature com.dynamicsoft.bar instead, given com.dynamicsoft.foo is not supported: B->A: SIP/2.0 421 Feature Required Via: SIP/2.0/UDP bigmachine.dynamicsoft.com Require: com.dynamicsoft.bar From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com;tag=98765 Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 2 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: 2 ACK and then resubmits the request, indicating that com.dynamicsoft.bar is supported: A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com Supported: org.ietf.sip.supported, com.dynamicsoft.bar From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 3 INVITE Subject: Venture Capital now, B includes the com.dynamicsoft.bar header in the response, in addition to a Require header indicating com.dynamicsoft.foo: J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft supported January 16, 2000 B->A: SIP/2.0 300 Moved Via: SIP/2.0/UDP bigmachine.dynamicsoft.com Require: com.dynamicsoft.bar From: sip:jdrosen@dynamicsoft.com To: sip:jtoto@dynamicsoft.com;tag=12345 Call-ID: 70710@bigmachine.dynamicsoft.com Bar: IgnoreContact;newname=''Jack Toto'' Contact: sip:jack_toto@yahoo.com CSeq: 3 INVITE finally, 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=12345 Call-ID: 70710@bigmachine.dynamicsoft.com CSeq: 3 ACK 6 Security Considerations This extension introduces no new security considerations beyond those discussed in RFC 2543 [1]. 7 Open Issues 1. The current specification does not support extensions which require a proxy to modify responses as they travel along. This can probably be added without too much complexity. Is this a useful function. 2. Proxy-Require is not used; it doesn't seem necessary. It doesn't matter whether the endpoint generating a response is a proxy or UAS. Is that OK? 3. Do we need the Require header in the final non-421 response to indicate what features were finally applied? 4. Should we remove org.ietf.sip.supported and have the presence of the Supported header alone indicate support for this extension? J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft supported January 16, 2000 8 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 9 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. [2] J. Rosenberg and H. Schulzrinne, "Reliability of provisional responses in SIP," Internet Draft, Internet Engineering Task Force, Dec. 1999. Work in progress. J.Rosenberg,H.Schulzrinne [Page 9]
