Internet Engineering Task Force Bernie Hoeneisen Internet Draft Markus Isomaki draft-hoeneisen-sip-proxy-supported-00.txt Krisztian Kiss Expires: January 2002 Nokia July 2001 The SIP Proxy-Supported header field 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. This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract The Session Initiation Protocol (SIP) provides a mechanism that allows a User Agent Client (UAC) to request that a particular protocol extension has to be used to process the request. The User Agent Server (UAS) declines the request if it does not support the extension. Recently also means have been defined for the User Agent Server (UAS) to determine which extensions are supported by the User Agent Client (UAC). Furthermore there are also means for requiring proxy servers to understand certain features. Hoeneisen/Isomaki/Kiss Internet Draft [Page 1] Internet-Draft The SIP Proxy-Supported header field July 2001 However, there is currently no way for a User Agent (UA) to determine Which extensions are supported by all the intermediate proxy servers that remain in the signaling path for subsequent requests within a particular call leg. Knowing about proxy-supported extensions would allow the UA to tailor its subsequent requests accordingly. This document defines a SIP extension that allows UACs to indicate in a request set of extensions. All the intermediate proxy servers, which insert themselves into the Record-Route, have to indicate their support for the extension requested by the UAC. This information then can be used when deciding which features to use for SUBSEQUENT requests. Features determined by this extension can be e.g. new methods, which require special handling in proxy servers. 1 Introduction The Session Initiation Protocol (SIP) [1][2] defines the Require and Proxy-Require request header fields that indicate to the UAS and proxy server, respectively, that it should only process the request, if it supports the features enumerated. The features are listed in the headers as option tags. A UAS or proxy, respectively, must understand the option tags in order to process a request. Recently also means have been defined to allow UAS to determine which extensions are supported by the UAC (Supported header field) [3][2]. However, currently SIP provides no mechanism for User Agents to determine the capabilities of the intermediate proxy servers to be used for subsequent requests. In this scenario a UA wants to use a certain extension in a subsequent request, but the UA needs to determine first if all the intermediate proxy servers have the support for it. As certain subsequent requests cannot be processed correctly in the intermediate proxy servers without understanding the extension, the UA needs a way to determine which extensions are supported by the intermediate proxy servers. Hoeneisen/Isomaki/Kiss Internet Draft [Page 2] Internet-Draft The SIP Proxy-Supported header field July 2001 The main differences between the Proxy-Require [1][2] and the herein defined Proxy-Supported mechanism are that the Proxy-Supported allows a request to go through, even if an intermediate proxy server does not support an extension indicated; i.e. no 420 Bad Extension is sent as with Proxy-Require. The extensions indicated in Proxy-Supported do not apply to the request carrying it, but only to subsequent requests within the same call leg, and are thus relevant only to record-routing proxies. Even if some of the record-routing proxies do not support all the enumerated extensions, e.g. session initiation can continue, although without the unsupported extensions. This document defines an extension to SIP that enables the ability for UACs to indicate which extensions are supported by all record-routing proxy servers within a call leg. This is done through a new header field, called Proxy-Supported and an extension parameter used in the Record-Route header field. Similarly to the Supported header defined in [3][2], the Proxy-Supported header field, inserted by the UAC, contains a list of option tags. Every record-routing proxy server in the signalling path removes option tags, which it does not support, from the list in the Proxy-Supported header field. The features indicated by the tags still remaining in the header after UAS has processed it are thus supported by the whole "signaling path". As UAS mirrors the header in responses, UAC will learn this information as well. However, there are some backwards compatibility issues with record-routing proxy servers and UASs that do not know how to treat the Proxy-Supported header field. This problem is solved in a way that every record-routing proxy server understanding Proxy-Supported extension indicates this in Record-Route parameter. The lack of the parameter leads to the deletion of Proxy-Supported header in the next proxy-server (or UAS) understanding it. If UAS does not implement Proxy-Supported extension, it will not mirror the header field in responses. The lack of the header field in responses indicates to the UAC that it cannot use any of the listed extensions. Hoeneisen/Isomaki/Kiss Internet Draft [Page 3] Internet-Draft The SIP Proxy-Supported header field July 2001 An example utilization of the extension can be found in [6], where an alternative way of providing reliable provisional responses compared to [7] is described. The solution is based on a new method, which proxies need to handle with special rules. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations. 3 Extension Syntax 3.1 Proxy-Supported Header Field This extension defines a new general header field, Proxy-Supported. The syntax for this header field is: Proxy-Supported = "Proxy-Supported" ":" 1#option-tag The BNF [5] for option-tag is given in RFC 2543 [1]. In principle, the Proxy-Supported general-header field enumerates all the capabilities supported by every intermediate proxy server, which insert itself to the Record-Route header field. The UAC, which consider support of certain features of subsequent requests in all intermediate record-routing proxy servers, MAY include this header field in requests. The UAS understanding Proxy-Supported MUST mirror this header field from the request to the response. Each proxy server, which understands the Proxy-Supported header field and inserts itself in the Record-Route header, MUST remove all option-tags, which it does not support. If no option-tag is left, the proxy server MUST remove the whole Proxy-Supported header field. Hoeneisen/Isomaki/Kiss Internet Draft [Page 4] Internet-Draft The SIP Proxy-Supported header field July 2001 To ensure backwards compatibility, i.e. one or more proxy servers do not understand the Proxy-Supported header field, special means have to be applied. In principle each server (proxy and UAS) checks, whether the last record-routing proxy server supports the herein described feature. Therefore, the usage of the proxy-supported extension parameter for the Record-Route header field is introduced in section 3.2 The following defines the entry for the Proxy-Supported as in Table 4/5 of [2]. Table 1 lists the places where the Proxy-Supported may appear: where proxy ACK BYE CAN INV OPT REG ____________________________________________________ Proxy-Supported gc(*) mr - - - o o o (*) proxy servers MUST NOT insert this header field to its own responses Table 1: Places of Proxy-Supported 3.2 Proxy supported extension parameter for Record-Route This extension defines a new extension parameter for Record-Route, called proxy-supported-param. The syntax for this extension parameter is: rr-param = generic-param | proxy-supported-param proxy-supported-param = "proxy-supported=" "yes" The proxy-supported extension parameter is used together with the Proxy-Supported header field. If the Proxy-Supported and at least one Record-Route header field are present in a request, every proxy server and finally the UAS, which understands the Proxy-Supported header field MUST check, whether the last proxy server, which inserted a Record-Route, supports this feature. If no Record-Route has been inserted so far, no checking is required. The checking is done as follows: If the topmost Record-Route header field does not contain the proxy-supported extension parameter, the Proxy-Supported header field is removed before further processing of the message. As long as the Proxy-Supported header field is present (and understood by the proxy server), a record-routing proxy server inserts a proxy-supported extension parameter in its own Record-Route entry of a request. Hoeneisen/Isomaki/Kiss Internet Draft [Page 5] Internet-Draft The SIP Proxy-Supported header field July 2001 4 Detailed Protocol Semantics In this section the detailed behavior required from user agent clients, user agent servers, and proxies are discussed in order to implement this extension. 4.1 UAC Behavior If the UAC wishes to determine and inform the UAS, whether all intermediate record-routing proxy server support one more features, it places the corresponding option tag(s) in a Proxy-Supported header field of the initial request. If any feature indicated in the Proxy-Supported header field in the request requires also support in the UAC (in addition to the intermediate proxy servers), a UAC MAY include the corresponding option-tags also in the Supported header field in the request. It is useful to indicate that this feature can be used in subsequent requests issued by the other UA. If a UAC wants to use such a feature in a subsequent request within the same call leg, it has to ensure, that the corresponding option-tag was present in the Proxy-Supported header field of the last response, from which the UAC uses the Record-Route entries to construct the Route header field. For details how to construct the Route header field see [2, section 16]. If the feature requires also support in the UAS (in addition to the intermediate proxy servers), a UAC MUST ensure, that its support has been indicated in the Supported header field of the response. Hoeneisen/Isomaki/Kiss Internet Draft [Page 6] Internet-Draft The SIP Proxy-Supported header field July 2001 4.2 UAS Behavior If the Proxy-Supported and at least one Record-Route header field are present in a request, the UAS supporting the Proxy-Supported extension MUST check whether the last proxy server, which inserted a Record-Route, supports this feature as follows: If the topmost Record-Route header field does not contain the proxy-supported extension parameter, the Proxy-Supported header field is removed before further processing of the message. The rest of this discussion assumes, that the Proxy-Supported header field is still present, i.e. not removed by the above described checking. The Proxy-Supported header field MUST be mirrored from the request to every 2xx and 1xx (except 100 Trying) response. The UAS MAY mirror the Proxy-Supported header field also to other responses if this is considered useful. If any feature indicated in the Proxy-Supported header field in the response requires also support in the UAS (in addition to the intermediate proxy servers), a UAS MAY include the corresponding option-tags also in the Supported header field in the responses. It is useful to indicate that this feature can be used in subsequent requests issued by the UAC corresponding to this UAS. If a UAS wants to use such a feature in a subsequent request, it has to ensure, that the corresponding option-tag was present in the Proxy-Supported header field of the initial request. If the feature requires also support in the UAC (in addition to the intermediate proxy servers), a UAS MUST ensure, that its support has been indicated in the Supported header field of the initial request. UASs, which do not understand Proxy-Supported extension, silently discard the Proxy-Supported header and do not mirror it in responses. Hoeneisen/Isomaki/Kiss Internet Draft [Page 7] Internet-Draft The SIP Proxy-Supported header field July 2001 4.3 Proxy Behavior for Requests The following discussion applies only for record-routing proxy servers (whereas other proxy servers behave as in [2]): If the Proxy-Supported and at least one Record-Route header field are present in a received request, a record-routing proxy server supporting Proxy-Supported extension MUST check, whether the last proxy server, which inserted a Record-Route, supports this feature as follows: If the topmost Record-Route header field does not contain the proxy-supported extension parameter, the Proxy-Supported header field is removed before further processing of the message. The rest of this discussion assumes, that the Proxy-Supported header field is still present, i.e. not removed by the above described checking. A record-routing proxy server MUST check for every option-tag listed in the Proxy-Supported header field, whether it supports the extension identified by it. Option-tags for extensions, which the proxy server does not support, MUST be removed from the Proxy-Supported header field. If no option-tag is left after removal, the proxy server MUST remove the whole Proxy-Supported header field. If the Proxy-Supported header field is still present, i.e. not removed by any of the above steps, a record-routing proxy server MUST insert a proxy-supported extension parameter in its own Record-Route entry placed into the request. Proxy servers, which do not understand Proxy-Supported extension, forward the request unmodified. The same applies to any proxy server that does not insert itself into the Record-Route header field. It is assumed that subsequent requests within a particular call leg are always routed strictly according to the Route header, i.e. no additional (stateful) proxies are traversed. If this is not the case, a proxy server or UA violating the rule MUST know the capabilities of the additional proxy servers beforehand or remove the Proxy-Supported header. Hoeneisen/Isomaki/Kiss Internet Draft [Page 8] Internet-Draft The SIP Proxy-Supported header field July 2001 4.4 Proxy Behavior for Responses Concerning the Proxy-Supported extension, the proxy behavior for responses equals as it is described in [2]. A possible Proxy-Supported header field is forwarded downstream. Note: If the proxy server issues its own response, the Proxy-Supported header field MUST NOT be present in those responses. 5 Security Considerations This extension introduces no new security considerations beyond those discussed in RFC 2543 [1][2]. 6 Acknowledgements The authors would like to thank Pekka Pessi for the comments on this document. 7 Author's Addresses Markus Isomaki Nokia Research Center Ruoholahti 1/B6 P.O. Box 407 FIN-00045 NOKIA GROUP email: markus.isomaki@nokia.com Hoeneisen/Isomaki/Kiss Internet Draft [Page 9] Internet-Draft The SIP Proxy-Supported header field July 2001 Bernie Hoeneisen Nokia Networks Valimo 13B/3 P.O. Box 314 FIN-00045 NOKIA GROUP email: bernhard.honeisen@nokia.com Krisztian Kiss Nokia Research Center Visiokatu 1 P.O. Box 100 FIN-33721 TAMPERE email: krisztian.kiss@nokia.com 8 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. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol" (RFC2543bis-03), Internet Draft, Internet Engineering Task Force, May 2001. Work in progress. Hoeneisen/Isomaki/Kiss Internet Draft [Page 10] Internet-Draft The SIP Proxy-Supported header field July 2001 [3] J. Rosenberg and H. Schulzrinne, "The SIP supported header" Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [4] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [5] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [6] B. Hoeneisen, M. Isomaki, K. Kiss, "Simple Reliability of Provisional Responses in SIP" Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [7] H. Schulzrinne, J. Rosenberg, "Reliability of Provisional Responses in SIP", Internet Draft, Internet Engineering Task Force, March 2001. Work in progress Hoeneisen/Isomaki/Kiss Internet Draft [Page 11]