Internet DRAFT - draft-hoeneisen-sip-proxy-supported
draft-hoeneisen-sip-proxy-supported
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]
